サイトをクリーンな状態に保ち、今後のハッキングを防ぐには、次のものが必要です。
- サイトのサーバー（ウェブ、データベース、ファイル）へのシェルまたはターミナル管理者アクセス
- シェルまたはターミナルのコマンドの知識
- コードの理解（PHP や JavaScript など）
- ファイル、データベース、画像など、サイトのバックアップを作成するストレージ
次のアクション
このステップでは、次の操作を行います。
- ハッカーがユーザーの個人情報を（フィッシング ページなどで）取得しようとしていると思われる場合の追加リソースの場所。
- Search Console の [URL の削除] を使用して、ハッカーが作成した、ユーザーに表示される好ましくない新しい URL のうち、Google 検索結果に表示したくないものを迅速に削除するオプション。
- Search Console でURL の再クロールを Google にリクエストするオプションを使用すると、Google 検索の検索結果に表示するクリーンなページ（新規または新しく更新されたページ）の処理を迅速化できます。
- 最新の最も安全なバージョンのソフトウェアをインストールする。
- 不要または未使用のアプリケーションやプラグインを削除して、サイトの脆弱性を軽減します。
- 適切なコンテンツを復元し、ハッカーのコンテンツを削除します。
- ハッカーに悪用される根本原因の脆弱性を修正する。
- すべてのパスワードを変更しています。
- サイトの安全性を維持するための計画。
1. サポート リソースを探す
（フィッシング攻撃の一環として）サイトからユーザーの機密情報を取得した場合、サイトのクリーンアップやファイルの削除を開始する前に、ビジネス、規制、法的責任について検討することをおすすめします。フィッシングの場合は、antiphishing.org のドキュメント「フィッシングによってサイトがハッキングされた場合の対処方法」など、役立つリソースがあります。
2. ハッカーによって作成された新しい URL の迅速な削除を検討する
ハッカーがユーザーに表示されるまったく新しい URL を作成した場合は、Search Console の [URL を削除] 機能を使用して、これらのページを Google 検索の検索結果からすばやく削除できます。このステップは省略可能です。ページを削除して、404 ステータス コードを返すようにサーバーを設定するだけで、時間が経つとページは自然に Google のインデックスから削除されます。
- URL の削除を使用するかどうかは、作成された不要な新しいページの数（ページが多すぎると、URL の削除に含めるのが面倒になる可能性があります）と、これらのページがユーザーに与える潜在的な損害によって決まります。URL の削除を通じて送信されたページが検索結果に表示されないようにするには、望ましくない削除済み URL に対して 404 ファイルが見つかりませんでしたというレスポンスが返されるようにページを設定してください。
- ハッカーによってのみ損傷を受けた、以前は正常だったページの削除をリクエストする場合は、このツールを使用しないでください。これらのページは、クリーンアップ後に検索結果に表示する必要があります。URL の削除は、検索結果に表示したくないページにのみ使用してください。
3. Google による正常なページの処理を早めるかどうか検討する
新しい、または更新されたクリーンなページがある場合は、Search Console で URL の再クロールを 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
バックアップが利用できない
サイトがまだ感染している場合でも、サイトのバックアップを 2 つ作成します。追加のバックアップを作成しておくと、誤って削除したコンテンツを復元したり、問題があれば元に戻ってやり直したりできます。後でわかりやすいように、各バックアップに「感染」という印を付けます。
バックアップの 1 つはサイトのディスク イメージ（「クローン版」）とします。この形式を使用すると、コンテンツの復元がさらに簡単になります。ディスク イメージは緊急時のために残しておくことができます。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
ディスクイメージがない場合は、データベースのバックアップを 2 つとファイル システムのバックアップを 2 つ作成します。
新しいバックアップ ファイル システム コピー（サーバー自体ではない）でサイトのコンテンツをクリーンアップする手順は次のとおりです。
- 前回の調査でファイル権限が緩すぎることが判明した場合は、修正してください。サーバーのコピーではなく、バックアップ コピーでこの操作を行うようにしてください。
- また、バックアップ コピーで、被害を評価するで不正使用が判明した URL に対応するすべてのファイルをクリーンアップします。これらは、サーバー構成ファイル、JavaScript、HTML、PHP などです。
- ハッカーによって作成された新しいファイルも削除（404 レスポンスを返す）ようにしてください。これらのファイルは、Search Console の URL 削除ツールを使用して送信されている場合も、そうでない場合もあります。
- コードまたはクラックされたパスワードに脆弱性がある場合は、修正します。入力検証ライブラリやセキュリティ監査が役立つことがあります。
- サイトにデータベースがある場合は、バックアップ内のハッカーが変更したレコードのクリーンアップを開始します。処理が完了したと思われる直前に、さらに多くのレコードをチェックし、データベースがクリーンであることを確認します。
- サイトに関連するすべてのアカウント（FTP アクセス、データベース アクセス、システム管理者、CMS アカウントのログインなど）のパスワードをもう一度変更します。UNIX ベースのシステムでは、次のコードを使用します。
$passwd admin1
この時点で、サイトの感染したバックアップ コピーにはクリーンなデータのみが含まれているはずです。この正常なコピーを手元に保管して、対策 5 に進んでください。
5. 不要なソフトウェアを削除する
サイトで使用しなくなったサーバー上のソフトウェア（ウィジェット、プラグイン、アプリケーションなど）を削除できるかどうかを検討します。これにより、セキュリティを強化し、将来のメンテナンスを簡素化できます。
6. すべてのサーバーをクリーンアップする
- 単にアップグレードするのではなく、クリーン インストールを行います。アップグレードすると、以前のバージョンのファイルが残ることがあります。感染したファイルがサーバーに残っていると、サイトが再びハッキングされる可能性が高くなります。
- サーバー管理者の場合は、OS と、コンテンツ管理システム、e コマース プラットフォーム、プラグイン、テンプレートなどのすべてのソフトウェア アプリケーションを新規インストールする必要があります。利用可能なセキュリティ アップデートとパッチを確認してください。
- クリーンなバックアップ ファイル システムのコピーから、新しくインストールされたサーバーに良質なコンテンツを転送します。既知のクリーンなファイルまたはデータベースのみをアップロードして復元します。適切なファイル権限を維持し、新しくインストールされたシステム ファイルを上書きしないでください。
- サイトに関連するすべてのアカウント（FTP アクセス、データベース アクセス、システム管理者、CMS アカウントのログインなど）のパスワードを最後に変更します。UNIX ベースのシステムでは、次のコードを使用します。
passwd admin1
7. 長期の管理計画を作成する
次のことを強くおすすめします。
- サイトを定期的に自動バックアップする。
- ソフトウェアの更新に常に気を配る。
- サーバー上にインストールする前に、すべてのアプリケーション、プラグイン、その他のサードパーティ ソフトウェアのセキュリティ対策を理解してください。1 つのソフトウェア アプリケーションのセキュリティの脆弱性が、サイト全体の安全性に影響する可能性があります。
- 強力なパスワードを作成する。
- マシンへのログインに使用するすべてのデバイスを安全に保つ（オペレーティング システムとブラウザを更新する）。
8. クリーンアップの完了を再確認する
次の質問に「はい」と答えられるかどうかを確認します。
- ハッカーがユーザーの個人情報を取得した場合、適切な手順を踏んでいますか？
- サイトで最も安全な最新バージョンのソフトウェアを実行していますか？
- 今後のサイトの脆弱性につながりかねない、不要または未使用のアプリケーションやプラグインをすべて削除しましたか？
- コンテンツを復元し、ハッカーのコンテンツを削除しましたか？
- サイトのハッキングを許した根本原因の脆弱性を修正しましたか？
- サイトを安全に保つための計画はありますか？
これで、サイトをオンラインに戻せます。