他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。
また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。
「第4回 攻撃者が侵入後に行うバックドアの設置例」では、バックドアを仕掛ける手法の事例をいくつか紹介した。今回は、それらのバックドアへの対処と検知方法について説明する。
対処法 - バックドアを仕掛けられてしまったら
侵入やバックドアの痕跡を見つけた時点で、サーバ管理者はどのような対処をすべきか？ という問いに対して、読者の皆さんなら何と答えるだろうか。持っている意見は人それぞれだろうが、共通項目として、おそらくほとんどの方が「原因究明」と「復旧」を挙げるのではないかと思う。
- 原因究明
侵入やバックドアの手口、攻撃者の特定、被害状況の調査 - 復旧
バックドアが設置される前の安全な状態に戻す
本稿では、これらの対処法について説明する。説明は原因究明、復旧の順に行うが、これらの対処をどちらから先に行うかについては、置かれている状況やその組織のポリシーや管理者の考え方によって異なるため、ここではあえて触れないことにする。
原因究明 - バックドアと侵入痕跡の調査
まずは侵入やバックドアの手口、攻撃者の特定、被害状況の調査から行う。本作業は、早急に本来のサービスを再開させるため、迅速かつ的確に行う必要がある。そのため、理想をいえばこのような最悪の事態に備え、どういった調査が必要になるのかについて、あらかじめ文書などにまとめておくのがよいだろう。そうしておくと、実際に突然その状況下に置かれた場合でも、比較的慌てずに調査を行うことができ、また操作ミスを誘発する可能性も減るだろう。
原因究明の前に（暫定策の実施と準備）
原因究明の前に行わなければならないことがいくつかある。
- 不審なサーバはネットワークから切り離す
- 改ざんされていない安全なコマンドの準備
- 調査用パソコンの準備
- メモと時計の準備（※追加）
1.ネットワークから切り離す
もし、より厳密な原因究明を行いたい場合は、対象サーバをこの時点でネットワークから切り離さない方がよいだろう。例えば通信中のネットワークの状況などは、そのままの状態で調査しないと、より確実な情報を得ることができないからだ。なお、ここで切り離さない場合は、遅くとも後述の「原因究明の手順」が終了した時点で切り離すようにしよう。
そうではなく、厳密な調査よりもこれ以上被害を拡大させたくない（別サーバに影響を及ぼしたくない）場合は、この時点で対象サーバを物理的に従来ネットワークから切り離そう。そして切り離した後は、原因究明のために独立したネットワークに接続し直すとよいだろう。
2.安全なコマンドの準備
バックドアにより原因究明の際に使用するコマンドが改ざんされていた場合、正しい結果が得られない恐れがある。そういったケースを考慮して、あらかじめスタテイックバイナリ形式の安全なコマンド群をCD-ROMなどのメディアに格納しておき、原因究明の際に対象サーバ上でマウントして使用するとよい。
もちろん実行するコマンドは、確実にそのメディアのものが使用されるように、絶対パスを指定する必要がある。＊1なお、本稿では安全なコマンドが/cdrom/bin以下に格納されているものとして話を進める。
このことは、LKM（ローダブルカーネルモジュール）型のバックドアの前では、無意味になってしまうことに注意が必要である。
3.調査用パソコンの準備
調査用のパソコンを1台準備し、対象サーバと同じネットワークに接続して調査することをお勧めする。調査自体は対象サーバにリモートログインしてから行うことになるが、ログインと同時に、バックドアによる何らかの不具合が発生したり、いままさに侵入している攻撃者に気付かれてしまい、証拠陰滅や重要なファイルを消されてしまう可能性もある。そのため調査は十分慎重に行う必要がある。特に侵入中の攻撃者を刺激するような行為は絶対に行ってはいけない。その場合は、速やかに対象サーバをネットワークから切り離した方が無難だろう。
ログイン時およびログイン後の調査作業は、一般ユーザー権限で行うことをお勧めする。管理者権限（root）で行わないのは、万が一操作ミスがあった場合にシステムに与える影響が一般ユーザーと比べて大きくなるためだ。そのため管理者権限は、必要な時（後述のlsof、find、chkrootkit、tarなど）のみ使うようにし、それ以外は一般ユーザー権限で調査することをお勧めする。このことは、通常のサーバ運用においても同じことがいえるだろう。
なお、調査用のパソコンを準備できない場合は、対象サーバのローカルコンソールからログインし調査を行うことになるが、リモートログインと同様、通常は一般ユーザー権限で調査することをお勧めする。
4.メモと時計の準備（※追加）
調査時に実行したコマンドの時刻や結果については、後述のscriptコマンドによる記録とは別に、紙に記録しておくことをお勧めする。そのためには、メモ用紙、筆記用具、時計を忘れずに用意しておくこと。また、対象サーバのシステム時計が実際の時刻とずれていた場合は、その差異を記録しておくこと。
原因究明の手順
では、原因究明の手順を追ってみよう 。
- 調査コマンド実行内容の保存（script）
- ログイン履歴のチェック（w、last）
- 実行プロセスのチェック（ps）
- 通信のチェック（netstat、lsof、nmap）
- MAC timeの採取（mac-robber）（※追加）
- 不審なファイルのチェック（find、strings）
- バックドアツールの検出（chkrootkit）
- ログと調査結果の収集
1.調査コマンド実行内容の保存（script）
まずは原因究明のために実行した一連のコマンドとその結果をログとして保存する。保存するにはscriptコマンドを使うとよい。
調査用のパソコンがある場合は、scriptコマンドを調査用パソコンのターミナル上で実行すればよいが、そうでない場合は対象サーバで実行することになる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
本稿内の実行コマンドの先頭の「%」は一般ユーザー権限、「#」は管理者権限（root）によるコマンドの実行を意味する。
これ以降、このターミナルで実行した結果はすべて/tmp/chousa.logファイルに格納される。なお、scriptコマンドを終了したい場合は、exitを実行すればよい。
2.ログイン履歴のチェック（w、last）
w、lastコマンドを使い、だれが、いつ、どこからログインし、何を実行したのかを確認する。
（1）w（現在のユーザー状況の表示）
現在ログイン中のユーザーが何をしているかを調査する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記では、172.16.10.10（FROM）からrootログインし（USER）、vi（上記ではvimコマンド）でsshd_configファイルを編集している（WHAT）ことが分かる。
（2）last（ログイン履歴の表示）
過去のログイン履歴を調査する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記から以下のことがうかがえる。
- 現在ログイン中のユーザー（still logged in）は、y-kimuraとrootである。
- ユーザーkimu が1月16日の3:34?3:39の間ログインしていた。
- サーバを再起動（リブート）したのは、1月13日20:32である。
上記結果より、外部（172.16.10.10）からrootでログインしている不審なログイン履歴があるのを確認できる。
3.実行プロセスのチェック（ps）
psコマンドを使い、不審なプロセスが存在するかどうかを調査する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
その結果、前回仕掛けたバックドアプロセス（emacs、xinetd）を確認することができた。
4.通信のチェック（netstat、lsof、nmap）
不審な通信を見つけ出すためには内部と外部の双方から調査を行う必要がある。
（1）内部からの調査 （netstat、lsof）
サーバ内部から調査するためには、netstatやlsofといったコマンドを使用するとよい。
- netstat を使う
netstatコマンドを使うと、現在接続中の通信の様子やサーバで待機しているポートを割り出すことができる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ProtoがtcpでStateがLISTENの行は、このサーバで待機しているTCPポートを示し、StateがESTABLISHEDの行は接続中のTCPの通信を示している。また、Protoがudpの行は待機しているUDPポートを示している。
- lsofを使う
lsofコマンドを使って、netstatと同じような通信の様子を出力することができる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（2）外部からの調査（nmap）
- nmapを使う
netstatやlsofで内部から調査しても、前回紹介したadoreのようなLKM型のバックドアを使用して特定の通信を隠ぺいされると検出することができない。そういった場合、外部から対象サーバに対してポートスキャンを行うのがよいだろう。ここではnmapを使用して、ポートスキャンを実施する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記は全TCPポート（1-65535）に対してポートスキャンを行っている。必要であればUDPスキャン（-sU）も行うとよい。出力結果として、8888/tcpという見慣れないポートが待機中であることが分かる（第4回の「xinetdのバックドア」の項目参照）。
5.MAC timeの採取（mac-robber）（※追加）
現時点の対象サーバ上の全ファイルのタイムスタンプ（MAC time）を採取しておく。MAC timeを採取するには、既存のコマンドであればls（-l, -ul, -clオプション）やstatを使えばよい。ツールであればDan FarmerとWietse Venema両氏のThe Coroners Toolkit(TCT)のGrave-robberや@stakeのmac-robberなどが知られている。ここでは、後々の解析が容易な@stake提供のmac-robberを使ったMAC timeの採取例を紹介する。
なお、MAC timeの採取にはそれなりの時間を要してしまう。そのため、ネットワークに接続したままの状態（オンライン）で本作業を行うと、被害が拡大する可能性もより高くなることを十分に理解しておく必要がある。安全性をとるのであれば、この時点で対象サーバをネットワークから切り離し（オフライン状態にして）、MAC timeを採取した方が無難だろう。
（1）コンパイル
mac-robberを展開しコンパイルする。コンパイルが完了するとmac-robberという実行ファイルができあがる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
標準ではスタティックリンク形式(gccで-static指定)の実行ファイルmac-robberが作成される。このmac-robberは、先述の安全なコマンド群が格納されているCD-ROMに格納しておくとよいだろう。
（2）実行 （MAC timeの採取）
全ファイルのMAC timeをローカルディスクの/tmp/mactime.logに出力したい場合は、以下のとおり実行すればよい。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
また、結果をローカルディスクのファイルに出力せずに、調査用パソコン(192.168.0.142)上のmactime.logファイルに出力する場合は、netcatを使うという方法もある。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
この場合、調査用パソコンの2222/tcpにて、
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
を事前に実行する必要がある。
（3）解析 （TASK mactime）
mac-robberの結果を解析するには、@stake提供のTASKに含まれるmactime（TCTのmactimeをベース）を使えばよい。なお、本作業はここでは行わず、後でじっくりと調査した方がよいだろう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記の例は、先述のmac-robberで採取したログ（/tmp/mactime.log）より、2003年1月10日から2003年1月20日までに更新されたMAC timeの情報を出力している。なお、日付部分はMM/DD/YYYYの形式で指定する（-yオプションでYYYY/MM/DDの形式）。
6.不審なファイルのチェック（find、strings）
（1）setuid（setgid）ファイルのチェック
findコマンドを使い、サーバ上のsetuid（setgid）されたファイルの中で、不審に思われるものが存在するかどうかをチェックする。以下はその一例である。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
指定したオプションの-type f はファイルタイプがファイルのもののみ表示するようにし、-perm、-u+sおよび-perm、-g+sで、setuid、setgidされたファイルをそれぞれ表示している。また、-lsを追加し、lsコマンド形式でファイルの詳細内容の表示も行っている。
上記の実行結果には、前回作成したバックドアCGIプログラムの/var/www/cgi-bin/.exploitも検出されていることが分かる。
（2）バイナリファイルのチェック （strings）
不審なバイナリファイルを見つけたら、stringsコマンドを使い、それがどういったことを行っているのかチェックする。strings によってすべてが分かるというわけではないが、大体の内容を把握するにはちょうどよいだろう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
C言語のprintf、system、setuidといった関数が呼び出され、さらにはemacsコマンドを実行し特定IPアドレス（172.16.10.10）に出力を試みているCGIプログラムであることが分かる。
7.バックドアツールの検出（chkrootkit）
chkrootkitは、Nelson Murilo氏が中心となって開発を進めているUNIX用のバックドア検出ツールで、主な特徴は以下のとおりとなり、chkrootkitを用いた検出方法を見ていこう。
| chkrootkitの特徴 |
|---|
| 既知のバックドアの検出 |
| プロミスキャスモードの検出 |
| lastlogの改ざんチェック |
| wtmpxの改ざんチェック（Solarisのみ） |
| LKM型バックドアの検出 |
| ファイル中の文字列チェック |
（1）コンパイル
chkrootkitを実行するために必要な各種コマンド群をコンパイルする。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
check_wtmpx、chkdirs、chklastlog、chkproc、chkwtmp、ifpromisc、stringsといった実行形式のファイルが生成される。これらのファイル（コマンド）は、シェルスクリプトのchkrootkitから実行されるので、通常は個別に実行する必要はない。
（2）実行前に
実行する前にchkrootkitのオプションを確認しておく。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
| オプション | 説明 | |
|---|---|---|
| -h | ヘルプメッセージの表示 | |
| -V | chkrootkitのバージョン表示 | |
| -l | テストモード | |
| -d | デバッグモード | |
| -q | 必要最小限のメッセージ出力 | |
| -x | 詳細モード | |
| -r dir | チェックしたいルートディレクトリの指定 | |
| -p dir1:dir2:dirN | chkrootkitで使用するコマンドが格納されているディレクトリ |
また、-lを指定して、検査対象となる各種プログラムも確認しておく。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（3）実行
実行は単に./chkrootkit とすればよいが、ここでは-qで必要最小限の情報のみを出力し、-pで安全なコマンドが格納されているパス（/cdrom/bin）を指定した。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
実行結果より、inetdの改ざんおよびRamen wormと思われるバックドアが検出されたことが分かる。なお、現chkrootkitのバージョンは、LKMのチェックが甘いのか、残念ながら前回紹介したadore LKMを正しく検出することができない。
8.ログと調査結果の収集
（1）ログの収集
後でじっくりと調査するため、ログやシステムファイルのバックアップを取り、調査用のパソコンにでも転送しておくことをお勧めする。各種ファイルを収集するには、tarコマンドを使用するとよい。tarコマンドは複数のファイルを1つにまとめてくれる機能を持つ（アーカイブ）。ここではシステムファイルが/etc以下、ログが/var/log以下のディレクトリに格納されているものとして説明する。また、tarはGNU版のtarを使用し、zオプションでgzipによる圧縮を行うことにした。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
実行した結果、/tmp以下にbackup-etc.tar.gzとbackup-varlog.tar.gzが作成される。なお、アーカイブした結果を確認する場合は、次のとおり実行すればよい。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（2）調査結果の収集
実行したコマンドの履歴（/tmp/chousa.log）やログやシステムファイルのバックアップを、バックアップメディアか調査用のパソコンにファイル転送し、後でじっくりと自分で調査するか、専門機関に調査を依頼すればよい。もちろんすべてを専門機関に依頼するという選択肢もある。なお、採取したログ（chousa.log）やバックアップファイルは、MD5ハッシュなどでそれ自身の整合性も忘れずに保存しておこう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
また、調査ログおよびアーカイブデータのバックアップが完了した時点で、これらのファイルは対象サーバから削除しておこう。
【重要】なお、調査結果は耐火金庫などに入れ厳重に保管しておくとよいだろう。（※追加）
コラム 〜 MAC timeの重要性（※追加）
「5. MAC timeの採取」でも紹介したが、原因究明の際に重要な手掛かりとなり得る、MAC timeについて少し解説しておく。
UNIXやWindowsなどのファイルシステムでは、おのおののファイルやディレクトリにmtime、atime、ctimeといった3つの時刻属性（タイムスタンプ）が保存されている。これらの時刻属性は、それぞれの頭文字を取ってMAC timeと呼ばれている。
| 時間 | 意味 | 時刻の変更条件＊1 |
|---|---|---|
| mtime | ファイルの最終修正時刻 | ファイルの内容が変更された場合（ファイル操作でmknod（2）、truncate（2）、utime（2）、write（2）などのシステムコールを利用した場合） |
| atime | ファイルの最終 アクセス時刻 | ファイルの内容にアクセスした場合 （ファイル操作でexecve（2）、mknod（2）、pipe（2）、utime（2）、read（2）などのシステムコールを利用したファイル操作を行った場合） |
| ctime | ファイル情報の最終変更時刻 | ファイルへの書き込みやiノード情報を変更した場合（ファイル操作でchmod（2）、chown（2）、mknod（2）、link（2）などのシステムコールを利用した場合） |
| 表1 UNIXにおけるMAC time | ||
表1に示すとおり、MAC timeには、対象サーバ上で行ったさまざまなファイル操作のタイムスタンプが保持されている。こういった情報は、侵入者（あるいはバックドア）が、いつ、どのファイルを作成、改ざん、アクセスしたのかを特定するための重要な手掛かり（証拠）にもなり得る。そのため、MAC timeを取り扱う場合は、以下の点に注意しながら十分慎重に行うことをお勧めする。
- 原因究明の際は慎重に
原因究明で行う手順（実行するコマンド）によっては、現時点のファイルのMAC timeを変更してしまう可能性があることに注意すること。例えば、「原因究明の手順」で使用しているstringsコマンドの場合、実行すると対象ファイルである.exploitの最終アクセス時刻（atime）が変更されてしまう。そのため、MAC timeは、そういったコマンドを実行する前に採取した方がよい。
- MAC timeは改ざん可能
MAC timeは、必ずしも正確な情報であるとは限らないことに注意しよう。なぜならMAC timeは、侵入者（バックドア）によって意図的に改ざんされている可能性があるからだ。
- MAC timeの保持精度の違い
原因究明や証拠保全のためにバックアップしたデータを、本来とは異なるファイルシステムに戻す場合、戻す先のファイルシステムが記録できる時刻の精度（分解能）によっては、MAC timeが変更してしまう可能性がある。
例えば、UNIXファイルシステムのデータをWindowsのFATにコピーした場合、各ファイルのMAC timeは偶数秒になってしまう。これは、FATのファイル作成日時が偶数秒単位でしか記録できないためで、UTC 1970年1月1日0時0分0秒から秒単位で記録しているUNIXファイルシステムのファイルをFATにコピーすると、奇数秒はすべて偶数秒に繰り上げとなってしまう。このことは、NTFSからFATにおいても同様の問題が発生する。
【参考】マイクロソフト サポート技術情報
［NT］NTFSからFATへのファイルのコピー時に日時が変わる
http://support.microsoft.com/default.aspx?scid=kb;ja;JP402160
Copyright © ITmedia, Inc. All Rights Reserved.