インシデントを発見する方法（2）- システムの改ざんを検知する方法 -：管理者のためのセキュリティ推進室〜インシデントレスポンス入門〜（3）

　前回は、インシデントを発見するうえで最も簡単な方法である、ログの内容を確認したり、システムの現在の状態を確認する方法を紹介した。しかし、「侵入」という深刻なインシデントが発生し、その結果としてシステムの設定などが改ざんされてしまった状況では、同時にログが改ざんされたり、システムの状態を確認するためのコマンドが改ざんされることで「侵入」や「改ざん」の痕跡が隠滅され、インシデントの発見が困難になってしまうことが多い。

　そこで今回は、まずコマンドが改ざんされていないかどうかを確認する方法を紹介する。そのうえでシステムに対する改ざんの一般的な例やそれらの改ざんを検知するためのツールなどを紹介する。

完全性（integrity）の確認、保証

　前回紹介したような、ログを確認したり、システムの状態を確認するためのコマンドが“信用できる”、つまり改ざんされていないこと（完全性：integrity）を、それらのコマンドを実行する前に必ず確認しなくてはならない。以下ではその方法を紹介する。

（1） チェックサム (メッセージダイジェスト、フィンガープリント)

　まずあらかじめ改ざんされていないことが保証されている状態で、インシデントを発見する際に用いるコマンドに対してMD5などでチェックサムを計算する。

　計算結果は、必ず「別のシステム上に」保存しておく。同じシステム上に保存してしまうと、それらの情報すらも攻撃者によって改ざんされる可能性があるからである。例えば、netstatコマンドのMD5のチェックサムは以下のように実行して調べることができる。

・BSD系OSの場合

% md5 /usr/bin/netstat
MD5 (/usr/bin/netstat) = 21787e9d74f95f2cf578e12882e9f962

・Linuxなどの場合

% md5sum /bin/netstat
21787e9d74f95f2cf578e12882e9f962 /bin/netstat

　ここで表示された「21787e9d74f95f2cf578e12882e9f962」という文字列（32けたの16進数）がMD5によるチェックサムの値である。もし、netstatコマンドのファイルの内容が少しでも変更されると、チェックサムの値が異なるので、事前に保存しておいた値と比較することで改ざんの有無を確認することができる。

　さらにコマンドだけでなく、そのコマンドが起動時に動的にリンクする共有ライブラリについても同様にチェックサムを保存しておく。そのコマンドがリンクしている共有ライブラリはlddコマンドなどを次のように実行することで調べることができる。

% ldd /usr/bin/netstat
/usr/bin/netstat:
-lkvm.6 => /usr/lib/libkvm.so.6.0 (0x40033000)
-lc.28 => /usr/lib/libc.so.28.0 (0x40038000)

　これは、netstatコマンドが起動時に、/usr/lib/libkvm.so.6.0と/usr/lib/libc.so.28.0というライブラリをリンクするという意味である。従って、netstatコマンドを実行する前には、netstatコマンドだけでなく、/usr/lib/libkvm.so.6.0と/usr/lib/libc.so.28.0も、事前に保存したチェックサムの値と比較して改ざんされていないかどうかを確認する必要がある。

Darwin (MacOS X) otool -L
HP-UX chatr
SGI IRIX elfdump -L

objdump -p /cygdrive/c/WINNT/system32/netstat.exe | grep dll

　共有ライブラリを用いず、すべてのライブラリを静的にリンクしているコマンドもある。その場合はlddを実行すると次のように表示される（表示内容の詳細はOSによって異なる）。

% ldd /bin/ps
ldd: /bin/ps: not a dynamic executable

　この場合は、そのコマンドのチェックサムだけを保存しておけばよい。

（2）ファイルサイズ、最終更新時刻

　コマンドが改ざんされた場合、そのコマンドのファイルサイズが変わったり、最終更新時刻が最近の時刻になっていることが多い。従って、コマンドのファイルサイズや最終更新時刻を事前に保存しておき、それらの情報と比較することで完全性を確認する方法も、ある程度は有効である。

　しかし、最終更新時刻を改ざんすることは比較的容易であり、またファイルサイズを変更せずにコマンドを改ざんすることも 決して不可能ではないということに注意してほしい。

（3）外部メディアへの保存

　上記のような、システムが改ざんされていないことが保証されている状態と現在のシステムを比較する方法よりも、より確実にコマンドの完全性を保証する方法としては、事前にそれらのコマンドをフロッピーディスクやCD-Rなどの外部メディアに保存しておく方法がある。

　特に、上記のようなチェックサムを計算する際に用いるコマンド（md5やmd5sumなど）だけでも、このような外部メディアに保存しておくべきであろう。また可能であるならば、外部メディアに保存するコマンドは共有ライブラリを用いない形式、つまりすべてのライブラリを静的にリンクしたバイナリの形式で作成し直したものにしておくことをお勧めする。

システムの改ざんの例

（1）ファイルの設置

　UNIX系OSの場合、侵入が行われた後には、/tmpや/var、/dev以下にバックドアなどを設置するためのプログラムの痕跡が残されることが多くある。

　まず、lsコマンドなどを用いて不審なファイルが存在しないかどうかを確認する。特に不審なファイルは.（ピリオド）で始まるファイル名（隠しファイル）であることが多い。lsコマンドを用いる場合は、-aオプションを付けて実行することを忘れないでほしい。

　また、/tmpなどの特定のディレクトリに限らず、以下のように実行することで、システム全体に不審な隠しファイルが存在しないかどうかを確認することも大切である。

find / -name ".*" -ls | cat -v

　ただし、findやlsのようなファイル名を表示するコマンドが特定の名前のファイルやディレクトリを表示しないように改ざんされている可能性がある。「完全性（integrity）の確認、保証」の項で紹介したように、それらのコマンドの完全性を確認してから作業を行ってほしい。

（2）ファイルの属性の変更

　ファイル自体を改ざんするのではなく、ファイルのアクセス権限（属性、モード）を変更し、本来特定のユーザー以外が閲覧できないように設定されたファイル（ログやメールなど）をほかのユーザーでも読めるように変更されている場合がある。特に、管理者以外がアクセスできないようなファイル、およびそのアクセス権限の一覧などをあらかじめ用意しておき、権限の設定が変更されていないかどうかを確認する。

　また、正規のコマンドのまま内容は改ざんされていないが、本来の設定と異なる属性としてsetuid やsetgidが設定されている場合がある。これは管理者以外のユーザー権限のまま、管理者以外はアクセスできないファイルにアクセスしたり、管理者以外は実行できない処理を行うなどの目的で行われたと考えられる。

　このような場合は、以下のように実行して、システム上のsetuidやsetgidされたファイルの一覧を表示させて、不審な設定変更が行われていないかどうかを確認する。

find / -user root -perm -4000 -ls
find / -group kmem -perm -2000 -ls
find / \( -perm -004000 -o -perm -002000 \) -type f -ls

（3）設定変更

　以下に挙げた設定ファイルは、一般的に改ざんの対象となることが多い。不審な設定が追加されたり、書き換えられていないかどうかを確認する。そのために、あらかじめ正常な状態でのファイルをFDやCD-Rなどの外部メディアに保存しておき、比較できるようにしておくとよい。

　ただし、上記のファイルはOSによってファイル名が異なるので、使用しているOSに合わせて適宜読み替えてほしい。

改ざんのチェックを行うツール「Tripwire」

　コマンドやシステムの設定ファイルなどが改ざんされていないかどうかをチェックする方法として、自動的に、かつ定期的に特定のファイルをあらかじめ保存しておいたデータと比較し、変更があった場合にメールなどで報告するなどの方法がある。

　しかし、この方法では、あらかじめ保存してあるファイルに関する情報が改ざんされてしまった場合には用をなさない。そこでこのようなチェックを行なう専用のツールとして、Tripwireが広く用いられている。

　Tripwireでは、ファイルに関する情報を保存しているデータベースファイルや設定ファイルなどを暗号化することで改ざんを防いでいる。しかし、たとえTripwireでも、Tripwireのコマンド自体が改ざんされたり、データベースのファイルを削除されてしまった場合には対応不能である。「完全性（integrity）の確認、保証」の項で紹介したような方法でTripwireのコマンド自体の完全性を確認するとともに、データベースファイルなどの必要なデータを外部メディアにバックアップすることを忘れてはいけない。なお、Tripwireの使い方については、Tripwireのマニュアルを参照してほしい。

改ざんツール「rootkit」

　かつてはシステムの改ざんや、その隠ぺいのためのログやコマンドの改ざんは、攻撃者によって1つ1つ手動で行われることが多かった。しかし現在は、これらの処理をほぼ半自動的に行うためのツールとしてrootkitと呼ばれるソフトウェアが使われるようになってきている。

　rootkitは、日々機能が追加され、改ざんの内容や手法がより巧妙になってきている。特に最近では、システムのカーネルモジュールとして稼働し、システムコールのレベルで改ざんを行うrootkitが現れた。このrootkitは、コマンドのファイル自体は一切変更せず、システムコールを書き換えることで改ざんを隠ぺいするので、コマンドのチェックサムを確認したり、別メディア上に保存した完全性の保証されたコマンドを用いても、それらの処理を改ざんされたシステム（OS）上で行う限り、改ざんを検知することは極めて困難となる。

　もちろん 上記で紹介したTripwireを使っても検知することはほとんど不可能である。この場合は、完全性の保証された別のシステムに、調べたいシステムのハードディスクをマウントし、完全性の保証されたコマンドなどを、別のシステム上で実行することで、改ざんの有無を確認する以外に確実な方法はない。

メモリの痕跡などから調べるツール「TCT」

　システムの完全性を確認するための方法として、Tripwireのような、ファイルの情報を事前に保存しておき、それと現在の情報を比較するという方法のほかに、メモリ上に残された痕跡やファイルシステムに残っているファイルの断片などを拾い上げ、そこからシステム上に起こったインシデントの詳細を調べる方法がある。

　そしてこれらの膨大な処理を、ある程度自動的に行うためのツールがある。そのようなツールとして有名なのがTCT（The Coroner's Toolkit：http://www.porcupine.org/forensics/tct.html）である。これはtcp_wrappersやPostfixなどの作者として有名なDan Farmer氏とWietse Venema氏によって開発された。TCTの具体的な使い方については、TCTのWebサイト（http://www.porcupine.org/forensics/tct.html）を参照してもらうとして、ここで注意してほしいのは、TCTは大変便利で優れたツールではあるが、「完璧ではない」ということである。

　インシデントの内容によっては、またTCTの使い方によってはかえってインシデントの痕跡を消してしまうこともあり得る。またTCTが収集する情報はあまりに膨大であるため、その中からインシデントの痕跡を見いだすことは、決して容易なことではない。意味のあるデータを得ることができずに徒労に終わる可能性もある。そこまでの作業の手間をかけてインシデントの詳細を調べるより、まず先にシステムの復旧を行った方がよい場合もあるであろう。システム管理者は、取り巻く状況を十分に考慮したうえでTCTを使うか否かを判断してほしい。

　2回にわたり、「インシデントを発見する方法」として一般的な方法を紹介した。紹介した内容はあくまで一般的なものであり、OSや使用環境によってファイル名やコマンドのオプションなどの詳細は異なることがある。記事の内容を参考にして、自サイトにあった「チェックリスト」を作成することを強くお勧めする。

　次回は、インシデントを発見した後の対応手順について説明する。

■参考文献

[1] Intruder Detection Checklist
http://www.cert.org/tech_tips/intruder_detection_checklist.html

[2] CIAC-2305 Unix Incident Guide: How to Detect an Intrusion
ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2305.pdf
　ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2305.txt

[3] Windows NT Intruder Detection Checklist
http://www.auscert.org.au/Information/Auscert_info/Papers/win_intruder_detection_checklist.html