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

第6回 証拠保全のために正規のバックドアを用意する

伊原 秀明
Port139
2003/11/13

---

　前回は、インシデントレスポンスの位置付けとログオンにおけるトラップ、不正アクセス調査用のログオン手段（正規のバックドア）の設置について解説した。今回は、実際にシステムへログオンする手段の検討と、“揮発性情報”の保全について解説する。

図1 調査員が利用する“正規のバックドア”をシステム上に構築したイメージ

　図1を見ていただきたい。これは前回も掲載した図だが、事前に不正アクセス調査用のバックドアが設置された状態である。調査員は事前に設置したこのログオン手段を利用してシステムへログオンすることになる。これまでの連載の中でも解説されてきたように、従来型のrootkitと比較してKernel rootkitは非常にやっかいな存在である。仮に不正アクセス調査用のバックドアをシステム構築時に設定したとしても、調査員のログオン時に影響を受ける危険性は十分考えられる。

影響を考慮してシステムへログオンすべし

　次に図2を見ていただきたい。従来型のrootkitであれば不正アクセス調査時にCD-ROMなどに保存した“安全なコマンド”を利用することで不正確な情報を見破ることも可能であったが、Kernel rootkitでは安全なコマンドを利用したとしても不正確な情報を得ることになってしまう。^＊1

＊1 ただし、いずれにせよ侵害された可能性のあるシステム上のバイナリを実行することは極力避けなければならない。

図2 Kernel rootkitを用いた調査

　このため、不正アクセス調査用のバックドアでトラップを回避しながら調査を行ったとしても、必ずしも“正確な情報”を得ているとは限らない点にまず注意しなければならない。従来型のrootkitとKernel rootkitの違いについては本連載の2〜4回で詳しく解説されているのでそちらを参照してほしい。^＊2

＊2 Kernel rootkitがいかにしてOSへ侵入し、システム管理者を欺くか、の技術的詳細については、2003年8月23日に筆者が関係する団体で開催したPort139勉強会にて4lj氏が「Kernel rootkit」と題して解説された。そのときのPDF資料とWindows Media Player形式のデータが公開されているので興味のある方はそちらも参照していただきたい（http://www.port139.co.jp/cakeoff.htm）。

揮発性情報の保全

　さて、そもそもなぜトラップが発動する危険性があるにもかかわらずシステムへログオンし、“初期対応”や“証拠保全”を行う必要があるのか、と疑問に思われる方もいるだろう。それほどトラップが怖いのであれば、“電源プラグを引っこ抜いて直接ハードディスクを調査すれば簡単にトラップを発見できる”という意見もあるだろうが、そうすると重要な証拠や痕跡を消してしまうことになるのだ。

図3 不正アクセス調査を行う場合の基本的な調査対象

　図3を見ていただきたい。システムが侵害を受けていないか、不正アクセス調査を行う場合に、調査対象となるのは基本的に以下の3つとなる。

1. メモリ
2. ハードディスク
3. ネットワーク

　むろん、これら以外にもバックアップテープやらキーロガー装置、紙など調査対象はさまざま考えられるが、PCが調査対象である点を考慮するとこの3つが重要なポイントとなる。さて、このうち図3において“電源プラグを引っこ抜いた”場合に何が起こるかを考えてみていただきたい。まず、メモリ上の情報はすべて消えてしまうだろうし、通信情報も消えてしまう。ホストが停止することからネットワーク上を流れていたパケットは通信相手が応答しなくなるので通信が途絶える（消える）形になる。

　例えばメモリ上にある重要な情報としてはプロセス情報（ps）、通信状況（netstat）などが挙げられる。もしバックドアプロセスが起動後に実体ファイルがHDD上から削除されていた場合には、メモリにしかその証拠はないことになる。^＊3

＊3 ご丁寧に完全削除ツールを使ってファイルが削除されている場合には電源断してしまうと基本的にはお手上げである。

　また、もしバックドアプロセスを発見することができ、その通信相手が分かれば不正アクセス者へと通じる手掛かりを得られる可能性もある（当然見えないようにKernel rootkitで隠ぺいされている確率は高いが……）。いずれにせよ、揮発性情報を得ることで“その時点でシステムがどのように稼働していたのか”を知ることができる。むろん誤った結果を得る可能性はあるが、逆にそれはそれで誤った情報が表示されるように細工されていたという証拠にもなり得る。逆に、急に電源断した場合にはシステムに対して少なからず悪影響を与える危険性もあるので「電源プラグを抜きました」とはなかなか簡単にはいえないだろう。

　揮発性情報にはどのようなものがあり、どのような順序で取得すべきかは前回も紹介したRFC3227を参照していただきたい。簡単にいってしまえば“消えやすい情報から取得していく”というのが重要なポイントである。^＊4

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

保全のためのログオン手段、いまさらtelnet？

　さて、揮発性情報を取得しようとする場合にはシステムへのログオンがどうしても必要になってくる。ここで問題になるのはどのような手段を使ってシステムへログオンするかである。ログオン手段を選択するうえでの重要なポイントは“トラップの回避”である。

　一般的にLinuxなどをシステム管理者がリモートから管理したり、コンソールからログオンする経路は、不正アクセス者にとって“トラップを仕掛けておくべき場所”と考えることもできる。例えばリモートから管理するのであれば最近であれば一般的に“Openssh”を利用することが多いだろう。

　しかし、そういった“一般的に利用するログオン手順”はトラッブを仕掛けるには格好の場所であり、不正アクセス調査やインシデントレスポンスに利用するわけにはいかない。^＊5

＊5 シリアルポートを監査用ログイン手段に利用する方法もあるだろう。この場合、事前にシリアルポートを利用するためのケーブルなどを準備しておく必要がある。また、ファイル転送などについてはnc（netcat）を使うほど簡単ではないので事前に十分手順を確認しておいていただきたい。

　そこで、筆者が個人的に推奨しているのは通常の管理には“ssh”なり暗号化された通信を利用し、不正アクセス調査やインシデントレスポンスには“telnet”を利用するというものだ。「いまさらtelnet？」という方も多いだろうし、telnetに関連するセキュリティ上の問題点を考慮すれば疑問に思われるかもしれない。まずtelnetには以下の問題がある。

• 通信内容が暗号化されずにネットワーク上を流れる（パスワードなどが丸見え）
• sshへと切り替えられ不要なサービスとして停止されていることが多い

　しかし、これらの点は逆に考えるとメリットでもある。不正アクセス調査やインシデントレスポンスに利用するログオン手段は必ずしも暗号化されている必要はない。むしろ、調査員がどのようなコマンドを実行し、どのような調査を行ったか、といった記録を取ることが非常に重要になる。そのような場合、通常はビデオで撮影したり、リモートからログオンに利用するソフトウェアのログ機能などを利用することになるわけだが、パケットもむろんキャプチャしておくことになる。通信内容が暗号化されていると、調査員がどのようなコマンドを実行したかを後から確認することが難しい（というよりできない）のだ。^＊6

＊6 telnetによる通信が不安な場合にはIPSecを利用する手段もある。といってもESPでパケットを暗号化してしまうのではなくAHのみ利用するのだ。この場合、調査用のログオン手段（ポート）へはIPSecによる鍵交換を行える端末のみが利用可能になるとともに、どのようなデータをやりとりしたかを確認することも可能になる。 ただし、事前にIPSecの設定（インストールなど）を行っておく必要があるのと、IPSec関連のポートが利用できないとせっかくのログオン手段も無駄になるので、あまり複雑な手段を用意するのはお勧めしない。

　不正アクセス調査やインシデントレスポンスでは、事前に決めた手順どおりの操作を行ったかということや、記録の正確さが重要になってくる。そのため、ビデオ撮影したりするのは“裁判官や弁護士”といった技術的に不慣れな人の理解を助けるために利用することになる。さらに記録やログ以外に、調査員の行動を保証（確認）するものとしてパケットキャプチャデータがあれば、ストリームの再構成を行うことでどのようなコマンドを実行したかを後から確認することができる。ただし、telnetによるログオンで問題となるのは“パスワードなど通信内容が丸見え”ということのほかに“不正アクセス者に監査している状況を知られる危険性がある”という点である。このため、不正アクセス調査やインシデントレスポンスで不正アクセス者がいま現在そのシステム上に“存在し何らかの操作を行っている”ケースではtelnetは不向きというより危険な手段であるかもしれない。

　しかし、telnetは一般的なUNIXなら標準で実装されており、WindowsでもWindows 2000以降では標準機能（デフォルトでは無効）として実装されている。このため複数のOSが混在する環境でも、調査員は基本的に同じ手順で調査できるメリットがある（telnet用のソフトウェアにも事欠かないだろう）。

　また、最近ではsshへと移行しているのでtelnetdはあまり利用されていないので、“空いている”という部分もある。むろん、23/tcpでtelnetdを動作させる必要はない。調査員が利用する手段なので標準ポート以外、例えば1023や10023/tcpといったポートを利用するのが望ましい。さらに設定したポートは調査員が行う不正アクセス調査やインシデントレスポンス以外で悪用されないように、パケットフィルタやIDSによる監視を行うなど厳重に管理しておく必要がある。^＊7

＊7 注意しなければならない点として、事前に取り決めた手順に従って調査員用のログオン手段が利用できない場合だ。このようなケースは異常が発生していると判断して、電源断など次の手順に移るべきである。何かほかの手段がないかとあれこれと行うのはせっかく作成した手順書を無意味にしてしまうとともに、よりトラップに引っ掛かる確率が高くなる。

◇

　今回は、調査員が利用するログオン手段について簡単にまとめてみたわけだが、別にtelnetにこだわる必要はない。自分（調査員）が慣れている手段を事前に設定し、そこにトラップを仕掛けられないように工夫しておくことが重要なのだ。最も危険なのは、ログオン手段よりもむしろログオン時に実行されるシェルに何か“細工”が施されているケースだろう。いずれにせよログオンを行うという行為は危険を伴うということを十分認識しておいていただきたい。

　次回は、ログオン後に実行すべき事柄と注意点について解説したいと思う。

「第5回」へ

「第7回」へ

index
第6回 揮発性情報の保全とログオン手段
	影響を考慮してシステムへログオンすべし
	揮発性情報の保全
	保全のためのログオン手段、いまさらtelnet？

関連記事

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

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

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

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

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