問題があるならIPレベルでブロックしてください
(boston.conman.org)- 最近Webトラフィックを分析していて、ThinkbotというWebボットが最も多くのトラフィックを発生させていることを発見した
- このボットは
robots.txtを無視し、自己紹介文も単に「問題があるならIPをブロックしろ」と言わんばかりで、非常に不誠実だった - 1か月の間に74個の異なるIPを使用し、それらは41個のネットワークブロックに分散していた
- 調査の結果、これらすべてのネットワークブロックはTencent所有であり、これがGreat Firewallのコスト転嫁の可能性と結びつくのではないかという疑念が生じた
- 最終的に約47万件以上のIPを含む大規模なブロックルールを追加した
Thinkbotの出現
- Webトラフィックの分析中、Thinkbotという名前のWebボットが上位のシェアを占めていることを発見した
- User-Agent文字列は次のような不誠実なものだった
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- 「テスト段階で問題になるならIPをブロックしてください」という文句以外に、参照URLすらない
robots.txtファイルをまったく尊重せずにクロールを進めていた- Webサイト運営者としてこれをブロックしようとしても、単一IPではなく74個のIPアドレスを使用していた
- これを逆追跡してASNを調べた結果、41個のネットワークブロックから発生していた
- これは単純な単一IPブロックでは防御できないことを意味する
Tencentとの関連性
- この41個のネットワークブロックはすべてTencent所有だった
- 筆者は、中国政府がこれを黙認または奨励している可能性があり、外部世界にGreat Firewallのコストを転嫁しようとする試みと解釈できるのではないかと疑っている
- 中国国内ではコンテンツ収集が許容され、外部でブロックされてもCCPの立場では問題にならない一方、ブロックを試みる他国や他サイトには負担として作用する
ファイアウォールによるブロック措置
- 筆者は自らbadbotsファイアウォールルールにTencentのネットワークブロックを追加した
- 例:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19など - 合計40超のネットワークブロックを追加し、これがTencent所有IPの全体を網羅しているわけではないものの、476,590件以上のユニークIPを含む
結論と比喩
- 筆者はこのような状況を「インターネットではもはや良いものを持てない」という現実として表現している
- 単なるボットトラフィックの遮断を超えて、インターネット生態系全体の信頼低下と不可避な防御的対応を示す事例だ
6件のコメント
実際、中国脅威論は他の分野ではすでに以前から現実のものになっていましたが、今や中国はインターネット生態系全体の存続そのものまで脅かし始めているのですね。
これは単なる嫌悪感情や政治的な偏向に基づく話ではなく、本当に現実になりつつあるということを、多くの人が知る必要があると思います。
問題があるならIPレベルで遮断してください
なぜ毎回こういう事件や事故は、ふたを開けてみるとCCPなんだ..
うわぁ.. 本当に最高だ..
すごい..
また中国ですね
Hacker Newsの意見
Webクローラーを開発しながら、できるだけ友好的に作ろうと努力していた。
robots.txtを厳格に確認し、ゆっくりクロールし、User Agent文字列で明確に身元を示し、単一のIPアドレスだけを使っていた。ところが、robots.txtファイル自体に適用される各種のボット対策トリックを経験することになった。最近では、slow loris攻撃のようにrobots.txtのダウンロードが非常に遅く、誤って404として扱ってそのままクロールを続けてしまった。その経験以降、タイムアウト時はDisallow /として扱うコードに変えた。皮肉なことに、ルールをきちんと守ろうとしていても、anti-botツールを検知するコードを書く状況になっている泥棒を防ぐために玄関の呼び鈴を隠すようなものだと思う
サーバーアプリケーションと同じように、クライアント側でも相手が悪意ある、あるいは不適切な挙動を見せたら静かにTCP接続を切る。相手はしばらく資源を浪費したあと、自分で状況を認識すべきだ
こうした現象は、意図的ではない可能性のほうが高いと思う。
robots.txtのルールを守らない悪性ボットは、そもそもそのファイルをダウンロードしないのだから、悪意というよりミスや無能さかもしれないルールを守ろうとする人だけを罰するような制裁は、むしろ逆効果だと思う
ルールをよく守ろうと努力している点は高く評価したい。
robots.txtに制限をかけるのはミスかもしれないが、クローラーの中にはrobots.txtからより興味深いページを見つけるものもいるので、これを遅くする方法が素早く問題を避ける助けになることはある。結局こうした方式はボットの情報を遮断し速度を落とすので、サイト運営者の立場では悪性ボットによる被害がある以上、正直なボットとの区別にそこまで気を配れないのも無理はないボットによって深刻な被害を受けるWebサイトには、どんな共通点があるのか気になる。私は
.comTLDで自宅サーバーを何年も運用しており、関連キーワードでもGoogle検索順位は高いほうで、ルーターやサーバーに特別なボット遮断設定もなかった。好奇心からボットのリクエストだけ数えたことはあるが、大半はポートスキャンかインデックスページを取得する程度で、動的に読み込まれるリンクをたどることはほとんどない。Apache 2の時代も、いまAxumで複数サイトを運営している現在も、ボットによる目立った影響はない。もしかするとディレクトリリスティングのせいなのかとも思うので、説明を聞けるとうれしいWebスクレイピングの問題に、多くの賢い人たちが過剰に執着している気がする。もしボット活動が実際にサイトへ大きな負荷や問題を起こしていないなら（もちろん例外はあるだろうが）、大半は無意味な「旗取りゲーム」にすぎない。このゲームの違いは、結局相手の旗を見つけられず、ただ時間を失うだけという点だ。最善の対処は、拡散していて識別しにくい参加者が負荷を生んでも耐えられる、速くてよく設計されたWebプロダクトを作ることだと思う。現実的には、このアプローチは実際の人間ユーザーの満足度も大きく高める
経験上、この問題の深刻さを知らないだけかもしれないと思う。以前の職場ではWebアプリのアプリケーション性能を担当していたが、一部のユーザーは稲妻のように速い一方で、大半は遅かった。性能ログを分析すると、全リクエストの60%が既知のボットだった（おかしなボットは除く）。しかも、いくつかの会社はサービスにDoS攻撃まで仕掛けてきて、そのせいでサイトが落ちたこともあった。問題は、ボットが常にキャッシュ済みレスポンスだけを取りに来るため、実ユーザーの会話がLRUキャッシュから追い出され続けることだ。あるボットは訪れたすべてのページを数分おきに再スクレイプし、別のボットはスループットを上げてサービスが遅くなるまで押し続ける。ときにはJavaScriptの実行やフォーム送信まで試みる。Googlebotだけが唯一礼儀正しく振る舞う。実際の流入トラフィックの40%がたった1つのURLに集中するなど、ボットから得られる利益もほとんどない。あとになって気づいたが、多くのボットは初期AI企業のデータ収集用だった
友人が、友人同士だけで使う小さくて公開されたgiteaインスタンスを運営している。ところが毎時数千件のボットリクエストが来る。サービスに直接影響しなくても、少なくとも嫌がらせのようには感じる
私は高速なWebプロダクトを作るために、データをプレミアム料金で取得している。だからこうしたエンティティを遮断すれば、時間の無駄どころか実際に帯域やサーバー費用を節約できる。そのおかげで本当の顧客も、コンテンツがスクレイプされなくても何の不便もなく同じ恩恵を受けられる。誰かに搾取されていると考える理屈が理解できない
「旗取りゲーム」よりは、モグラたたきに近いと思う。個人的な経験では、「悪いボット」を識別して遮断しようとするフォーラムでは、常にさらに多くのボットが現れて終わりがない
私たちの中には賢い人が多いが、技術的な問題に過剰に執着する傾向もある。何もしないとずっと気になりそうだし、遮断だけでもすればいらだちが少し減る
robots.txtを真剣に受け止める人がHacker Newsに思ったより多いことには、いつも驚かされる。善意のある人が多いという点は本当に印象的だ。でもrobots.txtは実質的な解決策ではない。人々がrobots.txtというものを知っていなければならないし、クローラーにrobots.txtチェックのコードを追加しなければならないので複雑さが伴う。他に実用的な解決策があるのか気になる。「マイクロペイメント」や「実名認証のための巨大なマークル木」などは昔から語られてきたが、実際に実装されたことはないrobots.txtを知らないボット開発者はほとんどいないと思う。自分のプロジェクトだけはみんなのルールを無視してよい特別なケースだと勘違いしている人がいるだけだrobots.txtには法的拘束力がないこちらのログにもそういうボットパターンが見える。かなり目障りではあるが、それでもボットだと名乗っており、実トラフィックは多くない。トラフィックの大半は実ブラウザのふりをしたり、ブラジルやアジアの複数IPから来たりするボットだ。ボット遮断のためにここ1週間あらゆることを試してみたので、役に立ちそうな経験を共有する。
数百のIPから、1日に数回ずつだけリクエストが来るが、どれも実在のUAを装っている
referrer URLをほとんど送らないが、Huawei Cloudのボットはreferrerを送ることがある（ただしトラフィックは少ない）
主な試みは、
id=を含むURLの帯域を制限（1Kb/s）して遅くなれば諦めるだろうと考えたが、ボットは気にせずそのままリクエストし続けたkeep-alive接続にも適応してきたので、
/cgit/ではkeep-aliveを完全に切ったが、それでも接続を占有してしまう現在使っている方法は、
id=を含むURLはnotbotクエリ文字列がある場合だけ許可し、referrerがなければ403メッセージで正規ユーザーならnotbotパラメータを追加するよう案内する、というもの。この方法で負荷は減り正規ユーザーの接続も改善したが、ボットは依然としてリクエストを続け、403を受け取り続けている結論として、サイトごとに特化したad hocな方法を使うか、Cloudflareのように十分な資源を持つところに任せるかの二択しかないようだ。標準的なボット遮断ソリューションには限界があり、資源の多い側なら十分に回避するかコストを払えてしまう
MSIE 3.0やHP-UXのようなあまり使われないUAサブストリングを403で先回りして遮断する方法もある。その後403ログを集め、問題のあるASNだけを別途遮断するというモグラたたきを繰り返す
私はdjbwaresのBernstein publicfile系ソフトウェアを使っている。static GEMINI UCSPI-SSLツールも追加しており、GEMINI仕様から取ったアイデアとして、リクエストURL内のfragmentとクエリパラメータをどちらも禁止している。理由は、GEMINIで禁止するロジックと同じものをstatic HTTPサービスにも適用できるからだ。サーバー設定上、クエリパラメータを正しく処理しようとすると特殊なファイル名をいくつも別途生成しなければならず、現実的ではない。このアイデアのおかげで、CGIやPHPの脆弱性を狙う攻撃はそもそもファイルシステムに到達せず、リクエスト分解の段階で弾かれる。staticサイト運営者には、GEMINIのようにクエリパラメータまで遮断することを勧めたい。もちろんstaticサイトというカテゴリでクエリパラメータを本当に使いたいなら例外だ
いつからか、IP範囲をホワイトリスト化する方式が実際に可能なのか気になるようになった。adblockリストのように、コミュニティの努力で保守されるアプローチも想像してみた
残念ながら、行儀の良いボットほど安定したIPを使い、悪意ある行為者はいつでも家庭用プロキシを使う。住宅プロキシIPを禁止すると実ユーザーに被害が及び、悪意ある利用者はすぐ別の場所に移る。実際に数千のIPを相手にした経験から言うと、IPベースの情報だけでは判断が難しく、追加情報が必要だ
Pokémon Goの会社も、リリース直後にスクレイピングを防ぐためこの方法を試した。3つのIPカテゴリに分け、ブラックリスト（Google Cloud、AWSなど）、非信頼IP（住宅回線）、ホワイトリスト（正常なIPv4など）として分類した。最初は主要なスクレイパーを除外できたが、最大規模のスクレイパーはモデム端末の農場を運営してこれを回避した。その結果、一般ユーザーは地図なしでゲームを諦め、コアなプレイヤーはむしろスクレイパー利用を有料で増やした。結局サーバーにはさらに大きな負荷がかかった。Pokémon Goが下した多くの誤った判断の一つだと思う
すでに多くの米国企業がこれを実施している。ただ、海外にいるときでもサービスを解約する手段を提供しないまま料金を取り続ける場合、それは不合理だ
ホワイトリストとブラックリストは、必ずしも二項対立で選ぶ必要はない。大半のトラフィックはグレーゾーンで発生する。特定のIPをホワイトリストに入れたのに異常兆候が検知されたら、ホワイトリストから外し、告知し、通知を受け、解消された事実まで相互に調整しなければならず、現実には非常に複雑だ。ホワイトリストが有効なのは、信頼関係のあるパートナー同士だけだ。ブラックリストは、問題の多いアドレスや、CIA、ロシア、中国、クラウド事業者などを遮断するのに有用だ。企業内部専用ホストなど、robustな不正利用対策を持つ場所だけをホワイトリスト化するのが現実的なアプローチだ
私はオープンソースプロジェクト GoodBots を通じて、前向きなボットのホワイトリストを作っている。PR大歓迎だ
すべてのリクエストにカスタムヘッダーを追加して送らせ、それ以外のすべてのリクエストは遮断する方法を使っている
外側ではCloudflareプロキシを使い、内部的にはCrowdsecとModsecurity CRSをTraefikの前段に置いている。誤検知を減らすよう調整したあと、非常に安定して運用できている。一時遮断されたIPと報告済みIPはCrowdsecへ送り、その後Discordチャンネルにログとして投稿する。1日平均で数十個の異なるIPを遮断している。体感では、非公開リソースへのアクセスやCVE狙いの試みは、中国IPより米国IPのほうがはるかに多い。公開コンテンツのクロールは気にせず、それ以外はすべてSSOまたはイントラネットからしかアクセスできないようにしている。特定の国を遮断するより、exploitやフラッディングの試み自体を止めるほうが効果的だ
Crowdsecのような方式は魅力的だが、サーバー上の全トラフィックを営利企業に渡すのは大きなリスクだと思う
深刻な攻撃の試みは、結局Cloudflare WAFのようなところで既に止められるはずだ
多くのアパート建物では、外部へ出るのに使えるIPアドレスが数個しかない（Carrier-grade NAT 参照）
私のトラフィックの半分以上はBing、Claude、そしてFacebookのボットだ。これらは主要なトラフィック貢献者ではないが、サーバー資源だけを食い、サイトが遅くなるときの主因になる（AI、Microsoft、Facebookは常識すら無視することが多い）。中国などは悪性トラフィックの一部にすぎず、本当の問題は
robots.txtやDNS rate limitを無視する米国系企業だ