皆様、AI Scraperの攻撃受けてますか～！
…このサーバは、受けてます。forgejoでのコードホスティングに対する、秒間60リクエスト程度の猛攻です。おかげ様で、
- forgejoの使用メモリは増えるわ、
- 常時100%にCPUが張り付くわ、
- gitの子プロセスが無限にfork-execされ続けるわ、
とさんざんな状況でした。IPアドレスを見るとどれもAlibaba Cloudだったのですが、無数のIPアドレスを使っているため1、IPアドレスのブロックは使えません2。伝統的なレートリミットで制限しようにも、同一IPアドレスはレートリミットには引っかからないような頻度でしか使われていないので効果は無さそうです。え？robots.txtですか？当然のように無視してブラウザのふりしてやってきますよ。
この状況を改善しないとforgejoをやめざるを得ないか、あるいは登録者以外にはそもそもアクセスできないようにnginxでアクセス制御するしかないかな…と思っていたところ、思い出しました。
Anubisです。
AnubisはProof of Workを定期的に解かせたり、その他にも諸々工夫することによって、人間にとっては大したことなくても、botには重すぎるリクエストにすることでbotから身を守るというシステムのようです。
Anubisの入れ方
意外と日本語での言及がなかったので書いておきます。環境はUbuntu Linuxでdocker compose, nginxです。nginx -> forgejoというリバースプロキシ構成だったのを、nginx -> Anubis -> forgejoの三段構成にします。
docker composeでAnubisを立ち上げる
compose.ymlに次のような設定を入れて、サービスを立てます：
anubis:
image: 'ghcr.io/techarohq/anubis:latest'
environment:
- 'BIND=:3000'
- 'SERVE_ROBOTS_TXT=true' #お好みで
- 'TARGET=http://<forgejoの内部ホスト名>:<forgejoのlistenポート>'
restart: unless-stopped
expose:
- '3000'
networks:
- code-link
- planet-link環境変数での設定方法は、詳しくはこちらを見てください。
nginxで接続先を切り替える
リバースプロキシの先をAnubisにするだけです。が、Caddyと使ってる場合forgejoの場合一工夫必要ですのでこちらをご覧くださいませ。弊サーバはnginxですので、とくに何もしていません。切り替えてるだけです。
反省点
「なんか重いな～」じゃなくて、さっさとログ見とけばよかった…。マシンが可哀そうになるくらいログが流れてました。まぁ管理が片手間だとどうしてもそうなる…。とりあえず、トラフィック代で気づくわけでは無かったので、そこは不幸中の幸いだったかな～と。
Webにおける情報の公開そのものについて
こんな辺鄙なところまでAI Scraperが来るとなると、いよいよ何を公開するのか、本当に公開するのか、そういったことについて考えていかないといけない…そんな時代が来てるのかもしれません。世知辛い。
とりあえず、著作をAIに使われて嫌な気分になってる人の気持ちはよ～～～～く分かりました。想像よりしんどかった。git blameなんて何に使うんだか知りませんけど（ある程度構造化されたトークン列でも欲しいのかな）、その辺も含めて正直薄気味が悪いです。
そして残るは虚無感
計算資源に対抗するためには…計算資源を使わせろ！
…電気をこれだけ無駄に使って、一体俺たちは何をやってんだろな