18-5. InterScan7 の運用あれこれ (1) InterScan7 の運用あれこれ1 `29/11 * 運用あれこれ 半年ぐらいほかっていた。またぞろspamが増えてきた。1日150通ぐらい迷惑メ− ルがやってくる。毎日何通すり抜けたか一応メモしている。大体これまで1日に数通がす り抜けた程度だった。それが10月の終わり、土日にかけて同じ件名のメ−ルが10通ぐ らい抜けてきた。前後数日で減ってそれ以降は来ない。11月の始めにも同じような現象 が起きた。社内の他の人のところへもたくさん届き、クレ−ムを幾つかもらうこととなっ た。何とかせよと。99%ぐらいの非常にいい成績で迷惑メ−ルをブロックしているにも かかわらず、少しでも増えるとすぐにケチをつけてくる。まあそんなもんです。11月に 来たメ−ルを見て、ビ−トルズのゲットバックという歌がすぐに浮かんだ。内容はごく普 通のビジネスメ−ル。英語を翻訳すると "添付の手紙を見て下さい 更に詳細は私のオフ ィスに返信されたし どうもありがとうございます"。これでは検知できる訳がない。 ひょっとしてこのメ−ルはDoS攻撃ではなかったか。10月のでは Mail-Store マシン が固まった。メ−ルの送受信ができなくなり、マシンをリブ−トした。DoS攻撃ではな いが一時的にspamが大量に来たのはそうだと思う。元々ディスクの容量が少なくなっ てきていたのでエラ−になったのだと思う。 /var パ−ティションが96%になっていた。 多分、夜間だったりしたらそのままマシンは一時的に機能不全になっていたかも知れない が、少しずつメ−ルを処理し正常に戻っていたのでないか。/var/adm/messeage.0 などを 見るとこの1ヶ月、次のような警告が何度か出ていた。しかし動作としては異常に気付く ことは無かった。"tmpfs: [ID 58458 kern.warning] WARNING: /tmp: File system full, swap space limit exceeded"。"sendmail[8550]: [ID 21593 mail.crit] NOQUEUE: SYSER R(root): daemon: cannot fork: \377\377\..."。 `29/10/27 に InterScanのパタ−ンファイルが新しくなっていないことに気付いた。スパ ムメ−ル判定ル−ルが Mail-Store本番機は 16972.003、予備機は 16972.004 だった。本 番機は /etc/hosts にパタ−ンファイルを取りにいく先のURLとIPアドレスを記入し ている。前に snoop で調べたのだ。 本番機はDNSでパタ−ンファイルのありかを調べ るように設定している。改めて予備機で snoopで見たらこれまでのとは違っていた。変更 になったのは多分27日だと思う。 URLは imss7-as.activeupdate.trendmicro.co.jp と imss7-unix-p.activeupdate.trendmicro.co.jp に変わっていた。手動でパタ−ンファ イルを取りに行かせて、その際の様子を snoop でみた。 やるたんびに異なるIPアドレ スがでてきた。10個ぐらいあるのかもしれない。2つのURLのIPアドレスは一緒で よさそうだった。その一つを /etc/hosts ファイルに記述し直した。 11月早々、スパムメ−ルの検出レベルを'低'から'中'にした。とりあえず自分が会社に いる間'中'にして誤検知がないか監視した。1週間位みたところ誤検知はない。迷惑メ− ルは深夜から早朝にやってくる。一日数通から4、5通、'低'で抜けたメ−ルを転送して '中'でチェックしたら半分位ひかかった。なんとゲットバックのメ−ルが'中'で検知でき たのには驚いた。info.zipとやらの添付も無し、全く普通のビジネスメ−ルにしか見えな いのに。そうこうする内に InterScan7 の更新期日が過ぎてしまった。契約期間が過ぎて 猶予期間は後、何日と画面に出るようになった。どうも更新猶予期間は90日みたい。保 守料金をSI業者を通じて払って、ライセンス証書がきた。電話でアクティベ−ションコ −ドを入れ直すんですかと聞いたら必要なし、また1週間位したらちゃんとなるとのこと。 もし期限切れのままならメニュ−の概要で [ステ−タス更新] をクリックしてみること。 * /opt/trend/imss/log のログ パソコンから http://192.168.1.1:8455/IMSS.html で見える制御画面には、 ソフトがど このディレクトリに入ったかは出てこない。 InterScan7 のパッケ−ジをダウンロ−ドし てきて展開し、isinst.sh コマンドでインスト−ルをすると、デフォルトで /opt/trend/ 以下に入る。インスト−ル場所を他、例えば /usr/trend/ と指定しても、PostgreSQL は /opt/trend/imss/PostgreSQL/ に入る。 PostgreSQL のデ−タベ−スには隔離するメ−ル が入る。ログを何日分とっているかは [ログ]->[設定] の "ログファイル" の設定による。 ここでの設定は、アプリケ−ションのログの詳細レベル[標準▽]、〆ログファイルを保存 する日数 [90]日、〆サ−ビス別ログファイルの最大サイズ [2000]MB だった。 実際11 月4日 /opt/trend/imss/log ディレクトリを見たところ、log.imss.20090806.0001 から log.imss.20091104.0001 の91個のファイルがあった。 /opt/trend/imss/config/imss.ini 関係する部分のみ ----------------------------------- |sys_log_path=/home/trend/imss/log log.imss はシステムログでメ−ル送受信の全ロ |sys_log_prefix=log.imss グ。sysevt.imss はイベントログ。polevt.imss はポリシ−イベントのログ。他にログいろいろ。 # cd /opt/trend/imss/log # ls -l *20091026* -rw-r--r-- ... 367349 10月 26日 23:59 imssmgr.20091026.0001 -rw-r--r-- ... 526754 10月 26日 23:59 imssps.20091026.0001 -rw-r--r-- ... 191307 10月 26日 23:55 imsstasks.20091026.0001 -rw-r--r-- ... 12487218 10月 26日 23:59 log.imss.20091026.0001 -rw-r--r-- ... 3377993 10月 26日 23:59 polevt.imss.20091026.0001 -rw-r--r-- ... 1078 10月 26日 23:46 sysevt.imss.20091026.0001 他にファイルのサイズが0の euqerror.imss.20091026.0001 など9個あった。 [ログ]->[クエリ]->[システムイベント] sysevt.imss.20091026.0001 日時 コンポ−ネント 説明 -------------------------------------------------------------------------------- .. 09:15:14 hostB アカウント[admin]がログオンしました。 .. 09:02:42 hostB IMSSデ−モンが開始しました。 .. 09:02:41 hostB IMSSデ−モンが停止しました。 .. 09:00:13 hostB 予約アップデ−ト - スパムメ−ル判定ル−ル 16974.003 をダウン | ロ−ドしました。 .. 16:15:19 hostB 予約アップデ−ト - スパムメ−ル判定ル−ルをダウンロ−ドできません。 .. 16:00:14 hostB 予約アップデ−ト - スパムメ−ル判定ル−ルをダウンロ−ドできません。 .. 15:45:15 hostB 予約アップデ−ト - スパムメ−ル判定ル−ルをダウンロ−ドできません。 新しい判定ル−ルをダウンロ−ドしたら InterScan は自動で再起動するのか?。 どうも そうみたい。予備機でも頻繁に "IMSSデ−モンが開始しました"、"IMSSデ−モンが停止し ました" が出ていた。予備のマシンでも "ダウンロ−ドできません" と同じようなログが 出ていた。普段は Mail-Store の予備としてただ電源を入れているだけで何も働いてない。 [ログ]->[クエリ]->[ポリシ−イベント] polevt.imss.20091026.0001 日時 処理 ル−ル メッセ−ジID -------------------------------------------------------------------------------- .. 16:29:54 隔離 初期設定のスパムメ−ル対策ル−ル 2009027xxxx@xxx.nix.co.jj .. 16:29:36 隔離 初期設定のスパムメ−ル対策ル−ル 000d01c56xxxx@xxx.nnn.con [ログ]->[クエリ]->[MTAイベント] log.imss.20091026.0001 全部の1個1個のメ−ルの送受信ログが記録されている。ある日の1時間分のログを表示 させてみようとした。まるでちっとも表示されてこない。# vmstat 5 4 でみると cpu の us が50以上と出た。かなり負荷がかかっている。不用意にこの [ログ表示]はやらない 方がいいだろう。現時点からと2分前を指定してみた、これはすぐにログが表示された。 << 隔離領域に保存されたメ−ル >> # ls -l /var/imss drwx------ ... 512 10月 26日 12:50 pgdata/ << この中にデ−タベ−スの形 -rw------- ... 40634225 10月 29日 15:22 pglog になって保存されている。 * Mail-Store の sendmail のログ Mail-Store のマシンでは InterScan のデ−モンが動いていて、それを sendmail デ−モ ンがサンドイッチしている。ログは2つの sendmail から出ることになる。正常なメ−ル 配送なら from は2回出てくる。sendmail のログは /var/log/syslog にできる、古いの は順に syslog.0 から syslog.7 になって行く。下のデ−モンは上から3つが親プロセス、 一番下の1つは root 126 から生まれた子プロセス。実際のメ−ルの処理は子プロセスが 行なう。次の瞬間 root 2251 のプロセスはメ−ルの処理を終え消えていた。 # ps -ef | grep sendmail root 123 .. 10月 26 ? 0:44 /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-rx.cf root 126 .. 10月 26 ? 0:33 /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-tx.cf smmsp 135 .. 10月 26 ? 0:00 /usr/lib/sendmail -Ac -q15m root 2251 .. 15:29:50 ? 0:00 /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-tx.cf * すり抜けて来た迷惑メ−ル 件名のキ−ワ−ドによる検知で、すり抜けて来るた迷惑メ−ルをフィルタリングするよう にしてみる。 [ポリシ−]->[ポリシ−リスト] 画面の {初期設定のスパムメ−ル対策ル− ル} をクリックする、デフォルトのままならこの名前で出ている。でてきた画面のコンテ ンツのところの {件名のキ−ワ−ド} に〆を入れ、クリックする。すでにキ−ワ−ドが登 録された "デマメ−ル" とか "人種差別" とか幾つかある。[追加]をクリックしてリスト 名に適当な名前を書く。ここでは "ジシャヨウ" と書いてみた。この "ジシャヨウ" の中 に検知したいメ−ルの件名を記述する、[ code name is deep blue] を検知するようにし た。傾向として数日ですり抜け迷惑メ−ルは全く来なくなる。しばらくすると件名が例え ば Hello Wife というのが来るようになる。ひょっとすると添付ファイルが付いているの は同じマルウェアかも知れない、文面だけちょっと変えて。キ−ワ−ドを登録して、しば らくこれで同じ件名の迷惑メ−ルを隔離し止める。1週間もチェックすれば十分である。 ------------------------------------------------------------- | ジシャヨウ | ----------------------------------------------------------- | 初期設定のスパムメ−ル対策ル−ル > キ−ワ−ド > ジシャヨウ | | [保存][キャンセル] | ----------------------------------------------------------- | |リスト名: [ ジシャヨウ ] | | |キ−ワ−ド: [指定したすべてのキ−ワ−ド ▼] | << ここと | | -------------------------------------------- | | | | ■追加 ■削除 | | | | | □ キ−ワ−ド/正規表現 大小文字区別 | | | | | □ code name is deep blue □ | | << ココを | | | □ Hello Wife □ | | | | -------------------------------------------- | | ----------------------------------------------------------- ・指定したすべてのキ−ワ−ド [ "code name is deep blue" ] 検知せず。 ・指定したすべてのキ−ワ−ド [ code name is deep blue ] 検知した。 ・指定したすべてのキ−ワ−ド [ name is deep blue code ] 検知せず。 ・指定した任意のキ−ワ−ド [ code name is deep blue ] 検知した。 ・もう1つテストした。指定した任意のキ−ワ−ド [ code name is deep blue ] で、 メ−ルの件名を [ name is deep blue code ] にしてみた。検知しなかった。 [隔離およびア−カイブ]->[クエリ] の画面で、{件名: [ code name* ]} と入れて隔離さ れたメ−ルをリストする。{件名: [ code name ]} では検索しない、メ−ルはリストされ なかった。件名のキ−ワ−ドで検知されて隔離されたメ−ルは、隔離理由は"コンテンツ" となる。spamメ−ルのチェックの順序は、先ず {スパムメ−ルの検出レベルを指定す る} でのパタ−ンファイルにより判定し、次に {コンテンツ、件名のキ−ワ−ド} でやる。 件名や本文のキ−ワ−ドで判定するのには、作業に負荷がかかる。 InterScan7 内部では できるだけ {スパム判定ル−ル} でチェックするようにしているのだろう。多分11月始 めの迷惑メ−ルはボットからだと思う。1時間に1本とかぽちぽち来た、差出人は自分に なっていた。さてトレンドマイクロのレピュテ−ションで検知できたのだろうか。 (2) InterScan7 の運用あれこれ2 `29/04〜11 * すわっDoS攻撃か spamがまた増えている。他所でも起こった可能性がある。いつもなら毎朝、百通位の ところが千通きた。2008年4月3日の朝のこと。メ−ルの DoS攻撃、ボットにより標 的になったか。自分宛にきた迷惑メ−ルは10ぐらいだった。ほとんどが Mail Delivery Subsystem からで、自社に存在しないメ−ルアドレス宛のメ−ルで、管理者宛にエラ−メ −ルになり返ってきたもの。3日の 0:12〜0:58 の間、1分間に20から30位きていた。 **ykomono**@nix.co.jj 宛のメ−ル。別件で何日かして Gmailに登録したメ−ルアドレス が漏れた?、自分のメ−ルアドレスを語っての、エラ−メ−ルがまたまた一杯きた。 * 迷惑メ−ルの誤検知から 2009年4月初め。迷惑メ−ルの誤検知が広く問題になってきている。多くの企業で迷 惑メ−ル対策を実施するようになり、だいぶ広まってきた感がある。それに伴いメ−ルが 相手に届かない、内に来ないといったことが目立ってきた。感触としてどうもそんな感じ じゃないかと思っていた。asahi.com にずばりそうした記事が載った。2009年4月6 日付け "迷惑メ−ルに間違えられないための5つの基本"。4つ目にビジネスで HTMLメ− ルは使わない。これは昔から言われたことだ。2つ目の、件名にはしっかりと要件を記載 する事。"お世話になります"、"打ち合わせ結果"等は迷惑メ−ルによく使われるので御法 度と書いてあった。同じ人が AllAbout に2007年9月12日に、ほぼ一緒の記事を出 していた。2009年でやる対策としては、どうも今一つのような気がすると思った。 お疲れ様です。このフレ−ズは営業さんがよく使うようだ。メ−ル本文でかんとうしのよ うに書いている人がいた。InterScan7 では迷惑メ−ルになった。 検知レベルを変えても 迷惑メ−ルだった。自社のメ−ルサ−バだけの問題なら "お疲れ様です" をキ−ワ−ドの フィルタリングから除外するとか、ピンポイントで迷惑メ−ルにしないように回避策をと れるかもしれない。でも相手企業でも迷惑メ−ル対策をしていて、そこでひっかかるかも 知れない。その人のパソコンで会社が入れたソフトでもひっかかるかも知れない。さまざ まな迷惑メ−ル対策で迷惑メ−ルと認識されないように、最大公約数的なル−ルを見つけ なければいけない。これはかなりやっかいな話だ。 どうもメ−ルの誤検知はゼロにはできそうにない。たまたま何かの拍子で迷惑メ−ルと判 定されてしまう。それならまだそれで仕方ない、誤差の範囲だということで割り切ってし まうことができる。しかし何かの拍子ではなく、かなりのパタ−ンで迷惑メ−ルと判定さ れるらしいことが分かった。お疲れ様です、というフレ−ズが本文の1行目にあるとだめ とか。これは仕方ないでは済ますことはできない。大方、迷惑メ−ルと判定されそうだと いうことが分かっているのなら、何とか対処せねば。ということから、隔離されたメ−ル をやはり各自で確認できるようにすること。これは必要である。 * 隔離メ−ルが指定日数残ってない 隔離する期間は7日間で、ディスク割り当ては 500MB にしていた。 ある日よくよく見た ら隔離メ−ルが3日分しかなかった。十分な容量を割り当ててないとこういうことになる らしい。どうも適当なところで区切るようで3日前の途中から残っていると言うのでなく、 午前0時からのメ−ルが残っているみたい。一日分の隔離メ−ルのサイズをだいたい計り、 64倍した容量を割り当てるのがトレンドマイクロの推奨とのこと。InterScan のレポ− トによれば、毎日の隔離メ−ルの容量は 40MB 前後位になっていた。2週間では 40MB*14 *64=35840MB=35840/1024=35GB。隔離領域は /usr/trend/imss/queue/quarantine/ にある。 /usr は # df -k で見たら使用可能は約 20000000KB=20000000/1024=19531MB=19GB。ディ スク容量は完全に足らないが、とりあえず割り当てを10GB、隔離期間を14日にした。た だ InterScan の画面でこれらの値を入れるだけ、特に何の変化もないし。InterScanは再 起動しなくてもいい。これで14日分の隔離メ−ルが残るようになった。 * 圧縮ファイルの中身はチェックするのか 3行20列ぐらいでいやらしい文面を書いた。 これをただのテキスト test.txt と Word で word.doc にして、添付メ−ルにした。そもそもいやらしい言葉、日本語を3つや4つ 羅列したぐらいではスパムとして検知されなかった。 ↓ そのまま通った。添付メ−ルでなくメ−ル本文に文面を書いたらスパムで止められた。 [ポリシ−]->[ポリシ−リスト] の {初期設定のスパムメ−ル対策ル−ル} の {検索条件} の {添付ファイル} の所で、 {名前または拡張子} {MIMEコンテントタイプ} {実ファイル タイプ}、いずれかで Word にチェックした。上の文面 word.doc をメ−ルに添付した。 ↓ 上の3つどれでも止められた。理由は "添付ファイル"。拡張子をみて止められた。 実際に来た迷惑メ−ルで、3YMH6JJY.zip ファイルが止まった。ファイル名を aaa.zip に 変えても止まった。中身は知らない。いやらしい文面 test.txt を圧縮して test.zip に してメ−ルに添付した、これは止まらなかった。 ↓ InterScan は圧縮ファイルの中身の文面はチェックしてないのでないか。トレンドが用意 したスパム判定ル−ルのパタ−ンファイルでチェックしているのでないか。 * 添付ファイルの圧縮が問題になるのでないか メ−ルの添付ファイルの圧縮率が結構高いのがある。 CADデ−タの DXF や IGES ファ イル。これらは ASCII テキストなので、圧縮がよく効くのでないか。 [ポリシ−]->[検索の除外]->{セキュリティ設定違反} いずれかが合致すれば ------------------------------------------------------------- |メッセ−ジの合計サイズが次の値を超える [30]MB (1) |いずれか1つのファイルの解凍後の合計サイズが超える [50]MB (2) [test1] aaa.zip 添付ファイル 2201KB が元。InterScan ではサイズが 2.9MBになった。 中身は PDF ファイルが4つ入っていた。773/563/805/820KB = 2961KB。 (1)を[1]MBにした。止まった。[2]MB, [3]MB も止まった。 (1)を[3]MB、(2)を[1]MBにした。通った。[2]MB, [3]MB も通った。 [test2] bbb.zip は添付ファイル 2548KB が元。InterScanではサイズが 3.4 MBになった。 中身は PDF ファイルが1つ入っていた、4646KB。 (1)を[2]MBにした。止まった。[3]MB も止まった。 (1)を[4]MBにした。通った。 (1)を[4]MB、(2)を[4]MBにした。止まった。 [test3] ccc.zip 826KB が元。InterScan ではサイズが 1.1MBになった。 中身は PDF ファイルが2つ入っていた、683KB と 1023KB。 (1)を[0]MB、(2)を[1]MBにした。通った。 (1)を[1]MB、(2)を[1]MBにした。止まった。 [test4] 圧縮ファイルを作った ddd.zip、圧縮後は 2021KB。InterScan では 2.7MB。 中身は PDF ファイル 2238KB と 203KB 2つ。 (1)を[0]MB、(2)を[1]MBにした。止まった。(2)を[2]MB も止まった。 (1)を[3]MB、(2)を[3]MBにした。通った。 * サイズが小さいメ−ルも止められる場合がある どういうこと。受信者をたくさんにすると駄目。たくさんといっても10人も無いので止 まってしまった。To: のところにずらずらとメ−ルアドレスが書かれているメ−ルのこと。 Excel の添付ファイルあり、これもA4で1枚程度の内容で。レベル中で止まった。レベ ル低にしたら通った。 * 迷惑メ−ル検知の仕組みはどうなっているか トレンドマイクロのレピュテ−ションのブラックリストに載ったメ−ルの内容は、しばら くして InterScan7 の判定ル−ルのパタ−ンファイルに反映されるのでないか。どうもそ んな気がする。ッシュ値の様なものがパタ−ンファイルに入っているのでないか。すり抜 けた迷惑メ−ルは、 Mail-Relay でトレンドマイクロのメ−ル・レピュテ−ションをやる ようにしてたら迷惑メ−ルとして検知できたのだろうか。 * InterScan7 設定したら後は手放しでいいか そういうわけにはいかない。レベル中にするとスパムとして止められるメ−ルがでてきた。 レベル低にして同じメ−ルを出したら通った。どうも金土日にかけて、大量にすり抜けて くる迷惑メ−ルがある。金曜日に帰宅するさいにレベルを中にあげておく。月曜日に出社 したところで、レベルを低にする。そして誤検知がなかったか隔離メ−ルを全部チェック する。しばらくしたらレベル低でも、すり抜けメ−ルは減ったので低のままにした。 * 件名でのフィルタリングがどうもおかしい メ−ルの日本語の件名はフィルタリングで認識しないみたい。件名でただの "1" とか"2" のメ−ルは認識して止められた。同じメ−ルの内容で自分が自分宛にメ−ルを出して確認 したら止められずに通った。メ−ルの本文も "konnitiwa" とかで、件名が "1" でも通っ た。InterScan7 はひょっとして学習したのか。 * InterScan7 のライセンスの更新 そうこうする内に InterScan7 の更新期日が過ぎてしまった。契約期間が過ぎて猶予期間 は後、何日と画面に出るようになった。どうも更新猶予期間は90日みたい。保守料金を SI業者を通じて払って、ライセンス証書がきた。電話でアクティベ−ションコ−ドを入 れ直すんですかと聞いたら必要なし、また1週間位したらちゃんとなるとのこと。もし表 示が期限切れのままになっているようならメニュ−の概要で、サポ−ト契約が終了しまし たうんぬんの {詳細な情報} をクリックする。[ステ−タス更新]をクリックすると、小さ な画面 "ライセンスが正常にアップデ−トされました" が出る。"期限切れ(更新猶予期間 内)" が "アクティベ−ト済み" に変わる。スパムメ−ル対策 の [ステ−タス更新]をク リックすると、IPフィルタの方も"アクティベ−ト済み" に変わる。 * メ−ルの誤検知がひどい `2a/01 メ−ルの誤検知がひどくなってきた。2010年1月27日。数日前から10通は誤検知 している。3日ぐらいして誤検知はまた減ってきた。えらいばらつきがある。レベル低よ り低い値をセットしてみるか、高中低の値は幾つだったか。 しきい値は 高−4.5、中−5、 低−7。Gumbler 騒動で感知が敏感になったのでないか。 一月以上、一日に何度もメ−ル の誤検知がないかチェックしていた。画面のスクリ−ンタイムアウトが短い。チェックし ようとするたんびにアカウントを入れないけない。たまらん、長くすることはできないの か。できます。しかし画面からはできない。制御ファイルのパラメ−タを直接いじること。 サポ−トセンタ−に問い合わせしたら教えてくれる。そんなこんなで、いつの間にか誤検 知が減ってきた。一日にゼロかあっても数通。やはり Gumbler のせいで、InterScan7 の 迷惑メ−ルを検知する感度が敏感になっていたのだと思う。 初期設定のスパムメ−ル対策ル−ル > スパムメ−ル [保存][キャンセル] *** 上の@をクリックするとでてくる *** ------------------------------------------------------------ | 〆 スパムメ−ル検出レベルを指定する | ○ 高: より多くのスパムメ−ルを検出します。InterScan MSS を通過して | クライアントに到達するスパムメ−ルが多すぎるときに設定します。 | ◎ 中: 標準の設定です。 | | ○ 低: より少ないスパムメ−ルを検出します。InterScan MSS によって | スパムメ−ルと判定されるメ−ルが多すぎるときに設定します。 | ○ 指定 検出のしきい値: [5.0 ](3.0-10.0) | | □ 承認済み送信者リスト ... | | □ ブロックする送信者リスト ... | | □ 承認済み送信者リスト ... | |テキスト除外ル−ル | □ テキスト除外ル−ルに一致するメッセ−ジを除外する ... -------------------------------------------------------------------------- * InterScan7 のこれって考えないといけない `2a/01 [ログ]->[設定] 以下はデフォルトの設定値 ------------------------------------------------- |デ−タベ−スへのログへのレポ−ト | |-----------------------------------------------| |デ−タベ−スのアップデ−ト間隔 [01 ▼]分 | << これって短過ぎるのでないか。 |クエリ用にログを保存する日数 [30 ]日 | 実運用ではもう少し長目に設 |-----------------------------------------------| 定しないと、デ−タベ−スに |ログファイル | アップデ−トする作業が終わ |-----------------------------------------------| らない内に、また次の処理が |アプリケ−ションログの詳細レベル [標準 ] | 発生してしまうのでないかと | 〆ログファイルを保存する日数 [90 ]日 | 危惧する。それで5分にして | 〆サ−ビス別ログファイルの最大サイズ [2000]MB | 運用している。 ------------------------------------------------- * InterScan7 でサイズの大きいメ−ルを止める `2d/10 管理者にも止めましたというメ−ルを送るようにしている。 Mail-Store の画面に出てく るログと日時が一致していることに気付いた。 差出人: postmaster@imss.com このメ−ルは自動で配信しています。メ−ルの 宛先: NotificationRecipients サイズが大きいのでメ−ルストアで止めました。 件名: Mail delivery stopped もう少し小さいサイズで送ってください。 MMM は "Dropped invalid comments from header address" に展開して読んで下さい。 Mail-Store に telnet していると、こんなログがでてくる。# ls とか作業している時で も出てくるので、邪魔だなとおもっていた。 Oct 29 17:08:25 hostB sendmail[5653]: [ID 801593 mail.alert] r9T88PnO005649: MMM Oct 29 17:08:26 hostB last message repeated 1 time Oct 29 17:09:48 hostB sendmail[5850]: [ID 801593 mail.alert] r9T89knO005844: MMM Oct 29 17:09:50 hostB last message repeated 1 time Oct 29 17:09:58 hostB sendmail[5880]: [ID 801593 mail.alert] r9T89vnO005878: MMM Oct 29 17:10:16 hostB last message repeated 2 times よく見れば NotificationRecipients なんて宛先は全くおかしいわけで、これまで漫然と 見過ごしていた。InterScan でまともなメ−ルアドレスにしてみよう。root 宛でもいい。 (3) InterScan7 の運用あれこれ3 `2a/04〜05 -------------------------------------------------------------------------------- InterScan7 が内部で使っている PostgreSQL のバグによるディスク領域の圧迫への対処。 -------------------------------------------------------------------------------- * InterScan7 のバグ 以下`2a/04 Mail-Store の本番機でも予備機でも、どうもディスク容量が減っている。 見るたびにパ −ティションの /var の容量が増加している。予備機は普段は何もメ−ルのやりとりはし ていない。`2a/04 改めて両方のディスク容量を調べた。まるで /var は足りない、df -k では95%が使用とか出た。メ−ルボックスは /var/mail/ にある、このままではメ−ル がパンクしてしまう。CTCのサポ−トセンタ−に問い合わせた。 そしたら InterScan7 のバグだった。InterScan7 が内部で使っている PostgreSQLのバグで /var/imss/pgdata/ 内で 'デ−タベ−ス' がどんどん大きくなるのだ。不要なデ−タを削除するスクリプトが あり、それを走らせたら使用ディスク容量が10%になった。 * ディスク領域を空けるスクリプト [ 大きな領域をくっている所 ] # df -k ファイルシステム kbytes 使用済み 使用可能 容量 マウント先 /dev/md/dsk/d6 20646121 19781048 658612 97% /var # cd /var 予備機の方でこれらを見た。スタンバイしているだけで何も実 # du -sk * 際にはメ−ルをやりとりしてはない。にもかかわらず、どんど 716 adm ん /var 領域を圧迫していく。本番機の方も同じようなことに 18565479 imss になっていた。よくこれでスワップアウトとかエラ−が出てい 1196 log ないもんだ。imss 以下がでかい。#ls -l とやっても大きいと 8 lost+found は出てこない。pglog は一見して大きそうだが約18MBしか 285389 mail ない。18639265/1024=18202.4=18202KB/1024=17.7758=17.7 MB。 | # ls -l /var/imss drwx------ 10 imss other 512 1月 11日 16:43 pgdata/ -rw------- 1 imss imss 18639265 4月 19日 10:35 pglog [ vacuum.sh を実行してみた ] InterScan7 の画面で アップデ−ト スケジュ−ル を無しにして作業する。これは[概要] の画面で状態を見ることができる。アップデ−ト スケジュ−ルは 15分になっているはず。 [管理]->[アップデ−ト] 画面の "〆予約アップデ−トを有効にする"。この〆を外して画 面下の [保存] をクリックする。vacuum.sh コマンドを実行するのは15分毎はやらない ようにすること。だから例えば9時5分とか9時23分とかそんな時刻でやること。 # chown imss:imss vacuum.sh トレンドマイクロのサイトからvacuum_pglargeobj.sh # chmod 775 vacuum.sh を取ってきて vacuum.sh に名前をかえた。 名前が長 いので短くした。/usr/trend/imss/script/ 等におく。 # ./vacuum.sh INFO: vacuuming "pg_catalog.pg_largeobject" ここから下、17分ぐらいしてでてきた。 INFO: "pg_largeobject": found 7866809 removable, 43309 nonremovable row 続く | versions in 2190215 pages 終わったのは16時間後だった。 [ vacuum.sh を実行中の様子 ] 実行中にメ−ルの送受信やってみたらできた。 vacuum.sh コマンドをかけて30分かそこらの時に見た様子である。 # ps -ef | grep vacuum root 19576 19556 0 ... /opt/trend/imss/PostgreSQL/bin/vacuumdb -d imss -U sa -z root 19556 615 0 ... /bin/sh ./vacuum.sh -v -f --table pg_large # df -k ディスク容量は変わっていない。 ファイルシステム kbytes 使用済み 使用可能 容量 マウント先 /dev/md/dsk/d6 20646121 19362595 1077065 95% /var # vmstat 5 4 全然CPUを使ってないが、これでちゃんと動いている。 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr m0 m1 m4 m5 in sy cs us sy id 0 0 0 1216800 455056 15 71 33 2 2 0 0 0 0 2 0 370 67 72 1 1 99 0 0 0 993208 202568 77 53 6 385 385 0 0 0 0 0 0 810 1673 765 0 2 97 0 0 0 993208 204448 68 0 2 361 361 0 0 0 0 0 0 790 1033 732 0 3 97 0 0 0 993208 206272 75 51 2 377 377 0 0 0 0 0 0 792 1681 782 0 2 98 [ 終わった後のディスク容量 ] # df -k ファイルシステム kbytes 使用済み 使用可能 容量 マウント先 /dev/md/dsk/d6 20646121 1912595 18527065 10% /var # cd /var # du -sk * # du -sk * は var 内のファイルのサイズをディレクトリ毎に出す 1115551 imss ということ。出た値を全部たすと 1892265。単位キロバイト。 1249 log 285388 mail # du -sk とやると 1 多い 1892266 と、集計した値だけ出てきた。 | [ 一日たってもう一度やった ] 今度は早く処理は終わるはず。終わるまで7分30秒だった。次の日もやってみた、ほぼ 同じ時間だった。実行中に秒数が幾つかでている、これを全部合わせた時間がこの処理に かかった時間になる。各自、自分で計算してもらいたい。 # ./vacuum.sh INFO: vacuuming "pg_catalog.pg_largeobject" INFO: "pg_largeobject": found 16610 removable, 43535 nonremovable row versions in 14775 pages DETAIL: 0 dead row versions cannot be removed yet. Nonremovable row versions range from 75 to 2092 bytes long. There were 6422 unused item pointers. Total free space (including removable row versions) is 45637968 bytes. 3382 pages are or will become empty, including 0 at the end of the table. 12788 pages containing 45593912 free bytes are potential move destinations. CPU 1.10s/0.19u sec elapsed 4.59 sec. INFO: index "pg_largeobject_loid_pn_index" now contains 43535 row versions in 30192 pages DETAIL: 16610 index row versions were removed. 29913 index pages have been deleted, 20000 are currently reusable. CPU 1.03s/0.21u sec elapsed 12.70 sec. 1分ぐらいして、ここで止まった。 ここから下、一挙に出て終わった。 INFO: index "pg_largeobject_loid_pn_index" now contains 43535 row versions in 30192 pages DETAIL: 16610 index row versions were removed. 29913 index pages have been deleted, 20000 are currently reusable. CPU 1.03s/0.21u sec elapsed 12.70 sec. INFO: "pg_largeobject": moved 14651 row versions, truncated 14775 to 10246 pages DETAIL: CPU 4.55s/2.23u sec elapsed 396.85 sec. これで6.6分 INFO: index "pg_largeobject_loid_pn_index" now contains 43535 row versions in 30192 pages DETAIL: 14651 index row versions were removed. 29857 index pages have been deleted, 20000 are currently reusable. CPU 0.84s/0.14u sec elapsed 6.63 sec. INFO: analyzing "pg_catalog.pg_largeobject" INFO: "pg_largeobject": scanned 3000 of 10246 pages, containing 12598 live 続く rows and 0 dead rows; 3000 rows in sample, 43026 estimated total rows VACUUM * Mail-Store で imssmgr が動いてない 以下`2a/05 いつの間にかこんな表示になっていた。隔離メ−ルなんかをこれでは見れない。ずっと迷 惑メ−ルの誤検知をチェックしていたが、安定してきたのでやめていた。久しぶりに見よ うとしたら、こんなことになっていて見れなかった。https://xxxx:8455/IMSS.html の管 理画面の表紙である。ただしパタ−ンファイルは最新に更新されていた。管理画面の中に アクセスできないだけで、メ−ルのウィルスチェック、スパムチェックはちゃんと行なっ ている。数ヶ月前に PostgreSQL の 'デ−タベ−ス' がどんどん大きくなる問題に対処す るため vacuum_pglargeobj.sh をやった。この表示になったのはその後のことだと思う。 管理下のサ−バ設定 InterScan7 の管理画面の表示 ------------------------------------------------------------------------- |ホスト名 | 接続 | 検索サ−ビス | ポリシ−サ−ビス | Web隔離 | |-----------|-------------|---------------|------------------|----------| |hostB | ×赤 [削除] | 〆 [停止] | 〆 [停止] | | ------------------------------------------------------------------------- ここ2つは透明になっていた ともかく # kill imssmgrmonのPID をやり # ./S99MONITOR start をやった。そしたら何 の問題もなく、全部が緑の表示になった。隔離メ−ルも出てくるか一応確認すること、翌 日確認しました。S99MONITOR start をやった直後、 管理者である自分宛にメ−ルが数十 通きた。"postmaster@nix.co.jj メ−ル配信を止めました、Mail delivery stopped." で 大きなサイズの添付ファイルがついたメ−ルを止めましたというメ−ルだった。夕方6時 ジャストに S99MONITOR start をやった、メ−ルは送信日時と受信日時とも、18:00 から 18:01 の日付だった。どこかでこれらの管理メ−ルが止まっていたということになる。 メ−ルが溜まっていたことが影響していたのかはっきりとは分からないが、ここ一月ほど POP3デ−モンがそこはかとなく、いつの間にやら止まっていることが1週間に一度ぐらい 起きていた。Mail-Storeの本番機で PostgreSQL の 'デ−タベ−ス' が肥大化していたの を小さくする処理をしたり、Mail-Storeの予備機に IWSS をインスト−ルしたりしてテス トもやっていた。POP3 デ−モンは popper -s -R -S -T600 というオプション状態で動か していた。そしてこの際 -T600 を -T120 に変更した。長時間 POP3 アクセスしたまま放 さずにいて、一杯 POP3デ−モンができて負荷がかかり、止まってしまうのでないかと。 * InterScan7 の起動と停止の確認 # cd /usr/trend/imss/script # ls -F S99ADMINUI* S99FOXDNS* S99REPORT* forceUpdate.sh* S99CLEANEUQ* S99IMSS* S99SCHEDULED* imssstop.sh* S99CLEANEXPIRE* S99MANAGER* S99UPDATE* postfixctl.sh* S99CMAGENT* S99MONITOR* dbctl.sh* regippro.sh* S99DIGEST* S99POLICY* euqtrans* vacuum.sh* [ IMSS を停止する ] # ./imssstop.sh stop << imssmgr などが止まる。Postmaster も止まる。 # ./dbctl.sh stop << 一応やってみた。PostgreSQL を止める。 Sun Microsystems Inc. SunOS 5.9 Generic May 2002 pg_ctl: could not send stop signal (PID: 1704): プロセスがありません。 [ IMSS を起動する ] # cd /etc/rc2.d # ./S98dbctl start << PostgreSQL が走る。 Sun Microsystems Inc. SunOS 5.9 Generic May 2002 waiting for postmaster to start.... done postmaster started # ./S99CMAGENT start << 画面はでない。https://xxxx:8455/IMSS.html /usr/trend/imss/bin/imsscmagent has started. # ./S99IMSSUI start << 画面は出た。でも接続は赤だった。 Central Controller has started. # ./S99MONITOR start << これで imssmgr と imssmgrmon が走る。 imssmgrmon has started. 画面は接続は緑になった。 # ps -ef | grep imssmg root 2360 ... /usr/trend/imss/bin/imssmgr root 2347 ... /usr/trend/imss/bin/imssmgrmon # kill 2360 で imssmgr を殺しても、すぐに新しいプロセスとして imssmgr はでき た。# kill -9 2360 とやっても同じだった。 だから正常な状態では imssmgrmon だ けあるということはないはず。 < 稼働する関連デ−モン > # ps -ef imss ... /opt/trend/imss/PostgreSQL/bin/postmaster -D /var/imss/pgdata -i root ... /usr/trend/imss/UI/javaJRE/bin/java -Djava.endorsed.dirs= -classpath /usr/tre.. root ... /usr/local/jvm/jre1.4/bin/java -Xrs -Dpicard.main.thread=blocking -DSERIAL_PORT root ... /usr/trend/imss/bin/imssd root ... /usr/trend/imss/bin/imssps .../jre1.4/bin/java は関係ないかも。 root ... /usr/trend/imss/bin/imssmgr imssd と postmaster はたくさんある。 root ... /usr/trend/imss/bin/imsstasks root ... /usr/trend/imss/bin/imssmgrmon < 正常な稼働状態の表示 > ------------------------------------------------------------------------- |ホスト名 | 接続 | 検索サ−ビス | ポリシ−サ−ビス | Web隔離 | |-----------|-------------|---------------|------------------|----------| |hostB | 〆緑 | 〆緑 [停止] | 〆緑 [停止] | | ------------------------------------------------------------------------- * このコマンドは使わないのかな /etc/rc2.d には S99MANAGER はない。 # cd /usr/trend/imss/script << S99MANAGER が全部のコマンドをまとめて実行 # ./S99MANAGER stop するものだと思うが、どうも違うみたい。 Shutting down imssmgr 3339 ... << imssmgr は止まった。imssmgrmon は止まって なかった。画面は出たが接続は赤。 # ./S99MANAGER start << imssmgr も起動した。 画面は出て接続は緑に sh: postconf: 見つかりません。 なった。 問題なさそうだがおかしな表示が出 imssmgr is running. た。どうもコマンドとして不完全な気がする。 (4) InterScan7 の運用あれこれ4 * popper デ−モンがそこはかとなく止まる問題 `2b/03 2005年末に Mail-Store を新しいマシン Sun Solaris 9 にした。その際に POP3サ− バは Qpopper にした、その設定が以下である。オプションの -T600 は最初この値で稼働 させていた。しばらくして、いつだったか -T120 に変更した。 パソコンのメ−ルソフト が長時間 POP3 アクセスしたまま放さずにいて、 一杯 POP3デ−モンができて負荷がかか り、止まってしまうのでないかと思い、短めに変更したのだった。しかしその後2010 年の5月頃からだったか、そこはかとなく popper デ−モンが止まってしまう現象が起き るようになったのは。3ヶ月に一度ぐらい popper が止まって、一度止まったらまたすぐ その日の内に止まる。そんなことが数回おきた。 /etc/rc3.d/S99QPOPPER ------------------------------------------------- |#!/bin/sh |case "$1" in | "start") | /usr/local/qpopper408/sbin/popper \ Qpopper のバ−ジョンは主と予 | -s \ 備マシンで 4.05、4.08 である。 | -t /var/log/qpopper/qpopper.log \ | -R -S -T600 どうも Qpopper のオプションの挙動はちょっとおかしい。 -T600 と記述しているのに実 際には -T60 として稼働していたようである。# ps -ef で見ると表示が長くて -T600 の しまいの 0 が表示されていないと思っていたのだが、いろいろ確認したらやはり -T60と なっていたようである。それを -T120 に変更したのでは、 余計に悪い方向に設定してい たことになる。それで今回 -T100 にした。これでも popper が止まるようなら、-T60 と かにしてみるか。-s は syslog 経由でログを取る指示で、このままでも構わない。 /etc/rc3.d/S99QPOPPER ------------------------------------------------- |#!/bin/sh /var/log/syslog を見たけ |case "$1" in ど swap うんぬんというロ | "start") グは出てなかった。 | /usr/local/qpopper405/sbin/popper \ | -s \ | -R -S -T100 | ;; * 予備の Mail-Store を本番機として稼働させた `2b/04 ひょっとしてどこからか大量メ−ル爆弾の攻撃を受けたのでないか。お釈迦様の誕生日に 大量メ−ルが来たのでないか、そうではないみたいだ。停電が数分間起こって、UPSの クライアントソフトの設定ですぐさまマシンがシャットダウンの手続きに入った。5分ぐ らい止めるのに余裕をもたせておけばよかったのだが。そもそもマシンのハ−ドディスク の状態がおかしくなっていたようだ。それでマシンを起動しなしたら、起動してこなった ということみたいだった。それでとうとうダウンしてしまった。 予備の Mail-Store のマシンぶれ−どを動かすことにした。おかしくなったマシンを診て 30分で判断した。InterScan7 へのアクセス、https://xxxx:8455/IMSS.htmlの管理画面 のログイン画面は出る。しかしアカウントを入れても間違いですと跳ねらる。パスワ−ド が違ったのかと思ったがそうではなかった。PostgreSQLデ−モンに InterScan7 が接続で きないために、起きていた。PostgreSQLのデ−タベ−スの中でマシンのIPアドレスが保 存されているのだ。以下のようなメ−ルが1通きていて、おかしいなと思っていた。 katou@nix.co.jj から katou@nix.co.jj へ ---------------------------------------------- |件名:ポリシ−サ−バ通知(デ−タベ−ス) |本文:ポリシ−サ−ビスはデ−タベ−スサ−バと | クエリル−ルに接続することができません。 [ 本番機は 192.168.1.1、予備機は 192.168.1.2 とする ] # cd /opt/trend/imss/PostgreSQL/bin # ./psql imss sa Welcome to psql 8.1.5, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit imss=# select * from tb_global_setting where name='ConfigUrl'; section | name | value | inifile | notes ---------+-----------+-----------------------------+----------+------- cmagent | ConfigUrl | https://192.168.1.2:8445/ | imss.ini | (1 row) imss=# update xxx このコマンドで 192.168.1.1 を指定する。 # cd /usr2/trend/imss/script いったんデ−タベ−スを止めて起動して、他のも起動 # ./dbctl.sh stop する。PostgreSQLはこの時点では止まっているかもし れない。InterScan7を制御する起動スクリプトはたく # cd /etc/rc2.d さんある。いろいろやってみて、これらのスクリプト # ./S98dbctl start を使えばいいのでないかと思う。 # ./S99CMAGENT start # ./S99IMSSUI start sendmail と popperデ−モンは止めなくても構わない。 # ./S99MONITOR start ユ−ザからはメ−ルの送受信はいつもの通りである。 * IPアドレスの変更についてもう少し調べた `2b/10 トレンドマイクロのサイトに Trent Micro InterScan Messaging Security Suite 管理者 ガイドというのがある。admin_guide_imss71_lin_r1.pdf 5,737KB、更新日時 2011/05/21。 169ペ−ジに "サ−バのIPアドレスを変更するには" という記事がある。手順は8個 ある。手順の3、4、5番はマシンのIPアドレスの記載なのだが、自分とこで設定した のもそうだが 127.0.0.1 になっていた。3、4番は odbc.ini それに euqodbc.ini ファ イル。5番は xxx/WEB_INF/struts-config-common.xml ファイル内の 127.0.0.1の記述で、 もう既にそうなっていたのでいじることはない。 xxx/trend/imss/config/odbc.ini xxx/trend/imss/config/euqodbc.ini 関係する所 ------------------------------ --------------------------------- のみ表示。 |Servername=127.0.0.1 |Servername=127.0.0.1 問題は6番目の作業である。Tb_euq_db_info は触ることはない、 メ−ルを別なマシンに 隔離する場合に定義するのに用いる。以前、トレンドマイクロではなくSI業者のサポ− トに問い合わせした時には、Tb_global_setting の値の変更をするようにと教えてもらっ たと思う。しかしどうもこれは InterScan を複数管理するための Control Manager を使 っている場合に使う設定らしい。Control Manager を使わない、今回のような利用状態で は設定する必要はないらしい。必須の設定は Tb_component_list だけらしい。 一度ちゃ んと設定をやってみて確認してみないと。なんちゅうややこしい話やないの!。 # ./psql imss sa 変更の仕方はサポ−トに問い合わせされたい。 imss=# select * from tb_component_list; scanner_id | scanner_name | ip_addr | daemon | policy | euq ....| app_ver ------------+--------------+---------------+--------+--------+----‖---+-------- 1 | hostB | 192.168.1.2 | 2 | 2 | 0 ... 0 | 7.1 (1 row) 以上のことはトレンドマイクロのサイトを見れば、そこそこ英文での記事が出ていた。イ ンタ−ネットで検索していて、http://esupport.trendmicro.co.jp/corporate/ サポ−ト 情報のペ−ジがヒットしてきた。[製品Q&A検索] で {検索キ−ワ−ド} を入れ、{製品 名} と {バ−ジョン} を選んで調べよう。でも Windows OSでのことやら Linux やら。 (5) InterScan7 の運用あれこれ5 * なかなか安定しませんです `2b/04 InterScan にログインしようとするとできない。アカウントを入れると跳ねられる。こな いだと同じ症状だ。PostgreSQLが動いてないのでログインができなくなっている。imss関 係の動いているデ−モンはこれ。imssmgr が動いてないので、 S99MONITOR だけ再起動す ればいいのでないか。デ−タベ−スソフトを起動し S99MONITOR を再起動した。これで元 に戻った。予備の Mail-Store を本番機として稼働させ、1週間経って起きた事。 imssd は10個ぐらい動いていた、下のは表示を省略。またなるかも知れない。訳が分からんけ どこうやって対処するしかない。PostgreSQL を動かしてから #./psql imss sa とやって IPアドレスがどうなっているか見たが、ちゃんとなっていた。 # ps -ef | grep imss imss 13228 29257 0 13:07:25 ? 0:00 /usr2/trend/imss/bin/imssd root 28779 1 0 4月 11 pts/9 2:33 /usr2/trend/imss/UI/javaJRE/bin/ java -Djava.endorsed.dirs= -classpath /usr2/tre root 28792 1 0 4月 11 ? 0:00 /usr2/trend/imss/bin/imssmgrmon root 28977 1 0 4月 11 ? 1:56 /usr2/trend/imss/bin/imssps root 12347 1 0 13:00:00 ? 0:00 /usr2/trend/imss/bin/imsstasks root 29257 1 0 4月 18 ? 0:13 /usr2/trend/imss/bin/imssd # /etc/rc2.d/S98dbctl start これやったらログインできた。 しかし状態は3つとも赤、未接続。次をやったら3つ緑になった。 # cd /etc/rc2.d # ./S99MONITOR stop Shutting down imssmgrmon 28792 ... # ./S99MONITOR start imssmgrmon has started. ログインできなくなるのがしばしば。そのたんびに上の作業をやって安定しない。おかし くなって正常になるまで InterScan7 から管理者へ、ポリシ−サ−バ通知(デ−タベ−ス) のメ−ルが大量にきた。コンソ−ルにもメ−ルのメッセ−ジがどんどんでてきた。まさに DoS攻撃になっていた。 メ−ルを止めるには # /etc/rc2.d/S88sendmail stop をやる。 あるいは上のコマンドをちゃっと入れるかである。サポ−トセンタ−に現象を知らせてか ら、これが InterScan7 のバグで負荷が大きい時に出ると分かったのは2週間が経ってい た。対処にはパッチをあてる、バ−ジョンをあげることが必要である。 もはやメ−ルサ−バをメインメモリ 1 GB で動かしているなんてのは無謀なことなんだろ う。マシンは販売終了になっていて、メ−カからはもうメモリは買うことはできない。ネ ットで見たらなんぼでもこれら Sun のマシン用に売っている。 9500円のもあれば5 万円近いのもでている。メモリを入手してもマシンにメモリを追加したことをどうやって 認識させるのか。何がしかコマンドを打たないけないのか、そこらも調べないといけない。 しかしこれ以上へたにマシンに触って不安定要素を増やしたくはない。ぶいまるはディス クが修復できたので、Mail-Store の予備機としてスタンバイするように設定しておく。 5月の連休前にこのマシンをリブ−トした。このマシンとは予備としてずっとおいていた Solaris 9 のブレ−ド 2500 のことである。PostgreSQLを動かしたり止めたり何やかんや している内に、マシンの動作が不安定になってしまったかも。連休の間に止まったんでは 困るので、一度リブ−トすることを決意した。やったら、とんでもないことが起きたのだ が何とか対処できた。それ以降1ヶ月位は問題なく動いている。 どうも今の InterScan7 のバグでずっと動かしているとかつての Windowsサ−バみたいにメモリにゴミが溜まって 来るのではないか。それで Qpopper が止まったり、PostgreSQL が止まったりしたのでな いか。半年か年に一度はマシンをリブ−トした方がいいということかも知れない。 * いきなりブレ−ド 2500 が落ちた `2b/09 2a/06 中頃のある日の夕刻、いきなり Sun のマシンのブレ−ド 2500 が落ちた。 ブレ− ドとパソコンをKVMスイッチで切り替えて使っていた。最初KVMスイッチがおかしい のかと思ったが。Sun のサポ−トセンタ−へ問い合わせた。マシンが落ちたのは内部の温 度センサ−のバグである。パッチがあるのでそれを当てて下さい。それでもまだ落ちるよ うだったらハ−ドウェア System Board の交換ということになります。という返事だった。 予備機としてブレ−ドは置いてあったのだが、ブイ210が調子が悪くなったので置き換 えたばかりだった。その前だったらパッチうんぬんでなく、ボ−ドの交換をサポ−トにや ってくれと言ったかも知れないが。ともかく本番稼働に入ってしまっているので、パッチ を当てるのはどうかな、それに分からんし。とりあえず様子を見るかと1年以上が経過し 9月の半ばまた起こった。しかも休みの日にそこはかとなく止まってしまった。 /var/adm/messages 他 messages.0,1,2,3 ファイルのログを見て。 Sep 10 13:59:39 hostB picld[64]: [ID 845468 daemon.crit] SUNW_piclenvd: 'sys-in' sensor temperature 46 outside safe operating limits (0...45). | 同様の警告がずっと6分毎と30秒毎ぐらいで出ていた。 Sep 11 18:52:27 hostB picld[64]: [ID 845468 daemon.crit] SUNW_piclenvd: 'sys-in' sensor temperature 46 outside safe operating limits (0...45). | この間は警告なしで、いきなり温度異常になってマシンが落ちた。 Sep 23 23:31:13 hostB picld[64]: [ID 845468 daemon.crit] SUNW_piclenvd: 'int-amb0' sensor temperature -127 outside safe operating limits (0...70). Sep 23 23:31:13 hostB picld[64]: [ID 669686 daemon.alert] /usr/sbin/shutdown -y -g 60 -i 5 "" 前回の時のログでも "temperature 46" という46℃を検知したというのがしばらく出て、 "temperature -127"と言うのが一発出て、マイナス127℃を検知したので、マシンを緊 急停止します。それでいきなりシャットダウンのシ−ケンスに入った。やはり何とかしな いといけないが、もうこのマシンの保守契約は終了してしまった。パッチを当てるしか手 だてはない。昨年サポ−トに問い合わせた時、パッチは http://jp.sunsolve.sun.com/内 にあった。しかしその後サンはオラクルに買収された。今回 Google で調べたら先のサイ トではなく http://wesunsolve.net/patch/id/118558-35 にあった。最新は 118558-39で Release date: 2007-01-11、PATCH REQUIREMENTS 変わらず。 どうもこのパッチの履歴を 見ると、どうもブレ−ド 2500 特有のバグというわけではなく、Solaris 9 全般のバグよ うに見受けられる。でも Ultra45 や V210 では起きてはないけど。 ---------------------------------------------------------------- | http://wesunsolve.net/patch/id/118558-35 |--------------------------------------------------------------- | WE SUN SOLVE! | A heap of information about the Solaris operating system... |--------------------------------------------------------------- | Patch 118558-35 | Obsoleted by: 118558-36 Sun OS 5.9: Kernel Patch | | GENERAL INFORMATIONS | | Latest release of this patch: 118558-39 | Release date: 2006-11-07 | | | Download at Oracle MOS << これがパッチみたいである。16.66 MBytes。 | | BUNDLE / PATCH CLUSTERS | This patch is not integrated in any bundle << 118558-39の方を見ると、ここに | パッチらしき xxx.zip というの | PATCH REQUIREMENTS が幾つもあった。どれを選ぶの。 | | 112233-12 : SunOS 5.9: Kernel Patch | 113073-14 : SunOS 5.9: ufs and fsck patch | 116532-01 : | 117171-17 : SunOS 5.9: Kernel Patch * 安定しなかった原因は多分これ `2b/10 予備機を本番機にするためマシンのIPアドレスを変えて不安定になっていた。最初SI 業者に教えてもらったが、多分自分が勘違いして PostgreSQL内の tb_global_setting の 設定値を変えればいいと思ったのが誤りの元だった。tb_global_setting はむしろ関係な く from tb_component_list の値を変える必要があった。肝心な値が変わってないので挙 動がおかしかった。マシンをリブ−トしたら問題なく稼働するようにはなったのだが、マ シンをリブ−トすれば from tb_component_list 値は変わるのか、一度確認してみること。 InterScan( InterScan Messaging Security Suite ) の PostgreSQL のデ−タベ−スの肥 大化したのを削除するスクリプトを走らせて、マシンに問題が起きたことはない。 3回か4回やってみて問題ないと一応は分かってはいるのだが、どうも何か起きるのでな いかと毎度不安になる。クロ−ンでスクリプトを起動させるようにしてみるか。CTCの Solution DataBase の"IMSSのデ−タベ−スが肥大化する問題および解決方法"2010/01/22 最終更新日から。 PostgreSQL 内の pg_largeobject テ−ブルの物理サイズが大きくなり 続ける問題。cron でスクリプトを実行させる記述がある。imss のアカウントで実行する よう指定されている。InterScan Web Security Suite(IWSS)をインスト−ルしたら、設定 されていたクロ−ンが下の抜粋である。 IWSS でもこの問題は根本的には解決されていな いということか。db_reindex.sh もデ−タベ−スを小さくするのに関係するのか。 /var/spool/cron/iscan -------------------------------------------------------------- |28 0-23/2 * * * /usr/iwss/bin/db_reindex.sh > /dev/null 2>&1 これも関係する?。 |58 3 * * * /usr/iwss/bin/db_vacuum.sh > /dev/null 2>&1 一つ気になることがあって追記 `2e/03。クロ−ンでは処理はせずに、時折り # df -k と やってディスクの容量をチェックして /var が90%位になったら、手動で処理するよう にしている。# ./vacuum.sh コマンドを打つのだが、この際最後に & を付けた方がいい のか。これまであまり気にしたことはなかったが、 Apollo から Sun のマシンに telnet で入って # ./vacuum.sh をやったこともしばしばある。Apollo の内臓時計がおかしいの か telnet が5分ぐらいで勝手に切れるようになる。 こんな時に vacuum.sh をやってい たらどうなるのか。& を付けてバックグラウンドで実行するよう指示した方がいいのでな いか。Apollo ではバックグラウンドの指示なんだが、UNIX系ではどうだったか。 * Sun のマシンを稼働させてテスト用に一時的に使用する `2f/07/s メ−ルストアを Sun から FortiMail に置き換えて、Sun は一応予備として設定して電源 切って置いておいた。FortiMail の予備には完全にはならないが、まるでなにもないより まし。いつの間にか予備機のIPアドレスが別に使われてしまっていた。それでマシンの IPアドレスを変えることにした。/etc/hosts ファイルでの修正は、 これは特に記すま でもないだろう。InterScan 内部で使われている PostgreSQL に書き込まれたIPアドレ スを変更するのは手続きが少々必要だが、前に簡単なマニュアルを書いておいたのでその 通りにやった。メ−ルは都合により外に行かないようにした、簡単に sendmail-tx.cf の "DSsmtp:[192.168.2.1]" の前にコメント # を入れて、できるようにした。 InterScan の状況を確認しようと https://192.168.1.x:8445/imss.html やったらエラ− になった。画面は出たが "HTTPS Status 404 - /imss.html" というのだった。 末尾の指 示が IMSS.html と大文字でないとまずい。 URLでの指示は大文字、小文字関係ないと 思っていたが違ったか。テスト用のパソコンでのメ−ル送受信の確認。Outlook でメ−ル 送信はできたが何か偉く時間がかかり、受信はできない。/var/mail/mqueue-rx にメ−ル が溜まっていた。InterScan の管理画面を見たら {検索サ−ビス} と{ポリシ−サ−ビス} が赤になっていた。それぞれ [接続] をクリックしたら2つとも緑になり、できた。ファ イアウォ−ルのフィルタリングのことも、かつての本番設定を見てやっておいた。 ------------------------------------------------------------------------------------ [ 付録 ] いきなり Sun のマシンが温度センサ−異常で落ちる件 * とりあえずの対策は `2b/09 -------------------------------------------------------------------------------- |$ telnet 192.168.1.1 手元の Apollo コンピュ−タから常時監視する |------------------------------------------------------------------------------- |Sep 26 14:57:38 hostB sendmail[4900]: [ID 801593 mail.alert] p8Q5vcIT004899: | Dropped invalid comments from header address |Sep 26 14:57:38 hostB last message repeated 1 time telnet で Mail-Store にアクセスしていると /var/adm/messages のログがコンソ−ルに 順々に出てくる。さて syslog.conf と hosts ファイルのどこがコンソ−ルにログを出す 指示になっているのか。 "Dropped invalid comments from header address" このログは 一日に十ぐらいは出てくる。sendmail.cf の設定で、このログは出さないようにできると 聞いた。その時、何らかのメ−ルの攻撃ですとSI業者のエンジニアは話していた。とも かく telnet でメ−ルストアの様子をこれで監視するようにした。それとは別にクロ−ン により /var/adm/messages ファイルに "temperature" キ−ワ−ドが出てないかチェック するのをやってみてもいい。 10分毎にその10分以内に "temperature" が出現したか を判定して、もしあればメ−ルで知らせる。スクリプトを書くのはちょっとめんどいか。 /etc/syslog.conf ------------------------------------------------------------------ |*.err;kern.notice;auth.notice /dev/sysmsg |*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages |*.alert;kern.err;daemon.err operator |*.alert root |*.emerg * |mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost) |# non-loghost machines will use the following lines |# to cause "user" log messages to be logged locally. |ifdef(`LOGHOST', , |user.err /dev/sysmsg |user.err /var/adm/messages |user.alert `root, operator' |user.emerg * |) /etc/hosts ---------------------------------------------------- |192.168.1.1 hostB hostB hostB.nix.co.jj loghost * ずっとの対策をやるには `2b/10 懇意にしているSI業者のカスタマ−・エンジニアが別件でやってきた。その際にこんな 不具合が起きることがあるんだけど、何か分かりますかと聞いてみた。そしたらよく知っ ていて、そこそこ起きる問題だという。ブレ−ド 2500 ならボ−ドの温度センサ−の異常 ではなく、ソフトウェアの問題だという。picld というプロセスがOSで動いていて、こ のソフトウェアの不具合とのこと。Solaris 9 では部分的なパッチはなく、カ−ネルのパ ッチに統合されているとの話だった。 # showrev -a コマンドでどんなパッチが当たって いるかリストされるので、それを見たらやはり当たってなかった。カ−ネルのパッチは約 16メガバイト、一応これだというのも教えてもらった。 カ−ネルのパッチを当てなくて回避するには、picld デ−モンを止めてしまえばいいとの こと。でもこれを停止させると prtdiagコマンドなどでのシステムの監視ができなくなる。 prtdiag を使ったのは V210 マシンのハ−ドディスクがおかしくなった際にサポ−トに問 い合わせて、これこれのコマンドを打ってくれと言われた時の一回である。ただしそれで トラブルの原因が分かった訳ではなかった。ブレ−ド2500 は保守は切れている。prtdiag コマンドを使う事は多分ない。自分ではコマンド叩いたログの内容は理解できないし。ハ −ドディスクの状態を表示する # metastat コマンドが、付随して使えなくなるとか。そ んなことが起きないと確認できれば、もう picld は停止させてもいいだろう。 # ps -ef | grep picld root 64 1 0 9月 24 ? 0:10 /usr/lib/picl/picld # /etc/init.d/picld stop * picld を止めてみました `2c/02〜03 Sun のマシンがおかしくなって、エンジニアさんが駆けつけるなり、電話でログを取るこ とを指示される場合。# prtdiag -v というのはよく叩くコマンドらしい。 ハ−ドウェア の状態が以下のような出始めで、こと細かに出てくる。これは V210 にてやった。 # prtdiag -v System Configuration: Sun Microsystems sun4u Sun Fire V210 System clock frequency: 167 MHZ Memory size: 1GB | System PROM revisions: ---------------------- OBP 4.11.4 2003/07/23 08:04 Sun Fire V210/V240,Netra 240 OBDIAG 4.11.4 2003/07/23 08:05 他にも指示されたのでは、# pkginfo -l は出てくるのがやたら長い、# prtconf -v はす ぐ終る、metastat -t、showrev -a、df -k、cfgadm -al、iostat -En などである。picld を止めたら何がでなくなるのか Sun V210 マシンでやってみた。そしたら出なくなったの は prtdiag -v だけだった。 # prtdiag -v picl_initialize failed: Daemon not responding << picld を止めてのログ。 どうも picld が動いてなくても Mail-Storeとしてメ−ルサ−バ機能には、影響しそうに ない。またまた別件で、Sun のマシンを前に触っていたエンジニアさんがやってきたので 彼にも診てもらいながらエイヤで picld を kill しました。 このままではマシンの電源 を入れ直したら /etc/init.d/picld が起動スクリプトにより、また picld は動いてしま う。これはどうすればいい?。/etc/init.d/ 内の制御はどうすればいいのかな?。 とも く暑くなる前にやっておきたかった。これまで2回起きたのは暑い月、日だった。 "分からない、見えない、でも暑い夏の年にあいつは現われるの、森の化け物が" * しまった!また起こしてしまった また出てきました。暑い日ではなく寒い日。 `2d/12 の初めの日、えらく冷える夜だった。 朝、Sun のブレ−ド2500 が温度異常で停止していた。 昨日の夜9時過ぎのことだったよ うだ。#/etc/init.d/picld stop でデ−モンを止めた。またこのマシンでは下記のように 再度起動してこないようにスタ−トアップの制御ファイルをいじった。他の Solaris 9の マシン Ultra45 と V210 もまだ本番機、予備機で動いている。ついでに picld を止めた。 マシンを移動したりした事があって、停止そしてまた起動したので picld が動いたのだ。 /etc/init.d/picld --------------------------------------------- |#!/sbin/sh |case "$1" in |'start') | if [ -x /usr/lib/picl/picld ]; then |# /usr/lib/picl/picld << コメントにするだけでよかったのに。 | fi 前に起こった時にやっておけばよか | ;; った。マシンがいったん動けば、そ |'stop') れで安堵してしまって。詰めをやら | /usr/bin/pkill -x -u 0 '(picld)' ずにおいてしまう、いかんいかん!。 | ;; |*) | echo "Usage: $0 { start | stop }" | exit 1 | ;; |esac %) |exit 0 これで大丈夫と安心していた。1ヶ月ちょっとして夕方、メ−ルソフトで送受信でエラ− が出た。メ−ルストアのマシンに ping 打ったら反応なし。サ−バル−ムに行ってマシン のコンソ−ルを見たら起動プロセスが走っていた。そして1分もしない内に正常稼働にな っていたのだが。/var/adm/messages を見ても異常らしきログはなかった。温度センサ− 異常はハ−ドウェアのレベルで起きているのでないか。picld デ−モンは止めているので、 その異常を検知できなかった。検知できればマシンを止めるプロセスが走る。安全にマシ ンを止めるということ。それが検知できなかったので、温度センサ−は働いてマシンが異 常を起こし、いきなり止まって起動してきたのでないか。いずれにせよOSのバグであり、 それなりのパッチを当てないことには根本的な解決にはならないということだろう。