徹底解剖：Read the Docsが受けた最新DDoS攻撃の影響と対策

Read the Docsが最近直面したDDoS攻撃について、その詳細と現状をまとめました。詳細なレポートや攻撃の特性、エンジニアが知っておくべき防御の教訓については、公式の技術ブログにて詳しく解説されています。インフラを守るための重要な知見が含まれているので、ぜひ一読することをおすすめします。

ドキュメントサイトを攻撃するなんて一体誰の得になるのか、理由が気になって仕方ないんだけど。

ここで「Under Attack Mode（攻撃下モード）」が全く使われなかったのは興味深いね。APIを壊したくないのは分かるけど、API以外のアクセスに対して一時的にチャレンジを要求するだけでも、ユーザーに大きな影響を与えずに少しは緩和できたんじゃないかな？

もっと気になるのは、攻撃者がRead the Docsを叩いて何を得ようとしているのかってこと。ドキュメントのホスティングは静的でCDNキャッシュが効きやすいから、データベースに依存するサイトと違って、完全に、あるいはほとんど静的なサーバーをダウンさせるには相当なトラフィックが必要になるはず。もしかして、競合他社のトレーニングデータを阻止したい悪意あるAIラボの仕業かな？情報セキュリティの観点から見ても、これほど奇妙なケースは聞いたことがないよ。個人的には、AIラボがデータスクレイパーの設定を誤った（エージェントの動きが過激になりすぎた）結果、DDoSのように見えてしまったんじゃないかと推測してる。今のスクレイパーはみんな「エージェント的」で、自己修復機能まで持っているからね。（例として、YCの https://parse.bot を見てみて）

Cloudflareの観点から見ると、あまりに素朴だけど「三度目の正直で敵とみなす」ような考え方と、幼児レベルの素早いブロック、それに手動での承認プロセスを組み合わせるのがいいんじゃないかと思ってる。この問題をISPレベルで処理しないのには、何か金銭的な理由でもあるの？

Cloudflareの「Under Attack」モードをオンにすれば攻撃を緩和できるっていう前提があるみたいだね。でも、今回の攻撃がいかに適応的だったかを考えると、その対策に対して攻撃側がどう反応するか、かなり興味があるよ。

私たちが決断したことの一つは、リアルなユーザーには常に逃げ道を用意しておくということ。Read the Docsは、特定のIPやユーザーエージェントを完全にブロックやBANすることはめったにありません。その代わり、「最悪の場合」でもJavaScriptチャレンジを要求する程度で、一度クリアすればその後1日程度は再チャレンジされることはほとんどありません。

ついに、ユーザーを放置しない有能な対応が出てきたね。活動中かどうかに関わらず「2つの大陸ごとブラックホール（遮断）する」なんて無能な対策を見るのはもううんざりだよ。

やったぜ、無料の負荷テストだ！

法的な対応をもっと見てみたいね。まずは数百のIPアドレスの背後に誰がいるのかを特定する。米国内のものから始めて、損害賠償を求めて訴訟を起こすんだ。証拠開示手続き（ディスカバリー）を利用して、接続先が何なのか突き止めて、そのデバイスのメーカーを訴える。それが家電やスマートTVなら、メーカーを一括して提訴することも可能かもしれない。過失致死傷罪、不法な契約妨害、ハラスメント、コンピュータ詐欺・不正行為防止法違反…いっそのこと、攻撃の踏み台にされることが分かっている「スマートTV」の販売禁止の仮処分を求めるのもいい。税関で輸入を差し止めれば、メーカーも本腰を入れるだろう。メーカーのEULA（使用許諾契約）は、被害者である原告とは何の関係もないから、メーカーを助けることにはならないよ。

これはAIによる攻撃で、readthedocsは単なるテスト標的だった可能性があるね。驚いたのは、Cloudflareの防御を回避するのがいかに簡単だったかってこと。CFをかわすのが簡単だとは知っていたけど、L7レベルのDDoSをもう少しうまくブロックしてくれると期待していたんだけどな。CFはL4のDDoS防御には強いけど、L7はそうでもない。つまり、世界中の何千ものエージェントが駆動する「エージェント型DDoS」の時代において、Cloudflareはあまり役に立たないってことだよ。