ModSecurityとCloudflare WAFの比較：置き場所の違いと選び方、併用の手順

ModSecurityはサーバーの中で動くWAF、Cloudflare WAFはサーバーの手前のクラウドで動くWAFです。どちらが優れているかではなく、「どこで攻撃を止めたいか」「誰が運用するか」で向き不向きが分かれます。この記事では、両者の仕組みの違い、WordPressで使うときの注意点、条件別の選び方、併用するときの設定の要点を説明します。

仕組みの違い：どこで通信を検査するか

ModSecurity：オリジンサーバーの中

ModSecurityは、Apache や Nginx に組み込んで動くオープンソースのWAFエンジンです。長くTrustwaveが開発してきましたが、現在はOWASPのプロジェクトとして引き継がれています（2026年10月現在）。Apache向けのv2系と、ライブラリとして独立したv3系（libmodsecurity、Nginxはコネクタ経由）があります。

エンジン自体は「ルールを実行する仕組み」で、何を攻撃とみなすかはルールで決まります。一般的には OWASP Core Rule Set（CRS）を入れて使います。CRSは複数のルールの点数を合計して一定以上なら遮断する「異常スコア方式」と、検知の厳しさを段階で選ぶ「パラノイアレベル」を持っています。

Cloudflare WAF：サーバーの手前のクラウド

Cloudflare WAFは、DNSをCloudflareに向けてプロキシを有効にしたサイトの通信を、Cloudflareのネットワーク上で検査します。Cloudflareが用意する管理ルール（マネージドルール）、自分で条件を書くカスタムルール、レート制限のルールなどを組み合わせて使います。どのルールセットや機能が使えるかはプランによって異なり、構成も変わることがあるので、最新の内容はCloudflareの公式ドキュメントで確認してください。

比較表

表のうち「迂回されるリスク」は見落とされやすい項目です。後の「併用の手順」で対策を書きます。

WordPressで使うときの注意点

誤検知への対処が運用の中心になる

WordPressの管理画面は、記事本文にHTMLやスクリプトに見える文字列を送ったり、REST API に複雑なJSONを送ったりします。WAFからは攻撃に似て見えるため、ブロックエディターで保存できない、プラグインの設定が保存されない、といった誤検知が起こります。

• ModSecurity: CRS v4にはWordPress向けの除外ルールがプラグインとして用意されています。まず SecRuleEngine DetectionOnly（検知のみ）で動かし、監査ログで誤検知のルールIDを確かめてから、範囲を絞った除外ルールを書きます
• Cloudflare: 管理ルールの中にWordPress向けのルールが含まれています。誤検知は、セキュリティイベントで該当ルールを確かめ、特定のパスやルールだけを除外（スキップ）する形で対応します。ルール全体を無効にするのは最後の手段です

どちらも、誤検知を「WAFを止める」ことで解決すると、守りが無くなります。原因のルールと対象のURLを特定し、除外を最小限にするのが基本です。

送信元IPを正しく扱う

Cloudflareを経由すると、サーバーから見た接続元はCloudflareのIPになります。このままだとModSecurityのIP単位の制限やログ、WordPressのログイン制限プラグインが、利用者のIPを区別できません。Cloudflareが付ける CF-Connecting-IP ヘッダーを、Apacheなら mod_remoteip、Nginxなら realip モジュールで本来の送信元IPとして扱うよう設定します。信頼するプロキシをCloudflareのIP範囲に限ることが条件で、限らないと誰でもヘッダーを偽装できてしまいます。

条件別の選び方

Cloudflare WAFが向く場合

• サーバーの運用に時間をかけられず、ルールの更新を任せたい
• 共用サーバーなどで、ModSecurityを自由に設定できない
• アクセスの急増やDDoSが心配で、オリジンに届く前に止めたい
• CDNによる表示の高速化もあわせて使いたい

ModSecurityが向く場合

• 通信を外部のサービスに通したくない事情がある（契約や社内規定など）
• ルールを細かく書いて、アプリケーションに合わせて調整したい
• VPSや専用サーバーで、ログやルールを自分で管理できる体制がある

両方使う場合

Cloudflareで大量の通信や広く知られた攻撃を手前で落とし、ModSecurityで残りを検査する「多層」の構成です。守りは厚くなりますが、誤検知の調査で「どちらが止めたか」を切り分ける手間が増えます。運用できる体制があるときに選んでください。

併用の手順

1. バックアップと検証環境: 設定を変える前に、Webサーバーの設定ファイルとサイトのバックアップを取ります。可能ならステージング環境で先に試します
2. Cloudflareを先に有効にする: DNSのプロキシを有効にし、管理ルールを有効にします。数日はセキュリティイベントを見て、管理画面の操作が止められていないか確認します
3. 送信元IPの設定: 前述の mod_remoteip または realip を設定し、ログに利用者のIPが記録されることを確かめます
4. オリジンへの直接アクセスを防ぐ: サーバーのファイアウォールで、HTTP/HTTPSの受け付けをCloudflareのIP範囲に限ります。IP範囲はCloudflareの公開しているリストを参照し、変更に追従する仕組みにします。Cloudflare Tunnel や認証付きのオリジンプル（Authenticated Origin Pulls）を使う方法もあります
5. ModSecurityを検知のみで入れる: CRSを入れて DetectionOnly で動かし、監査ログで誤検知を潰します
6. 遮断に切り替える: 誤検知が落ち着いたら SecRuleEngine On にします。切り替え後もしばらくはログを毎日確認します

手順4を省くと、攻撃者がオリジンのIPを見つけた時点でCloudflare WAFを迂回されます。過去のDNSの記録や、サーバーから送るメールのヘッダーからIPが分かることがあるため、IPを隠しているつもりでも制限をかけておくのが安全です。

まとめ

• ModSecurityはサーバーの中、Cloudflare WAFはサーバーの手前で検査する。違いは置き場所と運用の分担にある
• Cloudflareはオリジンの負荷を増やさず大量の通信を手前で止められるが、オリジンへの直接アクセスを防がないと迂回される
• ModSecurityはルールを細かく調整できる反面、導入・更新・ログ確認を自分で行う必要がある
• WordPressでは誤検知への対処が運用の中心。検知のみで始め、除外は最小限にする
• 併用するなら、送信元IPの設定とオリジンのアクセス制限をセットで行う

• Apacheのmod_securityでWAFを設定する方法
• CloudflareでWAFを設定する方法