« セキュリティインシデント3 | トップページ | 同姓同名多すぎー2 »

2006.02.11

セキュリティインシデント4

研究室のサーバが外部から不正侵入を受けた。サーバを止めてみると、いくつか見えてきたことが。

サーバを止めてしまうと、計算も出来ない、メールも受け取れないという困った状態になる。OSを再インストールし、それらを復旧させるのに1週間ほどかかってしまった。復旧作業を続けながらも、侵入方法を探してみる。というのも、侵入方法が分かれば、どこをしっかりと守れば良いのか考える参考になるから。利用者のパスワードが簡単すぎたのか? プログラムのセキュリティホールなのか? IPアドレスを偽装してうまく侵入したのか? 実は、これがなかなか分からなかった。仕方が無いので、あちこちガチガチに守った結果、新しいサーバは、利用者に使い勝手の悪いものになってしまった。

侵入方法が分からず、いつから侵入されていたのかも良く分からないので、まずは侵入者の痕跡を探してみた。侵入されてしまった以上、確かなことは何も言えないが、どうやら、侵入後、そのことが管理者に見つからないように偽装工作をしていたようだ。ネットワークの接続状況を表示するのに使う netstat というソフトが改竄されていた。また、今後は簡単に侵入できるように、アカウント管理などに用いるNISの設定が変えられ、sshdというサービスも改竄されていた。さらに、ネットワークカードの設定を盗聴モードに変更するようにもしてあった。他にも改竄されているところがあったかも知れない。最近は、このような不正侵入+偽装工作も簡単に行えるようにツールが配布されているらしい。まあ、初心者でも簡単にコンピュータが使えるようになったきたのだから、初心者でも簡単に不正侵入出来ても不思議ではない。さらに、侵入後、他のPCへ不正侵入を試みた痕跡もあった。これは、適当にパスワードを推測してログインするというものだった。このツールが eggdrop なのかも知れない。

肝心の侵入経路は、メールサーバの設定をしているときに分かった。メールサーバの設定方法を調べるのに、インターネットで検索していると、2年以上前のセキュリティホールの報告が目に付いた。この問題には対応したように記憶していたが、念のために調べてみた。すると、以前使っていたメールサービスは、この問題を抱えたものだった。

「あれ?」「この不具合は有名で、対応したと思うのだが....」とノートに記された管理ログをたどってみても修正の記録は無い。過去のメールを調べてみても、2年以上、ずっと問題のある古いプログラムを用いていたことが分かった。駄目ではないか!

改めて、ログをよく確認すると、普段は現れないメッセージが
rejecting connections on daemon MTA: load average: 12

これかも?
このメッセージ自体は、「負荷が大きいのでサボります」という意味だが、メールの流量は小さいので、普段はこのメッセージが現れることは滅多に無い。加えて、このログの時刻が、侵入されたと思われる時刻にとても近い。確証はないものの、そのような理由から、「メールサーバ経由の侵入」で、「侵入されたときにログが "rejecting ...."」なのかなと、個人的に思っている。
メールサーバ経由での侵入の手口を調べれば推測どおりなのか確認できるのだろうが、そこへ労力を注ぐ時間的な余裕がないので、追跡はここまでとした。

しかし、なぜ、修正したつもりになっていたのか?古い記憶と記録をだどってみると、どうやらこの時期、私はサーバの管理を後輩に引き継いで任せていたようだ。不具合を知ったときに、私の管理するコンピュータではすぐに対応し、研究室のサーバでも対応するように、後輩にメールしたり、口頭で何度か注意したりしていたのだが、そのままになっていた。

教訓: 身から出たさび

|

« セキュリティインシデント3 | トップページ | 同姓同名多すぎー2 »

パソコン・インターネット」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/1418/8606864

この記事へのトラックバック一覧です: セキュリティインシデント4:

« セキュリティインシデント3 | トップページ | 同姓同名多すぎー2 »