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

第7回 不正アクセス情報の入手方法
　　　　〜 ログオン後に収集する揮発性情報 〜

伊原 秀明
Port139
2003/12/11

---

　前回は、システムの揮発性情報を得るためにログオンする手段として、管理者用の安全なログオン手順（調査員用アカウントと、そのためのログオン手段）を“事前”にシステムへ設定しておく必要性について解説した。

　今回は実際にシステムへ調査員用アカウントでログオンし、どのような情報を入手すべきか、また“やってはいけない行為”について解説したいと思う。

悠長にコマンドを打つことは許されない

　調査用のログオン口を利用して調査員がログオンしたら、まず何をすべきだろうか。インシデントが発生しているシステムの初期対応なのだから、前回解説したように“揮発性情報”の取得が主たる目的となる。

　簡単にいってしまえば“電源プラグを抜いてしまうと失われる情報”（主にメモリ上に存在している情報）を得るために、わざわざトラップが実行される危険を覚悟でログオンするのだから、迅速にそれらの情報を取得する必要がある。^＊1

＊1 悠長に、「psコマンドのオプションって何が使えるんだっけ？」とmanコマンドによりマニュアルで確認している時間はない、manコマンドにトラップが仕掛けられていたら終わりである。必要なコマンドを迅速に実行し、そこで得られた結果内容の確認は後からじっくり行えばよいのである。

　例えば、実行中のプロセスは揮発性情報といえる。悪意のあるプロセスが常に実行されているという可能性は少ない。普通に考えれば、悪意のあるプロセスを常時実行したければ不正アクセス者はその存在を隠そうとするはずである。逆に、一時的にパケットをスニフィングしたり、攻撃用コードを実行している最中などでは悪意のあるプロセスが“調査員から見える状態で”一時的にメモリ上に存在している可能性がある。

　とはいえ、プロセスは役目を終えれば当然消えてしまう揮発性情報に変わりはない。また、その発見と特定が困難（勘と慣れが必要とされる）という面はあるが、ファイルシステム上のファイルはすでに削除されており、不正アクセスの証拠となるものが、メモリ上にあるプロセスしか存在しないようなケースでは、そのプロセスかメモリイメージ全体をダンプしておくなどの必要があるだろう。^＊2

＊2 不勉強な筆者は、Linuxにおいてプロセスを実行した後、その実体ファイルが削除された実行中プロセスのイメージファイルをダンプする方法（コマンドや手順）をこの原稿を書くまでよく知らなかった。削除されたファイルの復元は、時間が経過していない状態で正確なハードディスク イメージ ファイルの作成を行えば、専用ツールを利用することで可能になるが常に復元できるとは限らない。 逆にいえばLinuxを利用しているシステム管理者は、“揮発性情報”として実行中プロセスのイメージを確保する手順を事前に確認しておく必要があるといえるだろう。/procファイルシステム内のexeリンクを利用すれば可能なのだが、詳細については翔泳社刊「インシデント レスポンス 不正アクセスの発見と対策」のP368以降に記載されているのでそちらを参照していただくことをお勧めする。 ちなみにこの書籍は“管理者必須”として個人的にもお勧めなので、まだ持っていない方は入手することをお勧めしたい。 なお、Windowsではpmdumpというプログラムを利用すると実行中のプロセスが利用しているメモリ空間をダンプすることが可能だ。むろん筆者のIncident ResponceツールCDには入れてある。

　これは例えば、Tripwire^＊3のような完全性チェックツール（Integrity Check tool）の実行によりファイルが追加が確認されたような場合がそうだ。調査員のチェックではそのファイルの存在が確認できないようなケースでは、ファイルがKernel rootkitにより隠されているか、実体（ファイル）を削除されたかのいずれかということになる。

＊3 Kernel rootkitを利用してファイルが隠されると、ユーザーモードで動作する完全性チェックツールでは“追加されたファイル”を検出することがそもそも非常に難しい。不正アクセス者が内部にいたり慎重にファイルを隠した場合には基本的にはお手上げなので、完全性チェックツールだけでシステムへの侵害の有無を判断するのは危険である。 なお、整合性または完全性チェックツールと呼ばれるツールは数多く存在しており、Tripwireは10年以上前に作成された代表的なツールである。最近発生したDebianプロジェクトのサーバへの侵入事件では、別の完全性チェックツールAIDEによりファイルの改ざんが検出され、インシデントの発生が確認されたという例もある。いずれにせよ、完全性チェックツールはシステムのインストール時に一緒に（正常なデータベースを）構築しておくべきものである。筆者も過去3度ほどTripwireによりインシデントの発生を検知している実績があるので、まだインストールされていない読者の方はいまからでも（まだ侵害を受けていないことが前提となるが）インストールすべきツールといえるだろう。 【参考書籍：オライリー・ジャパン刊『Tripwire for Linux』】

必要な揮発性情報かを見極めるべし

　つい考えてしまうのが、メモリ上のすべての情報をログオンすることなくダンプし解析する方法である。むろん、これをうまく行うことが可能であれば何もいうべきことはないし、そういった機能を実装しているOSや、機能が今後実装されてくる可能性はある。しかし、現在のところ、一般的に利用されているLinuxやWindowsでは基本的に「調査用のログオン口を利用してログオンし情報を取得する」ということを行う必要がある。

　残念ながら調査員がログオンした段階ですでにシステム上のメモリやデータ、ハードディスクの内容は変化してしまい、厳密にはインシデント発生時の正確な状態とはいえない。^＊4

＊4 VMwareのような仮想OSの仕組みを利用している場合にはOSをサスペンドさせることも可能だが、その後の解析をどうするかといった課題はまだ残されたままである点に注意が必要だろう。仮想OSを利用するのは確かに便利なのだが、インシデントレスポンスという面ではまだ十分でない点がある。ただし、インシデントが発生したシステムをVMware上で仮想OSとして復元する方法についてはASR DataのSMARTを利用する例（www.linux-forensics.com/SMARTForensics.pdf）も報告されている。

人によって異なるコマンドライン

　例えば、TCP/IPの通信状態を確認するコマンドとして「netstat」コマンドがある。現在の通信状態を確認する意味では、揮発性情報を取得するコマンドの1つに含めるべきコマンドだといえる。しかし、一口に“netstatコマンドを実行”といっても人によりコマンドラインには癖があり、つい日ごろ慣れ親しんだコマンドラインオプションで実行してしまう。

　例えば、以下のnetstatコマンドはいずれも同じ情報を返すだろう。

netstat -na netstat -an netstat -a -n

　得られる結果が同じであれば問題ないように思えるかもしれないが、調査する人のコマンドオプション指定の違いにより、取得したい情報が得られなかったりする場合が予想される。そのため、調査員が揮発性情報を取得するコマンドについてはコマンドラインオプションの記述方法を統一し、後述する手順書に記述しておくべきだろう。

　また、可能な範囲でOSの違いを意識しないですむようにしておくとよい。例えばLinuxとWindowsが混在している環境でのインシデントレスポンスを考慮するのであれば、調査員がコマンドの引数をあまり意識しなくてすむようにすべきだろう。無駄と思えるハイフン記号（-）を含めてnetstatを実行するように手順書には記述しておくなどにより、調査員のミスを防いだり手順の共通化を図ることができるようになる。^＊5

＊5 Windowsのnetstatコマンドではnetstat -naのようにハイフン記号を含めてオプションを指定する必要がある。Linuxではnetstat naでも結果が得られるが、ハイフン記号を付けた場合（-na）とでは出力結果が異なるので注意していただきたい。

情報は必ずしも正確ではない

　ここで実行すべきコマンドはむろん事前にCD-ROMなどに準備した「安全なバイナリ（プログラム）」を想定しているわけだが、「安全なバイナリ」を利用していたとしても、必ずしも“正確な結果”が得られるわけではない点に注意しなければならない。

　これまでの連載で解説したように、Kernel rootkitが利用されている場合には、“安全なログオン手段（管理者用のバックドア）”を利用してログオンしても、当然のことながらKernel rootkitの影響を受ける。

　このため、調査対象システムでKernel rootkitの存在を前提として考えるのであれば、収集される結果データは「Kernel rootkitの影響を受けたデータ」と考えて扱うべきだろう。^＊6

＊6 むろん、オンラインでの調査を行う場合は、常にKernel rootkitの影響を前提に調査をすべきである。

証拠が必ず得られるわけではない 　（すでに消えているかもしれないという前提で）

　すでにプロセス情報の取得の段階で説明したことだが、揮発性情報というからにはインシデントレスポンスで調査員が現地に到着し、初期対応を開始した段階ではすでに“証拠となるデータ”はすべて失われている場合もある。^＊7

＊7 インシデント発生時には“ネットワークケーブルを抜け”と指示しているケースを時折見かけるが、筆者はこれに諸手を挙げては賛同できない。OSによっては“ネットワークケーブルを抜く”ことで揮発性情報のステータスが変化してしまう場合があるからだ。 もし”ネットワークケーブル”を抜くのであれば、どのタイミングでどのネットワークケーブル（侵害元ホストのケーブルなのか、ルータやHUBなど接続機器レベルのネットワークケーブル）を抜くべきなのかを事前に手順書に定めておくべきだろう。

　いずれにせよインシデントレスポンスは迅速に行わなければならないわけだが、仮に迅速に行動したとしても常に証拠となるデータを得られる保証はない。システムが稼働している以上、必要ない（使われてない）領域は必要としているプロセスやファイルによって上書きされていく。このため、インシデントレスポンスにおいて“揮発性情報”を取得するのは、“インシデント対応時点でメモリ上にはこういったデータが存在していた”ということを後から確認・証明するために行うといってもいいだろう。

頭で考えず、手順書に従って行動すべし

　インシデントレスポンスで重要な点は「いまから何をすべきか」をその段階になって考えていては駄目だということである。事前に作成した手順書に従って調査員は作業を行う必要がある。と簡単に書いているが、この手順書を作成するというのは意外に大変な作業なのだ。実際に作成し実施してみると分かるが、書き方が悪いと、手順書に書いてあるにもかかわらず作業を忘れるといったケースもある。

　これは実際のインシデントレスポンスではないが、去る9月10日に開催された「JNSA セキュリティセミナー Computer Forensics」で筆者は「不正アクセス調査」のデモを行ったが、このようなセミナーであっても手順書を用意し事前に何度も練習を行っている。しかし、手順書どおりいかない場合もある。デモのために事前に練習した中（実は10回以上）で、最も手順書どおりにコマンドを実行できたデータをPort139のWebサイトで公開しているので興味のある方はそちらを参照いただきたい。

【参考】「不正アクセス調査 デモ（練習版）」 練習版デモ手順書 PDF（193KB） http://www.port139.co.jp/ppt/030910/T0910Demo-Training.pdf 練習用デモ WMV（87MB）27分 http://www.port139.co.jp/ppt/030910/910Demo-Training.wmv

　デモ用ということもあり、少々手順書の文字が細かいことと、時間的な制約がある中で迅速な操作が求められたわけだが、手順書があっても、“できが悪い”となかなかうまくいかないものである。

　また、いわゆるForensic（フォレンジック）本来の「法廷の〜」という意味で証拠としてデジタルデータを取得するのであれば、“証拠保全手順書”を事前に作成する必要がある。^＊8

＊8 いずれの手順書についても、法律の専門家によるチェックが必要であることはいうまでもないだろう。

　ここで重要なポイントは何らかの「手順書」を作成したのであれば、それに従って行動する必要があり、「手順書に記載されていない操作やコマンドを実行してはならない」という点である。デジタルデータは改ざんが容易であることから、「手順書どおり」に行ったかどうかが後から重要な争点になる場合がある。

　むろん、不正アクセス者によって手順書どおりの行動が取れない場合もあるが、そのあたりについては法律の専門家へ相談した段階で必ずアドバイスがあるはずである。簡単にいってしまえば「例外発生時にはその旨、正確に記録しておく」ということになるのだが、例外を想定するのは難しい面もあるので日ごろの定期的な訓練が重要となるだろう。

取得したデータを保存する場所

　すでに述べたが、調査員がログオンした段階でシステムは変化している。これは「証拠の改変」ととらえることもできる。そのため、調査員は調査対象の内部をなるべく変化させることなくデータを収集する必要がある。

図1 データの保存先

　そのためには、事前にデータを保全する領域を確保しておく必要がある。インシデントが発生しているシステム上のハードディスクへ“収集したデータを書き込む”などといった行為は“やってはならない”行為の代表的な項目の1つである。

図2 証拠データを転送し、保存しておく

　このあたりの「インシデント対応時に収集した揮発性情報や証拠データを何処へ保存するか」という部分も、事前に考慮し手順書で決めておく必要がある。そうしないと、“やってはいけない行為”を連発することになり、結果として“証拠がまったく得られない、または信用できない”状態になってしまうので十分注意していただきたい。

◇

　次回は電源を断するかどうかの判断について解説したいと思う。現在稼働しているシステムの多くはインシデント発生時にシステムを停止することが想定されていない。そのようなケースで、どう「電源断」の判断を下すのかを解説したいと思う。

コラム　Internet Week T7 去る12月2日パシフィコ横浜で開催されたInternet WeekのセッションT7“スパマ・アタッカは他人ゴトにアラズ 〜加害者に仕立てあげられないための予防とインシデント対応〜”を聴講させていただいた。 講師の方はISPの方のため当然のことながら企業のインシデントレスポンスとは異なる視点を持ってお話を展開され、実際の対応事例などを聴くことができこの連載を書くうえで参考になる情報をいろいろといただけた。UNIX音痴なわたしには参考になるコマンドの解説などもあり非常に参考になったので資料が公開されたらぜひ参照されることをお勧めする。 最後の質問時間に今回のテーマでもある“揮発性情報の取得の為に危険性を認識しながらログオンする”ことについて講師の方に質問させていただいたところ、「コンソールは常にログオンした状態にしておくというのも1つの手段であろう」という回答をいただいた。 実は、「不正アクセス調査ガイド-rootkitの検出とTCTの使い方」（オライリー・ジャパン刊）でも少し書いたことなのだが、監視目的などのためにコンソールを常に上げておくのは、不正アクセス者がシステムを再起動したり、そのログオンセッションを切断した場合に役立たなくなる。しかし、これは逆にコンソールが利用できない状態になっていることから、インシデント発生を予想・確認できる可能性が高まるという面もあるので、環境に応じて採用を検討してみていただきたい。

「第6回」へ

次回は1月公開予定です

index
第7回 ログオン後に収集する揮発性情報
	悠長にコマンドを打つことは許されない
	必要な揮発性情報かを見極めるべし
	人によって異なるコマンドライン
	情報は必ずしも正確ではない
	証拠が必ず得られるわけではない
	頭で考えず、手順書に従って行動すべし
	取得したデータを保存する場所

関連記事

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

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

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

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

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