Cloudflare 無料プランの WAF を 2026 年版に組み直した — カスタムルール 5 枠の使い方

前述の🔧Cloudflareのセキュリティチェックと Ask AI で、DNSの地味な設定ミスを直した話では、DNSやメール関連の修正を行ったが、今回の記事は主にアクセス制限に関するカスタムルールを設定してみました。

Cloudflare 無料プランのファイアウォール設定をまとめた記事を見つけて、そのとおりに設定しようとしたら、途中で手が止まりました。

メニューの場所も、使うフィールドも、今は変わっています。

2026 年 8 月時点の仕様に合わせて、5 枠しかないカスタムルールを組み直した記録です。

💡

Cloudflareの項目や設定内容は頻繁に変わるので、今後も変更される可能性が高いのでご注意ください。

はじめに

参考にしたのは 2025 年 12 月の記事でした。

Cloudflareファイアウォールルール入門：無料5ルールで悪意トラフィック80%をフィルタ（テンプレ付き）

Cloudflare無料版はカスタムファイアウォールルールが5つだけ？実戦検証済みのWAFルールテンプレートを公開。IP・ASN・UA・パスなどのフィルタ条件と優先順位の設定方法を解説し、30分で悪意トラフィックの80%をフィルタできます。

https://eastondev.com

8 か月で、これだけ変わるんですね。🫢

私の環境は WordPress で、Bot Fight Mode は ON、外形監視と API 呼び出しは固定 IP から投げています。

この記事では、無料プランで実際に動く構成を最初から最後まで並べます。

Cloudflare 周りの設定は 🔧Cloudflareのセキュリティチェックと Ask AI で、DNSの地味な設定ミスを直した話でも触りました。あわせて読むと流れが掴めるかもしれません。

現象

参考記事どおりに進めようとして、次の 4 つで詰まりました。

左メニューに「Firewall Rules」が見当たらない
脅威スコア（cf.threat_score）を条件にしたルールが作れない
正規表現を使った式が保存できない
レート制限の画面に Managed Challenge が出てこない。選べるのは Block だけ

原因

Firewall Rules は WAF カスタムルールに統合されて、名前ごとなくなりました。現在の場所は Security > Security rules です。旧ダッシュボードのままなら Security > WAF > Custom rules になります。

脅威スコアは廃止されました。2025 年 3 月にダッシュボードでの指定ができなくなり、現在は値が常に 0 で返ります。参考記事の「黄金の 5 ルール」のうち 1 本は、丸ごと作り直しになります。

正規表現とログアクションは、無料プランでは使えません。カスタムルールは 5 本まで、という制限とセットで覚えておくのがよさそうです。

レート制限は無料プランだと 1 ルールのみ、集計期間 10 秒固定、アクションは Block のみ、ブロック時間も 10 秒固定です。

そしてもう 1 つ、設定を組む前に知っておきたかったのが評価順序でした。

flowchart LR
    A["リクエスト"] --> B["IP アクセスルール"]
    B --> C["WAF カスタムルール"]
    C --> D["レート制限"]
    D --> E["マネージドルール"]
    E --> F["オリジン"]
    A -.別系統.-> G["Bot Fight Mode"]
    G -.-> F

Bot Fight Mode はルールエンジンの外で動いています。つまり、カスタムルールの Skip アクションでは避けられません。ここを知らずに監視 IP をホワイトリストに入れて、通らなくて悩みました。

設定手順

1. Bot Fight Mode の ON / OFF

Security > Settings を開いて、フィルタで Bot traffic を選びます。

一覧に Bot fight mode のトグルがあるので、ここで切り替えます。旧ダッシュボードのままなら Security > Bots です。

ON にすると JavaScript Detections も自動で有効になり、こちらは無効化できません。CSP を設定している場合は /cdn-cgi/challenge-platform/ を許可しておく必要があります。

2. AI ボットの扱いを決める

2026 年 7 月から、AI クローラーを Search / Agent / Training の 3 分類で個別に制御できるようになりました。無料プランでも使えます。

同じ Security > Settings から設定します。ここはカスタムルールの枠を消費しません。

2026 年 9 月 15 日以降、新規ドメインでは広告表示ページの Training と Agent がデフォルトでブロックされます。既存ドメインは自動適用されないので、自分で決める必要があります。

私は Search を許可、Training と Agent をブロックにしました。検索経由の流入は残したい、という理由です。

3. IP アクセスルールで監視元を通す

Bot Fight Mode を避けられる唯一の方法が、IP アクセスルールでした。

Security > WAF > Tools > IP Access Rules で、監視元の IP を Allow で登録します。

登録したら、実際に監視やコールバックが通るか必ず確認してください。通らない場合、無料プランの選択肢は Bot Fight Mode を OFF にするか、Pro に上げて Super Bot Fight Mode を使うかの二択になります。

4. WordPress 側の下ごしらえ

wp-cron のループバックが Bot Fight Mode に止められます。ループバックを許可する設定は Pro 以上の機能なので、無料プランでは HTTP 経由の wp-cron をやめるのが確実です。

// wp-config.php
define('DISABLE_WP_CRON', true);

# サーバー側の cron に登録（1 時間ごと）
php /path/to/wordpress/wp-cron.php > /dev/null 2>&1

これで Cloudflare を経由しなくなり、予約投稿とバックアップが安定しました。

5. カスタムルールを 5 本作る

Create a custom rule in the dashboard

Create WAF custom rules in the Cloudflare dashboard.

https://developers.cloudflare.com

Security > Security rules から Create rule > Custom rules で作ります。上から順に並べてください。

ルール 1：ホワイトリスト（アクション：Skip）

(ip.src eq 203.0.113.45) or (cf.client.bot)

スキップ対象は「All remaining custom rules」と「Rate limiting rules」の両方にチェックを入れます。

ルール 2：機密パスとログイン画面（アクション：Block）

(http.request.uri.path contains "/xmlrpc.php") or
(http.request.uri.path contains "/.env") or
(http.request.uri.path contains "/.git") or
(http.request.uri.path contains "/.aws") or
(http.request.uri.path contains "/phpmyadmin") or
(http.request.uri.path contains "/vendor/composer/") or
(http.request.uri.path contains "wp-config") or
(http.request.uri.path contains "/wp-content/debug.log") or
(http.request.uri.path contains "/wp-content/uploads/" and http.request.uri.path contains ".php") or
(http.request.uri.path contains "/wp-login.php" and ip.src.country ne "JP") or
(http.request.uri.path contains "/wp-admin/" and not http.request.uri.path contains "/wp-admin/admin-ajax.php" and ip.src.country ne "JP")

/wp-admin/admin-ajax.php の除外は必須です。未ログイン訪問者向けのプラグインが叩くので、含めるとフロント側が壊れます。

/vendor/ ではなく /vendor/composer/ にしているのも同じ理由で、プラグインが同梱ライブラリを配信するパスに誤爆します。

ルール 3：ユーザー名列挙の遮断（アクション：Block）

(http.request.uri.path contains "/wp-json/wp/v2/users") or
(http.request.uri.path eq "/wp-links-opml.php") or
(http.request.uri.query contains "author=")

ルール 4：異常な User-Agent（アクション：Block）

(http.user_agent eq "") or
(http.user_agent contains "sqlmap") or
(http.user_agent contains "nikto") or
(http.user_agent contains "nmap") or
(http.user_agent contains "zgrab") or
(http.user_agent contains "masscan") or
(http.user_agent contains "WPScan") or
(http.user_agent contains "Scrapy")

python-requests や curl/ は入れませんでした。Bot Fight Mode が拾ってくれますし、プラグインの正規通信が名乗っている可能性があるためです。

ルール 5：空けておく

埋めませんでした。Security Events を見て、実際に来ている攻撃を確認してから決めるほうが無駄がないと思っています。

6. レート制限を 1 本作る

Create rule > Rate limiting rules で作ります。

(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")

閾値は 10 秒あたり 5 リクエスト、識別子は IP、アクションは Block です。

contains ではなく eq にしているのは、クエリ文字列がパスに含まれないためです。

POST に限定するのも大事で、GET を含めるとログイン失敗からの再表示で正規ユーザーが自分で引っかかります。

設定後の効果

項目	参考記事の構成	今回の構成
ルール 1	ホワイトリスト（Allow）	ホワイトリスト（Skip）
ルール 2	データセンター ASN にチャレンジ	機密パス＋ログイン画面を Block
ルール 3	脅威スコアでフィルタ	ユーザー名列挙を Block（脅威スコアは廃止）
ルール 4	異常 User-Agent を Block	異常 User-Agent を Block
ルール 5	機密パス保護	空き枠（実データを見てから決める）
ボット対策	カスタムルールで ASN 指定	Bot Fight Mode に寄せて枠を節約
AI クローラー	言及なし	Security Settings で 3 分類ごとに制御