Cloudflare Managed Ruleset には、Googlebot や Bingbot などよく知られたボットを装ったリクエストを検出するルールがあります。これらのルールは、リクエストの User-Agent ヘッダーを既知のボットパターンと照合し、逆引き DNS や IP 検証などの方法で送信元を確認します。User-Agent が既知のボットに一致しても送信元を検証できない場合、ルールはそのリクエストを偽ボットとしてフラグします。
次の表は、Cloudflare Managed Ruleset 内の偽ボット検出ルールです。
| ルール名 | ルール ID |
|---|---|
| Anomaly:Header:User-Agent - Fake Google Bot | |
| Anomaly:Header:User-Agent - Fake Bing or MSN Bot |
偽ボットのルールは、既知のボットとインフラやユーザーエージェントのパターンを共有しつつ、異なる IP レンジを使う正当なサービスで誤検知することがあります。よくある例は次のとおりです。
- Google Cloud サービス: Google Cloud Workflows や Cloud Functions などのサービスは、標準の Googlebot レンジ外の IP アドレスから、Google 関連の
User-Agentヘッダー付きリクエストを送ることがあります。これらのリクエストは IP 検証に失敗し、偽の Google ボットとしてフラグされます。 - Bing Webmaster Tools Site Scan: Site Scan は Bingbot と同じ IP レンジを使わないため、偽 Bing ボットのルールが発火します。このシナリオの具体的な対応は、マネージドルールによってブロックされる Bing の Site Scan を参照してください。
- 監視・テストツール: ボットに似た
User-Agentヘッダーを設定するサードパーティの稼働監視や自動テストツールも、フラグされることがあります。
偽ボットのルールが正当なトラフィックをブロックしている場合は、影響を受けるリクエストに対して特定のマネージドルールをスキップする 例外 を作成します。
例外の式を定義するときは、ルールを広く無効にせず、正当なトラフィックを識別できるリクエストプロパティを使います。例は次のとおりです。
- サービスが既知のアドレスセットを使う場合は、送信元 IP アドレスまたは IP レンジで絞り込みます。
- サービスが特定のエンドポイントにだけアクセスする場合は、特定の URI パスで絞り込みます。
- サービスが特定のネットワークから来る場合は、ASN で絞り込みます。
例外は、Cloudflare Managed Ruleset を実行するルールより前にルール一覧に置く必要があります。そうしないと効果がありません。
例外の作成手順は、例外を作成する を参照してください。