ボット遮断のために小さなツールを総動員する

 (lambdacreate.com)
4 ポイント 投稿者 GN⁺ 2025-06-02 | 1件のコメント | WhatsAppで共有
  • 大手AI/検索企業による無差別なクローリングとスクレイピングのせいで、個人サーバーやサービスが深刻な影響を受け、リソース消費とサービス不安定化が継続的に発生している
  • Zabbix・Lokiベースのモニタリングで異常トラフィックを検知した後、ログ分析ツール（lnav、goaccess）とSQLベースのクエリで攻撃者のパターン、IP、User Agentを詳細に把握
  • Nginx設定でUser Agentベースの403遮断、rate limit、Fail2Ban連携など段階的な防御体制を構築し、数百件の悪性IP遮断とサーバー安定化を実現
  • 主な問題はGiteaリポジトリ全体をtarballで大量ダウンロードしようとするボットであり、単なるコンテンツ消費者ではなく「AIデータ収集／モデル学習目的」のトラフィックが急増していた
  • 長期的には合法的なサービス（archive.orgなど）への例外処理と、検索エンジンでの露出は維持しつつAIのエンシットフィケーション（en-shitification）には対抗する戦略を検討している

序論: 私の小さなサーバーに降り注いだボットトラフィック

  • 最近、個人的に運営しているlambdacreateブログおよび複数のサービスに、正体不明の大量トラフィックが急増した
  • Archive.orgのような合法的サービスは歓迎するが、Amazon、Facebook、OpenAIなど大企業の無分別なデータクローリングがサイトに被害を与えている
  • AIモデル学習などによるデータ収集需要が高まるにつれ、この現象はさらに深刻になっている
  • この状況では本当の読者（人間）ではなく、主に大量のボットトラフィックに悩まされる

問題の確認: モニタリングツールによるトラフィック急増の診断

  • Zabbix、Lokiなどのモニタリングツールを使って、サーバー資源消費の状況を分析した
  • Giteaインスタンスで1日に20〜30GBに達するデータ増加が起き、各種CPU/メモリ警告が発生
  • nginxのトラフィック分析結果では、月間平均8req/sから瞬間的に20req/s以上まで急増した
  • トラフィック規模は巨大ではないが、平常時より10倍近く増加して資源枯渇を引き起こした

攻撃原因の分析: ログファイルの深掘り分析

  • lnavとgoaccessを使ってnginx accessログをSQLで分析した
    • 訪問者IP、User Agent、Referrerなどのパターンを把握
  • 結果として、特定サービスやコミュニティ由来の流入ではなく、特定IP帯からの大量クローリングが発生していた
  • User AgentにはAmazonbot、OpenAI、Applebot、Facebookなどを明示、または偽装した値が多数見つかった
  • これにより実際のサービス利用に支障が出たため、強力な遮断ポリシーの必要性が浮上した

解決策: Nginx、Fail2Banなど複数の防御レイヤーの組み合わせ適用

  • Nginx mapを使って悪性User Agentに即座に403を返し、rate limit（アクセス速度制限）を導入
  • 新規・未検知ボットに対してもWebリクエスト頻度を下げることで、サーバー負荷を最小化
  • 403発生ログをもとにgoaccess、lnavで新たな悪性IPとUser Agentを検知
  • 自動化セキュリティツールFail2Banにより、403応答が過剰に発生したIPを24時間自動遮断
    • 735件以上の自動BAN記録
  • 実際のリソース使用率はかなりの水準まで正常化した
  • 今後はarchive.orgなど正常サービス向けの例外ルールを適用し、検索エンジンのインデックスは許可しつつ、AI学習向けの無分別なクローリングは引き続き遮断する計画

結論: ツールの組み合わせの力と個人サービス防御の必要性

  • この一連の多層防御策を適用することで、個人ブログの円滑な運営とサービスのアクセス性を回復した
  • 多数の小さなシステム管理・自動化ツールの活用が、個人サーバー防御に効果的であることを確認した
  • 拡大するAI学習需要によって個人サーバーまで無分別にクローリングされる環境では、積極的な遮断と管理の自動化が不可欠である

関連記事

1件のコメント

 
GN⁺ 2025-06-02
Hacker Newsの意見

  • 悪質なクローラーの多くが大手検索エンジンを装っているのを頻繁に見かける。User-Agent を信じるべきではないという人もいるが、私が気に入っている方法のひとつは、robots.txt に怪しい情報（例: gzip bomb）を入れて、それを踏んだクローラーを次回のリクエストからブロックするように設定することだ。Caddy なら簡単に実装でき、こうすると主に深刻な違反者を捕まえられる。ボットの振る舞いを擁護するつもりはないが、こうしたボット数体でサイトが落ちるなら、悪意ある攻撃者に対して本当に脆弱なサイトだという証拠でもある

    • 最後のコメントが本当に核心を突いていると感じた。自分とは世代が違うのかもしれないが、最近文章を書く人たちがなぜそこまで少ないリソース消費に執着するのか理解できない。まるで祖父母が LED の明かりを消すことに大騒ぎしたり、燃料代を 5 セント節約するために 24km も運転したりするようなものだ。毎秒 20 リクエストなんて本当に大したことではない。たとえ動的生成だとしても（そもそもなぜ？ その時間でキャッシュ設定をしたほうがよほど得だ）、最近は "fuck the bots" みたいなスタイルの記事が流行っているとはいえ、これは別に新しい話題でもない。時間を無駄にせず処理できる、もっと生産的な方法はいくらでもある

    • robots.txt で gzip bomb を仕掛ける方法をもっと詳しく聞きたい。ほとんどの AI が robots.txt を無視すると思っているので、結局は一部のナイーブなクローラーしか引っかからないのではないかと気になる。誰かに反対したいわけではなく、善良な側に被害を出さずに実装する方法をもっと知りたいだけだ

    • 自分の分野で最大級のウィキのひとつを運営しているが、開発チームの他のメンバーを説得して gzip bomb を使わせるのはほぼ不可能だ。この方法はリスクが大きすぎる（EU 規制のせいだという発想）ので進める価値がないと頑なに言っている。実際の公開サイトで本当にこういう方法を使っているのか気になる

  • 最近はボットが robots.txt をまったく尊重しないので本当に腹が立つ。これを作った連中は本当に利己的だと思う。そんなボットを作った人間なら、もう好きにしろという気分だ

    • robots.txt に罠（ハニーポット）を仕込んでおけば、完全に無視する連中は引っかからなくても、わざわざ問題を起こしに来るボットをふるい分ける助けにはなる

    • チャットボット、検索エンジン、価格比較ツールのようなものを使っている人にも、同じことを言える。実際には、こうした利用者こそがスクレイパーを経済的に誘引している主因だ

  • 筆者が「もう気にしない」と言った点は理解できるが、禁止された IP に Google、ripe.net、semrush が入っているのを見た。他の企業はともかく、Google は本当にブロックしないほうがいいと思う。サイトを知られたいなら、Semrush や ripe.net もブロックする必要はないと思う。自分のコンテンツが AI や妙な連中にスクレイピングされるとしても、そもそもサイトを公開しているなら、ある程度は利用されることを覚悟すべきだ。たとえるなら、モーテルの看板の灯りを消しておいて客を呼ぶようなものだ

    • Semrush は長年にわたっていくつもの段階で本当にひどい迷惑をかけてきたので、この 8 年間 robots.txt に変わった案内文まで残していた。最終的には法務チームまで動かしてようやく大人しくさせた経験がある。私としても、「SEO」業者が実際の訪問者を押しのけながらサイトを乱暴にクロールするのを許す価値はない。Semrush の競合他社も同じようにひどかった。今の AI スクレイパーも質があまりに低く、大口投資家や PR 部門にまで正式な抗議文を繰り返し送らなければならなかったこともある。技術的にも法的にもさまざまな方法を使って、ようやく正常な状態に戻した

    • ボットが大量のトラフィック（帯域幅、メモリ、CPU、ディスク資源）を占有すること自体が実質的な問題だ。紹介文でも納得しがたいマナーだと触れられている。こうしたトラフィックをスクレイパーにわざわざ提供する必要はないと感じる。Google も AI スクレイパーを回しているので、おそらくそれがブロック一覧に入った理由ではないかと思う

    • Google を装う本物の悪質ボットも存在する。以前の Google は比較的行儀のよいスクレイピングをしていたが、筆者がブロックしようとしまいと、すでに必要なトラフィックを確保しているなら気にする理由はないだろう

    • この 10 年間、人々が Google を使うべきではないとまだ気づいていなかったのか不思議だ。特に Google が AI で独立系サイトを検閲するような状況まで出てきているし、関連コメントも直接リンクされている。今や Google は asset というより liability に近い存在だと思う

  • ボットのせいでサーバーログファイルが大きくなりすぎて、私のサーバーではついにロギング自体を無効にする事態になった。ボットは API、フォーム、さらにはサイト上でクリックでしか到達できない部分まで執拗に漁っていく。Anthropic、openAI、Facebook なども今なお私のサイトをスクレイピングしている

    • クリックでしか到達できない API の場合、ボットはどうやってアクセスしているのだろうか

    • その API についてもっと詳しく知りたい。UI の一部なのか、人間しか使えない部分を指すのか、それとも他の経路がまったくないのかをはっきりさせたい。最近では AI エージェントが実際のユーザー行動パターンを模倣するので、人間とボットを区別するのがほぼ不可能な時代だ

  • AI クローラーボットが User-Agent ヘッダーを正直に埋めてくれているのはよいことだと思っていたが、これほどトラフィックが多い原因がそれだというのは少し驚いた。ほとんどの Web サイトはそこまで頻繁にデータを必要としていないのに、トラフィックが多すぎる。開発者ブログならなおさら理解できない

    • AI クローラーの大半は robots.txt を順守するが、ブロックされたり遮断されたりすると、すぐにブラウザの User-Agent に切り替え、住宅用 IP から再クロールを試みた例もある。ただ、OpenAI/Amazon/Facebook を偽装するケースがあまりに多いので、正確な判別には慎重であるべきだ

  • tirreno の作者だ。私たちのプラットフォームはライブのログインユーザー向けに最適化されているが、ボットの検知とブロックにも効果的に使える。IP の最後のオクテットをアスタリスク（*）に置き換えて、同じサブネットをひとつのアカウントとして束ねることで IP を匿名化している。トラフィック異常（500/404 エラー、総当たりログイン試行、データセンター IP など）に対して自動ブラックリストを生成させることができる。tirreno のブラックリスト API を使えば、望ましくないトラフィックをエラーページへリダイレクトできる。監視ダッシュボードも提供しており、誤検知の防止と管理に役立つ
    tirreno Github, 管理者デモ

    • 最近は多くの ISP が CGNAT 構成に移行していて、ひとつの IP が数百人の実ユーザーを代表することもあるが、その問題をどう扱っているのか気になる

    • 公開された IP レンジをベースに同様のボットブロックも開発中だ。改善アイデアがあればいつでも歓迎する

    • IP の最後のオクテットを置き換える方式のせいで、実際の自分の情報とはまったく関係ないアドレスの近所と単一ユーザーとして束ねられてしまう。データセンター IP による誤検知も無視できない。実際、何もブロックされていないだけでも 87 個の信号機をクリックしてやっと通過できることがある。結局のところ、誤検知を回避する段階でも自分の個人情報を同意なく収集していないという建前のためのものに見える。顧客が実際に有料ユーザーを取り逃していることを即座に認識できるようなフィードバック構造は、ぜひ備えておいてほしい

  • 以前から気になっていたのだが、「ページノッキング（page knocking）」、つまり特定の順序でページを開くことでアクセス権を得る仕組みは可能ではないかと思っている。たとえば、指定された非公開 URL に先にアクセスしないと、他のページは 404 ではなく通常ページとして開けないようにする方式だ

    • そういうアーキテクチャは、一般ユーザーが検索エンジンでプロジェクトを見つけてアクセスできるようにしなければならないので、アカウント作成や別の認証なしにすぐ始められるケースには合わない

    • 使い勝手の面でも、どれだけうまく設計しても不便さは避けられない。ブックマークを使ったり友人にリンクを送ったりするたびに、404 ばかり出る不便さが予想される

  • 私の小さなサーバーは順調に動いていたので、最近は fail2ban の状態を見ていなかった
    コマンド実行結果の比較:

    sshd-ddos:      0
postfix:       583
dovecot:     9690
postfix-sasl: 4227
nginx-botsearch: 1421
nginx-http-auth: 0
postfix-botnet:  5425
sshd:         202157

22 万件を超える IP がブロックされている状況を見つけて少し衝撃を受けた

  • 私たちが追跡している DotBot/1.2 というボットは、ここ 2 週間で 22 万件を超えるリクエストを残している。Web サーバー上のファイル名やフォルダ名をランダムに要求するパターンだ。どこまで掘り進めるのか限界が気になって、興味本位であえてブロックせず観察している

  • AI や検索エンジン向けの中央集権的なインデックス構造も、そろそろプッシュや投稿方式に変えるべきではないかと考えている。自分が望むときだけ直接共有（プッシュ）する構造なら、スクレイピングの問題はかなり減るはずだ

  • 90 年代、私が子どものころ、ISP から電話が来て、自分のコンピューターがボットネットに組み込まれているのでインターネット接続を停止すると通知されたことがあった。あの時代に戻って、その行為を許している ISP の ASN 全体をブロックすれば、この問題も終わるのではないかと思う

    • 住宅用プロキシは ISP が直接提供しているのではなく、世界中の利用者が意図的に、あるいは知らないうちにマルウェアを入れて、自分のコンピューターをプロキシとして差し出していることで発生している。少し前に HN にこの件についてのよい記事が上がっていた

    • 自分のネットワークでは、特定のデバイスがマルウェアに関連したポートへアウトバウンド接続を試みるたびに警告を出すファイアウォールルールを設定している。ポート一覧はマルウェアの標的が絶えず変わるので定期的な更新が必要だ。ささやかな方法だが、これもまたひとつの防御層だ