Read the Docsに対する最近のDDoS攻撃の理解

ホーム / ブログ / エンジニアリング / Read the Docsに対する最近のDDoS攻撃の理解 Read the Docsに対する最近のDDoS攻撃の理解 2026年9月8日 タグ: ddos セキュリティ インフラストラクチャ パフォーマンス Cloudflare Terraform David Fischer 2026年6月の攻撃からの分析 2026年6月中旬から下旬にかけて、Read the Docsは当社の歴史上最大かつ最も洗練された分散型サービス拒否（DDoS）攻撃を受けました。ピーク時には、インフラストラクチャは毎分550万リクエスト以上、通常のベースライントラフィックの約100倍の攻撃を受けました。このインシデントはほぼ10日間続き、当社のインフラストラクチャ、エッジ防御、およびインシデント対応プロセスを試しました。過去に見た単純なトラフィックフラッドとは異なり、この攻撃はより分散化され、防御に迅速に適応し、キャッシュをバイパスするように意図的に領域を攻撃しました。当社の小規模なオペレーションチームが通常の睡眠時間に戻った今、この種の攻撃の解剖学、既存のレート制限がなぜ部分的にしか緩和できなかったのか、そして実際に（主に）攻撃全体を通して可用性を維持するのに役立った戦略について説明したいと思います。DDoS攻撃の進化 Read the Docsは歴史的に、当社がホストするドキュメントをスクレイピングするスパイダーやボットに対して非常に寛容であり、IPベースのレート制限はほとんどの悪用問題を解決していました。約2年前から、AIクローラーがより一般的になり、開発インフラストラクチャコミュニティの他のメンバーも同様の問題を経験しているように見えるにつれて、著しい増加が見られ始めました。AI生成スクレイパーをプロキシネットワークに接続することは容易になりました。当社の防御はそれに対応できましたが、6月の攻撃は、私たちが直面したことのあるどの攻撃よりも10倍以上大規模でした。この攻撃の主な特徴は以下の通りです：大規模なボリューム：ピーク時には、毎分550万リクエストを受け取りました。これは、通常の毎分10万リクエスト未満のピークと比較して大幅な増加です。グローバルな分散：数百万のユニークIPアドレスから、世界中の数百のネットワーク（ASN）にわたる悪意のあるリクエストを確認しました。これには、住宅用IPブロック、主要およびマイナーなホスティングプロバイダーが含まれていました。ヘッダーとTLSのランダム化：攻撃者は、シグネチャベースのフィルター（JA3/JA4）を回避するために、HTTPリクエストヘッダーとTLS接続パラメータを体系的にランダム化しました。自動CDN防御の限界：Read the DocsはCloudflareを使用しており、Cloudflareの自動DDoS保護は「既知のボットネット」と呼ばれる一部のトラフィックを緩和しましたが、攻撃の大部分は最初のチェックを通過し、レート制限とWAFルールに到達しました。キャッシュ回避：攻撃者は、キャッシュミスを引き起こすURL、特にユニークなパスを持つ存在しないページ（404）や一時的なリダイレクト（302）を発見し、意図的にそれらを標的にしました。適応的な行動：ブロックやレート制限を実装すると、ボットネットはリクエストレートを調整し、異なるターゲットパスをローテーションし、広範なIPプールにトラフィックを分散させて防御境界をプローブしました。規模と範囲 以前の小規模なDDoS攻撃や大規模な分散型スクレイパーは、通常、何らかの形で集中していました。リクエストは、少数の国、少数のIPブロック、または少数のブラウザ署名から発信されていました。この攻撃は真にグローバルでした。それはすべての国から同時に発生し、レート制限ルールがCloudflareの各コロに適用される場合には悪夢でした。単一のIPまたはサブネットから合理的なレートでスクレイピングしている正規のボットをヒットしないようにしながら、分散型攻撃を制限するルールを作成するのは困難です。一時的なリダイレクトに攻撃者が集中していたとき、ハードコードされたNginxリダイレクト（単純なリライト正規表現ディレクティブ）が、水平スケーリングされたインフラストラクチャでさえリクエストドロップを引き起こすほどのトラフィックで圧倒されました。そのようなNginxリダイレクトは、毎秒数千リクエストを容易に処理できます。世界中に分散するだけでなく、複数のRead the Docsプロパティも攻撃しました。公開コミュニティドキュメントだけでなく、商用ホストドキュメントも攻撃されました。また、ログインが必要な作者向けダッシュボードをダウンさせようとする攻撃も見られました。すべてのサイト訪問者（正規のものもそうでないものも）にJavaScriptチャレンジを与えるオプション（Cloudflareの「Under Attack Mode」）がありましたが、私たちはそうしたくありませんでした。これはすべてのAPI統合を壊し、何十万人もの実際のドキュメント読者に多くの摩擦を引き起こすでしょう。代わりに、レート制限とターゲットを絞ったチャレンジに、より多くのキャッシュとエッジへの機能プッシュを組み合わせて依存しました。「Cloudflareなしではこの攻撃に対処できなかったでしょう。」防御への適応 Read the Docsは、キャッシュとレート制限のためにCloudflareを多用しており、Cloudflareなしではこの攻撃に対処できなかったでしょう。IP、Read the Docsがホストする何千ものホスト名と何十万ものサブドメイン、ASN、ブラウザフィンガープリント、およびこれらの組み合わせに基づいてインフラストラクチャを保護するために、多数のレート制限ルール（Terraformで管理）があります。攻撃は少数のドメインで始まり、攻撃者はエッジでキャッシュされず、NginxのようなものではなくPythonバックエンドで提供される一時的なリダイレクト（302）を発見しました。数分以内に、オペレーションチームは短時間のダウンタイムのために呼び出され（キャッシュされたドキュメントが引き続き提供されるため、ユーザーは必ずしも当社のダウンタイムに気づくとは限りません）、約30分後にはこれらのリダイレクトをサーバーではなくCloudflareのエッジで提供されるように移行しました。これで終わりかと思いましたが、攻撃者はさらに1週間半の間、さまざまなホストやサービスで異なる戦術を試みました。攻撃中に変動する「ヨーヨー」トラフィックレベルを示す分析。攻撃者はレート制限のしきい値を発見するためにトラフィックを急増させ、その後レート制限ウィンドウが期限切れになるのを待つために後退しました。これはヨーヨーパターンと呼ばれ、自動スケーリングインフラストラクチャのコストを最大化し、断続的なサービス低下を引き起こすように設計されています。攻撃者は、レート制限を備えたWebアプリケーションファイアウォール（WAF）を実行していることを知っており、それにもかかわらず可能な限り多くの損害を与える方法を知っていました。ボリューム型DDoS攻撃に対する防御 毎分数百万リクエストのフラッドに対する防御には、エッジキャッシュ、Webアプリケーションファイアウォール、レート制限、ローカルキャッシュ、リクエストフィンガープリンティングを備えた多層防御アプローチが必要です。最も速いリクエストは、CDNまたはWebアプリケーションファイアウォールによって提供されるリクエストです。エッジキャッシュ 最初の防御線であり、私たちがすでに多用していたものです。適切なCDNを使用し、オリジンサーバーに到達するリクエストを可能な限り少なくすることです。CDNからドキュメントを提供することには多くの利点があります。Read the Docsでは、ドキュメントサイトは頻繁に変更されないため、かなり積極的にキャッシュしますが、Gitに新しいドキュメントがプッシュされて再ビルドされるたびに、特定のドキュメントサイトのキャッシュをパージします。CDNは、オリジンサーバーから地理的に離れている人々にとっても、ドキュメントの取得をはるかに速くします。しかし、防御をプローブしていた攻撃者は、CDNの応答速度によって、どのリクエストがキャッシュされ、どれがキャッシュされないかをすぐに発見しました。これは、キャッシュされないリクエストをいくつか見つけることが、攻撃者に攻撃の角度を与えることを意味します。まだキャッシュされないパスやエンドポイントをさらに発見していますが、リダイレクトと通常の200応答の両方に対して、非常に短命なキャッシュ応答（Cache-Controlヘッダーを使用）でさえ、この種の攻撃に役立ちます。Read the Docsが毎分45kのキャッシュされないリクエストを受けているときのSlack通知。キャッシュとレート制限なしでは、自動スケーリングインフラストラクチャは、当社の費用で負荷を処理するためにスケーリングアウトするだけです。レート制限とフィンガープリンティング すべてのユーザーにJavaScriptチャレンジを与えたくなかったので、ボット確率スコアとIPごとのレート制限を組み合わせたターゲットを絞ったレート制限ルールを使用して、疑わしいトラフィックにチャレンジを与え、正規のユーザーと適切に動作するボットは中断なく閲覧できるようにしました。JavaScriptチャレンジを解決したすべてのユーザーは…（原文はここで途切れています）