Cloudflareのセキュリティ設定｜無料対策の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

Cloudflareを導入したあと、「無料プランのセキュリティ設定はどこまで必要なのか」「強くしすぎて読者やGooglebotまでブロックしないか」と迷っていませんか。Cloudflareには自動で働くDDoS保護やWAFがある一方、Bot Fight ModeやUnder Attack Modeは使い方を誤ると、API、外部アプリ、検索クローラーなどの正規アクセスへ403を返す可能性があります。

この記事では、Cloudflareのセキュリティ設定を、既定で働く保護、自分で追加する無料対策、攻撃時だけ使う機能、別途実装が必要な対策に分けて解説します。osuke本人のCloudflare体験としては書かず、2026年8月23日時点のCloudflare公式資料と、Xで公開された利用者・開発者8件の成功例、誤検知、運用上の注意を照合しました。Xの結果は各投稿者の環境に限られ、Cloudflare全体の効果を保証するものではありません。

前提となる暗号化が不安な方は、先にCloudflareのSSL設定方法でFull (strict)まで確認してください。WordPressのキャッシュやプラグインとの関係はCloudflareでWordPressを高速化する設定、無料枠を含む全体像はCloudflareとは何かを解説した記事で整理できます。

記事のポイント

• DDoS保護・無料WAF・Browser Integrity Checkの既定状態を確認する
• 無料のCustom Rules 5件を重要な場所へ優先配分する
• Bot Fight ModeとUnder Attack Modeを常時ONにしない
• 403はSecurity EventsとRay IDで24時間以内に調べる
• オリジンIP保護とTurnstileのサーバー検証まで行う

Cloudflareの無料セキュリティ設定

無料プランでも、Cloudflareのネットワーク境界で自動的に働く対策と、自分で追加できるルールがあります。最初から全機能を強くするのではなく、守る場所と壊したくない通信を先に分けることが重要です。ここでは設定画面を触る前に理解すべき範囲から、WAF、DDoS、ボット、フォーム対策の順に進めます。

Cloudflareが守る範囲を理解する

Cloudflareが主に守るのは、ProxiedになったDNSレコードを通る通信です。訪問者と元サーバーの間にCloudflareのエッジが入り、大量アクセス、既知の攻撃パターン、不審なボットなどを元サーバーへ届く前に処理します。反対に、DNS onlyのホスト、Cloudflareを通らないメールサーバー、漏えいした元サーバーIPへの直接通信、WordPressの脆弱な管理者パスワードまでは、Cloudflareを有効にしただけでは解決しません。

Cloudflare公式のDDoS保護資料では、L3、L4、L7のDDoS対策を全プラン・全サービスへ提供し、自動検知と緩和を行うと説明しています。さらに攻撃の規模・時間に上限がなく、DDoS攻撃トラフィックを利用料金から除外するとしています。無料プランでも大規模トラフィックを自力で数えてからスイッチを入れる必要はありませんが、正当なアクセス集中や壊れたクライアントが誤って攻撃らしく見える可能性は残ります。

防御を4層に分けると判断しやすくなります。第1層は自動DDoS保護、第2層はWAFとCustom Rules、第3層はフォームのTurnstileやログイン制限、第4層は元サーバーのfirewall、WordPress更新、強固な認証、バックアップです。Cloudflareは第1・第2層を大きく助けますが、4層のうち1つだけで「安全になった」と考えないことが、無料対策で最も重要な出発点です。

最初に分ける4つの防御

• 自動: DDoS保護と既定の検査
• 追加設定: WAF Custom Rulesとボット対策
• アプリ側: ログイン、フォーム、WordPress更新
• 元サーバー側: IP制限、証明書、バックアップ

SSLをFull strictに設定する

セキュリティ機能を増やす前に、SSL/TLS暗号化モードをFull (strict)へ整えます。Flexibleは訪問者からCloudflareまでしかHTTPSにならず、Cloudflareから元サーバーまでは暗号化されません。Fullは元サーバーとの通信を暗号化しますが、証明書の正当性を厳格に検証しないため、有効期限とホスト名を検証するFull (strict)を基本にします。オリジン証明書や公開CA証明書を元サーバーへ正しく入れてから切り替えてください。

切り替えは「Flexibleから一気に強くする」作業ではなく、元サーバーの443番ポート、証明書の期限、対象ホスト名、中間証明書、WordPressのサイトURLを先に確認する作業です。条件が揃わないままFull (strict)にすると526、HTTPS強制が重なるとリダイレクトループが起こり得ます。トップページだけでなく、管理画面、ログイン、REST API、問い合わせフォームの4種類を匿名・ログイン状態で確認すると、公開ページだけ動く見落としを減らせます。

Full (strict)は後述するAuthenticated Origin Pullsの土台でもあります。公式のAuthenticated Origin Pulls資料は、AOPがOffやFlexibleでは機能しないと明記しています。暗号化、Cloudflareからの接続認証、元IP制限を順番に重ねることで、途中盗聴だけでなくCloudflareを迂回する直接通信にも対応できます。最初にSSLを確定すると、その後の403、525、526を別の問題として切り分けやすくなります。

Full (strict)へ進む前の確認

• 元サーバーが443番で応答する
• 証明書の期限とホスト名が正しい
• WordPressのURLがHTTPSになっている
• トップ・管理・API・フォームの4経路を試す
• 525・526・ループが残るなら次の設定へ進まない

WAFの無料マネージドルールを確認する

無料プランでは、Cloudflare Free Managed Rulesetが既定で展開されます。公式のManaged Rules資料によると、これはCloudflare Managed Rulesetの一部で、影響が大きく広く悪用される脆弱性を対象にしたルール群です。有料プランのCloudflare Managed RulesetやOWASP Core Rulesetと同じ範囲ではありませんが、無料だからWAFが空というわけではありません。まずSecurity SettingsでFree Managed Rulesetが有効かを確認します。

次にBrowser Integrity Checkを確認します。公式資料では、不正利用されやすいHTTPヘッダー、User Agentがないアクセス、非標準User Agentを検査し、既定で有効とされています。スパムや単純なクローラーを減らせる一方、古い機器、独自アプリ、監視サービスをchallengeする可能性があります。異常がないうちは既定状態を維持し、問題が出たパスだけconfiguration ruleやSkipで除外します。

サイト固有の条件はWAF Custom Rulesで追加でき、2026年8月時点の公式上限はFree 5件、Pro 20件、Business 100件、Enterprise 1,000件です。FreeではLog actionと正規表現を利用できません。5枠しかないため、国単位の思いつきブロックを増やすより、管理画面、不要なXML-RPC、公開不要のAPI、繰り返し狙われるパスなど、被害と誤検知を具体的に説明できる対象へ使います。

WAFの最初の順番

1. Free Managed Rulesetの有効状態を確認
2. Browser Integrity Checkの既定状態を確認
3. 24時間のSecurity Eventsを観察
4. 根拠のある対象へCustom Rulesを1件ずつ追加
5. 変更後に公開・管理・API・検索を再確認

DDoS対策とUnder Attack Modeを使い分ける

通常のDDoS対策は自動で働くため、Under Attack Modeを常時ONにする必要はありません。Under Attack Modeはレイヤー7 DDoS攻撃中に追加のManaged Challengeを表示する緊急機能です。Cloudflare公式も、APIトラフィックなどドメイン上の操作へ影響する可能性があるため、実際にDDoS攻撃を受けているときだけ使うよう注意しています。通常時の「念のためON」は可用性を下げます。

Xでは、瞬間的な投稿集中時にXを読めなくなり、Under Attack判定によるブロックではないかと推測した投稿がありました。原因は確定していませんが、利用者側からは「攻撃を防いだ」より「サービスを読めない」と見える例です。また、MCPエンドポイントがHTTP 403とcf-mitigated: challengeを返し、JavaScriptを実行できないクライアントが通れないという報告もあります。challengeはブラウザ以外の正規通信と相性が悪い場合があります。

攻撃を疑ったら、まずSecurity Eventsで急増したホスト、パス、国、ASN、User Agent、適用サービスを確認します。元サーバーのCPU・メモリ・同時接続、Cloudflare Status、自分の公開監視も同時に記録し、単なるWordPress障害や外部API停止と分けます。Under Attack ModeをONにした場合は開始時刻を残し、トップ、ログイン、フォーム、APIの4経路をテストし、攻撃の波が収まったらOFFへ戻します。

Under Attack Modeの運用ルール

• 常時ONではなくL7 DDoSの緊急時だけ使う
• ONの前後で時刻とイベント数を記録する
• API・MCP・監視・モバイルアプリを確認する
• 攻撃収束後は通常設定へ戻す
• 使ったまま忘れないよう終了条件を決める

Bot Fight ModeとTurnstileを選ぶ

Bot Fight ModeとTurnstileは同じボット対策でも適用範囲が違います。Bot Fight ModeはFreeプランで使え、既知の単純なボットやヘッドレスブラウザを検出し、ドメイン全体へ計算量の高いchallengeを発行します。一方、Turnstileはログイン、登録、問い合わせなど特定フォームの送信前に人間らしさを確認する部品で、Web通信全体をCloudflare CDNへ通す必要はありません。サイト全体か、重要操作だけかで選びます。

Cloudflare公式のボット対策資料は、FreeのBot Fight Modeをcustom ruleのSkip actionで回避できず、設定の細かな調整もできないと明記しています。誤検知した監視、API、提携サービスだけを除外したい場合、FreeではBot Fight ModeをOFFにするか、より細かく制御できる上位機能を検討する必要があります。最初の3日ほどは全サイトで有効化せず、Security Eventsと正規クライアントの動作を観察してください。

フォーム対策では、XにContact Form 7へTurnstileを導入した直後に大量スパムが解消した公開事例と、reCAPTCHAから変更後にスパムが届かなくなったという事例がありました。ただし件数・期間・構成は公開されておらず、同じ効果を保証できません。公式実装資料どおり、ブラウザ側にwidgetを置くだけでなく、サーバー側のSiteverify APIでトークンを検証しなければ防御は不完全です。

使い分けの基準

• ドメイン全体の単純ボット: Bot Fight Modeを小さく検証
• 問い合わせ・登録・ログイン: Turnstileをフォーム単位で導入
• API・MCP・監視がある: 全体challengeを慎重に判断
• Free Turnstile: 20 widgets、1 widget 10 hostnames
• 実装完了条件: Siteverifyの成功・失敗をサーバーで確認

Cloudflareのセキュリティ設定で失敗しない方法

設定をONにした直後より、1週間後に「なぜ403になったか」を説明できることが大切です。無料プランではログ保持やルール数に制約があるため、変更を小さくし、異常が起きた当日に記録します。ここからは誤検知の切り分け、管理・API・検索の保護、元サーバー対策、認証情報、最終チェックまでを運用手順にします。

誤検知をSecurity EventsとRay IDで切り分ける

正規ユーザーから403の連絡が来たら、いきなりWAF全体をOFFにせず、発生時刻、対象URL、利用端末、ネットワーク、画面に出たRay IDを集めます。Ray IDはCloudflareを通過するリクエストへ付く識別子で、公式資料ではSecurity Events内のIP、User Agent、ASNなどと照合できると説明しています。Ray IDは常に一意とは限りませんが、時刻とURLを組み合わせれば調査範囲を大きく絞れます。

Security EventsはCloudflareが対処またはフラグ付けした通信を表示し、Security Analyticsは対処しなかったものを含む全通信の傾向を表示します。2026年8月時点の公式上限では、FreeのSecurity Eventsはsampled logsのみで保持が最大24時間、Security Analyticsは最大7日です。サンプルのため全件が見えない場合があり、長い期間で探すより、障害時刻の前後15分へ絞る方が見つけやすくなります。

Xでは、ボリビアのMacアプリがWi-Fiとテザリングの双方で403になり、iOSアプリは動いたという報告がありました。ブラウザ、モバイル、デスクトップでchallenge通過能力が異なる具体例です。停止したクライアントだけで「国をブロックされた」と断定せず、同時刻のRay ID、適用サービス、Rule ID、Action、パスを確認し、該当ルールだけを変更します。

403調査シートの7項目

• 発生日時とタイムゾーン
• URL・HTTPメソッド・ステータス
• Ray ID
• 端末・ブラウザ・アプリ・回線
• Security Eventsのサービス・Rule ID・Action
• 同条件の再現有無
• 変更した設定と戻す条件

管理画面・API・検索ボットを守る

WordPressの管理画面、公開API、検索ボットを一つのルールで扱わないことが重要です。管理画面はログインする人が限られるため、固定IPやVPNを使えるなら範囲を限定し、不可能ならManaged Challengeやレート制御を検討します。公開REST API、Jetpack、決済通知、監視、MCPなどはブラウザのJavaScript challengeを解けない場合があるため、保護を強くする前に必要な送信元、パス、HTTPメソッド、認証方式を一覧にします。

検索クローラーはUser Agentの文字列だけで許可せず、Cloudflareが確認したbot情報を使います。公式のcustom rule例では、cf.client.botへ該当するVerified Botsを先頭のSkipルールで残りのcustom rulesから除外し、その後にブロックルールを配置します。ただし、このSkipでFreeのBot Fight Modeは回避できません。ルールの順番も動作の一部であり、先にBlockすると後続ルールが実行されない点を忘れないでください。

Xには、Google検索で約1,300件の求人ページが403により未登録で、CloudflareとGooglebotの衝突を疑った投稿があります。原因は投稿だけでは確定できませんが、検索流入への影響が大きくなり得る数値です。Search Consoleで403 URLと日時を確認し、Security EventsでVerified Bot、IP、ASN、Path、適用ルールを照合してから、必要な範囲だけ例外化します。サイト全体のWAF停止は最後の手段です。

1ルールに混ぜない対象

• 人が使うWordPress管理・ログイン
• ブラウザを使わないAPI・MCP・監視
• 決済・フォーム・Webhook
• GooglebotなどVerified Bots
• Jetpack等が使うXML-RPC・REST API

元サーバーIPの漏えいを防ぐ

DNSレコードをProxiedにすると公開DNSにはCloudflareのIPが返りますが、元サーバーIPが完全に秘密になるとは限りません。過去のDNS履歴、同じIPを使うDNS onlyのサブドメイン、メールサーバー、エラーページ、直接送信したメールヘッダーなどから判明することがあります。攻撃者が元IPへ直接接続できれば、CloudflareのDDoS保護、WAF、Bot Fight Modeを通らずにWordPressへ到達できます。

Xでは、オリジンIPが露出するとhostsファイルを実IPへ向けるだけでエッジ保護を迂回できるという実演が公開されています。特定サイトの被害報告ではありませんが、Cloudflare公式のオリジン設定も、過去DNSやメール設定で元IPが発見される可能性を示し、CloudflareのIP範囲と信頼する提携先以外からのHTTP/HTTPSを元サーバーで拒否するよう推奨しています。

実施はホスティング会社のfirewallでCloudflareのIPv4・IPv6範囲をallowlistし、管理用IPや監視元を追加したあと、その他を拒否する順番です。先に全拒否すると自分もCloudflareも接続できなくなるため、設定前後で新しいSSH接続や別セッションを使って確認します。さらにAOPを使えば、Cloudflareが提示するクライアント証明書を元サーバーが検証できます。共有証明書はCloudflareネットワーク由来まで、独自証明書は自分のゾーン由来まで厳しくできます。

オリジン保護の順番

1. DNS onlyと同居メールのIPを洗い出す
2. Cloudflareの最新IPv4・IPv6範囲をallowlist
3. 管理・監視・提携先の必要IPを追加
4. その他の80・443番への直接通信を拒否
5. 必要に応じてAOPまたはCloudflare Tunnelを選ぶ

アラート・API Token・変更履歴を管理する

無料プランのSecurity Eventsは最大24時間なので、異常を週末にまとめて調べる運用では証拠が残らない可能性があります。Cloudflareの通知設定で利用できるセキュリティ・DDoS関連の項目を確認し、ホスティング側のCPU、エラー率、死活監視、WordPressのログイン通知と組み合わせます。通知の種類や提供プランは変わり得るため、名称を固定した手順書より「誰が、何分以内に、どの画面を見るか」を決めておく方が長く使えます。

WordPressプラグイン、CI/CD、DNS更新ツールをCloudflareへ接続するときは、Global API KeyではなくAPI Tokenを使います。Cloudflare公式は、API Keyより制約を付けられるAPI Tokenを可能な限り利用するよう勧めています。対象アカウント、ゾーン、Read/Edit権限、許可IP、有効期限を用途ごとに絞り、DNS編集用とキャッシュ削除用を分けます。Gitへ登録せず、漏えいを疑ったら停止・再発行します。

変更履歴には、日時、変更者、画面またはAPI、変更前後、対象パス、理由、確認結果、戻し方を残します。WAF更新による誤検知もあるため、Cloudflare Managed RulesetのchangelogとWordPress更新日を同じ時系列で見ます。XでWordPressの攻撃ログや検索Bot・AI Botを分類し、Cloudflareやサーバーログと併用した投稿があるように、エッジだけでなくWordPress側の認証結果や処理結果まで照合すると、「Cloudflareで止めた」のか「元サーバーで失敗した」のかを分けられます。

残すべき変更履歴

• 日時・変更者・目的
• 機能名・Rule ID・対象条件
• 変更前と変更後
• 公開・管理・API・検索の確認結果
• 障害時に戻す操作と担当者
• API Tokenの所有者・権限・期限

無料セキュリティ対策を最終確認する

無料プランの完成形は、「すべてをBlock」にすることではありません。自動DDoS保護、Free Managed Ruleset、Browser Integrity Checkの既定状態を確認し、Custom Rules 5枠を重要箇所へ使い、Bot Fight Modeは正規クライアントへの影響を見ながら判断します。問い合わせフォームにはTurnstileとSiteverify、元サーバーにはCloudflare IPのallowlistまたはAOPを重ねます。これでエッジ、アプリ、オリジンの3層をつなげられます。

公開前テストは、匿名のトップ・記事、WordPress管理・ログイン、問い合わせ送信、REST APIやWebhook、検索クローラー、スマートフォンの6経路で行います。成功だけでなく、誤ったパスワード、期限切れTurnstile token、短時間の繰り返しアクセスが適切に拒否されるかも確認します。403が出たらRay IDを保存し、15分程度の狭い時間帯でSecurity Eventsを検索します。ルール変更は1回につき1件に限定してください。

最終的には週1回5分でSecurity Analyticsの上位パス・国・ASNを見て、月1回15分でAPI Token、管理者、プラグイン、バックアップ復元手順を確認します。緊急時はUnder Attack Modeを使い、終了条件に達したら戻します。今日の一歩は、Cloudflare管理画面のSecurity SettingsとAnalyticsを開き、既定3機能、Custom Rules件数、直近24時間のイベント、元IPへの直接接続可否を記録することです。

公開前の最終チェック10項目

1. 対象DNSがProxied
2. SSL/TLSがFull (strict)
3. 自動DDoS保護を前提に過剰設定していない
4. Free Managed Rulesetを確認
5. Browser Integrity Checkを確認
6. Custom Rules 5枠の目的を説明できる
7. Bot Fight Modeの誤検知経路をテスト
8. TurnstileをSiteverifyまで実装
9. オリジンへの直接通信を制限
10. 24時間以内にRay IDを調べる担当を決定

Cloudflareの無料セキュリティ設定は、機能数を増やす競争ではなく、正規通信を残しながら攻撃面を狭める運用です。まず既定保護を確認し、今日はCustom Rulesを増やす前にSecurity Eventsを15分だけ観察してください。次に守るべきパスが見えたとき、その1件から設定すれば、誤検知と手戻りを最小限にできます。