WAFによる偽装AIクローラー対策の限界：ブロックしても解析データは残り、攻撃は本物のクローラー名に移行
本記事は、ウェブサイトのセキュリティ対策として、AIクローラーによる認証情報スキャン（例：/.envや/wp-config.phpへのアクセス）をCloudflareのWAF（Web Application Firewall）で遮断した経験に基づいた分析レポートである。筆者は、入口で不正なアクセスを止めることで、解析データがクリーンになると期待していたが、実際には複数の課題が判明した。まず、WAFでリクエストをブロックした場合、そのリクエストはCloudflareのGraphQL Analytics API上で403エラーとして計上され、単に「遮断された」という事実が計測データに残るため、WAFは「オリジン（本番環境）を守る道具」であり、「計測の汚染を直す道具」ではないことが判明した。具体的なデータとして、Perplexity-Userという偽装UAからのアクセスは、ルール投入前は404（存在しないパス）であったが、ルール投入後は403として計上され、8日間で595リクエストという形で計測に残った。
さらに深刻だったのは、攻撃者が対策を回避した点である。当初、Perplexity-Userなどの偽装UAをブロックするルールを適用したが、攻撃は止まらず、代わりにAmazonbotやChatGPT-Userといった、本物のクローラーが使用する正規のUser-Agent（UA）名に活動が移行していた。このため、UAのみを条件としたブロックリストは、攻撃者が「本物と共有する名前」に移行した時点で機能しなくなった。対策の成功は、パスのブラックリスト化（`starts_with`ではなく`contains`を使用）や、実在しないUA（Google-Extendedなど）の特定に限定され、本物のクローラー名を持つアクセスを完全に防ぐことは極めて困難であることが示されている。結論として、単なるブロックリスト運用ではなく、集計側（データ取得スクリプト側）での高度な分類や、`cf.client.bot`などの検証結果を利用した判断が必要であると提言している。
背景
近年、AI技術の進化に伴い、大規模なデータ収集（スクレイピング）や、機密情報（設定ファイルなど）を狙った自動スキャンが深刻なセキュリティ脅威となっています。ウェブサイト運営者は、CloudflareなどのWAFを利用してこれらの不正アクセスを遮断することが一般的ですが、本記事は、単にブロックするだけでは不十分であり、攻撃者が手法を変化させるため、より高度なデータ分析と防御レイヤーの設計が必要であることを示唆しています。
重要用語解説
- WAF: Web Application Firewallの略。ウェブアプリケーションを外部からの不正な攻撃（SQLインジェクションなど）から保護する仕組み。リクエストを事前にフィルタリングし、不正なアクセスを遮断する。
- User-Agent (UA): ウェブブラウザやクローラーが、自身を識別するためにHTTPリクエストに付加する文字列。アクセス元を特定する重要な手がかりとなるが、偽装も容易である。
- GraphQL Analytics API: Cloudflareが提供する分析用APIの一つ。エッジ（WAFが設置されている最前線）で処理されたリクエストの応答ステータスや詳細なログを集計・提供する機能。ブロックされたリクエストもここに記録される。
今後の影響
本ニュースは、単なるセキュリティ対策の実施だけでは不十分であり、セキュリティ対策を「防御（ブロック）」と「計測（分析）」の二層構造に分けて考える必要性を示しています。今後は、WAFによるブロックログを単なる成功指標とせず、データ収集側で「不正なパターン」として分類・集計する仕組みの導入が必須となり、セキュリティ運用設計の高度化が求められます。