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

2026年6月中旬から下旬にかけて、Read the Docsは歴史上最大かつ最も巧妙な分散型サービス拒否（DDoS）攻撃を経験しました。ピーク時には、インフラストラクチャは毎分550万リクエストという、通常のベースライントラフィックの約100倍の攻撃を受けました。

このインシデントは10日間近く続き、私たちのインフラストラクチャ、エッジ防御、インシデント対応プロセスを試しました。過去に経験した単純なトラフィックフラッドとは異なり、この攻撃はより分散化されており、防御策に急速に適応し、キャッシュを回避する領域を意図的に攻撃しました。

小規模なオペレーションチームが通常の睡眠時間を回復した今、私たちはこの種の攻撃の解剖学、既存のレート制限がなぜ部分的にしか緩和できなかったのか、そして攻撃中に（ほぼ）可用性を維持するのに実際に役立った戦略について説明したいと思います。

DDoS攻撃の進化

Read the Docsは歴史的に、私たちがホストするドキュメントをスクレイピングするスパイダーやボットに対して非常に寛容であり、IPベースのレート制限でほとんどの不正利用問題を解決してきました。約2年前に始まり、AIクローラーがより一般的になり、開発インフラコミュニティの他のメンバーも同様の問題に直面しているようです。AI生成されたスクレイパーをプロキシネットワークに簡単に接続できるようになりました。私たちの防御策はそれらに比較的容易に適応しましたが、6月の攻撃は私たちが直面したことのあるものより10倍以上大規模でした。

この攻撃の主な特徴は以下の通りです。

• 大規模なボリューム: ピーク時には、通常の毎分10万リクエスト未満のデイリーピークと比較して、毎分550万リクエストを受け取りました。

• グローバルな分散: 世界中の数百のネットワーク（ASN）にわたる数百万の一意のIPアドレスから悪意のあるリクエストが発生しているのを確認しました。これには、住宅用IPブロックや、主要および小規模なホスティングプロバイダーが含まれていました。

• ヘッダーとTLSのランダム化: 攻撃者は、署名ベースのフィルター（JA3/JA4）を回避するために、HTTPリクエストヘッダーとTLS接続パラメータを体系的にランダム化しました。

• 自動化されたCDN防御の限界: Read the DocsはCloudflareを使用しており、Cloudflareの自動DDoS保護は「既知のボットネット」から発信された一部のトラフィックを緩和しましたが、攻撃の大部分は最初のチェックを通過し、レート制限とWAFルールに到達しました。

• キャッシュ回避: 攻撃者は、キャッシュミスを引き起こすURL、例えば存在しないページにユニークなパス（404）や一時的なリダイレクト（302）を意図的に標的にしました。

• 適応的な挙動: ブロックやレート制限を実装すると、ボットネットはリクエストレートを調整し、異なるターゲットパスをローテーションし、広範なIPプールにトラフィックを分散させて防御境界をプローブしました。

スケールと広がり

以前の軽微なDDoS攻撃や大規模な分散型スクレイパーは、通常、何らかの形で集中していました。リクエストは少数の国、少数のIPブロック、または少数のブラウザ署名から発信されていました。この攻撃は真にグローバルでした。それはすべての国から同時に発生し、Cloudflareの各コロ（colo）でレート制限ルールが適用される場合、悪夢でした。単一のIPまたはサブネットから合理的なレートでスクレイピングする正規のボットをヒットしないようにしながら、分散型攻撃を制限できるルールを作成するのは困難です。

攻撃者がリダイレクトに集中していたとき、ハードコードされたNginxリダイレクト（単純なrewrite正規表現ディレクショブ）を、水平スケーリングされたインフラストラクチャでもリクエストドロップを引き起こすほどのトラフィックで圧倒していました。そのようなNginxリダイレクトは、毎秒数千リクエストを簡単に処理できます。

世界中に分散するだけでなく、複数のRead the Docsプロパティも攻撃されました。公開コミュニティドキュメントも、商用でホストされているドキュメントも攻撃されました。また、ログインが必要な作成者向けのダッシュボードをダウンさせようとする攻撃者も見られました。

すべてのサイト訪問者（正規か否かを問わず）にJavaScriptチャレンジを与えるオプション（Cloudflareの「Under Attack Mode」）もありましたが、私たちはそれを望みませんでした。これは、すべてのAPI統合を壊し、何十万もの実際のドキュメント読者に多くの摩擦を引き起こすでしょう。代わりに、レート制限とターゲットを絞ったチャレンジを、より多くのキャッシュとエッジへの機能プッシュと組み合わせて利用しました。

防御策への適応

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通知］

Read the Docsが毎分45kのキャッシュされないリクエストを受けているときのSlack通知。キャッシュとレート制限がない場合、自動スケーリングインフラストラクチャは私たちの費用で負荷を処理するためにスケールアウトするだけです。

レート制限とフィンガープリンティング

すべてのユーザーにJavaScriptチャレンジを提供したくなかったので、私たちはターゲットを絞ったレート制限ルールを使用しました。これは、ボット確率スコアとIPごとのレート制限を組み合わせて、疑わしいトラフィックにチャレンジを行い、正規のユーザーや振る舞いの良いボットは中断なく閲覧できるようにしました。JavaScriptチャレンジを解決したことがある人なら誰でも、それが多くの摩擦を引き起こすことを知っています。私たちは、一部の悪意のあるトラフィックを通過させ、正規のユーザーにチャレンジしないことを優先することにしました。とはいえ、インフラストラクチャを保護するためにレート制限は依然として必要でした。

防御策は、リクエストがどこから来たか（IP、国）に焦点を当てるのではなく、リクエストがどのように見えるかに焦点を当てる必要があります。

• 暗号スイートとTLSの異常: 自動化されたスクレイパーやボットクライアントは、ブラウザとは異なる異常なTLS接続を頻繁に提示します。Cloudflareのボット検出には、これらを検出するための特定のツールがあります。

• 不正なリクエストが多すぎる: 正規のユーザーや良いボットは、ほぼ常に成功した（200）応答を受け取り、リダイレクトや404ではありません。200は常にキャッシュされるため、問題になることはほとんどありません。リダイレクトや404のような、よりコストのかかるリクエストが多すぎると見られる場合、ブラウザフィンガープリント、ASN、あるいはドメイン全体にレート制限を開始します。これらを「ペナルティボックス」と呼ぶルールを追加したことが、攻撃が変化するにつれて自動的に緩和する上で最も大きな違いを生んだ可能性があります。

• プロトコルの不整合: 悪意のあるツールは、古いHTTP/1.1接続を使用しながら、最新のUser-Agent文字列を宣言することがよくあります。残念ながら、この不整合は、完全にHTTP/2およびHTTP/3であったこの攻撃ではあまり役に立ちませんでした。

• クライアントフィンガープリンティング: 同じTLS暗号スイートを使用するGolang HTTPクライアントまたはPython requestsモジュールを使用するすべてのユーザーは、同じJA4フィンガープリントを持つことになります。このフィンガープリンティングは、ユーザーではなく、ブラウザまたはツールに固有です。攻撃者がTLSパラメータをランダム化していたため、これらのフィンガープリントもこの攻撃ではあまり役に立ちませんでした。

• IPブロックの分類: 私たちがまだ取り組んでいる分野の1つは、より多くのIPブロックを独自の制限を持つさまざまなカテゴリに分類することです。Read the Docsのような、多くの自動トラフィックを受け入れ、ボットを許可したいサービスにとって、Amazon、Google Cloud、Azureのような主要なクラウドASNから多くのトラフィックを受け取ることを知っています。それらは、ほとんどの住宅用または小規模なホスティングプロバイダーよりも高い制限を持つべきです。

ユーザーにエスケープハッチを提供する

私たちが下した決定の1つは、常に正規のユーザーにエスケープハッチを提供することです。Read the Docsは、特定のIPまたはユーザーエージェントを完全にブロックまたは禁止することは非常にまれです。代わりに、私たちの「最悪」はJavaScriptチャレンジであり、ユーザーがチャレンジを解決した場合、その後約1日間、再びチャレンジされる可能性は非常に低くなります。

学んだ教訓と重要なテイクアウェイ

2026年6月のDDoS攻撃は、高トラフィックインフラストラクチャの実行に関するいくつかの重要な教訓を強化しました。

• IPブロックは分散型攻撃には時代遅れ: ボットネットや大規模スクレイパーは、単純なIPブロックを無用にするプロキシサービスを使用します。私たちはすでにそれを知っていましたが、このインシデントはそれを強調しました。防御策は、IPだけでなく、より広範なレート制限（ASN、ホスト名など）を持つ必要があります。

• 積極的にキャッシュする: 単純な静的ファイル、404、または一時的なリダイレクトであっても、すべてをキャッシュします。数分という短いキャッシュウィンドウを設定するだけでも、これらのリソースが私たちのインフラストラクチャを攻撃するために使用されないことを保証します。CDNやほとんどのWebフレームワークのデフォルト設定は、Read the Docsのようなサービスが望むものではありません。

• キャッシュミスのサーフェスを保護する: 攻撃者は、キャッシュされないパス（例: 動的なリダイレクト、検索エンドポイント、404）を積極的に検索します。可能な限りキャッシュし、キャッシュが実現できない場合は、エッジで可能な限り多くを処理するようにします。

• ターゲットを絞ったチャレンジは、鈍器よりも優れている: ボット管理のヒューリスティクスとレート制限を組み合わせることで、正規のユーザーへの影響を最小限に抑えながら攻撃を緩和することができました。

• インフラストラクチャ・アズ・コードは不可欠: Terraformを介したエッジおよびWAFルールの管理により、複雑なフィルタリングルールを迅速かつ安全に見直し、テストし、バージョン管理し、展開することができました。

攻撃IPブロックからの低レベルのバックグラウンドトラフィックはまだ見られますが、私たちのインフラストラクチャは、攻撃前よりもはるかに強力な立場にあります。AIツールとプロキシネットワークがこのような攻撃をより安価でアクセスしやすくするにつれて、それらはもはや大規模なエンタープライズターゲットに限定されなくなっています。それらは、あらゆる注目度の高い公共サービスにとってのベースライン現実になりつつあります。私たちのオペレーションチームは完全な睡眠を取り戻しましたが、私たちはこれを、攻撃が過去のものになったというよりも、延長された猶予期間と見なしています。

---

詳細については、HackerNewsの投稿をご覧ください。