AIスクレイパー攻撃で維持が難しくなるオープンウェブ
(lwn.net)- 大規模言語モデルなどの学習データを収集するウェブスクレイピング攻撃が1年以上増え続け、独立系ウェブサイトはオープン性を維持するのが難しいほどトラフィック負荷が高まっている
- 攻撃者は数百万台の一般・モバイル端末で構成された住宅用プロキシを使い、各IPから数回だけリクエストし、user-agentを偽装することで従来のIPブロックを無力化している
- マルウェア、脆弱なメディアストリーミング機器、無料VPN、アプリSDKがプロキシ網を構成しており、GoogleによるIPIDEA・NetNutの解体後に攻撃量が一時的に減ったものの再び増加した前例がある
- サイト側はAnubisのプルーフ・オブ・ワーク、CAPTCHA、ログイン・有料ウォール、データ汚染ツールで対抗しているが、LWNは実際の読者や検索エンジン・Internet Archiveを妨げないようサイト最適化と攻撃中のコスト抑制に注力している
- スクレイパー防御とユーザー検証のコストがウェブ全体に転嫁されるなか、持続可能な解決策が出なければ、独立系サイトが防御壁の内側へ移り、オープンインターネットが損なわれるおそれがある
拡大し続けるスクレイパー攻撃
- 2025年初頭に取り上げた大規模言語モデルおよび関連プロジェクトの学習データ収集問題は、1年以上経った今も悪化している
- 正体不明の主体がウェブサイトに送るリクエストは前例のない水準まで増え、過剰なトラフィックによってオープンウェブを維持することがますます難しくなっている
数百万IPを動員する住宅用プロキシ
- 攻撃では数時間にわたり数百万個のユニークIPアドレスから連携されたリクエストが送られ、各アドレスはサイトに2〜3回以下しかアクセスしない方式が取られている
- 攻撃者が制御するuser-agentなどの情報は虚偽であり、それぞれのリクエストをウェブブラウザを使う普通の人のアクセスのように偽装している
- ボットは通常、画像やCSSを取得しないため人間と見分ける手がかりはあるが、判別が終わる頃にはそのアドレスは再利用されないため、事後的なIPブロックは効果がない
- トラフィックは中央のコマンド・アンド・コントロールノードが指揮する家庭用・モバイルネットワークから主に発生する
- 一般的な端末にインストールされたソフトウェアが制御ノードの命令を受けてウェブページを取得し、データを再送する
- かなりの数は端末所有者の認識や同意なしに動作しており、このように利用されるシステムは住宅用プロキシと呼ばれる
犯罪型プロキシ網と感染機器
- あるタイプは、マルウェアで掌握したシステム上でスクレイパーを動かす犯罪型オペレーターである
- Googleは年初にIPIDEAボットネットワークの解体に乗り出し、その運用方式に関する情報を公開した
- IPIDEA停止時期とLWNのスクレイパートラフィックが大きく減少した時期は重なっている
- 数か月は比較的平穏だったが、その後攻撃は再び増加した
- 最近ではメディアストリーミング機器が悪質なスクレイピングソフトウェアの主要な運搬体であることが確認されている
- 一部の機器は供給段階から感染している
- 別の機器はセキュリティが脆弱なまま販売され、販売後に容易に乗っ取られる
無料VPNとアプリSDKを利用した商用プロキシ網
- 別のタイプは、ある程度合法的な事業者のように振る舞い、「倫理的に確保した」IPアドレスを販売している
- Bright Dataは、ウェブサイトのアクセス制御やトラフィック制限を回避する能力を宣伝する代表的な事業者である
- 「無料」VPNの利用者は、Bright Dataが自分の端末経由でトラフィックをルーティングすることを許可しなければならない
- このVPNを使うスマートフォンやその他の機器は、Bright Dataの住宅用プロキシ網の終端となり、ウェブサイト攻撃に動員される
- 同様の事業者は、アプリ開発者が製品に接続できるライブラリを提供し、利用者のネットワーク接続を引き渡す見返りとして開発者に報酬を支払うこともある
- ある事業者は自社SDKの広告をLWNに掲載できるか問い合わせたが、会話はすぐに終わった
- 運営者は「GDPR準拠」などを掲げて合法的な外観を作ろうとするところから、露骨に非倫理的なところまでさまざまだ
- こうしたプロキシ運営者は数百万台の機器が接続されたネットワーク資源にアクセスするコードを実行できるため、その権限がウェブスクレイピングにしか使われないと仮定することはできない
モデル企業とプロキシ網の利用者
- モデル開発を中核事業とする著名企業も、自らウェブをスクレイピングしている
- そうした企業に容易に帰属できるトラフィックは、user-agentに正体が明確に示されている
- 一般に
robots.txtのような制御手段に従う - 2003年に書かれた記事に至るまで、最近変更があったか確認するかのようにサイト全体を繰り返し収集する
- ただし数百万システムで支えきれないようなトラフィックを送ってくるわけではないため、最大の問題ではない
- 誰が費用を払い、住宅用プロキシ攻撃を実行しているのかは明確ではない
- 最先端のモデル企業がこれらのネットワークを使っている証拠は確認されていない
- それらの企業はモデルへのデータ供給方法や学習データの出所を公開しておらず、コンテンツ制作者や運用上の問題を懸念する人々を尊重しているようにも見えなかった
- 公開されているモデル1つごとに、外部から見えないモデルが多数存在する可能性がある
- 多くの企業が、AI競争で先行すれば莫大な企業価値を得られるという期待のもとで独自モデルを作っているかもしれない
- 各国の非公開の政府機関も独自モデルと学習データを確保しようとしている可能性がある
- 大規模な犯罪組織も独自モデルを求める可能性がある
- AIツールが兵器として認識されるなか、軍拡競争が進行しており、インターネット全体がその過程に巻き込まれている
オープンインターネットを守るための防御策
- ウェブサイト運営者は、実際の利用者への影響を最小限に抑えながら攻撃を防ぐために、さまざまな防御装置を導入している
- Anubisはアクセス者に**プルーフ・オブ・ワーク（proof of work）**を要求してスクレイパーを遮断し、広く利用されている
- 商用サービスは「人間であることを証明」するボタンを表示し、別のサイトでは信号機を含むマスの選択やパズル片の配置などのCAPTCHAを要求する
- 一部のサイトは主要機能をログインや有料ウォールの内側に移し、iocaineのようなツールでスクレイパーが受け取るデータを積極的に汚染している
- 防御装置を構築・維持するコストと、それを通過しなければならない利用者の不便は、スクレイパーとその費用負担者が世界中に課した重い負担である
LWNの防御方式と制約
- LWNは最近、これまでで最も強力なスクレイパー攻撃を受けたが、構築してきた防御策のおかげで、実際の読者の大半が気づかない程度にトラフィックに耐えた
- 具体的な防御手段を公開すると攻撃者に対応情報を与えることになるため非公開にしており、防御側でも軍拡競争が続いている
- 実際の読者への影響をできる限り減らすことを優先している
- Anubisはサイトアクセスを遅延させて読者の負担になるため使っていない
- スクレイパーはいずれAnubisを回避すると見られ、すでにその兆候もある
- 数百万台の他人の端末を動員できるなら、プルーフ・オブ・ワークは大きな障害にならない
- 正常な検索エンジンやInternet Archiveのような組織のアクセスも妨げたくないとしている
- 支配的な検索エンジンだけを明示的な許可リストに載せることは、すでにサービス品質に問題のある独占事業者の地位をさらに強化する
- LWNは現在まで、特定検索エンジン向けの許可リストなしで正常なアクセスを維持することに成功している
- サイトの一部を積極的に最適化し、攻撃中はコストの高い処理を最小化している
- 匿名読者は時折こうした措置の影響を受けることがあるが、ログイン利用者は影響を受けない
- 防御措置が有効化された攻撃状況では、平時より応答時間が速くなる場合もある
- 現在の措置を恒久的な解決策とは見ておらず、効果が失われたときに備えて次の対応を検討する必要がある
NetNut解体と一時的な平穏
- Googleは7月2日、米連邦捜査局（FBI）などと協力してNetNut住宅用プロキシ網を解体したと発表した
- この措置の後、スクレイパー攻撃の水準はいくらか下がったように見えるが、過去の経験からするとこの平穏は長続きしない可能性がある
- Google Play StoreはNetNutに感染したアプリを検査する予定である
- 主要なアプリストア事業者は、住宅用プロキシ機能を持つアプリがなぜこれほど容易に登録できるのかについて回答していない
防御壁の内側へ押し込まれるインターネット
- インターネット全体が防御壁の内側へ移動し、創造性を促してきたオープンなネットワークが消える前に、より持続的な解決策が必要である
- 攻撃を引き起こす産業は、独立系ウェブサイトのコンテンツを持ち去ったあとにサイトが破壊される状況を気にかけておらず、同じ態度は地球や経済にも向けられている
- 大規模言語モデルと関連技術を運用する企業に最低限の倫理基準が適用されるまで、この行動は続き、ウェブサイト運営者は自衛するしかない
1件のコメント
Lobste.rs のコメント
最近知った、あらゆる露骨に怪しいビジネスの中でも、レジデンシャルプロキシが最も衝撃的だった
https://spur.us/blog/smart-tv-apps-residential-proxy-sdks で詳しく読んだが、これが合法だとは信じがたい。ボットネットと同じ分類に入れて、合法化されたボットネットと呼ぶべきだ
もう一つの被害者はリンクチェッカーだ。サイトにリンク切れがあるか確認するのがかなり難しくなっている
時間があれば、コンテンツがまだ生きているか確認するのに Common Crawl プロジェクトを活用してみたい
結局、GitHub リポジトリの履歴一覧のようなコストの大きい処理はすべて認証の壁の後ろに隠され、それ以外は静的化されて CDN で配信されるようになるだろう
アプリケーションレベルでは、より多くのコンテンツを静的化し、データベースクエリを減らし、キャッシュを活用することが明らかに役立つ。長い間、性能を大きく心配しなくてもよいという贅沢を享受してきたが、これからは小さなサイトでももっと気を配る必要があり、どこでも Cloudflare の「ブラウザーを確認しています」を見るよりはずっとましだ
小さな VPS で、Apache がリクエストごとに別プロセスを fork する従来型の方式のために問題が起きたことがある。LAMP サーバーを触りながら育ったので Apache はなじみがあり使いやすいが、マシンを最も効率よく活用できるわけではなく、結局はその点のほうが重要だ。実証データはないが、Caddy のようなサーバーのほうが負荷にうまく耐えられそうなので、次にサーバーをアップグレードするときに移行するつもりだ
fail2ban も使ってみたが、規模が大きくなると適切に対応できなかった。最終的にはブログ記事にまとめたセキュリティルールで Cloudflare に処理させることにした。Cloudflare に長期的に依存するのは気が進まなかったが、記事の下のほうにある CPU 使用率グラフを見て考えを変えた
Git ホストに膨大なコストを発生させるにもかかわらず、意外なほど多くのホストが、リポジトリ内部まで深くクロールされないように
robots.txtを設定していない「サイトを防御するために取った対策について説明してほしいという要望があったが、明らかな理由から詳しく議論したくはない。このレベルでも軍拡競争が起きている」というくだりは胸が痛む
私もこの戦いではかなり成功しているが、コモンズの悲劇のため、使った非常に単純な対策を公開すると効果が落ちてしまう。本当に興味深いテーマで、独創的なアイデアもあるのでブログに書きたいが、そうできないのが残念だ