過去最大のDDoS攻撃、ピークで3億9,800万rpsに到達
(cloud.google.com)- DDoS攻撃の規模が急速に拡大するなか、Googleは2023年8月にピークで3億9,800万rpsの攻撃を緩和しており、前年の記録である4,600万rpsの7.5倍に達した
- 攻撃者はHTTP/2のストリーム多重化を悪用したRapid Reset手法を使用し、複数のインターネットインフラ企業が影響を受けた
- 攻撃の波は2023年8月末に始まり9月まで続き、Googleサービス、Google Cloudインフラ、顧客を含む主要なインフラプロバイダーが標的となった
- Googleはネットワークエッジで攻撃を吸収し、防御システムを更新した。Application Load BalancerとCloud Armorの顧客も同じ基盤による保護を受ける
- HTTP/2をサポートするサーバー、プロキシ、アプリケーションサーバー、ロードバランサーはCVE-2023-44487の影響を受ける可能性があり、脆弱性の有無の確認とベンダーパッチの適用が必要
攻撃規模とRapid Reset手法
- GoogleのDDoS Response Teamは、ここ数年でDDoS攻撃の規模が指数関数的に拡大している傾向を確認した
- 2023年8月にブロックされた攻撃は、前年の最大記録より7.5倍大きい規模だった
- ピークで**3億9,800万requests per second（rps）**に達した
- 2022年に記録された最大のDDoS攻撃は4,600万rpsだった
- 2分間続いたこの攻撃は、Wikipediaが2023年9月の1か月間に報告した全ページビュー数を上回るリクエストを生成した
- 中核となる手法は、HTTP/2のストリーム多重化機能を利用した新しいHTTP/2 Rapid Resetである
攻撃対象とサービスへの影響
- 最近の攻撃の波は2023年8月末に始まり、9月を通じて観測され続けた
- 攻撃対象には主要なインフラプロバイダーが含まれた
- Googleサービス
- Google Cloudインフラ
- Googleの顧客
- GoogleはグローバルロードバランシングとDDoS緩和インフラにより、サービスの運用を継続した
- 業界パートナーとの協力により攻撃メカニズムを把握し、Google、顧客、そしてインターネット全体を保護するための緩和策を調整した
Googleの緩和方法とCloud顧客の保護
- 調査の結果、攻撃は広く使われているHTTP/2プロトコルのストリーム多重化機能を利用したRapid Reset手法を使っていた
- Googleはネットワークエッジで攻撃を緩和した
- エッジ容量への投資を活用し、Googleサービスと顧客サービスが概ね影響を受けないようにした
- 攻撃手法をさらに把握したうえで緩和策を開発した
- プロキシとサービス拒否防御システムを更新し、この手法を効率的に抑制した
- Google CloudのApplication Load BalancerとCloud Armorは、Googleが自社のインターネット向けサービスを提供する際に使用しているものと同じハードウェア・ソフトウェアインフラを使用している
- これらのサービスを利用するCloud顧客のインターネット向けWebアプリとサービスも、同様の保護を受ける
CVE-2023-44487と業界共同対応
- Googleは8月の初期攻撃を検知した直後に追加の緩和戦略を適用し、HTTP/2プロトコルスタックを実装しているクラウドプロバイダーおよびソフトウェアメンテナーと業界共同対応を調整した
- 攻撃が進行する間、攻撃情報と緩和方法をリアルタイムで共有した
- この協業は、複数の大規模インフラプロバイダーが使用するパッチと緩和手法につながった
- 新しい攻撃手法と、複数の一般的なオープンソースおよび商用プロキシ、アプリケーションサーバー、ロードバランサーにおける潜在的な脆弱性が、協調的な責任ある開示の対象となった
- この攻撃に関する集合的な脆弱性はCVE-2023-44487として追跡されている
- 深刻度はHigh
- CVSSスコアは7.5/10
影響を受ける可能性のある対象と必要な対応
- インターネットにHTTPベースのワークロードを提供している企業や個人は、今回の攻撃リスクにさらされる可能性がある
- HTTP/2で通信できるサーバーやプロキシ上のWebアプリケーション、サービス、APIが脆弱である可能性がある
- 組織は、HTTP/2をサポートするサーバーが脆弱でないことを確認する必要がある
- 自前のHTTP/2対応サーバーを運用または管理している場合は、オープンソースか商用かにかかわらず、関連するベンダーパッチが提供され次第適用すべきである
- CVE-2023-44487に対するベンダーパッチは、この攻撃ベクトルの影響を制限するための措置である
Google Cloud環境での防御推奨事項
- 大規模DDoS攻撃への防御は難しく、パッチ適用の有無にかかわらず、中規模以上の攻撃でサービスを継続運用するには相当なインフラ投資が必要である
- Google Cloudでサービスを運用している組織は、Cross-Cloud Networkのグローバル規模の容量投資を活用して、アプリケーションを提供・保護できる
- グローバルまたはリージョンのApplication Load Balancerでサービスを公開しているGoogle Cloud顧客は、Cloud Armor always-on DDoS protectionによる保護を受ける
- CVE-2023-44487のような脆弱性を悪用する攻撃は迅速に緩和される
- Cloud Armor always-on DDoS protectionがGoogleネットワークエッジで毎秒数億件のリクエストの大半を吸収できるとしても、毎秒数百万件の不要なリクエストは依然として通過する可能性がある
- Layer 7攻撃への対応には、Cloud Armorのcustom security policies、先制的なrate limitingルール、AIベースのAdaptive Protectionの導入が推奨される
- 現在のDDoS攻撃の波に関する技術情報は、HTTP/2 Rapid Reset DDoS攻撃の分析で確認できる
1件のコメント
Hacker News の意見
The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
それでも結果が米国のテック企業と顧客を数時間不便にする程度なら、なぜ続いているのかよく分からない。
そうして得た名声で、競合を攻撃したいあまりクリーンではない依頼者から金を受け取る。その依頼者が政府の場合もあれば、怪しい企業の場合もある。昨年は暗号資産企業同士が互いのWebサイトを攻撃することが多かった。
こういうことをする人たちは技術力は高いが、住んでいる場所や育った環境のために、その技術で稼ぐ機会が少ない場合が多い。
高度な攻撃者なら、能力と対応を試している最中だ。Taliban はかつて基地の外で子どもたちに爆竹を鳴らさせるために金を払い、防御側の戦術・技法・手順を確認していたし、銃声に鈍感にさせる効果もあった。
本当に優れた敵は、後者を実行しながら前者のように見せることができる。
Mirai ボットネットの場合、作者の一部は DDoS 緩和会社も運営していた。一方で武器を売り、もう一方でその武器への防御を売っていたわけだ。
名声、いたずら、あるいはボットネットを作るという挑戦自体が動機の場合もある。
インターネットインフラ規模のものにせよ、特定企業を狙ったものにせよ、こうした攻撃に関与したことがある人が、一時アカウントを作って動機を話してくれるほど勇敢、あるいは狂っていることはあるのだろうか。
目的のサイトを遅くしようとしていたわけではないが、実際の有料顧客に対して、サーバー費用が耐えられない速度でデータを取得しようとしていたのだ。
こうした攻撃は実際の DDoS 攻撃とは違うが、私の経験でははるかに一般的で、Cloudflare や Akamai のようなもので比較的簡単に緩和できるため、顧客にはそう勧めることが多い。
Cloudflare、Google、AWS の人たちがリアルタイムのビデオ会議に入り、互いに調整しながら緩和しているのか、それともそれぞれ離れたところで他社の状況を観察しつつ、自分たちの問題解決に集中しているのか気になる。
今回は全員が同じものを見ていると気づき、小さな対象には非常に大きな影響が出る可能性があったため、問題を共同で理解し、すべてのWebサーバー提供者と セキュリティ対応 を調整した。
十分に大きな受信帯域幅を確保して、数 Gb/s を受けても耐え、正当なトラフィック向けの余裕容量を残すだけなのだろうか。
多くのDDoSトラフィックは実際のHTTPではなく、IPアドレスに向けて回線を埋めるだけのゴミトラフィックです。より太い回線と、地理的に分散した複数のサーバーが役に立ちます。TCP SYNフラッドのように、TCP接続だけを開いて利用可能なポートを枯渇させる場合もあります。こうした異常なリクエストは、サーバー前段の複数の単純なリバースプロキシで処理できることが多いです
見た目には正常なHTTPトラフィックを送ってくる、より高度なクエリは、最終的には処理しなければなりません。キャッシュから応答する、攻撃者を遅らせて正常なトラフィックを識別するためにCAPTCHAを挟む、レート制限を適用する、といった方法です。実サーバーへ渡す前にリクエストが正常かどうかを判定したいので、そのためにさまざまなツールを配備できます
サーバー側はCloudflareから来たトラフィック以外をすべて捨てるように設定すればよく、この方式は効率的です
一般に、Googleの内部データセンター間トラフィックは、誰かがDDoSとして送り込める量よりはるかに大きいため、常に処理する方法を見つけられます
ただし、すべてのDDoSが容量ベースというわけではありません。Slowloris攻撃のように、プロトコルの基本機能を悪用するケースもあります
https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
今回の場合なら、クライアントがストリームを素早くリセットしていることを認識し、そのトラフィックを低速レーンに回す、あるいは完全にフィルタする方法かもしれません
https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
「記録的な攻撃について重要な点の一つは、約20,000台のマシンからなる中規模のボットネットが関与していたことだ」
大手プロバイダーがみなこれを行えば、次に訪れるCloudflareサイトの前に小さなTurnstileのようなページを挟めそうです
自分のネットワークに感染したデバイスがあるなら知りたいし、現状ではそれを検知する実際のモニタリングもありません。完全な解決策ではありませんが、少なくともユーザーに問題があると知らせるのは良い出発点です