Read the Docsを襲った史上最大のDDoS攻撃、ピーク時は毎分550万リクエスト
Understanding the recent DDoS attack against Read the Docs
2026年6月、Read the Docsは史上最大かつ最も巧妙なDDoS攻撃を受け、ピーク時には毎分550万リクエスト、通常の約100倍のトラフィックが押し寄せた。攻撃は10日間近く続き、世界中の数百万のIPアドレスから、キャッシュを回避する404や302リダイレクトを狙い、防御に適応する「ヨーヨー」パターンで自動スケーリングのコストを増大させた。Cloudflareの自動DDoS保護をすり抜けた攻撃に対し、チームはエッジキャッシュ、レート制限、ボットスコアを組み合わせた「ペナルティボックス」ルールで対抗。IPブロックの限界、積極的なキャッシュ、TerraformによるInfrastructure as Codeの重要性を浮き彫りにした。
攻撃者はレート制限のしきい値を見つけるためにトラフィックを増やし、その後レート制限ウィンドウを期限切れにさせるために引き下がった。これはヨーヨーパターンと呼ばれ、自動スケーリングインフラの金銭的コストを最大化し、断続的なサービス低下を引き起こすように設計されている。
HNでの議論
59- PinkSheep
> 彼らはハードコードされたNginxリダイレクト（単純なrewrite正規表現ディレクティブ）を圧倒していた
1. ngx_http_rewrite_moduleがどれだけ最適化されているのか気になる。パターンをプリコンパイルするのだろうか？LLMは「はい」と言ったが、このSOの回答[1]ではJIT設定オプションをオンにする必要があると述べている。設定自体が静的である場合、「Just in Time」は私の定義ではプリコンパイルとは言えない。
2. NGINXのドキュメントを見ると、これらのルールを書く際にはいくつかの落とし穴があるように思える。例えば、手動でリライトを短絡させて早期に終了させる必要がある？
3. 正規表現の注意点は、壊滅的なバックトラッキングを引き起こす正規表現が単純に見えることだ。この問題はもっと議論されるべきだと思う。まだ聞いたことがないなら、リンクを見てほしい。
[1] https://stackoverflow.com/questions/59284921/how-much-impact...
[3.1] https://joshua.hu/nginx-directives-regex-redos-denial-of-ser...
[3.2] https://en.wikipedia.org/wiki/ReDoS
[3.3] https://infrafolks.com/blog/regex-backtracking-devops/
[3.4] https://www.regular-expressions.info/catastrophic.html
- PinkSheep
この攻撃を緩和するためにチームが受けたストレスには申し訳なく思う。しかし、攻撃側に能力の片鱗が見えると、いつもわくわくする。L7での標的型アプリケーション固有の適応型攻撃？すごい！
もう一つの推測：注意をそらして他の侵入試みを隠すためのDDoS。
> 防御はIPだけでなく、より広範なレート制限（ASN、ホスト名など）を持つ必要がある。
説明/アプローチは静的で限定的に見える？なぜ、各リクエストをカウントするリーキーバケットを維持しないのか（チケット/ポイント）、高コストのリクエスト（404、リダイレクト）にはより高いコストを課す。IPの評判が悪化するにつれて（IPv4/32）、より広いサブネット（IPv4/31、次に/30など）に溢れ始める。適応性で適応性と戦う。// 多分私は全く当たり前のことを言っているのかもしれない。私はWeb DDoS保護側には関わっていない。
> 攻撃者はキャッシュ不可能なパス（動的リダイレクト、検索エンドポイント、404など）を積極的に探す。
前の点を続けると、個々のサーバーのリソース（メモリ、ソケット制限）が許す限り、リクエストを処理する前にストールさせる。評判の低いIPはより長くストールされ、キューを超えたリクエストはドロップされる。アイデアはグレースフルデグラデーション：
評判の良いIPはsleep()でストールしない。評判の悪いIPはストールされるが、最終的には429/403ではなく回答を受け取る（つまり、一度に多くのタブを開いたユーザー）。悪い評判のIPは、完全にブロックされる前に待ち時間+レート制限（キュー超過）によって遅延させられる […]
- Animats
もっと法的な対応が見たい。
まず、数百のIPアドレスの向こう側に誰がいるのかを突き止める。米国にあるものから始める。損害賠償を求めて訴訟を起こす。ディスカバリーを使って向こう側に何があるかを調べる。そのデバイスの製造元を訴える。それがアプライアンスやスマートTVであることが判明した場合、製造元に対する一つの訴訟に統合できる可能性がある。刑事過失、契約妨害、嫌がらせ、コンピュータ詐欺および濫用法違反…
攻撃をホストできることが知られている「スマートTV」の販売を禁止する差し止め命令を出すかもしれない。税関国境保護局に輸入品を押収させる。それで製造元は注目するだろう。
製造元のEULAは製造元の助けにはならない。なぜなら、原告、つまり攻撃を受けている当事者はEULAの当事者ではないからだ。
- fn-mote
Cloudflareの「Under Attack」モードをオンにすれば攻撃が緩和されるという前提がある。
攻撃の他の部分がどれほど適応的であったかを考えると、それがその障害にどうアプローチするのか非常に興味がある。
- bijowo1676
これはAI主導の攻撃で、readthedocsは単なるテストターゲットだったのかもしれない。
驚いたのは、Cloudflareの防御を回避するのがいかに簡単だったかだ。CFを回避するのが簡単なのは知っていたが、L7 DDoSのブロックに関してはCFがもっとうまくやると思っていた。
CFはL4 DDoSの防御は本当に優れているが、L7はそうでもない。
つまり、世界中の何千ものエージェントによって駆動されるエージェント型DDoSの時代において、Cloudflareは実際にはあまり役に立たないということだ。