「Rapid Reset」と呼ばれるHTTP/2プロトコルの脆弱性により、ここ数カ月でWebサーバーに対する過去最大規模のDDoS攻撃が発生している。Google、AWS、Cloudflareは本日、攻撃と脆弱性を共同で公表したが、最新のWebサーバーはすべてこの攻撃手法に対して脆弱なままだと指摘した。Webサーバーのベンダーやオープンソースプロジェクトも、緩和策とパッチ計画を発表している。
Googleによると、攻撃のピーク時には毎秒3億9800万件のリクエスト（rps）に達した。これは、2023年2月に記録された過去の記録の5倍以上であり、2分間に発生したWebトラフィックは、Wikipediaが9月の1カ月間全体で受けたトラフィックを上回った。Cloudflareによると、攻撃のピークは毎秒2億100万件をわずかに上回った。
Google、AWS、Cloudflareによると、攻撃による被害を抑えることができたという。Cloudflareは、「当初の攻撃の波では顧客トラフィックに一定の影響があり、リクエストのおよそ1％に影響が及んだが、現在は緩和手法を改良し、システムに影響を与えることなく、Cloudflareのどの顧客に対する攻撃も阻止できるようになった」と述べた。
問題なのは、攻撃者がわずか2万台のマシンからなるボットネットで攻撃を生成できたことだ。Cloudflareは脆弱性に関する技術ブログ記事（CVE-2023-44487）で、「現在、数十万台、あるいは数百万台のマシンで構成されたボットネットも存在する。Web全体で通常発生するリクエストは毎秒10億～30億件にすぎないことを考えると、この手法を使えば、Web全体に相当する量のリクエストを少数の標的に集中させることも、決して考えられないことではない」と述べた。
同じく懸念されるのは、この脆弱性が広く存在していることだ。
こちらもおすすめ：DDoS攻撃を3段階で阻止する方法
「最新のWebサーバーすべて」に影響
Cloudflareは、この攻撃がHTTP/2プロトコルの基盤にある脆弱性を悪用することから、「HTTP/2を実装しているベンダーはすべて、この攻撃の影響を受けると考えている。これには最新のWebサーバーがすべて含まれる」と指摘した。
「Google、AWSとともに、攻撃手法をWebサーバーのベンダーに開示しており、各社がパッチを実装すると見込んでいる。それまでの最善の防御策は、Webに公開されたWebサーバーやAPIサーバーの前段に、CloudflareのようなDDoS緩和サービスを利用することだ」
Apache Tomcat、MicrosoftなどのWebサーバーベンダーやオープンソースプロジェクトは、この脆弱性への対処方法に関するガイダンスを発表した。増え続ける発表はCVEリストで確認できる。
NGINXは例えば、攻撃対象領域を最小化するため、複数の設定変更を推奨している：
- keepalive_requestsは、デフォルト設定の1000リクエストに維持する
- http2_max_concurrent_streamsは、デフォルト設定の128ストリームに維持する
- limit_connは、単一クライアントから許可する接続数を制限する。アプリケーションのパフォーマンスとセキュリティのバランスを取った「妥当な設定」で追加する
- limit_reqは、単一クライアントから一定時間内に処理するリクエスト数を制限する。これもアプリケーションのパフォーマンスとセキュリティのバランスを取る必要がある。
NGINXは、1つのイベントループ内で導入できる新しいストリーム数に制限を設けるパッチを明日リリースすると発表した。この制限は、http2_max_concurrent_streamsディレクティブで設定された値の2倍となる。「リクエストの送信直後にストリームがリセットされる場合（今回の攻撃のケースなど）のように、最大しきい値に達することがなくても、この制限は適用される」とNGINXは述べた。
こちらもおすすめ：
HTTP/2「Rapid Reset」攻撃の仕組み
GoogleはHTTP/2「Rapid Reset」攻撃に関する技術ブログ記事で、「HTTP/2の主な設計目標は効率性だった。しかし残念ながら、正規のクライアントにとってHTTP/2をより効率的にする機能は、DDoS攻撃をより効率的にするためにも利用できる」と指摘した。
本質的には、Rapid Reset攻撃は「ストリームのキャンセル」と呼ばれるHTTP/2の機能を悪用し、リクエストを繰り返し送信してから即座にキャンセルすることで成立する。
Googleによると、HTTP/2プロトコルでは、クライアントはRST_STREAMフレームを送信することで、以前のストリームをキャンセルすべきだとサーバーに通知できる。このプロトコルでは、キャンセルにあたってクライアントとサーバーが連携する必要はなく、クライアントが一方的に実行できる。またクライアントは、サーバーがRST_STREAMフレームを受信すると、同じTCP接続からのほかのデータが処理される前に、キャンセルが即座に有効になると想定できる。
Googleは、「この攻撃がRapid Resetと呼ばれるのは、エンドポイントがリクエストフレームの送信直後にRST_STREAMフレームを送信できることに依存しているためだ。これにより、もう一方のエンドポイントは処理を開始した後、リクエストを即座にリセットする。リクエストはキャンセルされるが、HTTP/2接続は開いたままになる」と説明した。
この機能を利用したHTTP/2 Rapid Reset攻撃は単純だと、Googleは述べている。
「クライアントは、標準的なHTTP/2攻撃と同様、一度に大量のストリームを開く。しかし、サーバーやプロキシから各リクエストストリームへの応答を待つのではなく、各リクエストを即座にキャンセルする。ストリームを即座にリセットできるため、各接続で無制限の数のリクエストを処理中にできる。リクエストを明示的にキャンセルすることで、攻撃者は同時に開いているストリーム数の上限を超えない。処理中のリクエスト数は、ラウンドトリップ時間（RTT）ではなく、利用可能なネットワーク帯域幅だけに依存するようになる」
Googleによると、一般的なHTTP/2サーバーの実装では、キャンセルされたリクエストに対しても、「新しいストリームのデータ構造の割り当て、クエリの解析やヘッダーの解凍、URLからリソースへのマッピングなど、依然として相当量の処理を行わなければならない」。
リバースプロキシの実装では、「RST_STREAMフレームが処理される前に、リクエストがバックエンドサーバーへプロキシされる可能性がある。一方、クライアントはリクエストの送信にほとんどコストを負担しない。これにより、サーバーとクライアントの間に、悪用可能なコストの非対称性が生じる。攻撃者が得るもう1つの利点は、作成直後にリクエストを明示的にキャンセルするため、リバースプロキシサーバーがどのリクエストにも応答を送信しないことだ」
Googleによると、緩和策には複数の形態があるが、主に接続統計の追跡と、各接続がどれだけ有用かを判断するためのシグナルやビジネスロジックの利用が中心となる。「例えば、1つの接続で100件を超えるリクエストがあり、そのうち50％超がキャンセルされている場合、緩和対応の候補となり得る。対応の規模と種類は各プラットフォームのリスクによって異なるが、対応には、前述した強制的なGOAWAYフレームの送信から、TCP接続の即時切断までが含まれる。
「この攻撃のキャンセルを伴わない亜種を緩和するため、HTTP/2サーバーは同時ストリーム数の上限を超えた接続を閉じることを推奨する。これは直ちに実行してもよいし、少数回の違反を繰り返した後に実行してもよい」
次に読む：