インターネットはもはや安全な避難所ではない

 (brainbaking.com)
9 ポイント 投稿者 GN⁺ 2025-11-17 | 1件のコメント | WhatsAppで共有
  • 個人サーバーが AIスクレイピングボット の過剰なリクエストによってダウンする事例が発生
  • ログ分析の結果、Alibaba(US) Technology のシンガポールでホストされたIP帯域（47.79.*）から集中的なアクセス試行が確認された
  • Mozilla/5.0 形式の 偽装されたUser-Agent により、一般的なボット検知システムが無力化された
  • Fail2banとNginxの 自動ブロックシステム が過負荷に陥り、手動でIP帯域全体をブロックする措置が必要になった
  • 個人サーバー運営者が繰り返される攻撃によって セルフホスティング環境が縮小 し、中央集権型プラットフォームへ追いやられている現実

サーバーダウンの原因と初期対応

  • 数日前、サイトをホストしていた 小規模サーバーがスクレイピングボット攻撃 により一時停止した
    • 過去にも同様の攻撃があり、Anubis のような強力な防御ツールの導入を検討中
    • 繰り返される攻撃により、個人開発者の 創作意欲と趣味としての楽しさが減退
  • サーバー接続の遅延後に top コマンドで確認した結果、GiteaとFail2ban がCPUをほぼ使い切っていた
    • Giteaプロセスを終了してもFail2banの負荷は下がらず、Nginxのアクセスログが暴走 した状態だった

ログ分析と攻撃パターン

  • ログには /commit/ パスを対象にした多数の HTTP 502リクエスト が記録されていた
    • リクエストヘッダーには Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) など、通常のブラウザに偽装したUser-Agent が使われていた
    • ほとんどのUser-Agent検査ツールがこれを正常トラフィックと認識し、検知を回避 された
  • 攻撃IPは 単一の発信元ではなく複数のアドレス から発生していたが、共通して 47.79.* 帯域を使用していた
    • ipinfo.io の照会結果では、当該帯域は Alibaba(US) Technology Co., Ltd. の所有
    • PhpBBフォーラムなどでも、同じIP帯域による 攻撃事例の報告 が存在する

防御措置と限界

  • Fail2banがNginxログをリアルタイム分析してブロックルールを適用していたが、ログの急増で処理が遅延 した
    • /commit/ へのアクセスを試みるIPを即座にブロックするスクリプトを実行したが、速度面の限界があった
    • 最終的に iptables コマンドで 47.79.0.0/16 の帯域全体を 手動でブロック した
  • こうした対応は あくまで一時しのぎ にすぎず、新たなIP帯域からの攻撃が続く可能性がある
    • Cloudflareのような 外部保護サービス や Anubis のような高度な防御体制の導入を検討中
    • しかし、追跡機能のある米国サーバー経由 を望まないため、導入をためらっている状況

個人サーバー運営の難しさ

  • Giteaインスタンスを Codebergへ移行 する案を検討中
    • 個人サーバー運営者が繰り返される攻撃により セルフホスティングを断念 し、中央集権型プラットフォームへ移る傾向がある
    • こうした流れが インターネットの分散性と自律性の弱体化 につながっている
  • 他のブロガーたちも同様の攻撃被害を報告しており、小規模Web運営者全体の問題 として広がっている

そのほか観測された異常トラフィック

  • bioware.com, mcdonalds.com, microsoft.com など、大企業ドメインを参照する偽装Refererヘッダー が見つかった
    • 実際にはそれらのサイトがリンクを提供していたわけではなく、目的不明 のトラフィック増加現象だった
  • 攻撃が繰り返されても セルフホスティングを諦めない意思 を表明
    • 記事の最後では「Get Hostin’ Or Die Tryin’」という文句で、自律的なサーバー運営を続ける意思 を強調している

関連記事

1件のコメント

 
GN⁺ 2025-11-17
Hacker Newsの意見

  • インターネットはもはやソフトウェア趣味開発者たちの安全な場所ではなくなったように感じる
    2005年ごろから自分でサーバーを運用してきたが、サーバーがオンラインになる瞬間から常に攻撃を受けていた
    特にDNS名を付けたりTLS証明書を使ったりすると、証明書透明性ログに露出して攻撃がさらに激しくなるようだ
    Webサイトを公開すると悪性トラフィックが殺到し、特定の組織を怒らせると誰かを雇ってDDoSを試みているように見える
    クローラー、ボットネット、自動化された攻撃、怒った人たちまで、毎年経験することだ
    いくつものホスティング事業者を使ってみたが、結果は似たようなものだった

    • 昔は自分が作ったお粗末なPHPゲストブックが数日でXSSスパムサイトに変わった
      WordPressを更新しなかったら数時間でSEOスパムに感染し、Redisを誤って外部に公開したらボットネットRATがインストールされた
      でも、こうした出来事がインターネットが「危険だ」という意味だとは思わない
      むしろ自分が学ぶべき点を教えてくれた経験だった
      その後は証明書ログに出ないようstar-certを使い、Basic認証を追加し、バックアップを維持し、慎重に運用している
      本当に危険なのは、技術を知らない人が適当なexeを何でもインストールし、FacebookやTikTokにあらゆる情報を渡してしまう行為だと思う
    • 自分も個人ドメインを運用しているが、自分以外は誰も訪れないにもかかわらずボット攻撃が絶えない
      ほとんどがWordPressの脆弱性を狙うリクエストだが、WordPressを使ったことすらない
      初めてログを見たときは衝撃だったが、今では単なる日常業務として受け止めている
    • 攻撃者をからかうために「HTTP Adventure」というものを作って、有名な管理者アドレスに設置してある
      例: https://www.masswerk.at/wp-admin
    • 2008年ごろ、PageRank 6のビジネスサイトを運営していたが、そのころからScript Kiddiesの攻撃が爆発的に増えた
      IP帯域をスキャンして脆弱性を自動で探すツールが広まり始めた時期だった
      1995〜2008年のWeb、Web RingsやTechnorati、ファンサイトがあった時代が懐かしい
      参考: Script Kiddie Wiki
    • 「常に攻撃されていた」という表現より、実際にはトラフィックが**「収益化(monetised)」**されたと見るほうが正しいのかもしれない

  • 以前はzipbombを使ってボットを防いでいて、効果があった
    だがその内容をHNに投稿した後、新しいボットが押し寄せて6ドルのサーバーでは耐えられなかった
    1日10万リクエストに対して1〜10MBのペイロードを提供するのは不可能だった
    その後は特定のボットだけを対象にし、honeypotを作ってIPを収集し、403を返すようにした
    数か月たつとトラフィックは正常な水準に戻った

    • こうしたボット遮断技術には市場性がありそうだ
      ただし、ターゲット顧客が誰になるのかは分からない。ほとんどのセルフホスティング利用者はそれほどお金を持っていない

  • 自分のcgitサーバーにも1年間ずっとスクレイパーがアクセスし続けている
    ただし1分あたり2〜3回のリクエストで、かなり「礼儀正しい」ボットだ
    面白いのは、自分が上げているコードは全部upstreamからそのままcloneできるのに、わざわざこんなふうに取得していることだ
    ログを見ると、本当に非効率な自動化だ

  • Nginxのrate-limiting機能を自分で設定すれば、Fail2banより簡単に解決できる
    参考ブログ: https://blog.nginx.org/blog/rate-limiting-nginx

  • ブログのような公開サービスには適用しにくいが、個人用のセルフホスティングならmTLS認証をreverse proxyに設定するのを勧める
    証明書のないリクエストは即座に遮断され、自分のデバイスだけがアクセスできる
    一度設定すれば、その後はほとんど気にすることがない

    • ただ、Wireguardのほうが良いと思う
      設定が簡単で、AndroidやiOSでもうまく動く
      今はすべてのセルフホスティングサービスをWireguard VPN内でのみアクセスできるよう構成し、ファイアウォールはWireguardポートだけを開けている
    • ただし、ブログのように他人もアクセスする必要があるサービスにはmTLSは現実的ではない

  • Anubisはボットとの「いたちごっこ」をうまくやっている
    だが、Cloudflareのように大規模なトラフィックデータを持つところだけがIPレピュテーションに基づく遮断をうまく行える
    小規模運用者はIP範囲を丸ごと遮断するしかなく、これは非効率だ
    Crowdsecのようにレピュテーションデータを共有して悪性IPを遮断し、JSなしの簡単なチャレンジを提供するソリューションが必要だ
    こうしたアプローチが可能なら、趣味開発者たちも再びサービスを運営しやすくなると思う

  • 自分のGiteaインスタンスも最近、分散したIPとASNを通じたスクレイピングを受けた
    資金力のあるAI企業相手なら、Anubisでも防ぎにくいだろう
    そこで「スクレイパー毒入れ(poisoning)」を検討している — コードの代わりにゴミデータを提供する方式だ

    • 最近は「倫理的に調達された(residential)」IPだと主張するプロキシサービスまで登場している
      こうしたサービスがスクレイピングをさらに難しくしている

  • 人気のあるものは結局、大衆の手に渡って壊される循環をたどる
    だから新しい領域へ移動し続けるのが唯一の解決策のように感じる

  • DNSをCloudflareへ移してから、奇妙なSYNパケットが入り続けている
    443や22番ポートに1秒ごとにリクエストが来るが、SYN-ACKの後に応答がない
    ほとんどはブラジルなどのVPSゲームサーバーホスティング事業者から来ているようだ
    そこでSYNパケットをキャプチャしてRDAPで照会し、その組織のサブネットを丸ごと遮断している
    Googleだけはホワイトリストに残している
    Digital Oceanは悪性トラフィックの主要な発生源の1つに見える

    • これはSYNACK反射攻撃の一種だ
      ネットワークスタックが再試行することで、被害者へトラフィックが増幅されて届く
    • おそらくMinecraftサーバーDDoSのようなゲーム関連攻撃である可能性が高い
      src IPを偽装することが多いので、rp_filterをstrictに設定してみることを勧める 
      net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
    • だが、ISPがユーザーの行為を検閲するのは危険だ
      電力会社が赤い電球の使用を禁止しないのと同じように、サービス提供者がトラフィックを統制するのは望ましくない

  • この文章に共感したのは、インターネットが安全だからではなく、こうした現実を記録している点だ
    自分もAlibaba /16やAWS全帯域を遮断している

    • IP範囲を直接遮断するより、ASN単位で遮断するほうが効率的だ
      毎日cronでRouteViewsデータを取得してiptablesに適用するスクリプトを使っている
      例示コード: 
      iptables -A BAD_AS -s $ROUTE -j DROP;
    • ちなみにAWSは2014年からIP範囲をJSONで公開している
      他のクラウドもこのように提供してほしい