Contents
Bingbotの範囲が公開されてます
2022-09-30 BingbotをDNS使わないで検証するのは大変という話で2日前に書きましたが、IPアドレスの範囲が公開(2021-11)されていたことに気付いたので構成しなおしました。Cloudflareを使わずとも自力でDNS無しでシンプルに簡易検証できます。
Azureの範囲
Bingbotの範囲公開以前、AS8075の中の状況を探ろうとまずAzureの範囲を定期的に自動更新するためにはDownload Azure IP Ranges and Service TagsなどのHTMLをtidyで掃除(tidy5 -q -asxhtml)してXPathでJSONのターゲットを抜いて(xmllint –nowarning –html –xpath ‘string(//a[contains(@class, “failoverLink”)]/@href)’)ダウンロードしてと、JSONを手に入れるだけでふた手間ほど多くかかりました。そして手間をかけてもBingbotやらOutlookのMTAやらがこのAzureの範囲の中にいることを知ることになり、Bingbotの検証などには使えませんでした。公開されているBingbotの範囲を見るとAzureの範囲内と範囲外両方にまたがっていることがわかります。カオス。
Cloudflareさんに任せる
本題です。Pingoraなるものがオープンソース化されてあっという間にnginxを駆逐する日も来そうです。そんなCloudflareをリバースプロキシとして矢面に立たせている場合はGooglebotやBingbotだけがターゲットではないもののもう一つ、自分で頑張らない方法があります。
CloudflareのWAFメニューにあるFirewall rulesでは、cf.client.bot(cf.bot_management.verified_bot)というありがたい値が使えます。これがtrueならば良いボットかクローラだよ、ということで
|
1 |
( ip.geoip.asnum in { 15169 8075 } and not cf.client.bot ) |
のようなexpressionを使えばGoogleとMSいっぺんに良くないボット、クローラを対象にまとめて処理できます。これをBlockとかにすればOKです。通過した場合と分けて確認したい場合は次のように2つのルールにして運用します。
|
1 |
( ip.geoip.asnum in { 15169 8075 } and cf.client.bot ) |
|
1 |
( ip.geoip.asnum in { 15169 8075 } ) |
一つ目をAllowで通過させて、二つ目をManaged Challengeなどで止めてしまいます。楽です。
ところでFirewall rulesの適用順序を見ると、その前にIP Access Rulesがあります。このIP Access RulesはWAFメニューの中のToolsにあり、AS番号、IPアドレス、国でルールを決められます。IP Access RulesでAllowするとFirewall rulesが適用されないので、IP Access RulesにはAllowは使わないなどと決めておくとすっきりするかと思います。
余談ですがDDoS対策でオリジンサーバを隠す必要がある場合は、HTTPであればCloudflareから以外の場合はfaviconなども含めて一切のコンテンツを提供しない、name-based virtual hostに反応しないとかできる一方でHTTPSではSNIに反応しないようにしないといけないのでパケットフィルタでまとめて止めてしまいます。元のDNSサーバからゾーンを消す必要もありますが、DNS trailsのように大昔からDNSの履歴を保管し続けているサービスもあるのでオリジンサーバのIPアドレスやFQDNはこれまでにA RRやAAAA RRやPTR RRで公開したことが無いアドレス、想像できないAS、アドレスにすることになります。自動リンクチェックなどが動いている場合はproxyを使うようにしないとオリジンサーバから直接リンク先にアクセスします。などなど、よくあるレンタルwebサーバでは隠すことができないことが多いかと思います。さくっとVPSなどでCloudflare Tunnelとループバックインターフェースだけでコンテンツサーバを動かせばCloudflareのIPアドレスの範囲なども気にせずに済むので良いかもしれません。