HTTP/2 Rapid Reset攻撃とは？CVE-2023-44487の仕組みとWebサーバーの防御設定ガイド

「自社のWebサーバーのアクセスログを確認すると、短時間に大量のHTTP/2接続リクエストが記録されていた。」情シスとして、こうした不審な兆候に気づいたとき、どう対処すればよいか迷うことがあるかもしれません。

2023年10月、GoogleやCloudflare、Amazon Web Servicesが同時に公表した脆弱性CVE-2023-44487は、HTTP/2の仕様を悪用した「Rapid Reset攻撃」と呼ばれるDDoS手法です。従来の攻撃と比べてはるかに少ない接続数で記録的なリクエストを生成できるため、Webサービスを支えるインフラに深刻な影響を与えました。

この記事では、HTTP/2 Rapid Reset攻撃の仕組み・影響範囲・具体的な防御設定手順を、現場で使えるレベルで解説します。自社のWebサーバーがApache・nginxを利用している場合でも、CloudflareなどのCDN経由でWebサービスを公開している場合でも、参考になる対策が見つかるはずです。

HTTP/2 Rapid Reset攻撃とは？

HTTP/2は2015年に標準化されたWebプロトコルです。HTTP/1.1では1つのTCP接続で1つのリクエストしか同時処理できなかったのに対し、HTTP/2では「多重化（Multiplexing）」によって1つの接続上で複数の「ストリーム」を並列処理できます。これによりWebページの表示速度が大幅に向上しました。

ストリームとは、クライアントとサーバーの間で行われる1回のリクエスト／レスポンスのやり取りに相当します。クライアントはHEADERSフレームを送ってリクエストを開始し、サーバーがレスポンスを返します。また、クライアントはストリームを途中でキャンセルするためにRST_STREAMフレームを送ることができます。これはHTTP/2の正当な仕様です。

Rapid Reset攻撃は、このRST_STREAMの仕組みを悪用します。攻撃者はHEADERSフレームを送ってリクエストを開始した直後にRST_STREAMフレームを送り、即座にキャンセルします。これを1つのTCP接続上で高速に繰り返すことで、サーバーは「受け付けたが即座にキャンセルされたストリーム」の処理に追われ、CPUやメモリを消費し続けます。

攻撃の特徴は、攻撃者側が接続数を増やさずとも大量のサーバー負荷を発生させられる点です。CVE-2023-44487として公開された当時、Googleは毎秒3億9800万リクエスト、Cloudflareは毎秒2億100万リクエストというDDoS攻撃を観測・防御したと報告しています（各社公式ブログの公表情報に基づく）。

詳細は公式脆弱性情報で確認できます: CVE-2023-44487（NVD）

攻撃の仕組み（敵を知る）

HTTP/2の通常の通信フローと、Rapid Reset攻撃のフローを比較すると、攻撃の本質が見えてきます。

通常のHTTP/2通信では、次のような流れでストリームが完結します。

# 通常の HTTP/2 通信フロー（概念）
# クライアント → サーバー
HEADERS  (ストリームID: 1, リクエスト開始)
DATA     (ストリームID: 1, リクエストボディ)

# サーバー → クライアント
HEADERS  (ストリームID: 1, レスポンスヘッダー)
DATA     (ストリームID: 1, レスポンスボディ)
# ストリーム正常完了

一方、Rapid Reset攻撃では次のようなパターンが高速に繰り返されます。

# Rapid Reset 攻撃の通信パターン（概念）
HEADERS    (ストリームID: 1, リクエスト開始)
RST_STREAM (ストリームID: 1, 即座にキャンセル) ← ここが攻撃の核心
HEADERS    (ストリームID: 3, 新ストリーム開始)
RST_STREAM (ストリームID: 3, 即座にキャンセル)
HEADERS    (ストリームID: 5, ...)
RST_STREAM (ストリームID: 5, ...)
# この繰り返しが毎秒数百万回以上の規模で発生

サーバーはHEADERSフレームを受け取った時点でリクエストの処理（URLの解析・認証チェック・レスポンス生成の準備）を開始します。その直後にRST_STREAMが届いても、処理に費やしたCPU時間とメモリは無駄になります。これが短時間に大量に繰り返されると、サーバーリソースが枯渇してサービス停止に至ります。

この攻撃が脅威となる理由の一つは、HTTP/2の仕様ではRST_STREAMの送信レートを制限する仕組みが明示されていなかったことです。また、攻撃はHTTP/2接続内で完結するため、従来のTCPレイヤーの対策だけでは検出・防御が困難でした。

DDoS攻撃全般の仕組みについてはDDoS攻撃とは？仕組み・種類・対策もあわせて参照してください。

具体的な防御手順

Rapid Reset攻撃への対策は、大きく3つのアプローチに分けられます。

1. サーバーソフトウェアの更新

最も根本的な対策は、HTTP/2の実装に修正が加えられたバージョンへの更新です。主要なソフトウェアのベンダーは2023年10月前後に修正版をリリースしています。

・nginx: HTTP/2モジュールのストリーム処理に改善が加えられています。nginx -vでバージョンを確認し、パッケージマネージャーで最新版を適用してください。
・Apache httpd: mod_http2モジュールが改善されています。httpd -v（またはapache2 -v）でバージョンを確認し、更新してください。
・HAProxy・Envoy・IISなど: 各ベンダーのリリースノートとCVE-2023-44487への対応状況を確認して更新します。

バージョン確認と更新のコマンド例を示します。

# RHEL/Rocky/AlmaLinux の場合
sudo dnf check-update nginx httpd
sudo dnf update nginx httpd

# Ubuntu/Debian の場合
sudo apt update
sudo apt upgrade nginx apache2

# バージョン確認
nginx -v
httpd -v    # または: apache2 -v

2. HTTP/2ストリーム数の制限設定

ソフトウェアを更新した上で、HTTP/2の同時ストリーム数とリクエストレートを制限する設定を加えることで、防御の深みを増せます。

nginxでの設定例を示します（/etc/nginx/nginx.confまたは対象のvhostファイルを編集します）。

http {
    # 1接続あたりの同時ストリーム数を制限（デフォルト: 128）
    http2_max_concurrent_streams 64;

    # リクエストレート制限ゾーンの定義
    limit_req_zone $binary_remote_addr zone=http2limit:10m rate=50r/s;

    server {
        listen 443 ssl;
        http2 on;

        # レート制限の適用（バースト許容: 100リクエスト）
        limit_req zone=http2limit burst=100 nodelay;
    }
}

Apache httpdでのmod_http2設定例（/etc/httpd/conf.d/http2.conf等に追加）を示します。

# HTTP/2モジュールの有効化（未設定の場合）
Protocols h2 http/1.1

# 1セッションあたりの最大ストリーム数（デフォルト: 100）
H2MaxSessionStreams 64

# リクエストタイムアウト設定（mod_reqtimeout）
# ヘッダー送信後20秒以内、最低500バイト/秒
RequestReadTimeout header=20,MinRate=500 body=20,MinRate=500

設定変更後は必ずnginx -tやhttpd -tで構文確認を行い、サービスを再起動してください。nginxのセキュリティ設定全般についてはnginxセキュリティ設定入門で詳しく解説しています。

3. CDN・WAFによる多層防御

CloudflareやAWS CloudFront、Azure Front Doorなどを経由している場合、CDN側でRapid Reset攻撃を緩和する機能が実装されています。ただし、CDNを利用しているからといってオリジンサーバーの更新を怠ってはいけません。CDNをバイパスして直接オリジンを狙う攻撃への備えとして、サーバー本体の対策も並行して行うことが重要です。

WAFを組み合わせた防御設計についてはWAFとは？仕組み・選び方・導入手順もあわせて参照してください。

SYNフラッド攻撃などTCPレイヤーの類似攻撃との比較はSYNフラッド攻撃とは？TCPの弱点を突くDDoSと対策が参考になります。

中小企業でも今日からできること

「クラウドの大手ではないから関係ない」と思われがちですが、Rapid Reset攻撃のツールは広く流通しており、中小企業のWebサーバーも標的になり得ます。特に以下の状況に当てはまる場合は、優先的に対処を検討してください。

・自社管理のWebサーバー（nginx／Apache）を公開している: パッケージマネージャーで最新版に更新し、ストリーム数制限の設定を追加する
・VPS・クラウドで直接サービスを公開している: CDNやWAFを前段に置くことで攻撃の緩和層を追加できます
・HTTP/2を使っているかどうか分からない: ブラウザの開発者ツール（ネットワークタブ）でプロトコル列を確認し、「h2」と表示されればHTTP/2が有効です
・Apacheの設定をほとんど変えていない: mod_reqtimeoutとH2MaxSessionStreamsの設定を見直す

Webサーバーのバージョン確認と更新は、定期的なパッチ適用の一環として月次運用に組み込むのが理想的です。脆弱性管理の体制づくりについては脆弱性管理とは？発見・評価・修正・検証の4ステップが参考になります。

よくある誤解と注意点

・「HTTP/2を無効にすれば安全」: HTTP/2を無効にすることで攻撃は防げますが、パフォーマンスの低下とSEOへの影響が生じます。最新バージョンへの更新とストリーム制限を組み合わせた対策を優先してください。
・「CDNを使っているから大丈夫」: CDNは有力な緩和策ですが、CDNとオリジンサーバー間の接続もHTTP/2であれば影響を受ける可能性があります。オリジンサーバー自体も更新と設定変更が必要です。
・「ファイアウォールでHTTP/2を遮断すればよい」: Rapid Reset攻撃は正常なHTTP/2通信のフレームを悪用するため、L4ファイアウォールでは検出できません。L7（アプリケーション層）での対策が必要です。
・「一度対策すれば終わり」: HTTP/2の実装改善は継続して行われています。定期的なバージョンアップと設定の見直しを習慣化することが、長期的な安全性の維持につながります。
・「HTTP/3では発生しない」: HTTP/3（QUIC）は異なるプロトコルですが、同様のリソース枯渇攻撃の研究が進んでいます。HTTP/3への移行で本攻撃はなくなりますが、新たな脅威への継続的な注意が必要です。

本記事のまとめ