必要なもの:
- サイトのサーバー(ウェブ、データベース、ファイル)へのシェルまたはターミナルの管理者アクセス権限
- シェルまたはターミナルのコマンドの知識
- コードの理解(PHP や JavaScript など)
- サイト(ファイル、データベース、画像など)のバックアップを作成するためのストレージ
次の対策:
このステップでは、複数の対策について説明します。
- ハッカーがユーザーの個人情報を(フィッシング ページなどで)入手しようとしたと思われる場合に、サポートの情報源を探す。
- ユーザーから見える状態にある、ハッカー作成の完全に新しい不正な URL(Google 検索結果に表示したくない URL)を Search Console の URL の削除ツールを使って削除する(省略可)。
- 新しく作成または新たに更新された正常なページ(Google 検索結果に表示したいページ)の Google による処理を Search Console の Fetch as Google 機能を使って早める(省略可)。
- ソフトウェアの最も安全な最新版をインストールする。
- 今後のサイトの脆弱性につながるおそれのある、使用しないまたは不要なアプリケーションやプラグインを削除する。
- 正常なコンテンツを復元し、ハッカーのコンテンツを削除する。
- ハッカーに利用された根本原因の脆弱性を修正する。
- すべてのパスワードを変更する。
- サイトの安全性を維持するプランを立てる。
1. フィッシング ページなどでサイトの機密情報が失われた場合に、対処できるようにサポート情報源を見つける
サイトからユーザーの機密情報が(たとえば、フィッシング攻撃の一部として)漏れた場合、サイトのクリーンアップやファイルの削除を開始する前に、ビジネス上、規制上、法律上の責任について検討することをおすすめします。フィッシングの場合は、antiphishing.org に役立つ情報があります(サイトがフィッシングによってハッキングされた場合のガイドなど)。
2. ハッカーによって作成された新しい URL の迅速な削除を検討する
ハッカー作成の完全に新しい URL がユーザーから見える状態で存在する場合は、Search Console の URL の削除ツールを使って、こうしたページをより早急に Google の検索結果から削除することができます。これは省略可能なステップです。該当するページを削除してから、404 ステータス コードを返すようにサーバーを設定するだけでも、時間が経つうちに自然に、そのページは Google のインデックスに登録されなくなります。
- URL の削除ツールを使用するかどうかの判断は、新たに作成された不要なページの数や(ページが多すぎると [URL の削除] での指定が煩雑になります)、こうしたページがユーザーに及ぼすおそれのある被害の内容によって異なります。[URL の削除] で送信したページが今後検索結果に表示されないようにするには、不要なまたは削除した URL に対して「404 ファイルが見つかりません」というレスポンスを返すようにページを必ず設定します。
- ハッカーによる侵害を受ける前は正常なページだったので、クリーンアップ後はこのページを検索結果に表示させたいという場合は、この機能でページの削除をリクエストしないでください。 [URL の削除] は、今後一切結果に表示させたくないページにのみ使用します。
3. Google による正常なページの処理を早めるかどうか検討する
新しく作成または新たに更新された正常なページがある場合、Search Console の Fetch as Google 機能を使って、こうしたページを Google のインデックスに送信できます。これは省略可能なステップです。省略しても、時間が経つうちに、新しいまたは更新したページはクロールされ、処理されます。
4. サーバーのクリーンアップを開始する
ここで、被害の程度の確認と脆弱性の特定で取った記録に基づいて、サイトのクリーンアップを開始します。以下の手順は、利用できるバックアップのタイプによって異なります。
- 正常な最新のバックアップ
- 正常だが古い状態のバックアップ
- バックアップが利用できない
まず、サイトがハッキングされる前にこのバックアップが作成されたことを確認します。
- 正常な最新のバックアップ
- バックアップを復元します。
- 入手可能なソフトウェアのアップグレード、アップデート、パッチをインストールします。これは、OS のソフトウェア(サーバーを管理している場合)と、すべてのアプリケーション(コンテンツ管理システム、e コマース プラットフォーム、プラグイン、テンプレートなど)が対象となります。
- サイトで使用しなくなったソフトウェア(ウィジェット、プラグイン、アプリケーションなど)をサーバーから削除できるかどうか検討します。
- 脆弱性を修正します。
- 被害の程度の確認で見つかったすべての問題に対処したかどうかを確認します。
- サイトに関するすべてのアカウント(FTP アクセス、データベース アクセス、システム管理者、CMS アカウントなどのログイン)のパスワードを再度変更します。Unix ベース システムでは、次のコマンドを実行します。
$passwd admin1
- 正常だが古い状態のバックアップ
- 現在のサイトのディスク イメージを作成します。サイトが感染している状態でもかまいません。このコピーは安全のためです。他のものと区別するため、感染していることがわかるようにコピーに印を付けます。Unix ベース システムでは、次のようにディスク イメージを作成します。
$dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9 > /mirror/full-backup-20120125-infected.gz
- 画像やメディア ファイルを含む、サーバーのバックアップ ファイル システムのコピーを作成します。データベースがある場合は、データベースもバックアップします。
$tar -pczf full-backup-20120125-infected.tar.gz www/ $ mysqldump -u root -p --all-databases | gzip -9 > fulldb_backup-20120125-infected.sql
- 正常だが古い状態のバックアップをサーバー上で復元します。
- サイトで使用しなくなったソフトウェア(ウィジェット、プラグイン、アプリケーションなど)をサーバーから削除できるかどうか検討します。
- すべてのソフトウェアをアップグレードします。OS のソフトウェア(サーバーを管理している場合)と、すべてのアプリケーション(コンテンツ管理システム、e コマース プラットフォーム、プラグイン、テンプレートなど)が対象となります。入手可能なセキュリティ アップデートとパッチを確認して、インストールします。
- 脆弱性を修正します。
- 手動または自動で、サイトの
diff
を実行します(正常なバックアップと現在の感染しているコピーを比較します)。$diff -qr www/ backups/full-backup-20120124/
- 感染したコピーから保護したい新しい正常なコンテンツがあれば、アップグレード済みのサーバーにアップロードします。
$rsync -avz /backups/full-backup-20120124/www/clean-file.jpg /www/
- 被害の程度の確認で見つかったすべての URL を修正したかどうかを確認します。
- サイトに関するすべてのアカウント(FTP アクセス、データベース アクセス、システム管理者、CMS アカウントなどのログイン)のパスワードを再度変更します。Unix ベース システムでは、次のコマンドを実行します。
$passwd admin1
- 現在のサイトのディスク イメージを作成します。サイトが感染している状態でもかまいません。このコピーは安全のためです。他のものと区別するため、感染していることがわかるようにコピーに印を付けます。Unix ベース システムでは、次のようにディスク イメージを作成します。
- バックアップが利用できない
- サイトのバックアップを 2 つ作成します。サイトが感染している状態でもかまいません。余分にバックアップを作成しておくと、誤って削除したコンテンツを復元したり、うまくいかない場合に元に戻してもう一度試したりできます。後でわかりやすいように、各バックアップに「感染」という印を付けます。
- バックアップの 1 つはサイトのディスク イメージ(「クローン版」)とします。このフォーマットはコンテンツの復元が簡単になります。ディスク イメージを万一に備えて手元に残しておくことができます。Unix ベース システムでは、次のようにディスク イメージを作成できます。
$dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9 > /mirror/full-backup-20120125-infected.gz
- もう 1 つのバックアップは、画像やメディア ファイルを含む、サーバーのファイル システムのコピーです。データベースがある場合は、データベースもバックアップします。
$tar -pczf full-backup-20120125-infected.tar.gz www/
$mysqldump -u root -p --all-databases | gzip -9 > fulldb_backup-20120125-infected.sql
- ディスク イメージがない場合は、データベースのバックアップを 2 つと、ファイルシステムのバックアップを 2 つ作成します。
- バックアップの 1 つはサイトのディスク イメージ(「クローン版」)とします。このフォーマットはコンテンツの復元が簡単になります。ディスク イメージを万一に備えて手元に残しておくことができます。Unix ベース システムでは、次のようにディスク イメージを作成できます。
- サーバー上ではなく、新しいバックアップ ファイルシステムのコピー上で、サイトのコンテンツをクリーンアップします。
- これまでに調べて、ファイルに緩すぎる権限が見つかった場合は、権限を修正します。この修正は必ず、サーバー上ではなく、バックアップ コピー上で行います。
- 同様にバックアップ コピー上で、被害の程度の確認で不正使用が見つかった URL に対応するすべてのファイルをクリーンアップします。サーバーの設定ファイル、JavaScript、HTML、PHP などが対象です。
- ハッカーによって作成された新しいファイルも削除(404 レスポンスを配信)します(これらのファイルは、Search Console の [URL の削除] ツールで送信済みの場合があります)。
- コードや解読されたパスワードに脆弱性がある場合は修正します。入力検証ライブラリやセキュリティ監査が役立つことがあります。
- サイトにデータベースがある場合は、バックアップ内のハッカーに変更されたレコードのクリーンアップを開始します。この手順を完了する前に、その他のレコードの正当性チェックを実行して、正常な状態かどうかを確認します。
- サイトに関するすべてのアカウント(FTP アクセス、データベース アクセス、システム管理者、CMS アカウントなどのログイン)のパスワードを再度変更します。Unix ベース システムでは、次のコマンドを実行します。
$passwd admin1
- この時点で、感染していたサイトのバックアップ コピーには正常なデータのみが含まれているはずです。この正常なコピーを手元に保管して、対策 5 に進んでください。
- サイトのバックアップを 2 つ作成します。サイトが感染している状態でもかまいません。余分にバックアップを作成しておくと、誤って削除したコンテンツを復元したり、うまくいかない場合に元に戻してもう一度試したりできます。後でわかりやすいように、各バックアップに「感染」という印を付けます。
5. 不要なソフトウェアを除去する
サイトで使用しなくなったソフトウェア(ウィジェット、プラグイン、アプリケーションなど)をサーバーから削除できるかどうか検討します。削除するとセキュリティが向上し、今後の管理が簡単になります。
6. すべてのサーバーをクリーンアップする
- 単にアップグレードするのではなく、クリーン インストールを行います。アップグレードでは、古いバージョンのファイルが残ることがあります。感染したファイルがサーバーに残ると、新たなハッキングが起きる可能性が高まります。
- クリーン インストールは、OS のソフトウェア(サーバーを管理している場合)と、すべてのアプリケーション(コンテンツ管理システム、e コマース プラットフォーム、プラグイン、テンプレートなど)が対象となります。入手可能なセキュリティ アップデートとパッチも必ず確認します。
- バックアップ ファイルシステムのクリーンアップしたコピーから、新たにインストールしたサーバーに正常なコンテンツを移行します。正常な既知のファイルとデータベースのみをアップロード、復元します。ファイルの適切な権限を管理し、新たにインストールしたシステム ファイルを上書きしないようにします。
- サイトに関するすべてのアカウント(FTP アクセス、データベース アクセス、システム管理者、CMS アカウントなどのログイン)のパスワードを最後にもう一度変更します。Unix ベース システムでは、次のコマンドを実行します。
$passwd admin1
7. 長期の管理計画を作成する
ウェブ上にはサイトの強力な管理の参考になる便利な情報が多数あります(StopBadware の Preventing badware: basics など)。また、次の手順を行うことも強くおすすめします。
- サイトを定期的に自動バックアップする。
- ソフトウェアの更新に常に気を配る。
- サーバーにインストールする前に、すべてのアプリケーション、プラグイン、サードパーティ ソフトウェアなどのセキュリティ対策を把握しておく。あるソフトウェア アプリケーションにセキュリティの脆弱性があると、サイト全体の安全性が損なわれるおそれがあります。
- 強力なパスワードを作成する。
- マシンへのログインに使用するすべてのデバイスを安全に保つ(オペレーティング システムとブラウザを更新する)。
8. クリーンアップの完了を再確認する
次の質問に「はい」と答えられるかどうかを確認します。
- ハッカーがユーザーの個人情報を入手している場合、適切な手順を行いましたか?
- 最も安全な最新版のソフトウェアをサイトで実行していますか?
- 今後のサイトの脆弱性につながるおそれのある、使用しないまたは不要なアプリケーションやプラグインをすべて削除しましたか?
- コンテンツを復元して、ハッカーのコンテンツを削除しましたか?
- サイトのハッキングを許した根本原因の脆弱性を修正しましたか?
- サイトを安全に保つための計画はありますか?
9. サイトをオンラインに戻す
次のステップ
完了まであと一息です。このプロセスの最後の手順は、再審査のリクエストです。