- 公開Giteaサーバー
git.xeserv.us が AmazonBotのリクエスト によって不安定になり、運営者はAmazonBotチームに当該ドメインをブロックリストへ追加するよう要請した
robots.txt で全ボットに Disallow: / を設定したもののリクエストは止まらず、公開Gitサーバーの運用 自体をやめざるを得ないかもしれない状況になった- AIクローラーはユーザーエージェントを変えたり、住宅用IPプロキシ を使ったりして、ブロックを困難にしている
- nginx ingressで
Amazon ユーザーエージェントに 418 を返すようブロックしたが、リクエストは別のIPから続き、約 10% には amazonbot ユーザーエージェントすらなかった
- 結局、Giteaサーバーは再びVPNの背後へ移され、リクエスト前に プルーフ・オブ・ワーク検査 を行うリバースプロキシ
Anubis が作られた
AmazonBotのリクエストとrobots.txtの限界
- 運営者はAmazonBotの運営者に、
git.xeserv.us を ブロック対象ドメイン一覧 に追加するよう依頼した
- Gitサーバーをクローリングするなら、過剰なリソース消費に耐えるための ハードウェア増強費用 を支払えるよう連絡してほしいとした
- すべてのボットを拒否する
robots.txt はすでに設定していたが、実際のリクエスト遮断には不十分だった
User-agent: *
Disallow: /
- AIクローラーボットのブロックが難しい理由もあわせて整理している
- ボットが嘘をつく
- ユーザーエージェントを変える
- 住宅用IPアドレスをプロキシとして使う
- そのほかの手段も使う
nginx ingressでの遮断とAnubis公開
- 2025-01-17 17:50 UTCにnginx ingressの設定で ユーザーエージェント遮断 を追加した
nginx.ingress.kubernetes.io/configuration-snippet: |
if ($http_user_agent ~* "(Amazon)" ){
return 418;
}
- この設定の後もボットは毎回異なるIPからリクエストを続け、約 10%のリクエスト には
amazonbot ユーザーエージェントがなかった
- 2025-01-18 19:00 UTCにGiteaサーバーを再び VPNの背後 へ移した
- その後、Giteaサーバーの前段でリクエストを許可する前に プルーフ・オブ・ワーク を検査するリバースプロキシの作成を開始した
- 2025-01-18 23:50 UTCにそのプロキシは
Anubis という名前で https://git.xeserv.us/ で確認できるようになった
- 2025-03-26 14:27 UTC時点で
Anubis はドキュメントサイトを持つ独立プロジェクトになっている
1件のコメント
Hacker Newsの意見
もう弁護士名義の書簡を送るべき時だ。Computer Fraud and Abuse Act の起訴指針を見ると、米司法省は通常、明白な攻撃ではない公開サーバーへのアクセスを「不正アクセス」とは見なさないが、その後、権限者が明確な書面による停止要請を送り、被告がそれを受領・理解した場合、その時点からは不正と見なす、とされている
だから弁護士に「明確な cease and desist」書簡を書いてもらい、弁護士が勧める方法で書留郵便や送達人を使って Amazon に届ければよい。おそらく両方やって、メールも送るべきだろう
その後 Amazon が止まるか見ればよく、止まらなければ刑事告訴できる。そうすれば Amazon も気にするはずだ
https://www.justice.gov/jm/jm-9-48000-computer-fraud
Amazon bot は既知の Amazon IP レンジから来るべきで、robots.txt を守るべきだ。Amazon のエンジニアも別コメントで確認している: https://news.ycombinator.com/item?id=42751729
Amazon と一致するのが「AmazonBot」というユーザーエージェント文字列だけで、IP レンジや挙動が一致しないなら、Amazon に弁護士書簡を送るのはお金を燃やすようなものだ
このコメントの解決策が気に入った: https://news.ycombinator.com/item?id=42727510
サイトのどこかに人間が訪れるはずのないリンクを置き、robots.txt で禁止したうえで、どこかの IP がそのリンクを訪れたら 24 時間ブロックする方式だ。OpenAI のクローラーは特にワイルドカードを無視するというので、ワイルドカードの下に置くようにする
しかし関連 IP が多すぎて、トラフィックにはほとんど影響がなかった
受信ヘッダーをかなり詳しく見ることを勧める。varnishlog はこういう用途にかなり良く、長く眺めていると全リクエストに共通する特徴を見つけられる。たとえば報告された言語と地理的位置の珍しい組み合わせ、同じ古いブラウザバージョンなどだ
さらに悪いことに、エラーハンドラーにバグがあり、この条件が発生するとサーバープロセスが再起動し、その過程で「.NET 2.0 基準ではかなりまともだった」キャッシュ実装まで無効化された
それで安全策としてカナリア手法を入れ始めたのを覚えている。単純なカナリアをいくつか置く方が、別の Web サーバーを追加するよりなお安かった。もちろんキャッシュの問題も直し、そのサービスに悪いリクエストが多くなりすぎると「悲鳴を上げる」仕組みも追加した
ところが当のそれらの会社のクローラーは、自分たちが作ったマニフェストをパースできていなかった
うちでもすべてのAI・SEO ボットで同じ挙動を見ているので勧める。robots.txt をかろうじて守る程度で、ブロックもしづらい。クロール時にはスパムのように押し寄せて負荷を大きく上げ、顧客企業のサーバーを大量に落とす
AI クローラーがアクセスしたいなら、お行儀よくするか金を払うべきだ。そうでなければ、ほぼ普遍的なブロックが結果になるだろう
/apiに秒あたり平均 X 回以上リクエストする IP に対して iptables で-j TARPITをかけていたクラウドではどう実装するのかよく分からない。まだそこで必要になったことはない
https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
あるいは最低限、礼儀として夜間や混雑していない時間帯にクロールしてほしい
これが本当に Amazon だとは仮定しない。投稿者は、住宅向け IP を使い回し、ユーザーエージェント文字列も変わるリクエストを見ている。
大企業のクローラーを装うのは、目立ちたくない人たちがよく使う手口だ。リクエストが住宅向け IP から来ているという事実は、別のことが起きているという大きな警告サインである。
社内で確認できた情報からすると、これが本物の Amazon である可能性は非常に低い。Amazonbot は robots.txt を守るべきであり、常に Amazon 所有の IP アドレスから来るべきだ。検証手順はこちらにある: https://developer.amazon.com/en/amazonbot
私の知らない変な社内チームがこういうことをしていないか確認するため社内に転送はしたが、投稿者はこのトラフィックを悪意あるものと見なし、ユーザーエージェントを偽っているものとして扱うのがよい。
[1] https://brightdata.com/proxy-types/residential-proxies
最近同じ問題を経験した。自分の Forgejo インスタンスがホームサーバーの CPU を**100%**使い始めたのだが、Claude と Meta・Google の AI 仲間たちが、実質的に無限のリンクを高速で叩いていた。
robots.txt と Caddy のユーザーエージェントベースのブロックリストである程度は減らせたが、これがどれくらい長く通用するかは分からない。
スクレイピングの礼儀はどこへ行ったのだろうか？
さらに大きなリスクは、こうした企業の一つ、しかも「Open」を名乗る企業でさえ、経済や国家安全保障の観点から「潰すに潰せない」規模になることだ。
Facebook は MySpace から友達リストをスクレイピングしやすくしていたことで有名で、自分たちが大きくなった後には、同じ行為を自分のサイトで禁止した。
いい加減に目を覚ますべきだ。
これが Amazon を装った DDoS ではないと確信できるのか？
リクエストが住宅向け IP から来ているというのは本当に怪しい。
こうした DDoS の動機は、小さなサイトを落として Amazon の責任に見せかけ、Amazon を標的にすることかもしれない。
本当に Amazon なら、出発点は彼らが公開しているすべての IP レンジをブロックすることだ。ただし、その範囲外からもリクエストが来ているように聞こえる。
こうしたサービスはユーザーの帯域幅に対して金を払い、それを第三者に転売するため、多くのボットトラフィックが住宅向け IPから来ているように見える。
自分のサイト Pinboard も、AI クローラーと思われるものに叩かれている。この夏は中国とシンガポールの IP から始まったが、今では IP レンジでのブロックもできず、CAPTCHA に頼らざるを得ない。
トラフィック量はサイトを即座に落とせるほどで、私のところには学習させるほど面白いテキストもなく、リンクだけだ。
元記事の著者が、どうやって Amazon クローラーが原因だと突き止めたのか気になる。私も責任を押しつける相手を見つけたい。
こういうものと戦う最善の方法は、ブロックではないかもしれない。ブロックしても Amazon や他社には何の被害も与えられない。
代わりに、ボットに明らかに有害または破壊的なコンテンツを食べさせられたらどうだろう？
より大規模に行われ、Amazon が毒入りデータを見つけたら、それを素早く除去するために金を使わざるを得ず、ボットがそうしたデータを食べないようにしようとするだろう。
もちろん、そういうものを自分のサイトに置きたい人はいない、というのが最大の問題だ。
これらのスクレイパーはすでに CSAM やそれに準じるひどいものも平然と食べている。OpenAI のケニアのデータタグ付け下請け業者の一部は、これが原因で辞めた。2023 年の Time 記事だ。
今の AI 企業はデータ品質に関心がなく、量だけを見ている。彼らに被害を与えられる唯一の方法は、0 バイトを渡すことだ。
Sam Altman が承認したことの 10 分の 1 だけでも、普通の人ならすぐに刑務所行きだろう。
https://zadzmo.org/code/nepenthes/
Amazon と他のボットが生み出した送信トラフィック超過分を補填する善意のしるしとして、AWS クレジットを少し提供してくれるとよい。とはいえ、この記事の広告収益でおそらく埋め合わせられるだろう。広告ブロックを解除すれば採算は合う。
Nginx でブロックする前は、Bytespider が 59%、Amazonbot が 21% で、2つを合わせると自分たちの Git サーバー全体のトラフィックの 80% を占めていた
ClaudeBot は1か月の間に Redmine へ、ClaudeBot 以前の5年間の合計よりも多くのトラフィックを送っていた