2026年9月9日

DDoS攻撃の対策と緩和方法｜WordPressサイトとサーバーでできること・できないこと

サーバーセキュリティ・SSL

DDoS 攻撃への対策は「自分のサーバーで止められる攻撃」と「上流（ホスティング事業者や CDN）でしか止められない攻撃」を分けて考えるのが出発点です。回線を埋め尽くすような大量の通信はサーバー側の設定では防げないため、CDN や事業者の防御に任せ、サーバー側ではアプリケーション層の負荷を減らす工夫を重ねます。この記事では、攻撃の見分け方、CDN の使い方、nginx でのレート制限、WordPress 特有の狙われやすい箇所、攻撃を受けている最中の対応手順を説明します。

DDoS攻撃の種類と、どこで防ぐか

DDoS は多数の送信元から一斉に通信を送りつけ、サービスを使えなくする攻撃です。大きく分けると次の3種類があり、それぞれ防ぐ場所が違います。

帯域を埋める攻撃（UDP の大量送信や反射・増幅型など）：サーバーに届く前の回線が詰まるため、サーバー内の設定では対処できません。ホスティング事業者やクラウド、CDN の防御が頼りです。
TCP の接続状態を枯渇させる攻撃（SYN フラッドなど）：OS 側の設定である程度は耐えられますが、規模が大きいと上流での防御が必要です。
HTTP リクエストを大量に送る攻撃（アプリケーション層、L7）：見た目は通常のアクセスに近く、WordPress のように1リクエストごとに PHP とデータベースが動くサイトでは、少ない量でも重くなります。CDN の WAF、サーバーのレート制限、キャッシュで対処できる部分が大きい領域です。

小規模な WordPress サイトが実際に受けやすいのは、3つ目の HTTP フラッドや、ログイン画面への大量アクセスです。この記事も主にこの層を扱います。

まず攻撃かどうかを見分ける

サイトが重くなった原因は、攻撃とは限りません。検索エンジンのクローラーの集中、SNS で記事が拡散された、プラグインの不具合で重い処理がループしている、といった可能性もあります。対処を誤らないよう、最初にアクセスログで「どこから」「どこへ」来ているかを確認します。

# 送信元IPごとのリクエスト数（上位20件）
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# リクエスト先URLごとの件数（上位20件）
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# TCPの接続状態の概要と、SYN受信待ちの数
ss -s
ss -Hnt state syn-recv | wc -l

ログの場所や形式はサーバーによって違うため、Apache の場合は /var/log/apache2/ や /var/log/httpd/ などを確認してください。CDN を通している場合、ログの送信元 IP が CDN のアドレスばかりになるので、後述の実 IP の設定が必要です。

特定の IP や国からの集中、wp-login.php や xmlrpc.php、検索結果ページ（/?s=）への偏り、存在しない URL への大量アクセスなどが見えれば、攻撃や不正なボットの可能性が高まります。

CDNとWAFを前段に置く

帯域を埋める攻撃や大規模な HTTP フラッドに対して、個人や小規模な運営者が現実的に取れる手段は、CDN を前段に置くことです。Cloudflare、Amazon CloudFront と AWS WAF・AWS Shield、Google Cloud Armor など、主要な CDN やクラウドは DDoS 緩和の仕組みを備えています。どの範囲までが標準で含まれ、どこからが有料プランや追加契約になるかはサービスごとに異なり、変更もあるため、契約前に各社の最新の資料を確認してください（2026年10月現在）。

CDN を入れたら、次の点を押さえておきます。

静的ファイルと、可能ならページ自体をキャッシュする。CDN からキャッシュを返せれば、攻撃のリクエストがオリジン（自分のサーバー）まで届きません。ログイン中のユーザーや管理画面、カートなどはキャッシュから除外します。
オリジンの IP アドレスを隠す。攻撃者がオリジンの IP を知っていると、CDN を迂回して直接攻撃できます。メールの MX レコードや古いサブドメインが同じ IP を指していないか確認し、オリジン側のファイアウォールで CDN からの接続だけを受け付けるようにします。過去に IP が公開されていた場合は、IP の変更も検討します。
攻撃時の切り替え手段を知っておく。Cloudflare には、すべての訪問者にブラウザーのチェックを挟むモード（I'm Under Attack Mode）があります。名称や挙動は変わることがあるため、普段から管理画面のどこにあるかを確認しておくと、攻撃時に慌てずに済みます。

nginxでレート制限と接続数制限をかける

CDN の内側でも、オリジンを守るための制限をかけておくと、すり抜けてきた負荷を抑えられます。nginx では limit_req（一定時間あたりのリクエスト数）と limit_conn（同時接続数）が使えます。

# http コンテキストに記述
limit_req_zone  $binary_remote_addr zone=wplogin:10m rate=6r/m;  # 1IPあたり平均10秒に1回
limit_req_zone  $binary_remote_addr zone=general:10m rate=10r/s; # 1IPあたり毎秒10回
limit_conn_zone $binary_remote_addr zone=perip:10m;

server {
    # ...既存の設定...
    limit_conn perip 30;          # 1IPあたり同時接続30まで
    limit_req_status  429;
    limit_conn_status 429;

    location = /wp-login.php {
        limit_req zone=wplogin burst=5 nodelay;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php-fpm.sock;   # 環境に合わせて変更
    }

    location ~ \.php$ {
        limit_req zone=general burst=20 nodelay;
        # ...既存の PHP 設定...
    }
}

つまずきやすい点が2つあります。1つ目は、location = /wp-login.php を新しく作ると、その中で PHP の処理を書かない限り、ログイン画面がダウンロードされたり表示されなくなったりすることです。既存の PHP 用 location と同じ FastCGI 設定を入れてください。ソケットのパスは環境によって違います。

2つ目は、CDN やロードバランサーの内側では $binary_remote_addr が CDN のアドレスになり、全員が同じ IP として扱われてしまうことです。ngx_http_realip_module の set_real_ip_from で CDN のアドレス範囲を信頼し、real_ip_header で実際の送信元を示すヘッダーを指定します。Cloudflare なら CF-Connecting-IP が使えます。CDN のアドレス範囲は各社が公開している最新の一覧を使います。

設定後は nginx -t で構文を確認してから再読み込みし、ログイン・投稿の保存・画像のアップロードなど普段の操作が 429 にならないかを確認します。数値はサイトの規模で大きく変わるので、最初はゆるめに設定し、ログを見ながら調整してください。

WordPressで狙われやすい箇所を守る

WordPress には、攻撃に使われやすい入口がいくつかあります。

wp-login.php：ログイン試行の集中は、総当たり攻撃と DDoS の両方の性質を持ちます。上記のレート制限に加え、Wordfence や Limit Login Attempts Reloaded などのプラグインで試行回数を制限できます。プラグインは PHP が動いた後に処理するため、大量アクセスにはサーバーや CDN での制限の方が効きます。
xmlrpc.php：使っていなければアクセスを拒否できます。Jetpack や一部の外部アプリ連携が XML-RPC を使う場合があるので、止める前に影響を確認してください。
検索（/?s=）：検索はキャッシュが効きにくく、データベースに負荷がかかります。CDN の WAF で検索へのリクエスト頻度を制限する方法があります。
wp-cron.php：アクセスのたびに実行される仕組みのため、負荷が高いときは wp-config.php で define( 'DISABLE_WP_CRON', true ); とし、サーバーの cron から定期実行する方法があります。止めるだけだと予約投稿などが動かなくなる点に注意します。

あわせて、ページキャッシュ（WP Super Cache や W3 Total Cache、サーバー側のキャッシュ機能など）を有効にしておくと、通常のアクセスの処理が軽くなり、急な負荷にも耐えやすくなります。

攻撃を受けている最中の対応手順

実際に攻撃を受けたときは、次の順で進めます。

状況を記録する：開始時刻、アクセスログの抜粋、上位の IP や URL を保存します。事業者への連絡や後の分析に使います。
ホスティング事業者に連絡する：帯域を埋める攻撃は、事業者でしか止められません。契約によっては事業者側で遮断や回線の切り替えをしてもらえます。
CDN の防御を強める：攻撃時用のモードを有効にする、特定の国や IP 範囲へのチャレンジを設定する、問題の URL に厳しいレート制限をかける、といった操作をします。
オリジンを守る：オリジン IP が漏れていれば、ファイアウォールで CDN 以外からの接続を拒否します。少数の IP からの攻撃なら、fail2ban や一時的なファイアウォールのルールで遮断できます。
落ち着いたら振り返る：どの入口が狙われたか、キャッシュから外れていたページはなかったかを確認し、設定を見直します。

本番の設定を変更する前には、現在の設定ファイルを控えておき、元に戻せる状態にしておいてください。

まとめ

DDoS は「帯域」「TCP 接続」「HTTP リクエスト」の層ごとに防ぐ場所が違う。帯域を埋める攻撃はサーバーでは止められない
重くなったら、まずアクセスログで送信元と URL の偏りを確認し、攻撃かどうかを見分ける
CDN を前段に置き、キャッシュを効かせ、オリジン IP を隠す。プランごとの防御範囲は最新の資料で確認する
nginx の limit_req と limit_conn でオリジンを守る。CDN の内側では実 IP の設定を忘れない
wp-login.php、xmlrpc.php、検索、wp-cron.php といった WordPress の入口を個別に見直す
攻撃時は記録・事業者への連絡・CDN の強化・オリジンの保護の順に進める