サイトの問題を修正して管理する

必要なもの:

サイトのサーバー（ウェブ、データベース、ファイル）へのシェルまたはターミナルの管理者アクセス権限
シェルまたはターミナルのコマンドの知識
コードの理解（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. サーバーのクリーンアップを開始する

ここで、被害の程度の確認と脆弱性の特定で取った記録に基づいて、サイトのクリーンアップを開始します。以下の手順は、利用できるバックアップのタイプによって異なります。

正常な最新のバックアップ
正常だが古い状態のバックアップ
バックアップが利用できない

まず、サイトがハッキングされる前にこのバックアップが作成されたことを確認します。

正常な最新のバックアップ
1. バックアップを復元します。
2. 入手可能なソフトウェアのアップグレード、アップデート、パッチをインストールします。これは、OS のソフトウェア（サーバーを管理している場合）と、すべてのアプリケーション（コンテンツ管理システム、e コマースプラットフォーム、プラグイン、テンプレートなど）が対象となります。
3. サイトで使用しなくなったソフトウェア（ウィジェット、プラグイン、アプリケーションなど）をサーバーから削除できるかどうか検討します。
4. 脆弱性を修正します。
5. 被害の程度の確認で見つかったすべての問題に対処したかどうかを確認します。
6. サイトに関するすべてのアカウント（FTP アクセス、データベースアクセス、システム管理者、CMS アカウントなどのログイン）のパスワードを再度変更します。Unix ベースシステムでは、次のコマンドを実行します。
```
$passwd admin1
```
正常だが古い状態のバックアップ
1. 現在のサイトのディスクイメージを作成します。サイトが感染している状態でもかまいません。このコピーは安全のためです。他のものと区別するため、感染していることがわかるようにコピーに印を付けます。Unix ベースシステムでは、次のようにディスクイメージを作成します。
```
$dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9
  > /mirror/full-backup-20120125-infected.gz
```
2. 画像やメディアファイルを含む、サーバーのバックアップファイルシステムのコピーを作成します。データベースがある場合は、データベースもバックアップします。
```
$tar -pczf full-backup-20120125-infected.tar.gz www/ $ mysqldump -u root
  -p --all-databases | gzip -9 > fulldb_backup-20120125-infected.sql
```
3. 正常だが古い状態のバックアップをサーバー上で復元します。
4. サイトで使用しなくなったソフトウェア（ウィジェット、プラグイン、アプリケーションなど）をサーバーから削除できるかどうか検討します。
5. すべてのソフトウェアをアップグレードします。OS のソフトウェア（サーバーを管理している場合）と、すべてのアプリケーション（コンテンツ管理システム、e コマースプラットフォーム、プラグイン、テンプレートなど）が対象となります。入手可能なセキュリティアップデートとパッチを確認して、インストールします。
6. 脆弱性を修正します。
7. 手動または自動で、サイトの diff を実行します（正常なバックアップと現在の感染しているコピーを比較します）。
```
$diff -qr www/ backups/full-backup-20120124/
```
8. 感染したコピーから保護したい新しい正常なコンテンツがあれば、アップグレード済みのサーバーにアップロードします。
```
$rsync -avz /backups/full-backup-20120124/www/clean-file.jpg /www/
```
9. 被害の程度の確認で見つかったすべての URL を修正したかどうかを確認します。
10. サイトに関するすべてのアカウント（FTP アクセス、データベースアクセス、システム管理者、CMS アカウントなどのログイン）のパスワードを再度変更します。Unix ベースシステムでは、次のコマンドを実行します。
```
$passwd admin1
```
バックアップが利用できない
1. サイトのバックアップを 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 つ作成します。
2. サーバー上ではなく、新しいバックアップファイルシステムのコピー上で、サイトのコンテンツをクリーンアップします。
  1. これまでに調べて、ファイルに緩すぎる権限が見つかった場合は、権限を修正します。この修正は必ず、サーバー上ではなく、バックアップコピー上で行います。
  2. 同様にバックアップコピー上で、被害の程度の確認で不正使用が見つかった URL に対応するすべてのファイルをクリーンアップします。サーバーの設定ファイル、JavaScript、HTML、PHP などが対象です。
  3. ハッカーによって作成された新しいファイルも削除（404 レスポンスを配信）します（これらのファイルは、Search Console の [URL の削除] ツールで送信済みの場合があります）。
  4. コードや解読されたパスワードに脆弱性がある場合は修正します。入力検証ライブラリやセキュリティ監査が役立つことがあります。
  5. サイトにデータベースがある場合は、バックアップ内のハッカーに変更されたレコードのクリーンアップを開始します。この手順を完了する前に、その他のレコードの正当性チェックを実行して、正常な状態かどうかを確認します。
  6. サイトに関するすべてのアカウント（FTP アクセス、データベースアクセス、システム管理者、CMS アカウントなどのログイン）のパスワードを再度変更します。Unix ベースシステムでは、次のコマンドを実行します。
```
$passwd admin1
```
  7. この時点で、感染していたサイトのバックアップコピーには正常なデータのみが含まれているはずです。この正常なコピーを手元に保管して、対策 5 に進んでください。

5. 不要なソフトウェアを除去する

サイトで使用しなくなったソフトウェア（ウィジェット、プラグイン、アプリケーションなど）をサーバーから削除できるかどうか検討します。削除するとセキュリティが向上し、今後の管理が簡単になります。

6. すべてのサーバーをクリーンアップする

単にアップグレードするのではなく、クリーンインストールを行います。アップグレードでは、古いバージョンのファイルが残ることがあります。感染したファイルがサーバーに残ると、新たなハッキングが起きる可能性が高まります。
- クリーンインストールは、OS のソフトウェア（サーバーを管理している場合）と、すべてのアプリケーション（コンテンツ管理システム、e コマースプラットフォーム、プラグイン、テンプレートなど）が対象となります。入手可能なセキュリティアップデートとパッチも必ず確認します。
バックアップファイルシステムのクリーンアップしたコピーから、新たにインストールしたサーバーに正常なコンテンツを移行します。正常な既知のファイルとデータベースのみをアップロード、復元します。ファイルの適切な権限を管理し、新たにインストールしたシステムファイルを上書きしないようにします。
サイトに関するすべてのアカウント（FTP アクセス、データベースアクセス、システム管理者、CMS アカウントなどのログイン）のパスワードを最後にもう一度変更します。Unix ベースシステムでは、次のコマンドを実行します。
```
$passwd admin1
```

7. 長期の管理計画を作成する

ウェブ上にはサイトの強力な管理の参考になる便利な情報が多数あります（StopBadware の Preventing badware: basics など）。また、次の手順を行うことも強くおすすめします。

サイトを定期的に自動バックアップする。
ソフトウェアの更新に常に気を配る。
サーバーにインストールする前に、すべてのアプリケーション、プラグイン、サードパーティソフトウェアなどのセキュリティ対策を把握しておく。あるソフトウェアアプリケーションにセキュリティの脆弱性があると、サイト全体の安全性が損なわれるおそれがあります。
強力なパスワードを作成する。
マシンへのログインに使用するすべてのデバイスを安全に保つ（オペレーティングシステムとブラウザを更新する）。

8. クリーンアップの完了を再確認する

次の質問に「はい」と答えられるかどうかを確認します。

ハッカーがユーザーの個人情報を入手している場合、適切な手順を行いましたか？
最も安全な最新版のソフトウェアをサイトで実行していますか？
今後のサイトの脆弱性につながるおそれのある、使用しないまたは不要なアプリケーションやプラグインをすべて削除しましたか？
コンテンツを復元して、ハッカーのコンテンツを削除しましたか？
サイトのハッキングを許した根本原因の脆弱性を修正しましたか？
サイトを安全に保つための計画はありますか？

9. サイトをオンラインに戻す

次のステップ

完了まであと一息です。このプロセスの最後の手順は、再審査のリクエストです。