AWSボットが月間20億件のリクエストを送るのをどう止められるか？

• AWSインフラ上で 予期しない 大量のWebリクエスト問題 が発生
• 月間 2億件から20億件 まで急増したトラフィック現象が報告される
• ログ分析の結果、特定のUser-Agent からの反復的なリクエストを確認
• AWSサポートに問い合わせたものの、明確な解決策 は得られていない状況
• ファイアウォールルールの設定、User-Agentの遮断など さまざまなブロック方法の検討が必要に

---

問題の紹介

• あるAWSユーザーが、Webサーバーで 2B（20億件）のリクエスト が1か月の間に発生した現象について問題提起した
• これらのリクエストは、特定の User-Agentを使うボット から発生しており、通常の利用パターンと一致しない異常トラフィックである
• 突発的なトラフィック増加は、コスト上昇とシステム負荷の問題 につながる危険がある

原因分析

• 膨大なリクエストの大半は、疑わしいAWSのIP帯域 から流入している
• アクセス記録を通じて、特定のボットまたはスクリプト が原因であることを把握した
• User-Agentに共通したパターンが存在するため、フィルタリング が可能である

既存の対応と限界

• AWSサポートチーム に問い合わせたが、決定的な対策は提供されなかった
• このような大量のリクエストは、サービス障害の誘発とコスト負担 の増大につながる可能性が高い

解決の方向性と検討事項

• ファイアウォールルールの追加、User-Agentベースのトラフィック遮断、IPブラックリスト適用など、さまざまな遮断ポリシーの必要性を検討している
• 長期的には、トラフィック監視システムの 強化 と異常アクセスの検知および自動遮断体制の構想が必要になっている

[GN⁺]

Hacker Newsの意見

• 30xリダイレクトを試したことがある。たとえば301レスポンスで、自分の嫌いな会社がホスティングしている非常に大きなファイルへ誘導する方法だ。もしその会社のAWSインスタンスに7万個のWindows ISOを同時ダウンロードさせたら、さすがに気づくだろう。また、Cloudflareでは簡単ではないが、いわゆる「タールピット」戦略も使える。リクエストを受けた後、レスポンスを1文字ずつ、各文字ごとに30秒遅らせて送信する方法だ。1リクエストあたり10KBのヘッダー/レスポンスで毎秒700リクエスト発生しているなら、サーバーがとてつもなく遅いように見えるだろう
  • 301リダイレクト先として、特定の会社が気に入らないならAmazonのようなところを指定する方法を勧める
  • リクエストを受けて1文字ずつゆっくり送る戦略は、Slow Loris DDoS攻撃のちょうど逆だと思う。Slow Loris攻撃の説明はCloudflareで参照できる。つまり、攻撃側が遅い接続を使うのではなく、防御側が遅い接続で対抗するわけだ
  • 代案として、.sgの公式政府サイトに301リダイレクトして現地の法執行機関に処理させる方法も考えられる
  • AWSのインバウンドトラフィックは無料なので、インスタンス所有者が莫大な量のデータを受け取っても、AWS側で追加料金は発生しない点を指摘したい
• 明らかに悪意あるボットを運用コストの面で苦しくさせるのも一つの方法だ。特にgzip bombのような手法は、ボットが脆弱なら効果があるが、単にレスポンス前に10秒ほど待つだけでもサーバー側で約7,000個のポートを消費させられる。たいていのLinuxプロセスはこれに耐えられず落ちる。nginx + mod-http-echoで簡単に実装できる
  • 実際にこの戦略をすでに実装した人たちがいる。オープンソースコードのuser agentリストを見れば分かるし、実装自体も非常に簡単だ。関連ソースはここで確認できる
  • AWSの顧客はアウトバウンドトラフィックに料金を払うが、逆に大容量トラフィックをAWSやCloudflare側からこちらへ送らせる方法も気になる
  • 似たような状況を経験した。うちのサイトの価格情報を抜き取ろうとする悪質なスクレイピングが繰り返され、カタログ商品が数百万件もあるため動的に価格を計算するのに膨大なリソースを消費した。突然のリクエスト爆撃でインフラが耐えられず、サービスが麻痺しかけたこともある。防御策としては、スパムトラフィックをタグで区別して実際の顧客に影響しないようキャッシュする方法を試し、さらに価格にランダムな誤差値を入れてデータ自体を無意味にする案も議論した。最終的にはCloudflareと協力して悪性リクエストを迅速に遮断する方向に落ち着いたが、時間も費用も重かった。攻撃者は競合他社の外注サービスと推定されたが、正式なAPIを提供できる状況だったにもかかわらず直接問い合わせてこない点が残念だった。以前はこうした問題に対して「トラフィックに耐えられないならサイトが悪い」という空気もあったが、最近は認識がかなり変わった気がする
  • そのやり方だと、自分のサーバーでも7,000個のポートが消費されるのではないかと気になる
  • その手法を使うと、自分のサーバーにも同じだけ大量の接続が張られるのではないかと質問している
• Anubisのメイン作者だ。CloudflareでHTTP 200レスポンスを返すよう設定すると、ボットは200を受け取るまで叩くのをやめると経験した
  • ちなみに今はメインサイトに問題があるようだ
  • アプリケーションレイヤーで検出したら接続自体を強制的に切る方法も試したが、Cloudflare側の設定が難しいときには原始的なボットには効くようだ
• 以前、自分の個人ブログで似たような状況に遭った。7〜8年前だったか、突然トラフィックが急増してバズったのかと思ったが、あまりに機械的でおかしいと感じた。原因を調べると、誰かのボット/クローラーがテスト目的で自分のサイトをクロールしていた。数か月にわたって何度も丁寧に止めてくれと頼んでも無駄だったので、結局リダイレクトでそのボットをランダムなポルノサイトへ送るようにしたらクロールが止まった
  • このやり方が実質的に最強だ。クローラーログに残したくない場所や、自分自身やサービス提供者、望まないコンテンツへリダイレクトしてみるといい
• 200レスポンスのボディにEICARテスト文字列を含めてデータ汚染を誘うのも、かなり胸がすく報復方法だ。EICARテストファイルの説明を参照
  • SSRF攻撃の逆の発想として、ボットをクラウドのメタデータAPIへリダイレクトし、<shutdown>のようなエンドポイントを呼ばせても面白そうだと考えた。リダイレクトレスポンスにEICARテスト文字列まで入れれば、自動セキュリティ検知システムも作動させられるだろう
• AWS Singaporeから正常トラフィックを受けることがまったくないなら、その帯域全体をブラックホール化する方法も代案だ
  • WAFを使ってそのパケットを丸ごとドロップする方法がある。Cloudflare WAFの"block"機能がこういう用途だ
  • 自分も以前これをやったことがある。Byte Danceが運営するByte Spiderボットが数百万件の画像をさらっていき、最終的にはCloudinary側にユーザーエージェントのブロックも依頼し、最初はSingapore全体のブロックもした。AIスクレイピング企業が本当に悪質な形でボットを運用していることに腹が立った。Cloudinaryのような良いサービスを使っていたおかげで多少コストを抑えられ、最近はCloudflareでAIボット全体をブロックするやり方で終わらせている
  • 参考までに、AWSの各リージョンごとのIP帯域はここで確認できる
• 2018年に似たことを、もっと小さい規模で経験したことがある。AWS公式IP帯域jsonリストを読み込み、Windows Firewallでその帯域を遮断するツールを自作した。関連ブログ記事はここで参照でき、ツールのreadmeはこちらで見られる。何年もサーバーのスケジュールタスクとしてうまく動いていたが、今でも動くかどうかは確信がない。もし興味があればコードを公開するか、ほかの人に引き渡すことも考えられる。自分で実装してもそれほど難しくないはずだ。幸運を祈る
• シンガポールの通信規制当局はポルノ自体の所持も禁じている。だから悪性ボットへの対抗としてソフトコアを送信し、同時に当局とAWSへメール通報する戦略を提案する
  • 誰かがインターネット上で繰り返し被害を与えてくるなら、その国の法律を利用して対処するのが最も効果的だ。ほかの機関ではたいてい何の対応も期待できない
• Cloudflareにそのトラフィックが悪意あるものだと知らせれば、アカウント外でブロックしてくれるので、こちら側のトラフィック集計に負担をかけずに処理できる
• 似た経験がある。80MBのソフトウェアインストーラーに対して莫大な数のリクエストが来ていたのだが、問題のリクエストをplease-stop.txtというファイルへリダイレクトし、そのファイルの中で状況を説明して止めてほしいと書いておいたところ、実際に止まった