Webサイトを運営していると、悪意のあるボットトラフィックのためにサーバーが遅くなったり、統計が歪んだりする経験をすることになります。クラウドフレア（Cloudflare）を利用すれば、悪意のあるボットやディドス攻撃などを効果的に防御できます。クラウドフレアセキュリティルールで特定の国や特定のIPをブロックするように設定できます。
しかし、ボットを防ぐとセキュリティ設定をランダムな「ブロック」に指定すると、実際の訪問者までブロックされて問題になることがあります。 「頻繁に捕まえようと茅葺きを燃やす」という言葉のように、過度のセキュリティはむしろサイトの成長を妨げる可能性があります。では、どうすれば悪意のあるボットだけをブロックし、実際のユーザー（人間）は接続が可能になるのでしょうか？
クラウドフレアボットのブロック：実際のユーザーが通過し、ボットだけを防ぐ方法
サイトを運営してみると、商業用ボット（SEOボット）や悪性IPの接続が増加して問題になる場合があります。 クラウドウェイズから WordPressを運営している場合は、頻繁に流入するIPとボットを確認してブロックすることができます。
また、クラウドフレア（Cloudflare）と連携して、スパム訪問者が多く流入している国をブロックすることも考えられます。
この WordPress ブログ最近、突然、一部の国を中心に海外流入が急増する現象が発生しました。クラウドウェイズに問い合わせると正常なユーザー流入と言われましたが、訪れてすぐに離脱し、滞在時間が急落し、離脱率が急増してSEOにも問題になりました。
クラウドフレアでこのサイトのブログに対してプロキシを有効にし、海外訪問者が多くの国の流入をブロックしました。そしてスパムボットもクラウドウェイズで確認してブロックしました。これらの措置によって問題が解決されました。
クラウドフレアで特定の国やIPをブロックするためのセキュリティルールを設定するには、いくつかのオプションがあります。
上の図に示すように、ジョブの選択から希望のブロック方法を選択できます。
- 管理チャレンジ (Managed Challenge)
- ブロック(ブロック)
- JSチャレンジ（JSチャレンジ）
- インタラクティブチャレンジ
このうち 対話型チャレンジは、私たちがよく知っている「信号灯を選ぶ」、「歪んだ文字を入力する」などの既存のCAPTCHA（キャプチャ）方式を強制する設定で、 「人間には痛みを与え、ボットにはもう難しくないから」にクラウドフレアはお勧めできません。
ブロックを選択した場合、該当する条件を満たすユーザーがサイトにアクセスしようとすると、 "Sorry, you have been blocked" 画面が表示されます。
それでは、ボットは効果的にブロックし、人間のユーザーが通過する効果的な方法は何ですか？クラウドフレアでは管理チャレンジをお勧めしています。
クラウドフレアのブロック、JSチャレンジ、管理チャレンジの比較
クラウドフレアの「Firewall rules actions「ドキュメントでは管理チャレンジ（Managed Challenge）をお勧めします。
ブロック（Block）銀攻撃が明確な対象を直ちに拒否し、最も強力だが、通常のユーザーまで阻止する危険が大きく、 JSチャレンジは、すべての接続者にブラウザ検証のロード画面を強制し、単純なボットを防ぐのではなく、ユーザーの疲労度を高めます。一方、管理チャレンジはクラウドフレアのアルゴリズムが危険度を動的に分析し、大多数の人間は無事通過し、疑わしいトラフィックのみを選別的に検証するため、セキュリティを維持しながらユーザーエクスペリエンス（UX）を最大限に保護する最も推奨される方法です。
| 比較項目 | ブロック | JSチャレンジ | 管理チャレンジ |
|---|---|---|---|
| 動作方法 | リクエスト即時拒否(接続終了) | ブラウザに5秒内外のロード画面を表示して操作を実行する | Cloudflareアルゴリズムが危険度に応じて無検証/JS/クリック検証自動選択 |
| ユーザーエクスペリエンス（UX） | 接続不可 (エラー 1020/403) | 待ち時間発生 (無条件ローディング画面) | 最適化 （ほとんどロードせずに通過） |
| 主な防御対象 | 確定的な攻撃者（悪意のあるIP、ハッキングの試み） | シンプルボット(JS未サポートクローラー、スクリプト) | インテリジェントボットを含むあらゆる種類の脅威 |
| 利点 | 最も確実なセキュリティ（アクセス源収容） | サーバー負荷の軽減(L7進入前ブロック) | セキュリティとUXのバランスを保つ(誤検出最小化) |
| 欠点 | 通常のユーザー誤差の可能性 (False Positive) | 毎回ロード画面で離脱率が増加するおそれ | 検証方法が不透明である（ブラックボックス） |
| 推奨状況 | SQLインジェクションなどの明確な攻撃パターン | サーバー負荷が激しく、高速ボットフィルタリングが必要な場合 | 一般的なボットブロックとセキュリティルールを設定するとき（推奨） |
ブロックを選択すると、すべての流入をブロックするため、ボットだけでなく、通常のユーザー訪問もブロックします。
特定の国をブロックする目的でセキュリティルールを指定するときは、 ブロック オプションではなく JSチャレンジナ 管理チャレンジが効果的なようです。私は JSチャレンジに設定しましたが、 管理チャレンジを設定すると、実際のユーザー（人間）のユーザーエクスペリエンス（UX）を損なうことなく、ボットを効果的にブロックできると言われています。 管理チャレンジに変更しました。
中国は一般的にブロックしても大丈夫な国のようです。私はアメリカを除いて海外からの流入が過度に多いアルメニア（AM）、 ブルネイ（BN）、中国（CN）、ドイツ（DE）、インドネシア（ID）、シンガポール（SG）、イギリス（GB）、香港（HK）など8カ国を現在ブロックしています。完全にブロックされるのではなく、ボットだけがブロックされ、実際のユーザーは通過したり、JS/クリック検証プロセスを経たりすることができます。
クラウドフレアは香港と中国を別々の国の帯域として管理します。インターネット検閲環境が他の技術的現実を反映した措置と見られるが、政治的に敏感な「一つの中国」の問題とは妙に対照される部分です。 😄
シンガポールはアジアの中核デジタルハブで、AWS、Google Cloudなど大規模なクラウドデータセンターが密集しており、攻撃者が高性能サーバーを容易にリースしてボットを配布したり、経由地として活用するのに最適なインフラを備えています。また、インターネット検閲が激しい周辺国（中国、インドネシアなど）のユーザーがスピードが速く自由なシンガポールVPNやプロキシサーバーを介して迂回接続することが多く、実際のハッカーやボット運営者は他の場所にあっても最終攻撃トラフィックの発生源はシンガポールIPで識別されることが頻繁だとします。
ディドス攻撃防御
ディドス（DDoS）攻撃は通常大規模サイトを対象に行われましたが、数年前から小規模サイトを相手にも頻繁に行われています。これはディドス攻撃単価が多く下落しながら現れる現象だそうです。
私のブログについても、2024年8月と9月の間の1ヶ月間、2日に一度激しいディドス攻撃を受けたことがあります。ディドス攻撃を受ける場合、クラウドフレアと連動し、クラウドウェイズで攻撃IPを把握してブロックする方法である程度防御が可能です。
本当に便利な情報ですね！ WordPress 情報パッケージから初めて出てきたのを見ると、もっと信仰が行きますね。おかげでクラウドフレア設定がもう少し明確になったようです。