よこやま良平
WAFで不正アクセスを防ぎたいものの、設定を強くするとWordPressの投稿保存やフォーム送信まで止まり、弱くすると攻撃を通しそうで迷っていませんか？
結論から言うと、WAFは全停止か全許可で運用せず、ログのルールIDと対象URLを確認しながら最小範囲で調整するのが正解です。
20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。
WAFを有効にしただけで安心せず、攻撃と正常操作をログから分ける実務手順を解説します。
- WAFが防げる攻撃と、防げない侵入経路を区別できる
- 誤検知が起きた時に、ルールID・URL・時刻から原因を絞れる
- サイト全体を除外せず、必要な操作だけ安全に通す考え方が分かる
- WAFログを不正アクセス調査や再発防止へつなげられる
WAFの管理画面はサーバー会社、CDN、セキュリティサービスによって項目名が異なります。
ただし「何が、いつ、どのURLで、どのルールにより遮断されたか」を確認する基本は共通です。
この記事では、WordPress初心者でも実行できる順番に絞り、設定変更の前後で残す記録と検証方法まで説明します。
すでに403エラーや保存失敗が起きている場合も、WAFを丸ごと無効化する前に同じ手順で確認してください。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WAFで不正アクセスを防ぐ前に役割と限界を理解する
WAFを安全に使う第一歩は、WAFを「Webへの通信を検査する一つの防御層」と理解することです。
WordPress本体の更新、強い認証、バックアップ、感染後の駆除を置き換える仕組みではありません。
WAFはHTTPリクエストの特徴から攻撃を止める
WAFはブラウザやボットから届くURL、HTTPメソッド、ヘッダー、Cookie、送信データなどを検査します。
SQLインジェクションやクロスサイトスクリプティングなど、既知の攻撃パターンに一致した通信を遮断または記録します。
サーバー会社のWAF、CDN型WAF、WordPressプラグイン型ファイアウォールでは、検査する位置と見える情報が違います。
どの層で拒否したかを知らないまま設定すると、別の層のログを探し続けることになります。
WAFだけでは盗まれた正規IDの操作を判定しにくい
正しいユーザー名とパスワードで通常の管理画面操作をされた場合、通信の形は正規利用とよく似ています。
そのためWAFを有効にしても、認証情報の漏えい、古い管理者、FTP・SSH、脆弱な管理端末からの侵入は別に対策が必要です。
プラグインやテーマの脆弱性を狙う通信も、ルールが対応していなければ通過する可能性があります。
「遮断件数が多いから安全」「ログに何もないから侵入されていない」とは判断できません。
- WordPress本体・テーマ・プラグインを検証後に更新する
- 管理者を最小人数にし、強い固有パスワードと多要素認証を使う
- サーバー、CDN、WordPressのログを保存期間内に確保する
- 復元テスト済みのバックアップを本番サーバー外にも保管する
WAFで不正アクセスを防ぐ初期設定は観測から始める
WAFの初期設定では、いきなり最強の遮断へ切り替えるより、保護対象と正常操作を把握してから段階的に強化します。
正常な基準がなければ、攻撃を止めたのか業務を壊したのかを判定できません。
保護対象のドメインと経路を一覧にする
まず本番ドメイン、www有無、サブドメイン、管理画面、REST API、XML-RPC、問い合わせフォーム、決済や会員機能を一覧にします。
CDNを使う場合は、利用者からCDN、CDNからオリジンサーバーまでの経路も確認してください。
DNSがWAFを経由していない別ホストを向いていれば、その通信は検査されません。
一方でステージング環境まで本番と同じ強いルールを適用すると、検証作業を誤って止めることがあります。
正常操作を時刻付きでテストして基準を残す
投稿の下書き保存、画像アップロード、プラグイン更新、ログイン、ログアウト、フォーム送信などを一つずつ実行します。
実行したJST時刻、URL、利用者、結果を記録し、同じ時刻のWAFログにどのように見えるかを対応付けます。
業務で使うすべての操作を一度に行うと、どの通信が原因か分かりません。
一操作ごとに結果を確認することで、後から誤検知が起きた際の比較資料になります。
管理ルールは標準から始めて変更履歴を残す
サーバー会社やCDNが提供する管理ルールは、一般的な攻撃パターンを継続的に更新するため、通常は標準設定から始めます。
独自ルールを大量に追加する前に、標準ルールの名称、更新方式、検知と遮断の違いを確認してください。
変更記録には、変更日時、変更者、対象ルール、変更前後の値、理由、確認結果、戻し方を残します。
「動かなかったので何かをOFFにした」だけでは、数週間後に危険な例外が放置されます。
- 検知のみ・遮断・チャレンジなど各動作の意味
- ログの保存期間、タイムゾーン、閲覧できる担当者
- 緊急時に一時例外を追加できる権限と連絡先
- 設定変更後に確認する正常操作と攻撃テストの範囲
WAFの誤検知はWordPress特有の正常通信でも起きる
WAFの誤検知は、正常な操作に攻撃と似た文字列や大きな送信データが含まれた時に起きます。
WordPressではブロックエディター、REST API、管理画面のAjax、コードを含む記事、フォーム入力が代表例です。
投稿本文やフォーム入力の文字列がルールに一致する
セキュリティ記事でSQLやJavaScriptの断片を紹介した場合、その文字列自体が攻撃パターンとして検知されることがあります。
HTMLを扱うカスタム投稿、長いフォーム、URLを多く含む本文も、複数ルールのスコアを合計して止められる場合があります。
この時、入力内容を消して保存できたとしても、原因の証明にはなりません。
保存できなかった時刻とWAFログのルールIDが一致して初めて、誤検知の可能性を具体的に説明できます。
REST APIやadmin-ajax.phpが不審な連続通信に見える
ブロックエディターは自動保存や設定取得のため、短時間に複数のREST API通信を行います。
プラグインの管理画面もadmin-ajax.phpへ連続送信するため、頻度制限やボット対策に触れることがあります。
429なら頻度制限、403や406ならアクセス制御・WAFルール、500系ならオリジンサーバー側も候補です。
ただし製品ごとに応答コードを置き換えるため、HTTP番号だけでWAF原因と断定しないでください。
画像アップロードや更新処理がサイズ・時間制限に触れる
大きな画像、バックアップ、テーマやプラグインのZIPは、リクエストサイズや検査時間の上限に触れる場合があります。
サーバーのPHP上限とWAFの上限は別なので、片方だけ変更しても直らないことがあります。
制限値を無制限に上げるのではなく、必要なファイル種別、管理者の操作、対象URLに絞って調整します。
公開フォームまで同じ大容量を許可すると、資源消費型の攻撃を受けやすくなります。
- 原因を確認せずサイト全体のWAFを無効化する
- ルール一式や管理ルールグループ全体を除外する
- 攻撃元か未確認のまま利用者のIPを恒久許可する
- 再現時刻を残さず、同じ保存操作を何度も連打する
WAFログは時刻・URL・ルールID・動作をセットで読む
WAFログの確認では、一件のIPアドレスよりも、時刻、ホスト、URL、HTTPメソッド、ルールID、最終動作をセットで見ます。
同じIPでも複数人が共有し、同じ攻撃者でもIPを変えるため、単一項目だけの判断は危険です。
最初にタイムゾーンとリクエストIDを確認する
管理画面の表示時刻がJST、UTC、サーバーのローカル時刻のどれかを確認します。
WordPressの操作記録と数時間ずれて見える場合、別の通信を誤って原因だと判断するおそれがあります。
リクエストIDやイベントIDがある場合は必ず記録してください。
CDN、WAF、ロードバランサー、Webサーバーのログに同じIDが渡っていれば、一つの通信を層をまたいで追跡できます。
ルールID・一致箇所・最終動作を分けて見る
ルール名にはSQLiやXSSなどの分類が表示されても、それだけで本物の攻撃とは限りません。
一致したパラメータ、スコア、検知のみか遮断か、後続ルールで最終的に許可されたかを確認します。
複数ルールを合計する方式では、一つ一つは弱い一致でも合計点で遮断されます。
この場合、最後に表示されたルールだけを除外しても、別のルールで再び止まることがあります。
クライアントIPとオリジン接続元を混同しない
CDNやリバースプロキシを使うと、Webサーバーから見える接続元はCDNのIPになります。
利用者IPは信頼されたヘッダーへ記録されますが、そのヘッダーを誰でも上書きできる構成では証拠として使えません。
信頼するプロキシ範囲と実IPヘッダーは、サービスの公式手順に従って設定します。
IPだけで永久許可する運用は、共有回線、VPN、モバイル回線、IP変更に弱いため避けてください。
time: 2026-10-24T05:42:10+09:00
host: example.jp
method: POST
path: /wp-json/wp/v2/posts/123
rule_id: EXAMPLE-941
matched_field: request_body
mode: block
request_id: sample-request-id
client_ip: 192.0.2.10上の形式は確認項目を示す架空例であり、実際の製品名やルール番号ではありません。
ログを共有する時は、Cookie、Authorization、パスワード、フォーム本文、個人情報、完全なIPアドレスを必要に応じて秘匿化します。
- イベントの正確な時刻とタイムゾーン
- 対象ホスト、URLパス、HTTPメソッド
- ルールID、ルール名、一致した入力欄
- 検知・遮断・許可・チャレンジなどの最終動作
- クライアントIP、プロキシ経路、ユーザー種別
- リクエストIDとWebサーバー側の応答コード
- 同じ操作を正常完了できた比較時刻
WAFの誤検知を減らす設定は最小範囲で行う
誤検知を減らす時の結論は、サイト全体ではなく「特定ルール×特定URL×必要な操作」へ例外を限定することです。
例外の期限、責任者、戻し方まで決めると、障害対応で作った穴が残りにくくなります。
同じ操作を一度だけ再現してログを特定する
まず入力内容を別の安全な場所へ退避し、操作時刻を記録して一度だけ再現します。
ブラウザ開発者ツールのNetwork欄でURL、HTTPメソッド、応答コードを確認し、同じ時刻のWAFログを探します。
再現できない場合は、ユーザー、ブラウザ、送信内容、IP、Cookie、プラグインの状態など条件差を記録します。
不安定な現象を無理に連打すると、レート制限が加わり元の原因が見えなくなります。
ルール全体ではなく対象パラメータの除外を検討する
製品が対応していれば、特定URLの特定パラメータだけを検査対象から外す方法を優先します。
例えば投稿保存の本文欄で誤検知しても、同じURLの認証や別パラメータまで除外する必要はありません。
パラメータ単位の除外ができない製品では、対象URL、HTTPメソッド、管理者のみ、短い有効期限など複数条件で範囲を狭めます。
「/wp-admin/以下をすべて許可」は攻撃対象になりやすい場所をまとめて無防備にするため避けます。
検知モードで確認してから遮断へ戻す
設定変更後は、一時的に検知のみで正常操作と不審通信の両方を観測できる場合があります。
ただし検知モードは攻撃を止めないため、実施時間を限定し、監視担当がログを見られる状態で使います。
正常操作が成功し、対象外の攻撃ルールが引き続き動作し、別ユーザーやフォームにも悪影響がないことを確認します。
検証後は遮断へ戻し、設定画面とログの両方で適用状態を再確認してください。
サーバー会社へは再現情報をそろえて問い合わせる
利用者側でルール詳細を見られないWAFでは、時刻、対象URL、送信元IP、応答コード、操作内容、画面表示をサーバー会社へ伝えます。
個人情報や認証情報をそのまま送らず、問い合わせ窓口が求める安全な方法を使ってください。
「WAFを切ってください」ではなく、該当イベントと安全な最小例外の可否を確認します。
運営側しか変更できない管理ルールなら、独自除外よりベンダー側の修正や推奨設定が適切な場合があります。
WAFログを不正アクセス調査と再発防止へつなげる
WAFログは不正アクセス調査の重要な材料ですが、単独で侵入の有無を確定する証拠ではありません。
Webサーバー、WordPress、認証、FTP・SSH、メール、CDNの記録と同じ時系列に並べて判断します。
遮断ログと成功ログを分けて考える
WAFに大量の遮断が残っていても、それは防いだ試行を示しているだけで、侵入成功を意味しません。
反対に、危険な通信が許可された記録、管理者ログインの成功、ファイル変更が続いていれば優先度は上がります。
同じURIへの探索、異なるIPからの類似ペイロード、短時間の大量アクセスは攻撃キャンペーンの特徴になり得ます。
ただし検索エンジン、監視サービス、正常なAPI連携も連続通信を行うため、User-Agentだけで断定しません。
WAFの例外追加後は再侵入経路になっていないか監査する
過去に追加した許可IP、URL除外、ルール無効化、ボット許可、国別例外を定期的に一覧化します。
担当者や外注先が変わっても例外が残ると、攻撃者に使われる経路になることがあります。
例外には期限を設定し、期限到来時に自動失効できない場合はカレンダーや運用台帳で見直します。
削除後は業務操作を再テストし、必要ならより狭い条件で作り直してください。
侵害が疑われる時はWAF調整より証拠保存を先にする
未知の管理者、改ざんファイル、不審な転送、サーバー会社の警告がある場合、設定変更を重ねる前にログとファイルを保存します。
WAFを強化して表示が正常になっても、内部に残ったバックドアや盗まれた認証情報は消えません。
遮断、隔離、認証情報変更、感染範囲調査、正常データからの復元、再発防止は別工程として計画します。
復旧後も同じ攻撃パターンが続くか、例外から迂回されていないかをWAFログで追跡します。
WAF運用を止めないための確認頻度と担当を決める
WAFは導入時より、運用開始後の見直しで効果が決まります。
毎日すべてのログを読むのではなく、重要イベント、設定変更、定期監査に分けて担当と確認頻度を決めます。
毎日は通知と業務影響を確認する
遮断数の急増、管理画面やフォームの障害、特定URLへの集中、オリジンサーバー到達異常を確認します。
件数の増減だけでなく、前日と異なるルールや新しい対象URLが現れていないかを見るのがポイントです。
通知が多すぎる場合は、危険度、保護対象、動作、同一イベントの集約で優先順位を付けます。
通知そのものを停止すると重大な変化を見逃すため、閾値と送信先を調整します。
毎月は例外・ルール更新・ログ保存を監査する
有効な例外、無効化ルール、許可IP、管理者権限、通知先、ログ保存期間を台帳と照合します。
退職者や終了した外注先の連絡先・IP・アカウントが残っていないかも確認してください。
管理ルールの更新で新しい誤検知が起きることもあるため、更新履歴と障害発生時刻を照合します。
更新を止め続けるのではなく、テスト環境または限定的な検知モードで影響を確認して追随します。
変更時は前後比較と戻し方を必須にする
WordPress更新、テーマ変更、フォーム追加、API連携、CDN切替の前後で正常操作とWAFログを比較します。
変更前の設定をエクスポートできる場合は、安全な場所へ保存し、戻す条件を決めておきます。
WAF設定の反映には数分かかる製品もあるため、保存直後の一回だけで失敗と判断しません。
反映状態を管理画面またはAPIで確認し、キャッシュを区別してから同じ条件で再テストします。
- 保護対象ドメインとDNS経路が現状と一致している
- 重要な遮断・許可イベントを担当者が確認できる
- 例外ごとに理由、範囲、期限、責任者が記録されている
- 設定変更後に投稿保存・ログイン・フォーム送信を再テストした
- WAF以外の認証・更新・バックアップ対策も継続している
すでに不正アクセスやマルウェア感染が疑われる場合は、WAF設定だけで終わらせず、
復旧サービス「クイックレスキュー」も確認してください。
WAFと不正アクセスに関するよくある質問
完全には防げません。WAFはWeb通信に含まれる攻撃パターンを止める防御層であり、盗まれた正規認証情報、FTP・SSH、管理端末、未対応の脆弱性などは別に対策が必要です。
多要素認証、最小権限、更新、ログ監視、バックアップと組み合わせてください。WAFログに何もないことだけを安全の根拠にしないのが重要です。
本番サイト全体で長時間OFFにするのは避けます。先に操作時刻、URL、応答コードを記録し、WAFログのイベントと一致するか確認してください。
どうしても切り分けが必要なら、監視できる短時間に限定し、対象URLや検知モードなど製品が提供するより狭い方法を優先します。終了後は有効化と正常動作を再確認します。
一時的な切り分けには使えても、恒久対策としては不十分です。共有IP、VPN、モバイル回線では利用者が変わり、許可IPから認証情報が悪用される可能性もあります。
特定ルール、URL、HTTPメソッド、ユーザー認証、期限を組み合わせ、必要な操作だけを通す方が安全です。
必ずではありません。サーバーのアクセス制御、ファイル権限、セキュリティプラグイン、CDN、ログイン制限、地域制限でも403になります。
ブラウザの応答、WAFログ、Webサーバーログを同じ時刻で確認し、どの層が拒否したかを特定してください。
WAFで不正アクセスを防ぎ誤検知を減らす方法まとめ
WAFを有効にするだけでは、不正アクセス対策は完成しません。
正常操作を時刻付きで記録し、WAFログのURL・ルールID・一致箇所・最終動作と照合して、必要な範囲だけを調整することが重要です。
- WAFの防御範囲と限界を理解し、他の対策と重ねる
- 誤検知はサイト全体OFFではなく、特定ルールと対象URLから絞る
- 遮断件数だけで侵入成功・安全を断定せず、他ログと時系列化する
- 例外には期限と責任者を設定し、定期監査で不要な穴を閉じる
まずは今日、投稿保存やフォーム送信を一つ実行し、その時刻のWAFログを確認してください。
正常時の記録が一件あるだけでも、次に障害や攻撃が起きた時の切り分けは大きく速くなります。
侵害の兆候がすでにある場合は、WAF設定だけで隠そうとせず、証拠保存とサイト全体の調査を優先すべきです。
原因、侵入範囲、残存ファイル、認証情報まで確認して初めて、安全な再公開へ進めます。
WordPress・サイト保守を専門家に任せたい時は
復旧後の継続保守、バックアップ、更新、セキュリティ対策まで任せたいなら、
WordPress・サイト保守クイックレスキュー365をご確認ください。