【テクニカル・上級編】HTTP/2実装におけるメモリ枯渇攻撃(DoS)の防御 – HTTPプロトコル・通信規格実践ガイド

HTTP/2の美しき狂気：マルチプレクシングの恩恵と、メモリ枯渇（DoS）という名のパンドラの箱

ウェブの高速化という聖戦において、HTTP/2がもたらしたパラダイムシフトは劇的だった。TCPコネクションという一本の太いパイプラインを共有し、その内部で無数の「ストリーム」を縦横無尽に多重化（マルチプレクシング）する。HOL（ヘッド・オブ・ライン）ブロッキングの呪縛から解放されたブラウザは、リクエストを並列で撃ち込み、サーバー側もまた、非同期なイベント駆動の極みとしてそれに応える。パケットキャプチャを覗けば、そこには調和のとれた美しいプロトコル的共生世界が広がっている。

だが、インフラアーキテクトやセキュリティ・スペシャリストであれば、この「美しさ」の裏側に潜むダークサイドを嗅ぎ取っているはずだ。
コネクションの共有化と無制限の並列性は、そのまま悪意ある攻撃者にとって「効率的なリソース強奪兵器」へと変貌する。TCP層のウィンドウ制御やTLSの暗号化レイヤーをいかに最適化しようとも、アプリケーション層のパーサーが無限のメモリ割り当てを受け入れた瞬間、サーバーは静かに、しかし確実に膝をつく。

今回は、HTTP/2実装におけるメモリ枯渇（DoS）のメカニズムを、パケットレベルの挙動、HPACKの深淵、そしてLinuxカーネルや実装レベルでの具体的な防御策に至るまで、徹底的に解剖していこう。

—

1. パケットレベルで見る脆弱性：なぜHTTP/2は「踏み絵」を踏むのか

HTTP/1.1の時代、DoS攻撃といえば「Slowloris」に代表されるような、低速なコネクションを大量に維持してソケットを枯渇させる手法が主流だった。これに対してサーバー側は、`MaxClients` や `timeout` ディレクティブで対抗できた。

しかし、HTTP/2のマルチプレクシングはゲームのルールを根本から書き換えた。
1本のTCPコネクション上で、クライアントは最大 $2^{31}-1$ 個ものストリームを理論上同時にオープンできる。攻撃者は、たった1本のTCPコネクションを確立し、その中で数千、数万ものストリームを次々と生成（`HEADERS` フレームの送信）する。サーバーのTCPスタックから見れば、ウィンドウサイズは健全で、キープアライブも正常だ。しかし、アプリケーション層（HTTP/2パーサー）の内部では、各ストリームの状態管理構造体（Stream Control Block）や受信バッファのために、際限なくヒープメモリが割り当てられていく。

制御フレームの応酬とフロー制御の盲点

HTTP/2には、トラフィックを制御するためのメカニズムとして「ウィンドウベースのフロー制御」が備わっている。`WINDOW_UPDATE` フレームを用いることで、送信元に対して「ここまでしかデータを送ってはいけない」とプレッシャーをかけられるはずだった。

しかし、ここに設計のジレンマがある。
サーバーが「メモリを守りたいから小さなウィンドウサイズを設定しよう」とケチると、今度は正当な大容量コンテンツの配信速度（帯域幅遅延積: BDP の最大化）がスポイルされ、HTTP/2本来のパフォーマンスが台無しになる。セキュリティとパフォーマンスのトレードオフだ。攻撃者は、このフロー制御の隙間を縫い、データ本体ではなく「メタデータ（ヘッダー）」の生成と破棄、あるいは中途半端なストリームの放置によって、パーサーのメモリプールをじわじわと窒息させていく。

—

2. HPACKの魔術と「ヘッダー爆弾（HPACK Bomb）」の脅威

HTTP/2の高速化を支えるもう一つの立役者が、ヘッダー圧縮アルゴリズム「HPACK」である。
毎回同じようなヘッダー（`:method`, `:path`, `cookie`, `user-agent` など）をそのまま送るのではなく、静的テーブル（Static Table）と動的テーブル（Dynamic Table）を参照し、インデックス番号やハフマン符号化で数バイトに圧縮する。

このHPACKが、メモリ枯渇攻撃の格好のターゲットになる。それが「HPACK Bomb（HPACK爆弾）」だ。

復元ロジックの罠

HPACKの動的テーブルは、コネクションごとに状態を持つ。サーバーは、クライアントから送られてきた圧縮されたヘッダーブロックをデコードし、動的テーブルを更新しながら元のヘッダーへと復元する。

ここで悪意ある攻撃者は次のようなパケットを送りつける。
1. 静的テーブルや動的テーブルに存在しない、あるいは極端に長いカスタムヘッダー名を、ハフマン符号化の圧縮率の限界（あるいは不正なインデックス参照）を利用して極小のペイロードで構築する。
2. サーバーのHPACKデコーダーは、この小さなパケットを受信し、展開を開始する。
3. 展開された結果生じるプレーンテキストのヘッダーサイズが、数メガバイト、あるいは数十メガバイトに膨れ上がる。

[クライアント]
(数バイトの極小HPACKパケット)
│
▼ (TCP/TLS)
[サーバーのHTTP/2パーサー]
│
▼ (HPACKデコード処理)
[メモリ上に出現する巨大ヘッダーブロック] ⇒ 動的テーブルが溢れ、ヒープが圧迫・枯渇

パーサーが「このヘッダーブロック、デコードしたら50MBあるぞ」と気づいた時にはすでに遅い。その巨大な文字列を格納するためのメモリ領域が即座に確保され、数個の不正なストリームを送りつけられただけで、数ギガバイトのRAMが瞬時に蒸発する。これがHPACK Bombの恐るべき実態である。

—

3. 実装レベルの防衛ライン：プロトコル制限とリソース管理の極意

では、私たちはこの洗練された暴力に対して、どのように防壁を築くべきか。
幸いにして、現代の主要なHTTP/2実装（NGINX, Envoy, Apache, あるいはGo言語の `net/http` など）は、この種の攻撃に対する硬化（Hardening）パラメータを備えている。しかし、デフォルト値の多くは「あらゆる環境で動くこと」を優先しており、セキュアな高負荷環境では緩すぎるケースが散見される。

インフラアーキテクトとして、以下の制限事項（Limits）を厳格にチューニングし、コードや設定に落とし込む必要がある。

① 同時ストリーム数の制限 (`SETTINGS_MAX_CONCURRENT_STREAMS`)

1つのTCPコネクション上で許可するアクティブなストリームの最大数を絞る。デフォルトでは無制限（あるいは非常に大きな値）になっていることが多いが、これを適切な値に制限する。

② ヘッダーリストのサイズ制限 (`SETTINGS_MAX_HEADER_LIST_SIZE`)

デコード後のヘッダーの総サイズ（名前と値のバイト数の合計）に上限を設ける。HPACK Bombを防ぐための最も直接的な防衛策。

③ インバウンドウィンドウとバッファの制限

TCP層のバッファとHTTP/2のフロー制御ウィンドウを適切に小さく保ち、アイドル状態のストリームに対するタイムアウトを短く設定する。

—

4. 実践：Nginx / Envoy / Go言語における防御パラメーターの実装

理論をコードと設定に昇華させよう。現場ですぐに適用できる具体的な設定例を示す。

NginxにおけるHTTP/2ハードニング設定

Nginxの最新バージョン（モジュール構造の刷新以降）では、HTTP/2の細かいリソース制限を `http` ブロックや `server` ブロックで制御できる。

http {
# HTTP/2接続全体のパラメータ最適化

# 1つのコネクション内で許可する最大同時ストリーム数を抑制 (デフォルトは128や無制限に近い値)
# クライアントからの並列リクエスト暴走を防ぎ、メモリ消費の天井を固定する
http2_max_concurrent_streams 100;

# 受信可能なヘッダーの最大サイズ (HPACKデコード後のプレーンテキストサイズ)
# デコード結果がこのサイズを超えた場合、サーバーはRST_STREAM (H2_INTERNAL_ERROR) を返す
http2_max_header_size 16k;

# 動的テーブルの最大サイズを制限 (デフォルトは4096バイト)
# クライアントが動的テーブルを無駄に肥大化させるのを防ぐ
http2_max_field_size 4k;

# アイドル状態のストリームに対するタイムアウト (スローアタック対策)
client_header_timeout 10s;
client_body_timeout 10s;

server {
listen 443 ssl http2;
server_name example.com;

# TLS設定の最適化 (TLS 1.3推奨、強固な暗号スイートの選定)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

# セッションキャッシュの活用でハンドシェイクのオーバーヘッドを削減
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;

location / {
proxy_pass http://backend_cluster;

# バックエンドへの転送時にもバッファサイズを厳格に管理
proxy_buffers 8 16k;
proxy_buffer_size 32k;
}
}
}

Go言語 (net/http) によるセキュアなHTTP/2サーバー実装

独自にマイクロサービスやAPIゲートウェイをGoで構築する場合、`http.Server` の設定構造体である `http.Server` や、より低レイヤーの `golang.org/x/net/http2` パッケージを活用して制限を明示的にコードに埋め込む必要がある。

package main

import (
“log”
“net/http”
“time”

“golang.org/x/net/http2”
)

func main() {
mux := http.NewServeMux()
mux.HandleFunc(“/”, func(w http.ResponseWriter, r http.Request) {
w.Write([]byte(“Hello, Secured HTTP/2 World!”))
})

srv := &http.Server{
Addr: “:443”,
Handler: mux,
ReadTimeout: 15 time.Second,
WriteTimeout: 15 time.Second,
IdleTimeout: 60 time.Second,
}

// HTTP/2特有の脆弱性を防ぐためのコンフィグレーション
h2s := &http2.Server{
// 1コネクションあたりの最大同時ストリーム数を厳格に制限
MaxConcurrentStreams: 128,

// 各ストリームの初期ウィンドウサイズ (デフォルトより小さくしてメモリを保護)
InitialStreamWindowSize: 65535,

// コネクション全体の初期ウィンドウサイズ
InitialConnWindowSize: 1048576, // 1MB

// 【重要】HPACKデコード後の最大ヘッダーサイズを制限 (例: 16KB)
// 悪意ある巨大ヘッダーによるヒープ枯渇を防ぐ防壁
MaxUploadBufferPerConnection: 1024 1024, // 1MB
MaxUploadBufferPerStream: 256 1024, // 256KB
}

// http2サーバーとしてサーバーオブジェクトを有効化
// 内部で暗黙的に設定されるデフォルト値に依存せず、明示的にconfigureする
err := http2.ConfigureServer(srv, h2s)
if err != nil {
log.Fatalf(“Failed to configure HTTP/2: %v”, err)
}

log.Println(“Starting hardened HTTP/2 server on :443…”)
// TLS証明書のパスは環境に合わせて適切に設定すること
if err := srv.ListenAndServeTLS(“server.crt”, “server.key”); err != nil {
log.Fatalf(“Server failed: %v”, err)
}
}

—

5. トランスポート層（TCP/TLS）の最適化とレイヤー横断の防御戦略

アプリケーション層（HTTP/2）での制限をどれほど厳しくしても、その下のトランスポート層や暗号化レイヤーが適切にチューニングされていなければ、インフラストラクチャ全体の脆弱性は拭えない。極限のパフォーマンスとセキュリティを両立させるための「レイヤー横断の視点」を最後に整理しておこう。

Linuxカーネルパラメータ（sysctl）のチューニング

TCPスタックレベルでも、メモリ枯渇攻撃やコネクションアブュースに対する耐性を高めておく必要がある。`/etc/sysctl.conf` において、以下のカーネルパラメータを調整する。

SYNフラッド攻撃およびリソース枯渇対策
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192

TCPソケットのメモリプレッシャー制御 (自動チューニングの上下限)
メモリ使用量が一定の閾値を超えた場合に、カーネルがアグレッシブにバッファを解放する
net.ipv4.tcp_mem = 786432 1048576 2677726
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

終了したコネクションのFIN-WAIT-2状態を早めに回収し、ソケット枯渇を防ぐ
net.ipv4.tcp_fin_timeout = 15

TLSハンドシェイクの最適化とRTT削減

HTTP/2の恩恵を最大化するためには、TLS 1.3の導入が不可欠だ。TLS 1.2では鍵交換に追加のラウンドトリップ（RTT）が発生していたが、TLS 1.3は「1-RTT（早期データであれば0-RTT）」でハンドシェイクを完了する。
これにより、コネクション確立にかかるレイテンシが劇的に短縮され、クライアント側がマルチプレクシングの恩恵を受け始めるまでの「タイムラグ」が消滅する。

しかし、0-RTTデータ（Early Data）は「リプレイ攻撃」の危険性を孕んでいるため、APIサーバーやステートフルな処理を行うエンドポイントでは安易な有効化を避け、厳密な冪等性（Idempotency）が保証されたリクエストのみに限定するべきである。

—

結びにかえて

ネットワークプロトコルというものは、突き詰めれば「信頼と猜疑心のバランス」の歴史だ。
HTTP/2のマルチプレクシングとHPACKは、ネットワークの帯域を極限まで効率化する「信頼の産物」である。しかし、悪意ある攻撃者は常にその信頼の隙間を突き、設計者の想像を超えたリソース消費を引き起こそうとする。

インフラアーキテクトやテックリードに求められるのは、ただ動くシステムを構築することではない。プロトコルの内部挙動をパケット単位で解釈し、アルゴリズムの弱点を把握した上で、適切な防御パラメータという名の「防壁」をコードと設定の髄にまで浸透させることだ。

美しく、そして堅牢なネットワーク設計の追求に、終わりはない。