ハクソク

世界を動かす技術を、日本語で。

攻撃的なボットが私の週末を台無しにした

193日前原文(herman.bearblog.dev)

概要

Bear Blogで初の大規模障害発生。 原因はリバースプロキシの過負荷と監視システムの通知失敗。 インターネット上の悪質なボット増加が背景。 対策として監視・リソース強化や透明性向上を実施。 今後もボット対策と安定運用を継続予定。

Bear Blog初の大規模障害とその背景

  • 2025年10月25日、Bear Blogで初の大規模障害発生
  • リバースプロキシ がダウンし、カスタムドメインがタイムアウト
  • 監視ツール の通知失敗により、障害発見が遅延
  • 影響を受けたユーザーへの 謝罪

障害の根本原因

  • リバースプロキシ への過剰なリクエスト集中
  • 近年増加する 悪質なボット によるDDoS攻撃や過剰スクレイピング
  • 監視システムのプッシュ通知が 機能不全

現代ウェブのボット事情

  • AIスクレイパー ：ChatGPTやAnthropicなど、LLM学習用データ収集
    • ユーザー主導の検索は許可、モデル学習用はブロック
  • 悪質なスクレイパー ：脆弱性探索や機密ファイル(.env/.aws)狙い
    • 数百万件単位のリクエストを短期間でブロック
    • IPアドレスを頻繁にローテーション、携帯ネットワークASNs利用推測
    • アプリ開発者が無料アプリ経由でトンネル販売している可能性
  • 無秩序な自動化 ：簡単なスクリプトで大量スクレイピング
    • 一般家庭PCでもVPSより高性能化、DDoSの温床

既存のボット対策

  • CloudflareのWAFルールとレートリミット 導入
  • 独自コードで不正ボットを検出・隔離
  • Zip BombやProof of Work検証も検討したが、複雑化回避のため未導入

今回の障害の詳細

  • 数百のブログがDDoS被害、数万ページ/分単位でリクエスト集中
  • サーバー自体のスケーリングは機能、 リバースプロキシ がボトルネック
  • 5年間無停止だったサーバーが初めてダウン
  • 監視システム の通知漏れが復旧遅延を招く
  • 通知設定やアプリ自体の問題は検証済みだが原因不明

今後の対策

  • 監視の冗長化 ：2系統の監視サービスで電話・メール・SMS通知
  • リバースプロキシでのレートリミット・ボット対策 強化
    • サーバー負荷を約半減
  • リバースプロキシのリソース増強 ：従来の5倍負荷に耐える設計
  • 自動再起動機能 ：2分以上帯域ゼロなら自動リスタート
  • ステータスページ （https://status.bearblog.dev）新設で透明性向上

インターネットの現状と今後

  • 公開インターネットの大半は ボット によるアクセス
  • 悪質なボット増加で ウェブ運用の難易度上昇
  • 良質なインターネット空間維持のため、今後も ボット対策と安定運用 を継続
  • さらなる提案や相談は メール連絡 を推奨

まとめ

  • ボットとの イタチごっこ は今後も続く
  • 安定運用とユーザー保護のため 継続的な改善 に注力

Hackerたちの意見

すごいのは、これらのスクレイパーがスクレイピング中に何千ものIPアドレスを回していることだよね。だから、リクエストがモバイルデバイスのアプリを通じてトンネリングされているんじゃないかと思う。ASNsはだいたい携帯ネットワークだし。まだ推測の域だけど、アプリ開発者がアプリを無料で提供して、スクレイパーにトンネルアクセスを売ることで収益化する方法を見つけたんじゃないかな。ほんとにすごいし、影響を受けるデバイスの持ち主にとっては恐ろしいことでもあるよね！これについて何か裏付けがある？

└

これは実はよく知られている事実だよ。今は「住宅プロキシ」を売ってるサービスがたくさんあって、これらはいつもモバイルのIPアドレスなんだ。モバイルIPはCGNatを使っているから、IPをブロックするのも良くないんだよね。まるで都市全体をジオフェンスするようなもんだから。例えば、oxylabs、iproyal、brightdataとかがあるよ。最近、brightdataに直接悪用の苦情を出したんだけど、彼らのボットから何千ものリクエストを受けてたからね。面白いのは、苦情を認めた後も全然止まらなかったこと。

└

もしそこそこ成功しているアプリやSDK、ブラウザ拡張があれば、こういうことを追加するように頼まれることがあるよ。ほとんどの無料VPNサービスも、自分の帯域幅を貸し出してお金を稼いでると思う。

└

こんなのもあるよね。https://hola.org/ https://hola.org/legal/sdk https://hola.org/legal/sla > どうして無料なの？ > > Hola Free VPN Proxy、Hola Fake GPS位置情報、Hola Video Acceleratorを無料で使う代わりに、あなたはBright Dataネットワークのピアになるかもしれません。そうすることで、Bright Data SDK SLAの利用規約を読み、受け入れたことに同意したことになります。プレミアムユーザーになることでオプトアウトできます。この「VPN」がこれらの住宅プロキシを支えているんだよね: https://brightdata.com/ こういう会社は他にもたくさんあると思う。

└

SIMファームも別の可能性のある説明だね。FBIが数週間前に何十万ものSIMを持つファームを摘発したばかりだし。

└

接続を使わせることで数ドル（そんなに多くはないけど）もらえるんだ。Cloudflareのビジネスモデル（データセンターのIPをブロックする）が無価値になることを願って、やってる。まだ引き出しは試してないから、詐欺かもしれないけど。これは違法じゃないよ（詐欺じゃない限り）。

└

これについては、7月にこの「ギャング」が私がホストしているいくつかのサイトを攻撃し始めたときに書いたよ: https://wxp.io/blog/the-bots-that-keep-on-giving 彼らはcolo（M247、Datacamp、HostRoyale、Oxylabsなど）と国際的な住宅用IPのミックスを使ってる。後者が住宅用アプリプロキシに関係してるんじゃないかと思う（bright SDKとか）。Oxylabsも有名なプロキシプロバイダーだから、これらのIPへの入り口になってるんじゃないかって思う。ウェブサーバーをホストするのは本当に面白い時代だね！

Pingoo (https://github.com/pingooio/pingoo)を見てみるといいかも。これは自動TLSを持つリバースプロキシで、単純なIPブロッキングを超えた高度なルールでボットをブロックできるよ。

うちでもこれを感じてる。私たちは、すべての本、ブックリスト、著者、ナレーター、出版社がSEO用の独立したウェブページとして利用できる書籍ストリーミングプラットフォームを運営していて、数百万ページもあるんだ。この6ヶ月は地獄のような状況になってる。理由はいくつかあるけど、1. レート制限を無視するのが普通になった 2. ボットがUAで自分を特定しなくなった 3. ボットがVPNや似た技術を使ってIPレート制限を回避している 4. ボットがNobleTLSやJA3Cloakのようなツールを使ってja3レート制限を回避している 5. 一部の正当なLLM企業も上記のことをしてトレーニングデータを集めているようだ。私たちは彼らに自社を知ってもらいたいから、必ずしもブロックしたいわけじゃないんだ。正直、もう諦めそう。大規模で悪質なトラフィックを特定する安全な方法がなくなってしまったし、利用可能なバリエーションでは静的に生成できない。CDNキャッシュ（fastlyに感謝）を使っても、カタログが広すぎてキャッシュを完全に満たしながらページをタイムリーに更新するのは難しい。解決策は、オリジンサーバーをスケールアップすることかな… /shrug 本気で言うと、ボットにデータを取得するもっと効率的な方法を教えられたらいいな。マーケティングページに行くことで余計な負担をかけるのではなく、書籍情報を取得するために私たちのオープンAPIを使ってほしい。

└

原則として、中央サービスを使って悪質なIPをスケールで特定することは可能だと思う。つまり、毎千ページのヒットをシンプルなUDPパケットで報告すれば、中央トラッカーの負荷は非常に低く、悪用されているIPのブルームフィルターを公開するのに十分なデータを得られる。例えば、100万ビットであれば、かなり低い誤検出率になるよ。（もし悪質なIPが約1万件だけなら、正直、LRUカウンターを維持して全てを列挙するだけで済む。）追跡されたサイト全体で毎時10億ヒットがあっても、トラッカーサービスへの流入は約50KB/sに過ぎない。個々の参加サイトは、ソースIPごとに多くのヒットを受けるわけではないけど、数十サイトを集約すれば悪質な行為者が浮き彫りになるはず。クライアントは1時間ごとにブルームフィルターを引き出して（80KBのダウンロード）、一致するリクエストをドロップすればいい。今どきのLLMなら、これのバックエンドを1日か2日でコーディングできるだろうし、RasPiで動くはず。どこかの組織が責任を持ってインフラと広告を提供しなきゃね。

└

同じく、俺も数百のWordPressサイトを持ってるけど、ボットの活動がここ1、2年でめっちゃ増えた。AIのスクレイパーはかなり攻撃的で、例えばサイトにたくさんのパラメータがあると、ボットが全ての可能なパラメータを試そうとして狂ったようにリクエストを送ってくる。時々、掘り下げて新しいルールを考えて、大量にブロックしようとするけど、AIがGoogleを置き換えるかもしれないし、AIのデータベースに入ってないのも心配なんだ。

└

信頼できない会社の独自の単一ソース製品に頼るのは嫌だけど、（無料の）Cloudflare Turnstileは俺には合ってる。これだけが効果があった。アプリ内の「危険/高価な」（偶然ハニーポットみたいな）パスだけを保護して、実際にクローラーに取得してほしいものはそのままにしてる。それで十分なんだ。SEOのためにクローラーに俺のものをたくさん取得してもらいたいけど、Googleに独占させたくないし、聞いたこともないような良いクローラーにもアクセスしてほしい。でも、リソースを無駄にしたくはないんだ。

もしかしたら、ブログサービスを完全に静的にして、Cloudflareのページで処理させるのが助けになるかも？

└

Cloudflareは解決策じゃないよ。さらに中央集権的なインターネットを招くだけ。

今年の初めに、Hetznerで運営してたウェブサイトがあったんだけど、ASP.NETの実験をしてたんだ。ログを見てたら、WordPress関連のエンドポイントへのアクセスがめちゃくちゃあったのに気づいた。そこで、robots.txtにハニーポットを仕込んだっていう話を読んだんだ。完全に偽のエンドポイントに向けてね。理論的には、人間はrobots.txtを読まないから危険はないけど、ボットはよく読むから（少なくとも何があるか確認するためにね…大体「deny」は無視されるし！）その偽のエンドポイントにアクセスしてきたら、100%（できるだけ近いけど）人間じゃないって確信できるから、バンできるんだ。だから、やってみたよ。自動生成したrobots.txtファイルをその場で作ったんだ。60秒くらいキャッシュされるようにして、リソースをあまり使いたくなかったからね。リクエストが来たら、キャッシュされたものか新しいものを作るかだった。CPU使用率はほとんど無視できるレベルだった。でも、悪い奴らがキャッシュしないように、ファイルを作るたびに「deny」のエンドポイントを変えたんだけど、結局同じASP.NETコントローラーメソッドに行くようにしてた。そこにアクセスすると、10GBのzip爆弾を送り込んで、あなたのIPが自動的にFWのブロックリストに追加される仕組みだった。めっちゃ簡単だったよ：そのエンドポイントにアクセスするやつは絶対怪しいから…人間がたまたまそこに来たら、ブラウザでそのエンドポイントに行くと自動的にファイアウォールのブロックリストに追加されるってコメントも入れてたと思う。とにかく、最初はめちゃくちゃ悪い奴を捕まえた。最初は何千人もいたけど、だんだん減って、今は一日数十人になった。まあ、これは一つのデータポイントだけど、俺には効果があった…zip爆弾についても後悔はしてないよ :) 今は別のサイトも作ってるから、少し進化させて、短時間バンして、またその怪しいエンドポイントに戻ってきたらボットだってわかるようにして、地獄に送り込むつもり！完璧じゃないけど、俺には効果があったよ。

└

研究するのは面白いよね？これはインターネットの背景放射のようなものだ。ほとんどの場合、無害だし。エクスプロイトスキャナーはLLM時代には新しいものじゃないし、サーバーに負荷をかけるべきじゃない - もしエクスプロイトに脆弱じゃなければね。面白い事実：新しいエクスプロイトを知るために、来るリクエストを見てる人もいるよ。

└

完璧ではないけど、私にはうまくいったよ。これは私のアプローチで、zip bombを除いたものだね。AspNetCoreのパイプラインにミドルウェアを使って、IPv4ごとの論理的リソース消費率を追跡してる。クライアントが制限を超えたら、そのIPは一定期間HashSetに入る。もしそのセットにIPが入ってたら、レスポンスボディに「リソース制限を超えました。後でもう一度お試しください。」っていうシンプルなUTF8定数文字列が返される。私の戦略のもう一つの側面は、AspNetCore（Kestrel）を使うこと。設定が正しくされていれば、ほとんどノイズを無視できるくらい速いから、特定のシステムを壊そうとするクソ野郎のエッジケースに対処するために合理的な試みをする限りはね。悪質なクライアントを拒否する最初のミドルウェアとしてHashSetを使うのは非常に効率的だよ。ここではまだURLルーティングにも入ってないしね。私のウェブサーバーが見るすべての悪い行動をカタログ化して記録しようとするのが、今のところDDOSに対する最大のリスクだと感じてる。毎回「禁止されたクライアントを拒否しました」ってログを取るのは、ディスクの摩耗やIO利用に関して自分の足を撃つようなもんだよ。そんなバックグラウンドの放射線をディスクにログする必要なんてないし、考える必要もない。もしあなたのウェブサーバーが宇宙の真空に直接さらされるのに耐えられないなら、プロキシ/CDNの後ろに置くことができる（つまり、別のウェブサーバーで、そんなにひどくないやつ）。

└

もしそれが無防備なユーザーの携帯電話を通してプロキシされてたらどうなる？都市全体や地域をブロックするリスクがあるよ。

スクレイピングが産業になったのはすごいよね。

└

すごいよね。データは非常に価値がある。これは同時に二つの側面で現れる：誰がデータを持っているかが、誰がそれを見られるか、どんな状況で見られるかを大きく左右する。そしてもう一方では、できるだけ激しくスクレイピングされる。

インターネットはスクレイピングなしでは成り立たないよ。公のデータをスクレイピングすることに反対する声があるけど、実際には合法だし、日常的に使うサービスには欠かせないんだ。だから、政治的な議論にするんじゃなくて、公正な利用を目指して摩擦を減らすためのガイドラインを設定するのが正しいと思う。

└

え？どういう意味？

└

もうガイドラインはあったのに、あのクソみたいな連中が守ってないから、今こういう「反感」が出てきてるんだよ。

└

そうだね、でもこういうガイドラインは存在してるし、robots.txtのガイドラインは業界主導の自己規制的な基準なんだよね。でも新しいボットはそれを無視するんだ。立法が追いつくのには何年もかかるし、仮にそうなっても国や地域ごとになるから、グローバルなものにはならないよ。だって、インターネットの仕組みがそうなってないからね。立法があったとしても、OpenAIやMicrosoftを訴えることはできるけど、スクレイピングをしてそれを最高入札者に売る新しい会社を立ち上げるのは簡単だよ。

すべてをダークウェブに移して、企業がここで消費者に自分たちのものを売るのを許すの？この連中はおとなしく遊びたくないし、匿名性を侵害するようなReal IDや他の認証を持ち込まないと、止める方法がないよ。

└

ボットはデータのあるところに集まるんだ。別のネットワークに移るのは、ボットにくっついてくるようにお願いしてるようなもんだよ。

帯域幅の使用量が2分以上ゼロになると、リバースプロキシを自動再起動する。君の場合は常にトラフィックがあるから理解できるけど、最初に思いついたのは、再起動のループになっちゃうことかな。まあ、君のケースではあまり考えられないけどね。時々、こういう一律のルールが思わぬ理由で影響を受けることがあるんだ。例えば、プロキシが指定された時間内にトラフィックを処理できなかったりとか。でも、「今すぐ動くものを出す」ってアプローチには完全に賛成だよ！

└

ポート80を開けて、結果を記録してみて。サービスをどこにも告知してなくても、基本的なリクエストレートは2rpmを大きく上回ってるよ。すべてのIPのオープンポートは、常に脆弱性を探してスキャンされてるからね。

アプリを無料で提供して、スクレイパーにトンネルアクセスを販売して収益化する。多分、無料のVPNアプリだろうね。