-:管理者のためのセキュリティ推進室〜インシデントレスポンス入門〜(3)本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント(不正アクセス)に関する情報を紹介する。公開[JPCERT/CC,@IT]前回は、インシデントを発見するうえで最も簡単な方法である、ログの内容を確認したり、システムの現在の状態を確認する方法を紹介した。「侵入」という深刻なインシデントが発生し、その結果としてシステムの設定などが改ざんされてしまった状況では、同時にログが改ざんされたり、システムの状態を確認するためのコマンドが改ざんされることで「侵入」や「改ざん」の痕跡が隠滅され、インシデントの発見が困難になってしまうことが多い。そこで今回は、まずコマンドが改ざんされていないかどうかを確認する方法を紹介する。そのうえでシステムに対する改ざんの一般的な例やそれらの改ざんを検知するためのツールなどを紹介する。したような、ログを確認したり、システムの状態を確認するためのコマンドが“信用できる”、つまり改ざんされていないこと(完全性:integrity)を、それらのコマンドを実行する前に必ず確認しなくてはならない。以下ではその方法を紹介する。(メッセージダイジェスト、フィンガープリント)まずあらかじめ改ざんされていないことが保証されている状態で、インシデントを発見する際に用いるコマンドに対してMD5などでチェックサムを計算する。チェックサムを計算する方法には、MD5のほかにSHA1、RMD160などがある。計算結果は、必ず「別のシステム上に」保存しておく。同じシステム上に保存してしまうと、それらの情報すらも攻撃者によって改ざんされる可能性があるからである。netstatコマンドのMD5のチェックサムは以下のように実行して調べることができる。/bin/netstatここで表示された「21787e9d74f95f2cf578e12882e9f962」という文字列(32けたの16進数)がMD5によるチェックサムの値である。netstatコマンドのファイルの内容が少しでも変更されると、チェックサムの値が異なるので、事前に保存しておいた値と比較することで改ざんの有無を確認することができる。md5やmd5sumコマンド自体についても同様にチェックサムの値を保存しておくなどして、完全性を確認しなくてはいけない。コマンドだけでなく、そのコマンドが起動時に動的にリンクする共有ライブラリについても同様にチェックサムを保存しておく。そのコマンドがリンクしている共有ライブラリはlddコマンドなどを次のように実行することで調べることができる。(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のマニュアルを参照してほしい。以下にいくつかの例を紹介する。binutilsに含まれるobjdumpを次のように実行して調べる方法などがある。dll共有ライブラリを用いず、すべてのライブラリを静的にリンクしているコマンドもある。その場合はlddを実行すると次のように表示される(表示内容の詳細はOSによって異なる)。executableこの場合は、そのコマンドのチェックサムだけを保存しておけばよい。(2)ファイルサイズ、最終更新時刻コマンドが改ざんされた場合、そのコマンドのファイルサイズが変わったり、最終更新時刻が最近の時刻になっていることが多い。従って、コマンドのファイルサイズや最終更新時刻を事前に保存しておき、それらの情報と比較することで完全性を確認する方法も、ある程度は有効である。不可能ではないということに注意してほしい。上記のような、システムが改ざんされていないことが保証されている状態と現在のシステムを比較する方法よりも、より確実にコマンドの完全性を保証する方法としては、事前にそれらのコマンドをフロッピーディスクやCD-Rなどの外部メディアに保存しておく方法がある。上記のようなチェックサムを計算する際に用いるコマンド(md5やmd5sumなど)だけでも、このような外部メディアに保存しておくべきであろう。可能であるならば、外部メディアに保存するコマンドは共有ライブラリを用いない形式、つまりすべてのライブラリを静的にリンクしたバイナリの形式で作成し直したものにしておくことをお勧めする。静的にリンクする方法はコンパイラ(リンカ)によって異なるが、GCCの場合は-staticオプションを用いる。詳細は使用しているコンパイラ(リンカ)のマニュアルを参照してほしい。システムの改ざんの例(1)ファイルの設置UNIX系OSの場合、侵入が行われた後には、/tmpや/var、/dev以下にバックドアなどを設置するためのプログラムの痕跡が残されることが多くある。lsコマンドなどを用いて不審なファイルが存在しないかどうかを確認する。不審なファイルは.(ピリオド)で始まるファイル名(隠しファイル)であることが多い。lsコマンドを用いる場合は、-aオプションを付けて実行することを忘れないでほしい。/tmpなどの特定のディレクトリに限らず、以下のように実行することで、システム全体に不審な隠しファイルが存在しないかどうかを確認することも大切である。-vただし、findやlsのようなファイル名を表示するコマンドが特定の名前のファイルやディレクトリを表示しないように改ざんされている可能性がある。「完全性(integrity)の確認、保証」の項で紹介したように、それらのコマンドの完全性を確認してから作業を行ってほしい。(2)ファイルの属性の変更ファイル自体を改ざんするのではなく、ファイルのアクセス権限(属性、モード)を変更し、本来特定のユーザー以外が閲覧できないように設定されたファイル(ログやメールなど)をほかのユーザーでも読めるように変更されている場合がある。管理者以外がアクセスできないようなファイル、およびそのアクセス権限の一覧などをあらかじめ用意しておき、権限の設定が変更されていないかどうかを確認する。setgidが設定されている場合がある。これは管理者以外のユーザー権限のまま、管理者以外はアクセスできないファイルにアクセスしたり、管理者以外は実行できない処理を行うなどの目的で行われたと考えられる。このような場合は、以下のように実行して、システム上のsetuidやsetgidされたファイルの一覧を表示させて、不審な設定変更が行われていないかどうかを確認する。以下に挙げた設定ファイルは、一般的に改ざんの対象となることが多い。不審な設定が追加されたり、書き換えられていないかどうかを確認する。そのために、あらかじめ正常な状態でのファイルをFDやCD-Rなどの外部メディアに保存しておき、比較できるようにしておくとよい。上記のファイルはOSによってファイル名が異なるので、使用しているOSに合わせて適宜読み替えてほしい。改ざんのチェックを行うツール「Tripwire」コマンドやシステムの設定ファイルなどが改ざんされていないかどうかをチェックする方法として、自動的に、かつ定期的に特定のファイルをあらかじめ保存しておいたデータと比較し、変更があった場合にメールなどで報告するなどの方法がある。OpenBSDでは、/etc/changelistに列挙されたファイルに対して、そのような確認処理を行うように標準で設定されている。この方法では、あらかじめ保存してあるファイルに関する情報が改ざんされてしまった場合には用をなさない。そこでこのようなチェックを行なう専用のツールとして、Tripwireが広く用いられている。AIXに対応している。Tripwireでは、ファイルに関する情報を保存しているデータベースファイルや設定ファイルなどを暗号化することで改ざんを防いでいる。Tripwireでも、Tripwireのコマンド自体が改ざんされたり、データベースのファイルを削除されてしまった場合には対応不能である。「完全性(integrity)の確認、保証」の項で紹介したような方法でTripwireのコマンド自体の完全性を確認するとともに、データベースファイルなどの必要なデータを外部メディアにバックアップすることを忘れてはいけない。Tripwireの使い方については、Tripwireのマニュアルを参照してほしい。改ざんツール「rootkit」かつてはシステムの改ざんや、その隠ぺいのためのログやコマンドの改ざんは、攻撃者によって1つ1つ手動で行われることが多かった。現在は、これらの処理をほぼ半自動的に行うためのツールとしてrootkitと呼ばれるソフトウェアが使われるようになってきている。rootkitは、日々機能が追加され、改ざんの内容や手法がより巧妙になってきている。最近では、システムのカーネルモジュールとして稼働し、システムコールのレベルで改ざんを行うrootkitが現れた。このrootkitは、コマンドのファイル自体は一切変更せず、システムコールを書き換えることで改ざんを隠ぺいするので、コマンドのチェックサムを確認したり、別メディア上に保存した完全性の保証されたコマンドを用いても、それらの処理を改ざんされたシステム(OS)上で行う限り、改ざんを検知することは極めて困難となる。上記で紹介したTripwireを使っても検知することはほとんど不可能である。この場合は、完全性の保証された別のシステムに、調べたいシステムのハードディスクをマウントし、完全性の保証されたコマンドなどを、別のシステム上で実行することで、改ざんの有無を確認する以外に確実な方法はない。広く知られているrootkitに対しては、その存在を検知するためのツールが存在する場合がある。それらのツールはあくまで既知のrootkitに対する検知ツールであり、すべてのrootkit、特に新しいrootkitに対しても有効であるとは限らないことに注意してほしい。メモリの痕跡などから調べるツール「TCT」システムの完全性を確認するための方法として、Tripwireのような、ファイルの情報を事前に保存しておき、それと現在の情報を比較するという方法のほかに、メモリ上に残された痕跡やファイルシステムに残っているファイルの断片などを拾い上げ、そこからシステム上に起こったインシデントの詳細を調べる方法がある。これらの膨大な処理を、ある程度自動的に行うためのツールがある。Toolkit:http://www.porcupine.org/forensics/tct.html)である。Venema氏によって開発された。TCTの具体的な使い方については、TCTのWebサイト(http://www.porcupine.org/forensics/tct.html)を参照してもらうとして、ここで注意してほしいのは、TCTは大変便利で優れたツールではあるが、「完璧ではない」ということである。インシデントの内容によっては、またTCTの使い方によってはかえってインシデントの痕跡を消してしまうこともあり得る。TCTが収集する情報はあまりに膨大であるため、その中からインシデントの痕跡を見いだすことは、決して容易なことではない。意味のあるデータを得ることができずに徒労に終わる可能性もある。そこまでの作業の手間をかけてインシデントの詳細を調べるより、まず先にシステムの復旧を行った方がよい場合もあるであろう。システム管理者は、取り巻く状況を十分に考慮したうえでTCTを使うか否かを判断してほしい。2回にわたり、「インシデントを発見する方法」として一般的な方法を紹介した。紹介した内容はあくまで一般的なものであり、OSや使用環境によってファイル名やコマンドのオプションなどの詳細は異なることがある。記事の内容を参考にして、自サイトにあった「チェックリスト」を作成することを強くお勧めする。次回は、インシデントを発見した後の対応手順について説明する。国際活動〜今回は、日本を代表するCSIRTとしての、JPCERT/CCの国際的な活動について紹介する。Teams)FIRSTは、世界中のCSIRT同士の情報交換やインシデントレスポンス業務の協力関係を構築する目的で、1990年に米国CERT/CCなどが中心となって設立されたフォーラムである。設立当初は10数チームであった参加チームも現在は100を超えている。JPCERT/CCは、1998年8月に正式メンバーとなった。Team)のみである。FIRSTの正式メンバーになるためには既存メンバーによる推薦が必要である(http://www.first.org/team-info/)。参加チームは、JPCERT/CCのような地域に根ざしたCSIRTばかりではなく、企業や大学、軍などの自組織向けにサービスを提供するCSIRTや自社製品のセキュリティ関連情報の分析、公開などを行なっているCSIRTなど多岐に渡っている。CSIRTの種類については、連載第1回のコラムを参照してほしい。Conferenceを開催している。これはFIRST参加メンバーの親睦を深めたり、インシデント関連情報を交換することなどを目的に開かれているが、そのほかにも最新のセキュリティ関連技術についてのチュートリアルがあるなど、FIRSTのメンバー以外も参加することができるオープンな国際会議である。Villageで行われた。OSに対するインシデントの発見方法に関するセッションがあったことである。発見するための基礎知識として、さまざまなファイルシステムについての解説などがあり、インシデントレスポンスに役立つ技術的な内容が盛りだくさんであった。このような技術的な話題だけでなく、法的な問題に関する提言などがあるなど、Conferenceの内容は年々広範囲に渡ってきている。来年のConferenceは、6月22日〜27日の間、カナダのオタワで開かれる。詳細は、http://www.first.org/conference/2003/を参照してほしい。Coordination)国際的なフォーラムであるFIRSTに対し、アジア太平洋地域のCSIRTのフォーラムであるAPSIRCが存在する。これは1998年にCERTCC-KR(韓国)、SingCERT(シンガポール)、JPCERT/CCなどが中心となってボランタリに始まったものであるが、この数年間はほとんど活動らしい活動はなく、事実上休止状態にあった。2002の名前で会議を開催することで活動を再開した。3つの関連組織(11地域)が集まった。memberが参加した。サイト(http://www.jpcert.or.jp/apsirc/)を参照してほしい。アジア太平洋地域のCSIRTがこれだけの規模で一堂に会したのは、実は今回が始めてである。分かったのは、アジア太平洋地域のCSIRTにはFIRSTに参加していないチームが多いだけでなく、地域を代表しているCSIRTとはいってもボランティア組織とほとんど変わらない規模で細々と活動しているチームがあるということである。インターネットに接続はしているがCSIRTの存在しない地域が多いことも分かった。そのうえで、各地域やチームごとに抱えている問題やインシデントの趨勢など、多岐に渡った情報交換が行えたことの意味は大きい。APSIRCは、本格的な活動を始めたばかりであり、まだ具体的な組織形態や活動内容などは明確になっていない。2002をきっかけに情報共有などを通じたCSIRT同士の協力関係の強化、CSIRT設立支援などさまざまな課題が山積していることが浮き彫りになってきた。各地域、各チームの抱えている背景があまりに大きく異なっているため、これらの課題を解決していくことは決して容易なことではないが、大きな経済格差の存在や情報インフラの進み方のずれなど、アジア太平洋地域の特徴を踏まえたフォーラムの設立は意義深い。現在JPCERT/CCは、APSIRCの活動について中心的な立場で関わっている。今後APSIRCに関して進展があった場合は、できるだけ積極的に紹介していく予定である。Center(コンピュータ緊急対応センター)の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティインシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに日本で最初に加盟したCSIRT。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。