無理難題 [システム]
ある大規模営業所でループが発生して90台のPCが使えない状況が発生しています。
構成はこんな感じ
ループが発生しているのは右側のLANの部分です。
ここを切り離すと残りの端末は全て正常に使えます。
LANは営業所で作ったLANなので担当職員に保守業者を呼んで来たらセンターと一緒に切り分けをしましょう。と言っていたのですが
線をひっぱった電線屋さんだけを呼んで「断線はありません」と言われて帰してしまったみたいです。
そして副所長さんからセンターの担当部署にお手上げ宣言をしてきたら何を思ったかセンター担当部署の課長がいつものように大騒ぎ
朝の4時からセンターで7時までに富士通を手配して直させろ!
担当外だからと言ったんですが これはセンターの問題だ いいから呼べ 手配しろ!
また無茶を まあ 富士通を拝み倒してなんとか7:30から入ってもらってFSASが作ったLANのHUBに刺さっているLANケーブルを1本づつ調べてもらいましたが、9:30には「もうこれ以上調べられません。作ったところに直してもらってください」と断られてしまいました。
それを課長に言ったら 切れて センターは仕事をしていない。全部見させればいいだろう。同じ富士通だ全部やらせろ!
そりゃFSASは富士通と資本関係があるけれど別会社だし他社が作ったLANを直せ(しかも当然お客さんからはお金は出ません)と言われても富士通は断るよね。
結局さきほど営業所からFSASと構内線工事業者(電線屋)を手配してもらい
到着したらセンターに電話してくださいとお願いしました。
相変わらず課長は富士通の営業とか現場の偉い人を呼び出して対応をしてくれないとクレームを入れているようですが…
この課長 昔 NACHIのアラートが上がったとき(ウイルスバスターの誤報だったけれど)にも いくら関係ないと言っても HUB業者も呼べ 何があるかわからん。 いいから現場に行かせろ と騒ぎ 手配できないセンターを無能呼ばわり
そこまで言うのならと 現場についたら遊んでいていいから行って下さいとFSASに文句言われながらも手配しました。
当然私がPCのウイルスチェックやらやったことの経緯のヒアリングをしている間FSASのCEはずっと隣の椅子でただ座って暇そうにしていました。
相変わらず不思議な会社 [システム]
昨日熱を出して休んでいる間に私が常駐しているお客さんの入館方法が厳しくな
りました。
ビル管理部署が警備会社に対して「なんていい加減な管理をしているんだ」と
こっぴどく叱ったらしく入館証を持っているあるいはビル管理部署から渡された
申請中リストに名前が載っている人だけが入れます。
ここまで読めばごく当たり前のことなんですが
全体を聞いたら バカじゃないの?って思える運用が行われています。
1 入館申請中リストは会社の総務から取引をしている担当部署に提出
これがお客さんの本社に回りあちこちの部署を回ってここの支社の
ビル管理部署に届き、やっと受付警備に回る。
ただでさえ役所仕事で時間がかかるのに支社の管理者で決裁できないのかな
今日も入館できずにお客さんの担当が来るまで外で待たされた人多数。
朝番の意味がなくなった(お客さんが来る前にシステムが正常に動いている
か確認するのに)
2 常駐でないけれどシステムの設定変更に来る人も常駐業者と同じ扱い
でも常駐ではないから常駐者入館証は持っていないし、申請中リストにも
載っていない。 作業届が必要らしい。 でもお客さんのシステム担当
にはコンピュータを触るので作業届は出ていますが、ビル管理にはその
情報は行きません。
作業に来た人が入れてもらえませんでした。
3 打ち合わせで来る人は対象外
入館台帳に名前を書くだけで入れる
問題は3です。
質問 どうやって1〜3を見分けるの?
回答 1と2はいつも来ているからどこの会社の何をしている人か警備が知って
いるから3で入ろうとしてもわかる。
つまり顔も知らないどこの人かも知らない人なら適当に台帳に名前を書くだけで
入館できます。(身分証明書の提示も求められません)本社だと「打ち合わせ」って書く受付で打ち合わせをする社員に電話をして本当かどうか確認しますが、支社はそんな運用はしていません。
相変わらず変な会社。
情報漏洩防止 [システム]
さっきお客さんに呼び出されインターネット向けメールの監査の話をしてきました。
昨今情報漏洩について監督官庁からの規制が厳しくなり管理センターから外に送るメールについて、事前に送信先を申請して承認を受けたアドレス以外には送らないと言う運用をしたい。
しかもその申請アドレスも本当に必要なキーマンだけのアドレスだけを認めたい。
とこれだけ見ればごく当たり前のことです。
ところが
メールを使うのは
運行上の連絡事項(今夜設定変更作業がある、工事があるなど)
緊急連絡、障害時召集
障害復旧用の解析に伴うもの
プロジェクトの会議の招集なんてそんなのは会社に戻って会社のメールを使ってやれ
基本的に業務はお客さんのところに派遣されてずっと管理センターに常駐して遂行しています。
同じ人からどんどんスピードを求められているのに多数のベンダーをすぐに集めて会議をしろって言われるのに会社に戻ってからか~
まさに今障害が発生していてってときは管理センターからメールで召集してもいいみたいだけど
ますますやりにくくなるな~
ちなみに管理センターから送るメールは内部外部とわずにすべてお客さんの管理担当にメールのコピーが届くようになっています。
情報漏洩するには自爆覚悟で送らないといけないんだけどな~
ウイルスパターン配布のトラブル [システム]
会社ではウイルスバスターコーポレートエディションを使っています。
昨日の昼の3.703のパターンを配るときにトレンドマイクロが設定ファイル(server.ini)の記述を誤り、3.701から更新する際に500KBの差分ファイルではなく12.7MBのフルパターンをダウンロードせよ とやってしまったようです。
午後から社内ネットワークが全国のあちこちでping抜けが多発して原因がわからずずっと騒いでいました。
ぼくはWAN担当ではないので何が原因だろうと他の作業をしながら傍観していました。
夕方に営業さんから「緊急でお知らせすることがあります」って電話がかかってきたので ピ~ンと来ました。
「何かやったでしょう」とすぐに聞いちゃいました。案の定しでかしてくれていました。
何しろWAN回線を通じて全国の5万台弱のPCが一斉に12.7MBのパターンファイルをダウンロードを始めたからネットワークが悲鳴をあげていたようです。
去年もフルダウンロードにしてしまった事件があったのですよね。
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2006/08.html#20060831__trend2
パターンファイル 3.701.00 から 3.703.00へのアップデート時における、フルサイズのパターンファイルのアップデートに関して (トレンドマイクロ, 8/31)
毎度のことながらトレンドマイクロがチョンボるとダイレクトにシステムに影響を与えるから恐いですよね~
無限ループになった [システム]
社内のウイルスバスターがウイルスを検知するとその通知メールが私のPCに届きます。
メールは大量に来るので埋もれるといけないのでBeckyの振り分けルールで「ウイルス発見」というフォルダーに受信時に自動振り分け設定してます。
ところが受信箱に未読のメールが3000通もたまってしまったため自分に関係ないメールをバサバサ消しているとこの「ウイルス発見」のフォルダが壊れたようです。
よくあるんですが
やっかいなのに壊れ方がWORM_MYTOB.Xのmessage.scrと同じパターンになったらしくウイルスバスターCorpが誤検知しました。
これも未読メールを整理しているとたまにあります。(過去3回くらいあった)
ところが壊れたフォルダが「ウイルス発見」のフォルダなんですよ。
勘のいい人なら もうわかったでしょう。
誤検知した通知メールが「ウイルス発見」のフォルダに自動振り分けされるとまたWORM_MYTOB.Xとして誤検知⇒また誤検知通知メールが届く⇒自動振り分けされて と無限ループ状態になってしまいました。(T_T)
Beckyのファイルメニューの「修復」を実行してなんとか無限ループを断ち切ることができました。 ほっ
検知メールは複数の運用者が受信しているので全員に「誤検知だからね」と言って回ったchiichanでした。
久しぶりにきた~ [システム]
何が来たってウイルスです。
会社のメールサーバーではある拡張子をブロックしています。
過去に数度パターンファイルが間に合わずにBAGLEなどがGWを通り越して飛んできたのを目撃したのでしっかりガードです。
でブロックすると誰から誰宛のどんな添付ファイルをブロックしたか私の携帯電話に届くようになっています。
それが来たのは土曜日の午前3時前後
携帯電話に大量にブロック通知メールが届きました。
見ると なんと社長が社長宛にいかにも怪しい名前の添付ファイルが。
当然社長はPCを操作しません。しかも土曜日の午前3時にメールなんて送るわけありません。
見ると同じ時間に知っている人の名前でいっぱい飛び交っています。
ははは~ん これは新種(亜種)のウイルスだなと思っていると
トレンドマイクロからパターンが上がったと通知メールが携帯電話に届きました。
どうやらTROJ_BAGLE.EYのようです。
月曜日に会社に来るとパターンが上がった後にTORJ_BAGLE.EYのアラートがいっぱい届いていました。
あれ 待てよ よく見ると金曜日の17時にも大量に来ているじゃないの
ってことはウイルスバスターが当初のパターンでTORJ_BAGLE.EYを取りこぼしていて修正したな。
社〇保〇庁と同じじゃん [システム]
昨日大きなトラブルがありました。
昨日からサービス拡大をしたWEBサイト月曜日までは一部のユーザーだけに公開していたのですが先週の後半からフライングして使い始めた人がいたようです。
ログで見るとかなりの人が勝手にアクセスをはじめました。
その状態でしばし監視コンソールにはCPU90%以上のアラートが出始めまいた。
(閾値は90%に設定されていた)
構築会社に連絡をしたら調べますといいながら閾値を98%に上げました。
おいおい それって回収率をあげるために対象の分母を減らしたあの浣腸 いや官庁と同じジャン
やっていることが違うぞと騒いでいたのですが昨日はとうとう1日100%に張り付いたままになってしまいサービス停止させました。
全社をあげて人を出し深夜まで対策をしていました。マシンルームには常務まで来ていたのです。 お客さんの部長さんも来られていました。
前兆があったんだから土日に普通に対策をしていればこんなに大騒ぎにならなかったのに~
甘いな N社 と言いつつ私はN社からの出向社員です 爆笑
やってられません [システム]
とあるメールシステムのウイルスパターンが上がらなくなり
あらかじめもらっている手順では復旧しませんでした。
そこで保守コールして対応してもらいました。
職場では障害発生で10分以内、状況変化で5分以内で報告をしなくてはいけません。
前者はばっちり
さて復旧したのですぐにまずは電話で第一報 ちなみにサーバーはLINUXです。
担当「トレンドマイクロのプロセスの手動停止(killしました)と起動で復旧しました」
顧客T「アプリケーションですか? OSですか? プロセスではわかりません。」
担当「どっちでもなくトレンドマイクロのプロセスです」
顧客T「だからプロセスではわかりません トレンドマイクロのアプリケーションですか?」
担当「chiichanさん プロセスでは通じません なんて言いましょう」
私『勉強して』 管理センターにどっと笑いが
このTさん 運用監視部門の一番の若手 と言っても3年目です
営業さんや経理さんに説明するわけでもないのに 5分って時間を要求されているのに「プロセスとは何か」から話し始めたら一日かかりだ (T_T)
彼の先輩に「何とかならないの?」と苦情のメールを送りました。
別の機会にじっくり説明するのはかまわないんだけれど
不思議なプロトコル [システム]
今週FWの設定変更をしました。
トラフィックが急激に増えることが予測できたので2週間後に撤去予定のFWなので強力な装置に交換するのももったいないからCPU負荷をかけているセッション管理機能をオフにしました。
そしたら次の日からFWを通してのftp通信が出来ないというお客様からの申告がありました。
調べるとなんとftpってPCからサーバーにセッションを張るだけでなくサーバーから送られてくるデータはサーバー側からPCに対してhigh portで接続してくるんですね。
当然コマンドの内容にPCが何番のhigh portで待っているとサーバーに通知しているんですが。
ところがセッション管理をしていればコマンドのセッションとサーバーから張ってくるデータのセッションは対になっていますとFWがわかるので許可済みとして通過できます。セッション管理を切ったのであたかもサーバーからFWの内側に対してhigh portの接続を試みてきたように見え拒否をしていたそうです。
こんなことをしているって今回は勉強になりました。
2週間後に新しい経路に変更するのですがそっちで使うFWは処理能力が高いものなのでまたセッション管理をするようになるのでこんなトラブルは起きないようです。
2週間後に切り替わる新しい
まさに迷惑メール [システム]
今朝出勤してきたらスパムメールフィルターに大量に引っかかっていました。
なにしろTOCだけで300KBもあるので件数はすごいことになっているのがわかると思います。
で 大抵は出会い系のやつで数KBでかくても20kbなんで面倒なだけなですが
1社洗剤のセールスメール(トップとかブルーダイヤとか)これがエンコードされた状態で540KBもあります。
つまり2つで1MB以上
当然件数は会社のアドレスに手当たり次第送ってくるので集めるとGBオーダー
ここまでくるとメール爆弾のようです。
この程度の画像20KBもあれば大丈夫なはずだが
なんとかならないんですか?>ス〇〇ヤさん
こっちのメールサーバーは数年前の古いメールサーバーなんですよ。
勘弁してほしいな~
ななんとよく見たら同じ業者から他に735KBと590KBの画像つきDMもあった orz