Cloudflare WAF 徹底解説：複数サイトのルール一括管理からログ分析・設定項目まで

Cloudflareを導入してWebサイトのセキュリティを強化する際、避けて通れないのがWAF（Web Application Firewall）の設定です。特に、複数のクライアントサイトや自社メディアをマルチドメインで運用している場合、サイトごとに手動で設定していくのは効率的ではありません。

本記事では、Cloudflare WAFのポテンシャルを最大限に引き出すために、以下の3つのポイントをプロエンジニア向けに分かりやすく解説します。

1. 複数サイト（マルチドメイン）でのファイアウォールルール共通化・記載方法と画面遷移
2. 柔軟な防御陣形を敷くための「主要設定項目（フィールド）」の解説
3. 攻撃の予兆を捉える「ファイアウォールログ（セキュリティイベント）」の活用法

1. ファイアウォールルール：複数サイト（マルチドメイン）分の記載方法

Cloudflareの1つのゾーン（アカウントまたはドメイン単位）で、複数のサブドメインや、異なるサイトのトラフィックを効率的に処理するためのルールの書き方です。

個別にルールを作ると上限に達してしまうため、「Expression Preview（式エディター）」を活用して1つのルールに集約するのがベストプラクティスです。

設定画面へのアクセス手順（画面遷移）

複数サイト分のルールを記述する画面へは、以下の手順で遷移します。

1. Cloudflareダッシュボードにログインし、設定対象のドメイン（ゾーン）を選択します。
2. 左側のサイドメニューから [セキュリティ (Security)] をクリックします。
3. 展開されたメニューから [セキュリティ ルール (Security rules)] をクリックします。
4. [ルール作成 (Create rule)] を選択します。
5. 画面上部のタブが [カスタム ルール (Custom rules)] になっていることを確認します。

複数サイトをまとめる記載パターン（Expression）

「カスタム ルール」の作成画面に遷移すると、ビジュアル的に条件を選ぶ「ルール構築ツール（Rule Builder）」が表示されますが、複数サイトや複雑な条件を指定する場合は、その下（または右上）にある [式ビルダー] をクリックして、テキスト入力モードに切り替えます。

パターンA：特定の複数サイトの「管理画面」を一括保護する

(http.host in { "wpojp.com" "test.wpojp.com" "test2.wpojp.com"}) and (http.request.uri.path contains "/wp-admin" or http.request.uri.path contains "/wp-login.php") and ip.src.country ne "JP"

• 解説: * in {“…” “…”} を使うことで、管理している複数のホスト名をスペース区切りでスマートに一括指定できます。
  • 上記は「wpojp.com やそのテスト環境のWordPress管理画面・ログイン画面へのアクセスで、かつ日本（JP）以外からのアクセス」を検知する式です。
  • 入力後、画面下部の「アクションの選択」で [ブロック (Block)] または [マネージド チャレンジ (Managed Challenge)] を選択し、[展開 (Deploy)] ボタンを押すとルールが即座に反映されます。

パターンB：特定のサイトを「例外」として共通ルールを適用する

(not http.host in {"test2.wpojp.com"}) and (http.request.uri.path contains "/api/v1/")

• 解説:
  • 特定のテスト環境やLPなど、例外的にセキュリティを緩めたい（または別の扱いをしたい）サイトがある場合は、not を組み合わせて「そのサイト以外すべてに適用」という除外設定パターンが有効です。

2. ファイアウォールルール設定項目（フィールド）の詳細解説

自由自在にルールを組み立てるために、よく使う主要な設定項目（フィールド）の意味と実務での活用例をまとめました。

フィールド名（式での表記）	概要	実務での具体的な活用例
ホスト名 (http.host)	アクセスされたドメイン名。	複数サイトの中から、特定のサイトだけをターゲットに絞る時に必須。
URIパス (http.request.uri.path)	ドメイン以降のクエリパラメータを除いたURL部分（例: /contact/）。	/wp-config.php や .env など、公開してはいけないファイルへのアクセスを拒否する。
国 (ip.src.country)	アクセス元のIPアドレスから判定された国コード（2文字）。	海外からのスパム投稿やブルートフォース攻撃が多いサイトで、ne “JP”（日本以外）を指定してチャレンジを課す。
IPアドレス (ip.src)	クライアントのIPアドレス。	社内の固定IPや、特定の開発パートナーのIPを「常に許可（Bypass）」するために使用。
要求メソッド (http.request.method)	HTTPメソッド（GET, POST, PUT, DELETEなど）。	お問い合わせフォームやログイン画面（POSTリクエスト）に対してのみ、レートリミットやボット対策を強化する。
ユーザーエージェント (http.request.user_agent)	ブラウザやボットの識別文字列。	悪質なスクレイピングツールや、特定の古いブラウザからのアクセスを拒否する。
脅威スコア (cf.threat_score)	Cloudflareが独自に算出するIPの危険度（0〜100）。	スコアが「10以上（中程度のリスク）」のアクセスに対して、一律でJavaScriptチャレンジを出すような一括防御に最適。

選択できる「アクション」の使い分け

条件に合致したリクエストに対して、以下のどのアクションを実行するかも重要です。

• ブロック (Block): 完全にアクセスを遮断（403エラー）。明らかな攻撃、不正アクセス用。
• マネージドチャレンジ (Managed Challenge): Cloudflareが自動で判断し、怪しい場合のみ「人間であることを証明（Turnstile等）」させる。最も推奨される汎用アクション。
• バイパス (Bypass): WAFのチェックをスキップさせる。信頼できる社内IPや特定のAPI連携用。
• ログ (Log): アクセスは通すが、ログにだけ記録する。新しいルールをテスト運用する際に、既存アクセスに影響が出ないか確認するために重宝します。

3. ファイアウォールのログ（セキュリティイベント）の確認と分析

ルールを設定したら、それが正しく機能しているか、あるいは「誤検知（正常なアクセスをブロックしていないか）」をログから追跡する必要があります。

ログの確認手順

Cloudflareダッシュボードの左メニュー [セキュリティ] ＞ [イベント]（旧ファイアウォールイベント）を開きます。

ログを見る際の重要チェックポイント

1. アクティビティログのフィルタリング
   1. 「ブロック数が急増しているホスト名」や「特定の国（Country）」でフィルタリングをかけ、異常値がないかを瞬時に特定します。
2. 「誤検知（False Positive）」のセオリー
   1. WAF導入初期は、外部のAPI連携、決済ゲートウェイからのコールバック、社内ツールのスクレイピングなどがブロックされがちです。
   2. ログ詳細の [サービス] を確認し、WAFの管理ルール（Managed Rules） で引っかかっている場合は、該当する「ルールID」を確認し、そのIDだけをバイパス（一時除外）するルールを追加します。
3. ユーザーエージェント（UA）とIPの検証
   1. ブロックされたリクエストの IP や User-Agent を確認し、本物の攻撃か、クローラー（Googlebotなど）の誤ブロックでないかを見極めます（※Googlebotなどの正規クローラーは、Cloudflareが自動で「既知のボット」として認識しますが、カスタムルールで弾いていないか確認が必要です）。

まとめ：効率的なWAF運用がサイトの信頼性を生む

CloudflareのWAFは、直感的なWiresharkスタイルの式（Expression）を正しく組み合わせることで、1つのルールで何十ものサイトを横断的に、かつスマートに防御することができます。

ルールを設定した後は、必ず「セキュリティイベント」のログを定期的にウォッチし、意図したブロックができているか、一般ユーザーを巻き込んでいないか（誤検知がないか）を確認するサイクルを回しましょう。