よこやま良平
DDoS攻撃被害でサイトが突然停止したら、最優先は「原因を決めつけてWordPressを触ること」ではなく、証拠を残してサーバー・CDN事業者へ緊急連絡し、外側で通信を制御することです。大量アクセスは管理画面の操作やプラグイン追加だけでは止められません。
このページでは、売上や問い合わせを止めないために、発覚直後の10分、最初の1時間、復旧後24時間で何をするかを順番に整理します。自社サイトが見えない焦りの中でも、被害を広げない判断ができるようになります。
20年以上ITエンジニアとして、WordPressの制作・保守・復旧に携わっている、よこやま良平です。緊急対応では「直す作業」より先に、状況を保全し、正しい窓口へ正確な情報を渡すことが復旧時間を短くします。
DDoS攻撃が疑われるサイト停止時の優先順位／ホスティング会社へ渡す情報／応急的な通信制御と復旧判断／やってはいけない操作／再開後の監視と再発対策が分かります。
DDoSは、外部から大量の通信を送り、回線・サーバー・アプリケーションの処理能力を使い切らせる攻撃です。WordPressのファイル改ざんやパスワード窃取とは仕組みが違うため、侵入被害と同じ復旧手順だけでは解決しません。
ただし、アクセス集中、サーバー障害、重いプラグイン、データベース停止でも似た症状が出ます。本記事はDDoSの「見分け方」そのものではなく、被害が疑われてサイトが止まった時に安全に動くための実務手順へ重点を置きます。
担当者が少ない企業や個人サイトでも使えるよう、専門用語は必要な範囲にとどめています。上から順番に確認し、実施した時刻と結果を必ずメモしてください。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
DDoS攻撃被害でサイト停止した直後の結論
DDoS攻撃被害が疑われたら、まず証拠保全、外部確認、事業者連絡の3つを同時に進めるのが正解です。WordPressへ何度もログインしたり、設定を片端から変えたりすると、負荷と混乱を増やします。
発覚後10分で行う緊急対応
最初に、エラー画面、発生時刻、利用回線、確認端末、表示されたHTTPステータス、監視通知を保存します。スクリーンショットは画面全体だけでなく、ブラウザのURLと時刻が分かる状態で残してください。
次に、スマートフォン回線など社内とは別のネットワークからトップページと重要ページを各1回確認します。自分の端末だけの問題か、広範囲の停止かを切り分けるためであり、何十回も再読み込みする必要はありません。
- 発生時刻と最初に気づいた人を記録する
- エラー画面と監視通知を保存する
- 別回線からトップページを1回確認する
- サーバー会社またはCDNの障害情報を確認する
- 契約者情報を用意して緊急窓口へ連絡する
最初の1時間で守るものを決める
サイト全体を即座に元通りにすることより、事業への影響を小さくする判断が先です。問い合わせ、決済、予約、会員ログインなど、止まると損失が大きい機能から優先順位を付けます。
復旧見込みが読めない時は、別ドメインの告知ページ、SNS、メール、電話など、攻撃対象のサーバーを通らない連絡経路を使います。同じサーバー内に障害告知ページを置いても、回線ごと詰まれば表示されません。
原因が分からないままDNSを何度も変更する、WordPressを再インストールする、ログを削除する、無計画にサーバーを再起動する、攻撃者へ連絡する行為は避けてください。復旧の手掛かりや事業者側の観測情報を失う危険があります。
DDoS攻撃被害を事業者へ伝える情報
DDoS攻撃被害への対処は、サーバー会社やCDNへ「サイトが見えません」とだけ伝えるより、時刻・対象・症状・変化をまとめて渡すほど早く進みます。ネットワーク側の制御権限を持つ担当者が判断できる材料を揃えましょう。
問い合わせ前に集める最低限の記録
契約ID、対象ドメイン、サーバー名、接続元IP、発生時刻、平常時と異なるアクセス量、主なアクセス元、帯域・CPU・メモリのグラフを用意します。数値が取得できない場合は、管理画面で確認できなかった事実も記録に含めます。
「午前5時12分から、トップページと管理画面の両方で504。別回線でも再現。CDN管理画面ではリクエストが平常時の約何倍に増加」のように、観測事実と推測を分けて書くことが重要です。DDoSと断定できない段階なら「DDoSの疑い」と伝えます。
対象ドメイン／発生した日時とタイムゾーン／確認したURL／エラーコード／別回線での再現有無／帯域・リクエスト数・負荷の変化／直前の更新作業／希望する対応と連絡方法を1つのメモにまとめます。
ログを安全に保全する
アクセスログ、WAFログ、CDNイベント、サーバー負荷グラフは、保存期間が短いことがあります。管理画面から取得できる範囲をダウンロードし、ファイル名へ取得日時と対象を付け、元データを編集せず保管します。
ログにはIPアドレスやCookieなどの情報が含まれるため、公開チャットやSNSへ貼り付けてはいけません。委託先へ渡す場合も、契約上の窓口と安全な共有方法を確認します。
DDoSと侵入被害を混同しない
大量通信によるサービス妨害と、管理者権限の奪取やマルウェア感染は別の事象です。ただし、DDoSを目くらましにして別の侵入を試みる可能性はあるため、復旧後にはログイン履歴、ユーザー、ファイル変更も確認します。
見覚えのない管理者、検索結果の改ざん、不審な転送、未知のPHPファイルがあれば、単なるDDoS対応で終わらせず侵害調査へ切り替えます。証拠を残したまま、専門家とホスティング会社の両方へ相談してください。
社内と顧客への情報共有を一本化する
障害対応中は、技術担当、経営者、営業、顧客対応で認識がずれやすくなります。連絡担当を1人決め、発生時刻、現在の影響、実施済み対応、次回更新時刻を同じ記録から共有してください。担当者ごとに異なる推測を発信すると、顧客の不安と問い合わせが増えます。
顧客向けには「DDoSと断定」「個人情報が漏れた」と未確認の内容を書かず、現在確認できている影響と代替手段を伝えます。一方、社内記録には判断の根拠、事業者からの回答、設定変更を詳しく残し、後の報告書と再発対策に使います。
問い合わせ窓口がサイトと同時に止まる場合に備え、電話、別ドメインのメール、SNSなど複数の導線を準備します。ただし、担当者の個人アカウントを急に公開すると、なりすましや情報管理の問題が起きるため、平常時に公式な代替窓口を決めておくべきです。
DDoS攻撃被害を止める応急処置
DDoS攻撃被害を止める中心は、WordPress内部ではなくCDN、WAF、回線、ロードバランサーなど上流で不要な通信を落とすことです。攻撃リクエストがPHPへ届いてから拒否しても、その時点でサーバー資源を消費しています。
ホスティング会社の緊急措置を優先する
契約中の事業者に、DDoS緩和機能、IP単位・国単位・経路単位のフィルタリング、レート制限、一時的なブラックホールルーティング、上位プランへの一時移行が可能か確認します。機能名と適用範囲は事業者ごとに異なります。
ブラックホールは対象IP宛ての通信をすべて破棄する強い措置です。攻撃は止まっても正規利用者もアクセスできないため、営業影響と解除条件を確認したうえで使います。安易に恒久設定へしないことが大切です。
CDNとWAFで入口を絞る
CDNを利用している場合は、攻撃対策モード、レート制限、ボット対策、キャッシュ、地域制御などを検討します。ログイン、検索、XML-RPC、REST APIなど、負荷が高くなりやすい経路だけ条件を厳しくすると、通常閲覧への影響を抑えられます。
ただし、DNSをCDNへ切り替えた直後でも、攻撃者が元サーバーのIPを知っていれば直接狙われます。オリジンサーバーはCDNの送信元だけを許可するなど、事業者の手順に沿って入口を閉じる必要があります。
WordPress側でできることの限界を知る
WordPress側では、不要なXML-RPC、ログイン試行、重い検索、コメント投稿を制限し、ページキャッシュを有効にすることで一部のアプリケーション層攻撃を軽減できます。しかし、大容量の通信で回線が飽和する攻撃はプラグインだけで防げません。
クイックレスキュー365は、不正ログインブロック、ログインURL変更、XMLRPC遮断、ユーザー名漏えい防御など、WordPressへの攻撃面を減らす用途に向きます。マルウェアスキャン機能やネットワーク帯域のDDoS緩和機能はないため、目的を分けて使ってください。
通信がオリジンへ届く前に止められるか、正規ユーザーへの影響を限定できるか、解除条件と担当者が明確か、設定変更前の値を保存したか、という4点で判断します。
DDoS攻撃被害でやってはいけない復旧作業
DDoS攻撃被害の最中は、焦って大きな変更を重ねないことが復旧の近道です。変更点が増えるほど、攻撃の影響と自分の設定ミスを区別できなくなります。
WordPressの初期化や再インストールをしない
DDoSは通常、WordPressファイルを入れ替えれば止まる問題ではありません。初期化すると、注文、問い合わせ、会員情報、テーマ設定、証拠となるログを失う恐れがあります。
画面が真っ白、503、504でも、それだけでファイル破損とは判断できません。バックアップを取らずに再インストールするのではなく、まず上流の負荷とサーバー状態を確認します。
IPアドレスを1件ずつ手作業で拒否しない
DDoSでは多数の送信元や、正規端末を悪用した通信が使われます。目立つIPを数件拒否しても攻撃全体は止まらず、設定ファイルが肥大化してWebサーバーの処理負荷を上げる場合があります。
IP制限が有効なのは、対象が絞れており、上流機器やCDNで効率的に落とせる時です。自動化されたレート制限や事業者の緩和サービスを優先し、手作業の拒否は根拠と期限を決めます。
DNSを無計画に変更しない
DNS変更は反映に時間差があり、TTLやキャッシュの影響で新旧の経路が混在します。変更を繰り返すと、利用者ごとに見えるサイトが変わり、復旧確認が難しくなります。
切り替える場合は、現在のレコードを控え、TTL、メール用レコード、サブドメイン、証明書、オリジン制限まで移行計画に含めます。サイトだけを急いで切り替え、メールを止めないよう注意してください。
変更前の値、実施時刻、担当者、目的、確認結果、戻し方を必ず記録します。1回の変更ごとに効果を観測し、効かなければ元へ戻せる状態を保ちましょう。
DDoS攻撃被害から復旧する確認手順
DDoS攻撃被害からの復旧は、トップページが一度表示された時点では完了ではありません。正規利用者が重要機能を継続して使え、再度負荷が上がっても検知できる状態まで確認します。
段階的にサービスを再開する
最初に静的な告知ページやキャッシュ済みページを確認し、次にトップページ、主要な下層ページ、問い合わせ、ログイン、決済の順で機能を戻します。一斉に開放すると、正規アクセスの回復だけで再び負荷が跳ね上がることがあります。
社内、モバイル回線、可能なら異なる地域から確認し、HTTPステータス、表示時間、フォーム送信結果を記録します。ブラウザで見えることだけでなく、利用者が完了すべき操作まで試すことが重要です。
- 事業者から緩和状況と解除条件を確認する
- トップページと静的ページを確認する
- 重要なフォーム・予約・決済をテストする
- CPU・メモリ・帯域・エラー率を監視する
- 正規アクセスへの誤検知がないか確認する
- 関係者へ復旧状況と残る制限を共有する
攻撃終了後も24時間以上監視する
攻撃は止まったように見えて再開することがあります。少なくとも翌営業日までは、帯域、リクエスト数、5xxエラー率、応答時間、WAFブロック数、オリジン負荷を通常より短い間隔で監視します。
しきい値は攻撃中の最大値ではなく、平常時の平均と繁忙時間帯を基準に設定します。アラートが多すぎると重要な通知を見落とすため、警告と緊急の2段階に分けると運用しやすくなります。
一時設定を安全に解除する
緊急時に設定した国別制限、強いレート制限、ボット判定、メンテナンス表示をそのまま残すと、検索エンジン、決済通知、外部API、正規の海外利用者を長期間遮断することがあります。設定ごとに期限と解除担当を決め、攻撃の再発を監視しながら段階的に戻します。
解除前には現在値を保存し、1項目ずつ変更してエラー率と負荷を比較します。すべてを一度に元へ戻すと、どの制限が防御に効いていたか分からず、再攻撃時の判断材料を失います。解除後も最低1時間は主要ページとフォームを監視してください。
キャッシュを消す場合も、全消去によるアクセス集中に注意します。大量のページが同時に再生成されると、攻撃が収まっていてもCPU負荷が上がります。重要ページから温める、事業者の低負荷時間帯に行うなど、再開直後の負荷を抑える計画が必要です。
侵害とデータ不整合を確認する
DDoS中にサーバーが強制終了した場合、キャッシュ、セッション、予約処理、定期実行、データベース書き込みが途中で止まることがあります。注文の二重処理、メール未送信、予約投稿失敗がないか確認してください。
管理者ユーザー、プラグイン、テーマ、更新日時の新しいPHPファイル、ログイン履歴も点検します。不審点があれば証拠を残し、通常運用へ完全復帰する前に侵害調査を行います。
重要ページが安定表示／主要機能の操作完了／負荷が平常範囲／監視通知が動作／設定変更と解除条件を記録／侵入の兆候なし、の6項目を満たした時点を復旧完了とします。
DDoS攻撃被害を繰り返さない事前対策
DDoS攻撃被害への最善策は、次回の連絡先、判断基準、切り替え手順を平常時に決めることです。攻撃中にサービス比較や契約権限の確認を始めると、停止時間が長くなります。
技術対策を多層化する
CDN、WAF、レート制限、キャッシュ、オリジンIP制限、負荷監視、冗長構成を組み合わせます。単一機能に任せるのではなく、回線、Webサーバー、WordPressの各層で役割を分けます。
通常時のトラフィック量と繁忙期のピークを把握し、契約プランの上限、従量課金、DDoS緩和の対象と費用を確認します。防御で高額な転送料が発生するケースもあるため、料金アラートも必要です。
緊急連絡票と代替導線を用意する
契約ID、ドメイン、DNS、CDN、サーバー、保守会社、決済会社の連絡先を1枚にまとめます。担当者が不在でも連絡できるよう、認証方法と権限の保管ルールも決めます。
停止中の告知は、別基盤のステータスページ、SNS、メール配信を準備します。顧客向け文章は、発生時刻、影響範囲、代替手段、次回更新時刻を簡潔に伝え、未確認の原因を断定しません。
訓練で手順の穴を見つける
半年に1回程度、「サイトへ接続できず管理画面にも入れない」という想定で机上訓練を行います。連絡先が古くないか、契約者本人しか依頼できない作業がないか、監視通知が担当者へ届くかを確認します。
訓練後は、連絡までの時間、判断に迷った点、取得できなかったログ、復旧確認の漏れを改善します。手順書は作った日ではなく、実際に使って更新した日から価値が生まれます。
事業者のDDoS対応範囲を確認／通常トラフィックを記録／緊急連絡票を更新／別基盤の告知手段を準備／ログ保存期間を確認／復旧テストを定期実施します。
DDoS攻撃被害のよくある質問
DDoS攻撃被害の現場で特に迷いやすい点を、緊急対応の観点から簡潔に答えます。
いいえ。ログイン試行やXML-RPCなど一部のアプリケーション層攻撃は軽減できますが、回線を埋める大容量攻撃はCDN、WAF、ホスティング会社など上流での制御が必要です。
断定できません。アクセス集中、メンテナンス、PHPワーカー不足、データベース障害でも503は発生します。時刻、複数回線、負荷グラフ、アクセスログを照合してください。
事業者の指示がない限り、最初の手段にはしません。一時的に表示が戻っても攻撃通信が続けば再発し、ログや状態を失う恐れがあります。
発生時刻、被害内容、業務影響、ログ、画面、事業者とのやり取り、設定変更履歴を原本のまま保全します。個人情報を公開せず、相談窓口の指示に従って提出してください。
DDoS攻撃被害のサイト停止対応まとめ
DDoS攻撃被害でサイトが止まった時は、証拠保全、別回線での確認、事業者への緊急連絡を最優先にします。大量通信をWordPress内部だけで止めようとせず、CDN、WAF、回線など上流で制御することが重要です。
復旧後は重要機能を段階的に再開し、少なくとも翌営業日まで監視します。侵入の兆候、注文や予約の不整合、解除し忘れた制限も確認して、初めて復旧完了と判断できます。
ログを消さない／変更を重ねない／上流事業者へ連絡／重要機能から確認／復旧後も監視／対応記録を次回手順へ反映、の順番を守ってください。
よこやま良平が復旧現場で重視しているのは、作業量ではなく判断の順番です。自社だけで原因や制御範囲を判断できない場合は、設定を壊す前にサーバー会社と専門家へ相談してください。
DDoS攻撃被害によるWordPress停止が自分で直せない時は
ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。
WordPressが真っ白画面／WordPressがログインできない／ホームページのマルウェアや乗っ取り／サイトの表示くずれ／エラーが表示されている
これらでお悩みなら最短30分ですぐに解決します！
いまなら期間限定で
・万一改善されない場合は全額返金保証で安心!
・30日間動作保証で安心!
・初期費・調査料 0円で安心!