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