〜rootkitを検出するために〜
連載：インシデントレスポンスはじめの一歩

第5回 インシデントレスポンスの位置付け

伊原 秀明
Port139
2003/10/8

---

　前回までのラック新井氏と新町氏の連載の続きとなるわけだが、まずここで基本に立ち戻り「インシデントレスポンス（Incident Responce：IR）」がセキュリティ全体でどのような位置付けになるのかを見ていきたいと思う。

なお、あらかじめ断っておくが筆者は「好き好んでWindowsを利用する人間であり」UNIXに関する知識は乏しいため、おかしな点などあればぜひどんどん突っ込んでいただきたい。

※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者、筆者の所属先企業、および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。

“事故発生時の対応”がインシデントレスポンス

　図1のセキュリティ対策全体MAPを見ていただくとお分かりになると思うが、基本的にインシデントレスポンスは何らかのセキュリティインシデント(事象)が発生した後に実施する組織的な対応である。技術的には証拠保全などその後に続くComputer Forensics（コンピュータ・フォレンジック）^＊1などに関連する部分もあるが、基本的には事故発生時の対応がインシデントレスポンスである。

＊1 Computer Forensicsとは、コンピュータの内部を詳しく調査し、コンピュータの状態や、過去に発生した事象を追跡する作業のことをいう。

　通常、設定を行ったのちは運用に移り、ファイアウォール、Tripwire、IDSやシステムログなどの監視を日ごろ行うことになる。しかしながらこれまでの連載で紹介されたrootkitやKernel rootkitなどが用いられた場合、この通常“監視”では侵害の発生に気が付かないケースがあり得る。一般的に不正アクセス者は組織外からと考えがちだが、組織内部での犯行もやはり国内で増えつつあるのも事実である。

図1 セキュリティ対策全体MAP

　このため、筆者は監視の後に“不正アクセス調査”を位置付けている。これは、定期的な監査に近いものがある。監視の中では調査されないような個所をより詳細に調査していくことを筆者は不正アクセス調査と呼んでいる。いわばコンピュータ内部を探る探偵のようなものでサイバー探偵といったところだろうか。

　いずれにせよ、監視または不正アクセス調査で不審な状態を発見したり実際にインシデントが発生した場合に初めてインシデントレスポンスへと遷移する。

　インシデントレスポンスは基本的に“初期対応”を行うものであり、身近に例えれば「地震が発生したら机の下に隠れて外に飛び出さない」といったものを組織的に定義しておくものである。すなわちどう行動すべきか、何をしてはならないかを事前に手順書なりで定義しておく必要があるのだ。手順書といっても、皆さんも避難経路を図にしたりすると思うが、それのコンピュータ版と考えていただいてもいいだろう（むろん、技術者が対応する“証拠保全”などの部分は避難経路図などよりは詳細な手順書を作成する必要がある）。

　最近のセキュリティ業界では“Forensics（フォレンジック）”が1つのキーワードとなっているが、図1を見ていただくと分かるように、いわゆるComputer Forensicsはインシデントレスポンスの後の作業であり「正確なインシデントレスポンスなしにComputer ForensicsまたはNetwork Forensics」などあり得ないのである。

　もし、インシデントレスポンスを知らずにフォレンジックなどといっている人物がいたら「司法解剖でもするの？」といってやってほしい。

※補 Computer Forensicsを解説した日本語文献として筆者お薦めなのは＠police（http://www.cyberpolice.go.jp/）第3回セキュリティ解説の「コンピュータ・フォレンジクス」である。興味のある方はまずはこちらを読むことをお薦めする。

　いずれにせよ、Computer ForensicsまたはNetwork Forensicsを“不正アクセス被害の診断や解析”といった技術面ではなく、“訴訟対応”という意味合いで位置付けると、インシデントレスポンスで行う必要がある初期対応と証拠保全が、いかに重要な事柄であるかがおのずと理解いただけるのではないだろうか。

インシデントレスポンスは事前準備が重要

　図2を見ていただきたい。これはすでに侵害を受けてしまったシステムの状態を図示したものである。むろん、システム管理者や一般ユーザーは内部に“トラップ”や“バックドア”があることは知らない。

図2 侵害を受けてしまったシステムの状態

　では、この状態で監視などのフェイズで異常を検出したとしよう。あなたならこのシステムへどうログオンするだろうか。インシデントレスポンスの基本原則として「侵害されたシステムには触らない」というものがあるが、まだ“侵害”が特定できていない場合にはログオンして調査する必要が出てくる場合もある。

　また、“揮発性情報”（RFC 3227^＊2参照）を取得しようとした場合にはシステムへのログオンがどうしても必要になってくる。

＊2 RFC 3227とは、証拠収集とアーカイビングのためのガイドライン（Guidelines for Evidence Collection and Archiving）（http://www.ipa.go.jp/security/rfc/RFC3227JA.html）

　といって、通常のログオン手段を用いてログオンしたのでは、不正アクセス者が仕掛けたトラップに引っ掛かってしまう。この場合に何が発生するのかはトラップ次第なのだが、やっかいなのがトラップのループ状態に陥ることだ。

　図3のトラップループを見ていただきたい。システム管理者が通常のログオン手段を利用してログオンを行った場合、トラップが発動し不正アクセス者の痕跡を消去する仕組みになっていたとしよう（最近ではファイルの完全削除ツールなど不正アクセス者にとって証拠を消すための道具がいろいろとそろってきている）。

　システム管理が通常のログオンを行うと痕跡は消去されてしまい、その後の“調査活動”では何も発見することができない可能性が高くなる。むろんトラップによってはシステムを破壊的な状況にするようなものも存在するので、そのようなケースでは“侵害されていた”ということははっきり分かるだろう。

図3 トラップループ(オンライン)

　問題なのはせっかく調査活動を行っても“問題なし”となってしまい侵害を検出できないケースである。このシステムにはどこかに脆弱な個所がありそこを利用して不正アクセス者が侵入したわけだから、再度の侵入も簡単に行われてしまう可能性が高い。結局、調査活動が終了した後、再び不正アクセス者がやってきてバックドアの設置やrootkit／Kernel rootkitを仕掛けたりすることになる。このループを繰り返していたのではいつまでたっても不正アクセスの事実をつかむことができない。

　ではどうすればよいかだが、図4の不正アクセス調査の流れを見ていただきたい。こちらでは、通常のログオン手段は利用せず、不正アクセス調査専用のログオン手段を利用してトラップに引っ掛からない形でシステムへログオンする手段を表現している。^＊3

＊3 もちろん、この状態でもrootkit/Kernel rootkitの影響を受ける可能性は存在するが、トラップをもろに実行する危険性は少なくすることができる。ただし、不正アクセスが内部犯行の場合にはこの手のログオン手段を知っている危険性も考慮する必要がある。

図4 不正アクセス調査の流れ

　いわば、不正アクセス調査用のバックドアといったところかもしれないが、これであれば、不正アクセス者が仕掛けたトラップを回避しつつシステムへログオンすることができる。ここで注目していただきたいのは、“トラップを回避しログオン”した後すぐに証拠保全を行っている点である。ここは非常に重要なポイントなのだが、不正アクセス調査というような調査活動は場合によっては証拠となるデータを誤って消してしまったり、トラップを発動させてしまう危険性が存在する。

　そのため、調査活動を行う前にまず証拠保全を行いその時点でシステムがどうなっていたのかを後からでも解析できるようにしておく必要がある。この時点で証拠保全が正しく行われていればシステムに仕掛けられているトラップの存在やrootkitなどを一括して押さえることができる。「不正アクセス調査の前にまず証拠保全」ということを忘れないでいただきたい。“証拠保全”を行った後の不正アクセス調査で侵害の事実を発見できたら、“インシデントレスポンス”の作業へと入ることになる。

　いずれにせよ、トラップを回避しつつシステムへログオンする手段を事前に準備しておくことは重要なポイントである。

　図5の調査用ログオンは、事前に不正アクセス調査やインシデントレスポンスを考慮して、調査員が利用する“正規のバックドア”をシステム上に構築したところを示したものである。

図5 調査用ログオン(バックドア)

　逆にいえば、事前にこのような仕組みを作成し、調査用のログオン手段、調査用アカウントを作成していない場合には、ものの見事にトラップへ引っ掛かる可能性があるということである。

　調査用のログオン手段は何を使ってもよいが、通常は調査員のみが利用できるように設定し、パスワードなどは強固なものを設定しておく必要がある。調査用の正規のバックドアが不正アクセス者のバックドアに利用されたのでは意味がないからである。

　また、こういった調査用のログオン手段については調査員のみが知っているようにし、一般のシステム管理者などにはあまり存在を明かさない方が内部犯行を考慮した場合には有効だろう。なお、調査用のログオンの原則についてはいうまでもなく2人以上で行うことになる。

※補 このあたりはシステム管理者であれば必須の書籍である翔泳社刊『インシデントレスポンス』（http://www.seshop.com/detail.asp?pid=2993）を参照していただきたい。

◇

　今回はインシデントレスポンスの位置付けと、事前の準備策としての“正規のバックドア”について解説した。次回は、ログオン手段の検討と“揮発性情報”の重要性を解説していく予定である。

「第4回」へ

「第6回」へ

index
第5回 インシデントレスポンスの位置付け
	“事故発生時の対応”がインシデントレスポンス
	インシデントレスポンスは事前準備が重要

関連記事

連載：Webアプリケーションに潜むセキュリティホール

特集：クロスサイトスクリプティング対策の基本

連載：不正侵入の手口と対策

「連載 インシデントレスポンスはじめの一歩」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）