スクレイパーボットで遊ぶ

 (herman.bearblog.dev)
4 ポイント 投稿者 GN⁺ 2025-11-17 | 1件のコメント | WhatsAppで共有
  • 公開Webサイトに過剰なリクエストを送り、DDoSのように振る舞うスクレイパーボットの問題を扱い、それを逆手に取って時間を浪費させる実験的アプローチを提示
  • Markov連鎖ベースのテキスト生成器を作成し、.phpファイルのように見える偽データを生成、悪性ボットがこれをダウンロードするよう誘導
  • その後、静的コンテンツサーバーを構築し、小説 Frankenstein の段落をランダムに提供、リンク構造によってクローラーが爆発的に拡散するよう設計
  • すべてのページに**noindex, nofollow 属性**とリクエストカウンターを追加し、正常な検索エンジンは除外してルールを破るボットだけを捕捉
  • 実験結果は興味深かったが、Googlebotの誤検知リスクのため実サービスには適用せず、学習・実験用プロジェクトとして維持

スクレイパーボットの問題と対抗アイデア

  • スクレイパーが意図せず小規模WebサイトにDDoS級の負荷を引き起こす
  • 一部の運営者が保護方法を尋ねてきたが、この記事は**「防御ではなく逆襲」**に焦点
  • 別の開発者がMarkov連鎖で無限の偽データを生成してボットをだます事例を見て、自分でも実験を開始

Markov連鎖ベースの偽PHP生成器

  • RustでMarkov連鎖学習器を実装し、任意のテキストデータをもとに現実味のあるコンテンツを生成
  • .env、.aws、.php など脆弱なパスを狙う悪性ボットを対象に、本物らしく見えるが無意味なPHPコードを提供
  • ファイルサイズを2KBから10MBまで増やし、ボットのリソース浪費を誘発
  • 出力例はWordPressの関数名やコメントが混ざったもっともらしい偽PHPコードの形
  • 目的はボットの時間・資源を浪費させることと、攻撃者が実際の脆弱性を探すために時間を無駄にするよう仕向けること

効率化と静的データ提供の実験

  • VPSで1MB以上のファイルを提供すると応答遅延とサーバー負荷の増加が発生
  • これを解決するため、**静的サイト形式の「garbage server」**を構築
    • Frankenstein 小説全体をメモリに読み込み、リクエストごとに任意の段落4つを返す
    • 各ページ下部に5つのリンクを追加し、**爆発的なクロール拡散（5倍ずつ増加）**を誘導
  • 結果物は https://herm.app/babbler/ で確認可能

設計の詳細と運用方式

  • 選んだ小説はパブリックドメインであり、ハロウィン時期に作業したことと、AIとFrankensteinの類似性を理由に採用
  • すべてのページに noindex,nofollow 属性を付与し、ルールを破るボットだけを捕捉
  • 各ページ下部にはリクエスト回数カウンターを表示、メモリベースのためデプロイ時に初期化
  • .php リクエスト用の別サーバーも構成し、実際のPHPファイルをメモリからランダムに提供
  • 「Garbage for the garbage king!」というフレーズでプロジェクトを要約

リスクと制限事項

  • このシステムは実サービスに適用した場合、検索エンジン誤検知のリスクがある
    • Googlebotが誤ったエンドポイントをクロールすると、スパムサイトと分類される可能性がある
    • 検索露出の低下やChromeの警告表示につながる可能性がある
  • したがって検索依存のサイトには非推奨で、実験用プロジェクトとしてのみ運用
  • .php 用 babbler はHTMLではないためGooglebotへの影響はなく、悪性ボットのみが対象

まとめと個人的な結論

  • 悪性スクレイパーを誘い込むため、ブログに**隠しリンク（rel="nofollow"）**を追加
  • VPSのトラフィック上限超過時はCloudflareキャッシュの使用を検討
  • このプロジェクトを通じてMarkov連鎖とボットの動作原理を学びつつ、楽しさと怒りが混ざった実験を進行
  • 結論として、すべての試みが実用的である必要はなく、時には単なる楽しさだけでも十分

関連記事

1件のコメント

 
GN⁺ 2025-11-17
Hacker Newsの意見

  • 世の中が変わっても、結局は似たような問題にぶつかるものだ
    10〜15年前、私はソーシャルメディア監視サービスと戦っていた。大手ブランドがフォーラム上の感情を監視するために彼らへ金を払い、私が運営していた無料コミュニティを無断でクロールしてサーバーに負荷をかけていた
    彼らのボットを遮断してもIPとUAを変えて戻ってきたので、投稿にランダムでブランド名を挿入するフィルターを作って、彼らのデータ品質を壊した。この対策を有効にすると、2日でスクレイピングは完全に止まった

    • 私にも似た経験がある。自分のサイトの寄付フォームをクレジットカードのテスト用に使うボットがいて、IPを変えながら延々と試してきた。そこでブロックする代わりに成功/失敗メッセージをランダムに返すようにしたら、相手のデータが汚染されて数日で諦めた
    • ヘッダー分析の話は本当に役に立った。私のFediverseサーバーでも、古いChromeのUAを使うボットがAccept-Languageヘッダーをまったく送っていないことに気づいた。nginxで403を返すよう設定したら、トラフィックが減り始めた
    • 映画 The Imitation Game のように、すべてのリクエストへ即座に反応すると相手に気づかれる。一部のリクエストだけ処理したり、ランダムなエラーコードを返したりすれば検知されにくくなり、相手のデバッグをずっと難しくできる
    • ほとんどのボットはいまだにHTTPヘッダーのセットを正しく真似できていない。2025年になっても同じやり方でフィルタリングしているし、ボットは今も同じパターンで進化している
    • なぜ会社名を挿入するとボットが消えたのか気になる。もしかすると、ブランド言及を探す過程でデータシグナルが汚染されたからなのだろうか、と聞いてみたい

  • これらのボットはPHPファイルを実際にパースしているのではなく、その存在有無で脆弱性検知用のフィンガープリンティングをしている。レスポンスコードだけ見てすぐ捨てている

    • その通り、こういうケースではfail2banやcrowdsecのようなツールのほうが効果的だ。crowdsecを使ってみて、トラフィックの少ないサーバーでも脆弱性探索の試みがものすごく多いと分かった
    • それなら、わざと偽の脆弱性を見せてボットを誘い込む戦略もできそうだ。たとえば、自動化ボットを**ハニーポット(honeybot)**へ引き込んで内部動作を観察するような形だ。参考: The Cuckoo’s Egg
    • もしLLMスクレイパーがこうした応答を学習データとして使うなら、データ汚染(poisoning) のリスクはさらに高まるかもしれない。最近の論文でも、少数のデータポイントだけでモデルを壊せるとされていた

  • 最近、AIおよびスクレイパー向けのタールピット(tarpit) の話を聞いた。接続を切らずに、非常に遅い速度で無限のデータを流し続ける方式だ。Nepenthes というツールが面白そうで、試してみたい

  • 以前は、HNでスクレイパーを防ぐと非難されたものだ。「自分がどうアクセスしようが関係ない」という理屈だった

    • だが今は違う。人間が個人的にアクセスすることと、AI企業が大量のDDoS級リクエストを送ることは完全に別物だ。後者は明らかにコストを他人へ押しつける行為だ
    • 私はまともなスクレイピングなら問題ないと思っている。UAを明示し、robots.txtを守ればいい。だが今のように1秒あたり何十件も送り、古いChromeのバージョンに偽装するのは許容できない
    • 私は学術プロジェクトで、1日に1回求人サイトをスクレイピングしている。こういうのは合理的な利用だ。一方で、分単位でコンテンツを取り込んだり脆弱性を探したりするのはまったく別の問題だ
    • AIの登場が倫理意識そのものを弱めているのが一番憂うつだ。以前は自由を重視していた人たちが、今では著作権の強化や匿名性の排除を求めている。技術が人をより悪くしている

  • Apacheサーバーを自分で管理しているなら、RewriteEngineでPHPリクエストを即座に遮断できる

    RewriteEngine On
RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
RewriteCond %{QUERY_STRING} \.php [NC,OR]
RewriteCond %{THE_REQUEST} \.php [NC]
RewriteRule .* - [F,L]

    私のサーバーにはPHPがないので、こうしたリクエストはすべて悪意がある

    • nginxでも同様に設定している。PHPやASPXへのリクエストにはHTTP 418 “I’m a teapot” コードを返す 
      location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
error_page 418 /418.html;
      こうするとログのフィルタリングが簡単になる。例: FreeSolitaire.win/wp-login.php

  • 攻撃的なスクレイパーの大半はWordPressの脆弱性を狙っている。PHPファイルそのものではなく、その出力結果を欲している。こうした設定は一種のハニーポットに近いが、ボットがスクリプトどおりに動かなければ、そのまま去っていく

    • おそらく彼らは出力から正規表現で管理者ログインのパターンを探しているのだろう。なければすぐスキップする。つまり、4KBの偽PHPを生成するより、正規表現1行のほうがずっと効率的だ

  • 以前、zipbomb戦略をHNに投稿したところ、トラフィックが1日10万件に急増した。6ドルのVPSでは耐えられなかった。今は最も攻撃的なボットにだけzipbombで対応し、それ以外には403を返している。新しい戦略はうまく機能しているが、また公開するかどうかは悩んでいる。参考: 以前の投稿

  • 以前はfail2banしか使っていなかったが、もう少し面白い防御策を作りたかった
    .htaccessで怪しいパス（/.git, /wp-login）をdecoy.phpへリダイレクトし、10GBのdecoy.zipを強制ダウンロードさせる。
    decoy.phpは要求された機密ファイルのように見せかけつつ、実際には偽のログとSQLデータを無限にストリーミングしてボットを足止めする

  • これらのボットはPHPファイルをクロールしているのではなく、フレームワークの脆弱性を探している。想定外の応答を返すとすぐ諦めて別のターゲットへ移る

  • ときどきこう考える — ボットが無駄にしているリソースで暗号資産をマイニングさせることはできないだろうか？

    • やるならJavaScript実行を誘導する必要があるが、たいていのボットはすでにそうした試みを防ぐ対策を持っているはずだ