FOSSインフラがAI企業から攻撃を受けている

 (thelibre.news)
1 ポイント 投稿者 GN⁺ 2025-03-21 | 1件のコメント | WhatsAppで共有
  • SourceHut、KDE GitLab、GNOME GitLab、LWN、Fedora、Inkscape、Diaspora、Read the Docs など複数の FOSSインフラ が、AIクローラーとAI生成のセキュリティ報告によって障害・遮断・運用負荷に見舞われている
  • クローラーは robots.txt を無視したり、git blame・Gitログ・コミットページのような 高コストなエンドポイント を繰り返しリクエストしたりし、数万件のIPと偽装したUser-Agentで一般ユーザーのトラフィックに紛れ込もうとする
  • GNOME は Anubisのプルーフ・オブ・ワーク を導入したが、約2時間30分で81,000件のリクエストのうち通過したのは3%だけで、トラフィックの大半がボットである可能性を示した
  • Edgeバージョンの遮断、未ログインユーザーの制限、サブネット・国単位の遮断、IPブロックリスト、AIクローラー向けの robots.txt・.htaccess といった対応が続いており、実際のユーザーも遅延や接続遮断を経験している
  • 公開協業に依存するオープンソースプロジェクトは私設サービスより露出面が広く、AIスクレイピング とLLMの幻覚によるセキュリティ報告がメンテナーの時間と運用余力を直接むしばんでいる

複数のFOSSインフラで繰り返された障害

  • SourceHut の founder 兼 CEO である Drew DeVault は、LLM企業が robots.txt を尊重せずにデータをクロールし、SourceHut に深刻な障害を引き起こしていると批判した
  • KDE GitLab インフラは Alibaba 範囲のIPから来たAIクローラーで過負荷となり、KDE開発者が一時的に GitLab にアクセスできなくなった
  • GNOME GitLab では、障害を引き起こすAIスクレイパーを防ぐための Anubis プルーフ・オブ・ワーク・チャレンジャーのデフォルト読み込み画面が表示されるようになった
  • 事例が積み重なるにつれ、AIスクレイパーの攻撃性は強まり、公開協業を前提とするFOSSコミュニティの運用負荷も増している

クローラーの挙動と遮断の難しさ

  • Drew DeVault によると、LLMクローラーは robots.txt の要求を守らず、高コストなページまで含めてリポジトリ全体をなめるように巡回する
    • 対象には git blame、Gitログの全ページ、リポジトリ内のすべてのコミットが含まれる
    • クローラーは数万件のIPからランダムなUser-Agentを使い、各IPはHTTPリクエストを1件以下しか送らず、ユーザートラフィックに紛れ込もうとする
  • この方式のため緩和策を作るのは難しく、SourceHut では優先度の高い作業が数週間から数か月遅延している
  • ボットと人間の区別が難しいため、実際のユーザーも断続的に影響を受け、SourceHut の障害につながった
  • Drew は、すべてのAI企業が robots.txt やUser-Agentの申告を同じように扱っているかどうかまでは区別していない

KDEとGNOMEの対応

  • KDE sysadmin チームの Ben によると、KDE GitLab にDDoSを引き起こしたIPはすべて MS Edge を名乗っており、中国のAI企業が原因だった
    • Ben は OpenAI や Anthropic のような西側のLLM運営企業は、少なくとも正しいUser-Agentを設定していると見ている
    • 一時的な解決策は、ボットが名乗っていたEdgeバージョンを遮断する方法だった
    • ボットがUser-Agentを変えて紛れ込もうとする傾向があるため、最終的な解決策として使うのは難しい
  • GNOME は昨年11月から問題を抱えており、未ログインユーザーがマージリクエストやコミットを見られないよう レート制限 をかけた
    • この措置は実際の未ログインユーザーにも問題を引き起こした
  • その後 GNOME は Anubis に切り替えた
    • Anubis はブラウザに計算課題を提示し、ブラウザが時間をかけて解いてサーバーに送信するとアクセスを許可する
    • 開発者はこれを「核対応に近い措置」と表現しており、AIスクレイパーボットが robots.txt のような標準に従わないために強いられた選択だと見ている
  • Anubis もユーザーへの影響を残した
    • 同じ場所から多くの人がリンクを開くと、より高難度の課題が提示されることがある
    • あるユーザーは1分の遅延を、別のユーザーはスマートフォンで約2分の待機を経験した
    • GitLab のリンクがチャットルームに貼られたり、Triple Buffering GNOME のマージリクエストが Hacker News に投稿されて注目を集めたときに、このような状況が発生した
  • GNOME sysadmin の Bart Piotrowski が共有した数値によると、約2時間30分のあいだに合計81,000件のリクエストのうち Anubisのプルーフ・オブ・ワーク を通過したのは3%だけだった
    • Anubis通過率: {p:3}
    • これはトラフィックの97%がボットである可能性を示唆している

LWN、Fedora、Inkscapeの遮断事例

  • LWN を運営する Jonathan Corbet は、AIスクレイパーボットによるDDoSのため、サイトが「時々遅くなる可能性がある」とユーザーに通知した
    • 実際の人間の読者に提供されるトラフィックは全体のごく一部にすぎないという
    • ボットは一時、数百件のIPから同時にアクセスし、自分をボットとして識別せず、robots.txt も読まなかったという
  • Fedora プロジェクトの sysadmin Kevin Fenzi もAIスクレイパー問題に直面した
    • 1か月前には pagure.io を生かしておくために対応しなければならなかった
    • その後状況は悪化し、複数のサブネットを遮断し、実際のユーザーにも影響が出た
    • 切迫した状況でブラジル全体を遮断し、この遮断は今も維持されていると理解されている
  • Neal Gompa は、国全体の遮断にも限界があり、Fedora インフラがAIスクレイパーのため「数週間にわたって定期的にダウンしていた」と指摘した
  • Inkscape も先週同じ問題を経験した
    • Martin Owens は、昨年の一般的な中国発DDoSではなく、複数企業がスパイダー設定を無視し、ブラウザ情報を偽装している状況だと見ている
    • 彼は Prodigiusブロックリスト を作成し、AIを手がける大企業で働いているなら Inkscape のWebサイトにもうアクセスできないかもしれないと述べた

IPブロックリストと共同対応の試み

  • Frama software の BigGrizzly も悪質なLLMクローラーに flooded され、偽装User-Agentを使う 460,000件のIP のブロックリストを作成した
    • 彼はこのリストを共有できるとしている
  • ai.robots.txt プロジェクトは、AI企業に関連するWebクローラーの公開リストを作ろうとする、より包括的な試みである
    • Robots Exclusion Protocol を実装した robots.txt を提供する
    • リストにあるAIクローラーのリクエストにエラーページを返す .htaccess ファイルも提供する

DiasporaとRead the Docsのトラフィック数値

  • Diaspora インフラに関する Dennis Schubert の分析では、Webトラフィック全体のかなりの部分がAI企業のボットだった
    • OpenAI のUser-AgentボットがWebトラフィック全体の 4分の1 を占めていた
    • Amazon は15%、Anthropic は4.3%を占めていた
    • 全リクエストの約70%がAI企業から来ていると集計された
  • Schubert は、これらのボットは一度クロールして去るのではなく、6時間ごとに再び来て、robots.txt を気にしないと述べた
    • レート制限をかけると別のIPに切り替える
    • User-Agent文字列で遮断すると、ボットでないUser-Agent文字列に変えるという
    • これをインターネット全体に対するDDoSと表現している
  • Read the Docs は「AI crawlers need to be more respectful」という記事で、すべてのAIクローラーを遮断したところトラフィックが 75%減少 したと明らかにした
    • トラフィック減少率: {p:75}
    • トラフィックは1日800GBから200GBに減少した
    • これにより月あたり約1,500ドルを節約した
    • クローラーが数日で数十TBのデータをダウンロードする事例もあった
    • 複数のIPを使うため完全に遮断するのは難しい
  • Schubert によると、Google や Bing のような「正常な」クローラーは、合わせても1%未満にすぎない

AI生成セキュリティ報告が生んだメンテナー負荷

  • 問題はスクレイパーにとどまらず、AI生成バグ報告 にも広がっている
  • Curl プロジェクトの Daniel Stenberg は「The I in LLM stands for Intelligence」という記事で、AIが生成したバグ報告の問題を扱った
    • Curl はバグバウンティプロジェクトを運営している
    • 最近、多くのバグ報告がAIで生成されており、見た目にはもっともらしいため、開発者が確認に時間を費やしている
    • しかし報告には、AIに期待される典型的な幻覚が含まれている
  • CPython、pip、urllib3、Requests などのセキュリティ報告トリアージチームにいる Seth Larson も同様の問題を経験している
    • オープンソースプロジェクトに対して、きわめて低品質でスパム的なLLM幻覚セキュリティ報告が増えている
    • こうした報告は一見すると正当なものに見えることがあり、反証するのに時間がかかる
  • セキュリティ報告への対応はコストが高く、もっともらしいが作り物のバグ報告に対処することは、メンテナーに大きな追加負担を与える
  • Larson は、脆弱性検出にAIやLLMシステムを使わないでほしいと求めている
    • 現在のシステムはコードを理解できず、セキュリティ脆弱性の検出にはコード理解と意図・一般的な使用方法・文脈といった人間レベルの概念理解が必要だという

FOSSにより大きくのしかかる構造的負担

  • FOSSプロジェクトは商用製品より資源が少ないことが多い
  • コミュニティ主導プロジェクトはインフラのより多くの部分が公開されており、クローラーに露出している
  • 公開イシュー・セキュリティ報告・協業インフラが必要なため、AIスクレイパー とAI生成イシューが同時に負担として作用する
  • 結局、障害対応、遮断ポリシー、ユーザー被害の緩和、虚偽のセキュリティ報告の精査が、オープンソースメンテナーの時間を消費している

関連記事

1件のコメント

 
GN⁺ 2025-03-21
Hacker News のコメント

  • ここにも事例がある: https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse... 元記事でも引用されている記事だが、大規模なインターネットインフラを運営している知人たちは皆、似たような目に遭っている
    この記事は、そうした事例を一か所にうまくまとめている。書いたときにも言ったが、彼らは単に信頼資産を完全に燃やし尽くしているところだ
    この分野の主要スタートアップの1社は、私たちと直接協力し、費用を返金し、クローラーのバグも修正した。一方で Facebook はメールに返信せず、User Agent のリンクは 404 だった。同社のエンジニアが記事を見て正しいメールアドレスを教えてくれたが、そこに3回送っても返信はなかった

    • AI企業は、信頼資産は重要ではないという態度で動いているように見える。1000億ドルの資本を持つ800ポンドのゴリラのように、やりたい放題だ
      望むと望まざるとにかかわらずAIはあらゆる製品に入り、望むと望まざるとにかかわらずあらゆるデータを吸い上げる、という態度だ
    • 「あるクローラーが2024年5月に圧縮済みHTMLファイル73TBをダウンロードし、帯域幅コストが5,000ドルを超えた」という部分で、思わず読み返した
      専用サーバー中心で月に数百TBのトラフィックを処理するインフラを運用しているが、トラフィック費用は1TBあたりおおむね0.50〜3ドル程度だ。地域によって違いはあるが、AWSの送信トラフィック料金は本当に正気ではない
    • 返信がないなら、メールの代わりに買掛金チームへ請求書を送ればいい
    • メールを3回送っても返信がなかったなら、その時点からクロールはバグやミスではなくDDoSと見なすべきではないのか？
    • いっそ動的に生成したゴミ情報を食わせてみたらどうだろう？ 何も情報を与えないより面白そうだ

  • 自分のプロジェクトがプレビュー画像にこんなふうに出ているのを見ると、本当に現実感がない。すごいね！ 試してみたいならここにある: https://github.com/TecharoHQ/anubis
    今のところ実際に動いているように見える。私のブログで本番環境ではどう壊れるかを見るために、xeiaso.net にデプロイしてある

    • 人間に、今何をすべきで、そのページで何が起きているのかを少し説明してくれるとよさそうだ
      ローディングアニメーションのウィジェットのようなものはあるが、数週間前に Gnome のイシュートラッカーで初めて見たときは、Proof of Work に20秒ほどかかり、何が起きているのか分からなかった。最初はブロックされたか、CAPTCHAが読み込まれていないのだと思った
      今は何なのか分かっているが、「ボットかどうか確認中」ページだけを単体で見ると、100%明確とは言えないように見える
    • この方式は本当に気に入っている。インターネットが西部開拓時代のように振る舞うのは構わないが、責任の所在がないのは嫌だ
      サイトを無料で開放し続けたい側が、経済的負担をクローラーに移す良い方法だ。データが欲しいなら、持っていく側がお金を使えばいい
      検索エンジンから外れる可能性があるという欠点はあるが、サービスをグローバルまたはP2Pのインデクサーに登録できない理由もない
    • 気に入った。いつも通りよくできている
      そして https://news.ycombinator.com/item?id=43422781 に関連して、好きな草コインのごく少額を計算する方式を付ければ、暗号資産の実際に有用な使い道がもう一つ生まれるかもしれない
    • Anubis は有名にならない間だけ通用するだろう。有名になれば、クローラーたちはGPU/ASICで Proof of Work を処理し始めるだろうし、そうなれば終わりだ
    • ときどきランダムにあなたが作ったものに出会えるのがいい。ブログ形式の説明の仕方も好きなので、Anubisをもっと見てみるつもりだ

  • この速度なら、自由・オープンソースインフラだけの問題ではありません。もちろんそれが炭鉱のカナリアなので特に共感しますが、結局は匿名でのインターネットアクセス全体の問題です
    サイトを認証壁の向こう側に置くことはできますが、新しいボットは以前と違ってCAPTCHAを解き、実際のユーザーをまねます。特に住宅用IPや偽のUser Agentを使ったり、記事にあるようにPlaywrightのようなものに接続された実際のUser Agentまで使ったりすればなおさらです
    結局、サイトがクレジットカード、Worldcoin、あるいはそれと同じくらい憂うつな代替手段を求め始めること以外に何が残るのでしょうか

    • すでに半分くらいそこまで来ています。OpenStreetMapのマッピングをしながら、自前のWebサイトを持たない地域の事業者を探すたびに実感します
      彼らはFacebook、Instagram、Xなどをデジタル名刺のように使っています。普段FacebookやInstagramを使わず、Xもやめていてアカウントもないのですが、そうしたリンクをたどると一部の情報だけが表示された後、アカウントを作るか出ていくよう促すダイアログが出たり、原因不明のエラーが出たりします
      私的なコミュニティに参加するのは構いませんが、公開されると思って投稿された情報にこうした壁ができるのは本当にうんざりします
    • 静かな部分をあえて大きな声で言うなら、これが憂うつな最大の理由の一つは、単なる破壊ではなく、関係する悪者たちに複利で利益が積み上がる破壊だからです。コンテンツをスクレイピングするのは始まりにすぎません
      コスト増でサイトが永遠に落ちる？ すばらしい、人々はあらゆる文書にAIを使わざるを得なくなるからです。CAPTCHAから後退してクレジットカードや電話番号を入れさせる？ すばらしい、インターネットの匿名性がその分減るからです
      データ漏えいで詐欺が増える？ すばらしい、それを防ぐにはAIが必要になるでしょうから。悪意ある行為者にとっては、ほとんど全員が勝つ盤面です
      インターネットのバルカン化は昔から議論されてきました。そうした脅威や、すでに制御不能なゴミ捨て場であるという事実が、状況をさらに悪化させることに多少の慎重さを生むようにも思えますが、人々が耐えられる嫌がらせや摩擦の限界を押し広げることなど、結局は重要ではありません。実質的な選択肢がないからです
    • よく分かりません。小さなブラウザゲームを運営していますが、サーバーはLLMスクレイパーに定期的に完全に叩きのめされている一方で、ボットが作ったように見える新規アカウントはまだ一つも見ていません
      新規登録率も目立って変わっていません。ゲームでもWikiでも同じで、スクレイピングトラフィックの大半はWikiに集中しています。スクレイピングが減らなければ、Wikiはほぼ完全な認証壁の内側に置く必要が出てくる可能性が高いです
    • 次のX件のリクエストを行うには、これだけのトークンを処理しなければならない、という形にできるかもしれません。もちろん、かなりユートピア的に聞こえはします
    • 必ずしも認証壁の向こう側に置く必要はありません。各リクエストごとに匿名のマイクロペイメントサービスを使うことも十分可能です
      訪問者が多すぎることがWebサイトの存立危機になるインターネットだとすれば、私たちが暮らすインターネットは長く生き残れる構造ではないということです

  • 以前、検索エンジンがこのようなことを引き起こしたとき、業界は法規制が作られるのを避けるために合意し、robots.txt仕様を作りました。そのため法的枠組みは作られませんでした
    今はその合意に参加していない新世代の飢えたインデクサーたちがいて、競争圧力のために可能な限り多くのデータをかき集めようとし、robots.txtをただ無視しています
    いずれにせよ立法は行われるべきでしたし、robots.txtを無視する側はブロック、罰金、レート制限などを受けるべきでした

    • この計画が気に入るかどうかは分かりません。違法AIが合法AIより多くの知識と有用性を持つようにしてはいけません
      全面禁止以外にも選択肢はあります
    • 米下院や議会の議員の中に、robots.txtが何かを知っている人が一人でもいたら驚くと思います
    • 米国やEUの法律で、中国、タイ、ロシアから来るトラフィックをどうやって止められるのでしょうか。せいぜいインターネットを断片化するだけで、それは「最善」でもなければ、ひどい考えです

  • 私も最近攻撃を受けました [0]。複数のオープンソースパッケージのコードを置いている小さなForgejoインスタンスなので公開されている必要があるのですが、完全に壊され、生成されたZIPアーカイブでディスクがいっぱいになりました
    同じことを経験したのは私だけではありません。私の場合、Alibaba CloudのIPレンジをブロックしたところ、攻撃はいったん収まりました
    Forgejoインスタンスを運用しているなら、DISABLE_DOWNLOAD_SOURCE_ARCHIVESをtrueに設定することを強く勧めます。クローラーはなおCPUに食らいつき続けるでしょうが、少なくともディスクがZIPファイルでいっぱいになることはありません
    [0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

    • 「生成されたZIPアーカイブでディスクがいっぱいになった」というのは、つまりオンデマンドでZIPファイルを作る悪いソフトウェア設計です
    • むしろ、公開インターネットでサービスされるよう適切に設計された、よくできたソフトウェアに替えたほうがよいかもしれません
      ZIPファイルを生成し、丸ごとディスクに書き出してから、一度にクライアントへ送る設計は完全にひどく、使いものにならない方式です。適切な設計なら、メモリを最小限しか使わず、ディスクをまったく使わずに、段階的に生成してクライアントへ転送するべきです
      こんなばかげた設計があるということは、開発者たちが効率性をほとんど無視していたという兆候であり、同様の致命的な問題が大量にある可能性が高いです
      例えばForgejoのソースコードをざっと見ると、すべてのGit操作に専用ライブラリを使う代わりに「git」プロセスを起動しているように見えます。確認はしていませんが、そうした操作がその処理を実行する最も効率的な方法から非常にかけ離れていても驚きません
      これほど極端に粗末なソフトウェアを動かせば、CPUが100%に張り付き、サーバーが使えなくなるのも驚きではありません

  • ここでの大きな結論は、Googleと広告全般のウェブ支配力が失われつつあるということ
    ボットを防ぐ唯一の方法はCAPTCHAだが、そうすると検索インデクサーもサイトをインデックスできなくなる。結局、検索エンジンがサイトをインデックスできず、もはや価値を提供できなくなる
    現在LLMに入っている知識が枯渇するまでには少しタイムラグがあるだろうが、もはや誰も自動化された方法でウェブをスクレイピングできなくなるだろう
    すべて燃え尽きそうだ

    • 実際には、オオカミとウサギの個体群のようなリャプノフ安定性になるのだと思う。このシナリオで私たちはウサギだ
      AIの個体数が減ると人間のコンテンツが増え、それがAIにとってより多くの餌となり、AIが再び増える。すると人間の表現が埋もれ、人間はより静かになる。AIの餌が減ってAIが減少すると、ノイズが減り、人間が再び大きくなる。この循環がうんざりするほど繰り返される
    • 個人的には、これがWeb Environment Integrityの本当の動機の一つだったと見ている。Googleにはインデックスできるようにし、他のところにはできないようにするということだ
      私たちは厄介な二者択一に挟まれている。固定化された既存の強者を望むのか、それとも安価でオープンなホスティングを望むのか？
    • Googleはすでにサイトをスクレイピングして、検索結果に直接答えを表示している。トラフィックを重視し、広告枠を売りたいなら、今なぜGoogleに自分のサイトをインデックスしてもらいたいと思うべきなのか？
      広告ベースのサイトのかなりの数は暗くなるだろう。訪問者はボットだけになるはずだから
    • 認証ベースのクロールへ移行しなければならないなら、既存の検索エンジンの立場はさらに強まるだろう。招待されたクローラーだけがアクセスできるようになるためだ
      簡単なツールがあれば、大半はGoogle、Bing、そして多くてもあと一、二か所だけを許可するだろう
    • 最高のCAPTCHA回避技術を持つAI企業が勝ち、より巧妙な方法でLLMの出力に広告を挿入するだろう

  • ちょっとした妨害工作に興味がある人がいるなら、私のマイクロブログの本物の情報をある程度「溺れさせる」ことには成功したようだ
    LLaMaで実際の投稿1本につき数十本の矛盾する投稿を作り、人間がクリックしないよう見えない形でリンクした。いわばBannon流にゴミで区域を氾濫させるということだ

    • こういうアプローチが使われているのを見たことはあるが、成功率はよく分からない。論理的にはもっともらしい
      人間が実際には見られないパスを明示的に参照し、そのパスを叩くトラフィックはボットと見なす。ボットたちは我慢できない
    • その通り。ただしrobots.txtに必ず追加して、悪いロボットだけが被害を受けるようにすべきだ
    • 昨日これを読んで、より大きな規模で緩和する方法を考えてみた。ウェブサイトがランダムな仮想パスやエンドポイントを作り、ボットをローカルで提供されるLibrary of Babel[0]へ誘導し、役に立たないテキストでスパイダーを汚染する方式だ
      ボットがスクレイピングしたい正確なエンドポイントを知っている、よく構造化されたサイトには効かないだろうが、より探索的なスパイダースレッドは遅らせられるかもしれない
      [0] https://libraryofbabel.info/
    • ゴミで氾濫させるのではなく、ZIP爆弾のようなものを提供したり、計算資源を浪費させたりするような直接的な妨害工作はどうだろう？

  • VideoLANだ
    私たちも同じように、フォーラムとGitlabがAI企業のボットに叩かれている
    ほとんどはrobots.txtを守らない

    • これを解決するために取った対策を文書化した？

  • 狂った話だ。最終的には検索エンジンにインデックスされないウェブのバージョンへ向かうことになるのか気になる。90年代のブラウジングのように、ウェブサイト同士がリンクし合わないと知られない方式に近いウェブだ
    LLMスクレイピングへの解決策が、アクセスを許可する前にブラウザに作業証明をさせることだという点が気に入っている。新しいサイトがこういうものを導入し始めるのか気になる
    そうなれば検索エンジンにはインデックスされないが、知的財産権を守る助けにはなるだろう

  • 今まで考えたことはなかったが、LLM製品とクラウドコンピューティングサービスの両方を提供する企業が二重に収益を得るというのは狂っている
    売れるLLM製品を手に入れ、同時に増加した負荷の送信トラフィック費用とコンピューティング費用も受け取る。こう考えると、非効率なLLMスクレイピングを気にするインセンティブがどこにあるのか？ めちゃくちゃなままにしておくほど、別の帝国であるクラウドストレージの送信費用で稼げる構造だ