UnderForge of Lack

-----------
2010.01.4 書初め
-----------


あなたの所持しているサイトがこうなってしまったら？

あるいは、不審な iframeなどのインジェクションコードが挿入されていたら？

----------
1. サイト閉鎖

あなたにできることは、できるだけ早いサイトの閉鎖を行うことです。

本来ならアナウンスが最初だと思われがちですが、最近のインジェクションはそのアナウンスにも容赦なく改ざんを仕掛けてきます。

Virtual Host単位で運用しているのならば、Apache上のVirtual Host定義ファイルをディレクトリを一時的に変更するか、BASIC 認証を掛け、一時的にサイトをアクセス不能の状態にしてください。

上述の意味がわからない場合、FTP(恐らく)でアクセスし、全てのファイルを（必要ならバックアップをとって）削除するか、Webルートのフォルダ名を（変更可能なら）変更します。
※感染コードが入っているファイルの可能性が極めて高いため、バックアップファイルには細心の注意が必要です。
※Web Rootフォルダのパーミッションを 600 にする方法もありますが、userが apache の場合あまり意味がありません。

それでも再インジェクションされているようでしたら、プロバイダに連絡して一時的にアカウントの停止措置を取ってもらってください。

----------
2. ウィルスの除去

感染源を特定し、ウィルスを除去します。
が・・・最近のインシデントは単純にはいかないケースがあります。

2-1. 単独PCの場合
明らかにそのPCがウィルスに汚染され、かつLANが存在しない場合

速やかにウィルスを除去し、完全に安心できる環境を構築します。

2-2. 小規模LANの場合
LANが組まれていて、同一ネットワーク内に複数のノードが存在する場合、その全てのチェックが必要になります。

感染ノードが見つかれば、そのPCの駆除を行ってください。
worm型に侵されていた場合、同一ネットワーク内の全てのPCに被害が及んだ可能性があります。
慎重にチェックを行ってください。

2-3. 大規模LANの場合
※大規模環境のインシデント回復はそれなりに大変です。
Firewallのログをチェックし、不審なトラフィックがないかどうかチェックしてください。
IDSが導入されている場合、IDSの定義が適切に導入されているかチェックしてください。
DMZ内側からのOutgoingルールを再度チェックしてください。
DMZに設置されているサーバのログを慎重にチェックしてください。

インシデント用に、すべてのOutを塞いだルールを定義し、どのノードからOutgoing要求が出されているのかログを見て判断する方法が有効です。
敵はそこにいる

感染ノードが特定できたら、そのノードのセグメント全てを疑ってかかってください。
特に telnet や SSHトンネルコマンドを使用していた場合、それらが漏洩した危険性があります。

Squid導入の環境の場合、FTPのログを慎重にチェックしてください。
nginxでサーバーが駆動している場合、そのリバースプロキシの設定を確認しログをチェックしてください。
以後、大規模環境下の話は割愛します（長くなるため）

----------
3. FTPなどのPassword変更

環境がクリーンになったと確信が持てたならば（100%はありません。90%くらいでOKです）、サイトへの告知を行います。
※この段階で全てのコンテンツを再解放しないでください。

FTPのPasswordを変更します。
ISPのPasswordを変更します。
その他、自分の思いつく全てのPasswordを変更します。
※落ち着いてメモを取りながら行ってください。

サイト内のファイルを消していない場合：
サイトにFTPで入り、現在存在する全てのファイルを一旦ローカル（自分のPC）にバックアップします。
※当然、汚染コードを含んでいます。
　将来、感染していたページの詳細リストを作成する際に必要になるでしょう。

全てのコンテンツを一度抹消し、TOPページに、ウィルス感染の報告、並びに閲覧者への再感染の危険性およびウィルスチェックの呼びかけを行ってください。
※この時点で、報告のページはできる限り簡素なものにしてください。

２４時間以内に何度かチェックを行い、告知ページが再改ざんされていないことを確認してください。

----------
4. 連鎖の阻止

感染サイトの閉鎖が完了したら、自分の管理する（あるいは過去に管理したことのある）全てのサイトをチェックしてください。

CMSを使用している場合、インジェクションが一見しただけでは判らない位置にある場合があります。

特に .js, .php, .pl, .css ファイルを重点的に調べてください。
これらのファイルは、よほどのことがない限り、勝手に変化することはありません。

----------
5. インシデントからの回復

一部重複する部分もありますが、

インシデントからの回復

を参照してください。

----------
6. Google Blockedからの修復

最初の（血のような）真っ赤なエラーを快復するためには、Google WebMaster Tool への登録が必要です。

Google Accountを取得し

Google Webmaster Toolを申請し、

サイトの再審査をリクエストします。

サイトが本当に快復していれば、ブロックは解除されます。

----------
逐次加筆訂正されます

EoF

This entry was posted on 月曜日, 1 月 4th, 2010 at 6:00 AM and is filed under Trouble, knowledge, security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.