連載
» 2002年08月28日 10時00分 UPDATE

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

本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント(不正アクセス)に関する情報を紹介する。(編集局)

[JPCERT/CC,@IT]

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

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

完全性(integrity)の確認、保証

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

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

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

※ チェックサムを計算する方法には、MD5のほかにSHA1、RMD160などがある。


 計算結果は、必ず「別のシステム上に」保存しておく。同じシステム上に保存してしまうと、それらの情報すらも攻撃者によって改ざんされる可能性があるからである。例えば、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コマンドのファイルの内容が少しでも変更されると、チェックサムの値が異なるので、事前に保存しておいた値と比較することで改ざんの有無を確認することができる。

※ もちろんmd5やmd5sumコマンド自体についても同様にチェックサムの値を保存しておくなどして、完全性を確認しなくてはいけない。


 さらにコマンドだけでなく、そのコマンドが起動時に動的にリンクする共有ライブラリについても同様にチェックサムを保存しておく。そのコマンドがリンクしている共有ライブラリは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も、事前に保存したチェックサムの値と比較して改ざんされていないかどうかを確認する必要がある。

※ OSによってはlddではなく、別のコマンドを用いる必要がある。詳細については各OSのマニュアルを参照してほしい。以下にいくつかの例を紹介する。

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

また、WindowsならばCygwinhttp://www.cygwin.com/)のGNU binutilsに含まれるobjdumpを次のように実行して調べる方法などがある。

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など)だけでも、このような外部メディアに保存しておくべきであろう。また可能であるならば、外部メディアに保存するコマンドは共有ライブラリを用いない形式、つまりすべてのライブラリを静的にリンクしたバイナリの形式で作成し直したものにしておくことをお勧めする。

※ 静的にリンクする方法はコンパイラ(リンカ)によって異なるが、GCCの場合は-staticオプションを用いる。詳細は使用しているコンパイラ(リンカ)のマニュアルを参照してほしい。


システムの改ざんの例

(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などの外部メディアに保存しておき、比較できるようにしておくとよい。

ユーザー登録 /etc/passwd、/etc/shadow、/etc/master.passwd、/etc/groupなど
サービスの追加(バックドアの設置など) /etc/inetd.conf、/etc/servicesなど
アクセス制御の設定 /etc/hosts.deny、/etc/hosts.allowなど
パスワードなしでのログイン許可設定 /etc/hosts.equiv、~/.rhosts、~/.shostsなど
電子メール(転送設定など) /etc/aliases、~/.forwardなど
システムの起動処理 /etc/rc*、/etc/rc?.d/*、/etc/init.d/*など
ログイン時の処理 ~/.cshrc、~/.bashrc、~/.bash_profile、/etc/profile、/etc/csh.*など
ログ取得 /etc/syslog.confなど
cron処理 /etc/crontab、/var/spool/cron/crontabs/*、/var/cron/tabs/*など
そのほか /etc/ssh/sshd_config、 /etc/ttys、 /etc/ttytab など

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

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

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

※ 例えば、OpenBSDでは、/etc/changelistに列挙されたファイルに対して、そのような確認処理を行うように標準で設定されている。


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

※ Tripwire には、商用版http://www.tripwire.co.jp/)とオープンソース版http://www.tripwire.org/)があり、商用版はSun Solaris、Windows NT、HP-UX、IBM AIXに対応している。


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

改ざんツール「rootkit」

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

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

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

※ すでに広く知られているrootkitに対しては、その存在を検知するためのツールが存在する場合がある。しかし、それらのツールはあくまで既知のrootkitに対する検知ツールであり、すべてのrootkit、特に新しいrootkitに対しても有効であるとは限らないことに注意してほしい。


メモリの痕跡などから調べるツール「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

■コラム 〜JPCERT/CC の国際活動〜

 今回は、日本を代表するCSIRTとしての、JPCERT/CCの国際的な活動について紹介する。


(1) FIRST(Forum of Incident Response and Security Teams)


 FIRSTは、世界中のCSIRT同士の情報交換やインシデントレスポンス業務の協力関係を構築する目的で、1990年に米国CERT/CCなどが中心となって設立されたフォーラムである。設立当初は10数チームであった参加チームも現在は100を超えている。JPCERT/CCは、1998年8月に正式メンバーとなった。2002年 8月現在、日本からFIRSTに参加しているのはJPCERT/CCとIIJ-SECT(IIJ Group Security Coordination Team)のみである。なお、FIRSTの正式メンバーになるためには既存メンバーによる推薦が必要である(http://www.first.org/team-info/)。


 参加チームは、JPCERT/CCのような地域に根ざしたCSIRTばかりではなく、企業や大学、軍などの自組織向けにサービスを提供するCSIRTや自社製品のセキュリティ関連情報の分析、公開などを行なっているCSIRTなど多岐に渡っている。


※ CSIRTの種類については、連載第1回のコラムを参照してほしい。


 FIRSTは、年に1回、6月にAnnual Computer Security Incident Handling Conferenceを開催している。これはFIRST参加メンバーの親睦を深めたり、インシデント関連情報を交換することなどを目的に開かれているが、そのほかにも最新のセキュリティ関連技術についてのチュートリアルがあるなど、FIRSTのメンバー以外も参加することができるオープンな国際会議である。


 本年のConferenceは、6月24日〜28日までの間、ハワイのHilton Waikoloa Villageで行われた。本年のConferenceで興味深かったのは、今回の連載でも紹介したTCT(The Coroner's Toolkit)の作者であるDan Farmer氏とWietse Venema氏自らによるTCTの解説や、最近利用者が増えてきているPalm OSに対するインシデントの発見方法に関するセッションがあったことである。ほかにもインシデントの痕跡(Forensics) を発見するための基礎知識として、さまざまなファイルシステムについての解説などがあり、インシデントレスポンスに役立つ技術的な内容が盛りだくさんであった。このような技術的な話題だけでなく、法的な問題に関する提言などがあるなど、Conferenceの内容は年々広範囲に渡ってきている。


 なお、来年のConferenceは、6月22日〜27日の間、カナダのオタワで開かれる。詳細は、http://www.first.org/conference/2003/を参照してほしい。


(2)APSIRC(Asia Pacific Security Incident Response Coordination)


 国際的なフォーラムであるFIRSTに対し、アジア太平洋地域のCSIRTのフォーラムであるAPSIRCが存在する。これは1998年にCERTCC-KR(韓国)、SingCERT(シンガポール)、JPCERT/CCなどが中心となってボランタリに始まったものであるが、この数年間はほとんど活動らしい活動はなく、事実上休止状態にあった。


 しかし、2002年3月24日〜26日の間、JPCERT/CCが主催となり、東京でAPSIRC 2002の名前で会議を開催することで活動を再開した。この会議には、アジア太平洋地域の 13のCSIRTおよび 3つの関連組織(11地域)が集まった。また、FIRSTからもSteering Committee memberが参加した。


※ 参加チームなどについては APSIRC 2002 の Web サイトhttp://www.jpcert.or.jp/apsirc/)を参照してほしい。


 アジア太平洋地域のCSIRTがこれだけの規模で一堂に会したのは、実は今回が始めてである。そして改めて分かったのは、アジア太平洋地域のCSIRTにはFIRSTに参加していないチームが多いだけでなく、地域を代表しているCSIRTとはいってもボランティア組織とほとんど変わらない規模で細々と活動しているチームがあるということである。


 さらにインターネットに接続はしているがCSIRTの存在しない地域が多いことも分かった。そのうえで、各地域やチームごとに抱えている問題やインシデントの趨勢など、多岐に渡った情報交換が行えたことの意味は大きい。


 APSIRCは、本格的な活動を始めたばかりであり、まだ具体的な組織形態や活動内容などは明確になっていない。しかし、今回のAPSIRC 2002をきっかけに情報共有などを通じたCSIRT同士の協力関係の強化、CSIRT設立支援などさまざまな課題が山積していることが浮き彫りになってきた。各地域、各チームの抱えている背景があまりに大きく異なっているため、これらの課題を解決していくことは決して容易なことではないが、大きな経済格差の存在や情報インフラの進み方のずれなど、アジア太平洋地域の特徴を踏まえたフォーラムの設立は意義深い。


 現在JPCERT/CCは、APSIRCの活動について中心的な立場で関わっている。今後APSIRCに関して進展があった場合は、できるだけ積極的に紹介していく予定である。


Profile

JPCERT/CC

JPCERT/CCとは、Japan Computer Emergency Response Team/Coordination Center(コンピュータ緊急対応センター)の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティインシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに日本で最初に加盟したCSIRT。


[an error occurred while processing this directive]

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。