復旧への道
以上で調査作業は終了である。何らかの異常個所を発見できただろうか。 不正アクセスを受けていることを確信したのであれば，今後の方針について考えなければならない。
冒頭でも述べたが，コンピュータが不正アクセスを受けたら，決して不正アクセス者によって改ざんされた個所を修復しただけで，運用を続けようなどと考えてはならない。すみやかに再インストールし，バックアップからデータを書き戻して復旧させなければならない。たとえコンピュータの汚染個所を完全に取り除けたとしても，いったい誰がそのことを保証してくれるのだろうか。コンピュータのどこかに，おそらくほかのバックドアが隠されている。それらは巧妙に隠されているはずだ（別掲記事「危険を承知の復旧方法」を参照）。
一方で，異常個所がいっさい発見されなかった場合はどうすべきだろうか。この場合は，コンピュータに異常がないか，高度な技術を持った不正アクセス者によって汚染されている場合のどちらかである。コンピュータがどちらの状態にあるかを判別するには，次に紹介するモニタリングなどの方法により，さらに粘り強く調査作業を続けるしかない。あまり時間が残されていないのであれば，いっそのことコンピュータを再インストールして，不安要素を丸ごと取り除いてしまうのも賢い選択である。
ここではコンピュータが不正アクセスを受けていることが確実な場合を考えてみる。もしコンピュータが不正アクセスを受けたのであれば，そのコンピュータを復旧させるのはもちろん，どれくらい被害が広がっているのかも慎重に推測する必要がある。
もし同様の構成のコンピュータが，被害を受けたコンピュータと同じネットワークに存在するのなら，そのコンピュータにまで影響が及んでいる可能性が高い。また，被害を受けたコンピュータと同じネットワーク上を流れたすべてのデータ（パケット）は盗聴されていることを前提に考えなければならない。
真っ先にパスワードの存在が頭に浮かぶだろう。同じアカウントとパスワードの組み合わせで他のコンピュータにアクセスしている利用者が存在したら，即刻それらのパスワードをすべて変更し，アクセス状況を徹底的に調査すべきである。インターネット・バンキングなどとアカウント情報を共通化している利用者を予想してみてほしい。単にコンピュータが不正アクセスを受けただけでは済まなくなる。
情報システムが生活基盤の一部になりつつある現在，不正アクセス被害は非常に深刻な事態を引き起こす可能性がある。このことを，我々システム管理者は肝に銘じておかなければならない。間違っても，揉み消すことなどを考えてはならない。被害状況を正確に把握し，被害の拡大を防がなければならない。
このためには，今回調査対象となったコンピュータはもとより，その付近にあるコンピュータすべてを調査しなければならない。もちろん，現実的にこのような作業は不可能に近いかもしれない。このような事態を招かないよう，コンピュータの運用には細心の注意を払ってほしい。
モニタリングによる調査
これまでの調査で不正アクセスの痕跡がまったく発見されないにもかかわらず，何らかの理由でコンピュータが信頼できない状態にあるなら，そのコンピュータの通信をすべて傍受することにより，不正アクセスの痕跡を検出する手法が有効である。これを「モニタリング」と呼ぶ。
モニタリングに用いるアプリケーションは数多く存在する。ここでは多くのPC-UNIXパッケージに含まれ，Windows NT上でも動作する「tcpdump」を取り上げる。モニタリングは被害を受けたホスト上で行うことも可能だが，信頼性の観点から同じネットワーク・セグメントに接続された別のホストを使用するのが無難である。
| ||
|
実際にモニタリングするには，ネットワーク・セグメントの構成に注意する。例えば，スイッチング・ハブで構成されているネットワークでは，異なるポート間のモニタリングはできない。いったん共有ハブなどを経由して，被害を受けたホストとモニタリングを行うホストが同じトラフィックを受け取れる環境を用意しなければならない（図27[拡大表示]）。スイッチング・ハブがポート・ミラーリングのような機能を装備していれば，それを利用してもよい。
また，モニタリングを行うホストのセキュリティにも注意してほしい。モニタリング・ホストは，ネットワーク経由の接続をいっさい受けないように構成すべきである。
被害を受けたホストのトラフィックをすべてモニタリングするには，モニタリング・ホスト上で図28[拡大表示]のようにtcpdumpを動作させる。これはIPアドレス192.168.0.1のホストに対する通信を傍受する場合の記述である。コマンドに続く「not src host 192.168.0.1」が通信元のホスト（自分以外のすべて），「dst host 192.168.0.1」が通信先のホスト（自分自身）を示している。「and」キーワードで両方の条件が成立したトラフィックだけを記録するようにtcpdumpに指示している。
このように，tcpdumpを使用して適当な期間モニタリングし，不審な通信が発生していないかを監視する。1～1024番ポート（well-known port）以外の特定のポートに多くのトラフィックが集中していないか，well-knownであってもntpやdomainなどに特定のホストから必要以上に多くのトラフィックが集中していないか，などについて特に注意する。
実際にモニタリングを試してみると，いくつかの不具合に気づくだろう。例えば，Webやftpサービスを稼働しているホストの場合，それらに対するリクエストがすべて記録されてしまうため，ログの量が膨大になってしまう。
そこで「tcpdump -qpni eth0 not src host 192.168.0.1 and dst host 192.168.0.1 and not tcp port 80」のように適当なパラメータをtcpdumpに渡して，極端に多いリクエストは記録しないようにする。このコマンドでは，最後のand以降でhttp通信（tcp/80）をすべて無視するように指定している。
 |
| 図29●tcpdumpを使って効率良くモニタリングするコマンド例 |
また，特定のネットワークからの通信を記録したくない場合は，netキーワードを使って「tcpdump -qpni eth0 not src host 192.168.0.1 and dst host 192.168.0.1 and not src net 172.16 and not dst net 172.16」のように指定する。1台のホストでhttp，ftp，mail，dnsのサービスを提供しているような環境では，図29[拡大表示]のように指定することで，効率良く記録できるようになるだろう。
疑わしいシステムをリモートから監視し，不審なアクセスを発見したら，前述したfuserやlsofなどのコマンドを使用して，そのオーナ・プロセスを探し出す。
ただし，バックドアの中には非常に巧妙に作られているものがある。筆者の知っている限りでは，ある長さのICMPパケットを送った場合に限り，あるUDPポートが開くといったバックドアが存在する。ここまで巧妙なバックドアは，モニタリングでしか発見できないかもしれない。システムから排除することはまず不可能であろう。あきらめてシステムを再構築してしまった方が効率的である。
なお，tcpdumpの詳しい使用方法については，manやJM projectのホームページ（http://www.linux.or.jp/JM/index.html）などを参照するとよいだろう。
|
危険を承知の復旧方法 ここでは，あえてタブーに触れてみよう。代替のシステムが用意できるまで，何とかして現在の不正アクセスを受けたコンピュータで運用を続けたいと望むシステム管理者は少なからず存在するだろう。重ねて言うが，これはあってはならないことである。 しかし，実際に不正アクセスを受けた現場では，何とかしてサービスだけでも継続させたいと望むだろう。このような場合，次に説明する手法で運用を再開できるかもしれない。 繰り返すが，完全性はまったく保証されない。それどころかリスクが高すぎる。しかし，必要な場合もあるだろう。危険を承知の復旧法だと考えてほしい。 （1）汚染されたバイナリの除去 （2）ぜい弱点の修復 （3）フィルタリング |
|
渡辺 勝弘 |
