HPACK圧縮爆弾の罠：HTTP/2の美しき効率性が孕むダークサイドと、その防衛線
ネットワークの歴史を振り返ると、効率性を極限まで追求したプロトコルほど、皮肉にもその「優美な構造」がアタッカーにとって格好の武器となってきた。TCPのウィンドウ制御、SSL/TLSのハンドシェイク、そしてHTTP/2におけるバイナリフレーミングとヘッダー圧縮――。
私たちインフラアーキテクトやテックリードは、レイテンシーを削り、パケットの往復（RTT）を極小化することに情熱を注ぐ。HTTP/2の登場により、HTTP/1.x時代を長年苦しめた「Head-of-Line Blocking（行頭ブロック）」の呪縛から解放され、単一のTCPコネクション上で無数のストリームが並行して疾走する世界が手に入った。
しかし、その中核技術の一つである「HPACK（Header Compression for HTTP/2）」が、悪意ある者によって牙をむくことがある。それが、今回深く掘り下げる「HPACK圧縮爆弾（HTTP/2 Header Compression Bomb / CVE-2019-9512など）」だ。
わずか数キロバイトのコンパクトなパケットが、受信側のサーバーやリバースプロキシのメモリを数ギガバイト喰らい尽くし、瞬く間にOOM（Out of Memory）キラーの餌食にしてしまう。この恐怖のメカニズムと、パケットレベルの挙動、そして私たちが現場で講じるべき実践的な防衛策について、プロトコルの深淵を覗きながら紐解いていこう。
—
1. 圧倒的な効率性の裏側：HPACKが動的テーブルを維持する仕組み
HTTP/1.xのテキストベースのヘッダーは、CookieやUser-Agentなどの冗長な文字列が毎リクエストごとに送信され、帯域の大きな無駄を生んでいた。HTTP/2はこの問題を解決するため、RFC 7541で定義される「HPACK」を導入した。
HPACKの肝は、「静的テーブル（Static Table）」と「動的テーブル（Dynamic Table）」の二重構造にある。
- 静的テーブル: プロトコル仕様で予め定義された61個の一般的なヘッダーフィールド（例：`:method: GET` や `content-type: application/json` など）のペア。
- 動的テーブル: 通信を行っている最中のコネクション単位で動的に構築されるテーブル。一度送信されたカスタムヘッダー（例：`X-Custom-Tracking-Id: abc123xyz`）をテーブルに登録し、以降はインデックス番号（整数値）だけをバイナリとして流すことで、ヘッダーサイズを劇的に圧縮する。
パケットがネットワークを流れる際、ヘッダーブロックはHuffman符号化とインデックス参照によって極限まで圧縮される。理論上、数千バイトのHTTPヘッダーを、数バイトのペイロードに凝縮して送り出すことが可能だ。
しかし、ここに致命的な設計の罠が潜んでいる。「動的テーブルのサイズ管理」と「受信側のメモリ割り当て」の非対称性である。
—
2. パケットが崩壊する瞬間：HPACK圧縮爆弾の攻撃メカニズム
HPACK圧縮爆弾（別名: リソース枯渇攻撃、CVE-2019-9512 / Rapid Reset等を含む一連のHTTP/2脆弱性の文脈）の核心は、「極小のデータ量で、極大のメモリバッファを受信側に強制確保させる」点にある。
攻撃者は、次のような手順でターゲットのプロキシ（Nginx, Envoy, Apacheなど）やアプリケーションサーバーを追い詰める。
1. 動的テーブルサイズの最大化要求:
アタッカーは、HTTP/2のSETTINGSフレーム（具体的には `SETTINGS_HEADER_TABLE_SIZE`）を用いて、動的テーブルのサイズを許容される最大値（あるいは非常に大きな値）に設定するようサーバーに要求、または合意させる。
2. 極小のHuffman/リテラルヘッダーの連続送信:
送信するデータ自体は、数バイトから数十バイト程度の極めて小さなリテラルヘッダー（またはリファレンス）の嵐だ。しかし、その中身は「受信したら動的テーブルに追加し、それを膨大な回数参照して展開せよ」という指示の塊である。
3. 爆発的なメモリ膨張（Amplification Effect）:
サーバー側のHPACKデコーダは、受信したバイナリを忠実にデコードしようとする。動的テーブルに次々とエントリが追加され、展開されたヘッダー文字列全体を保持するためのメモリバッファ（通常、ストリームごと、あるいはコネクションごとに確保される）がアロケートされる。
結果として、数KBの受信パケットが、サーバー内部で数MB〜数GBのメモリ消費へと増幅（インフレ）する。マルチプレクシングによって何百ものストリームが同時にこれを実行された場合、瞬時にサーバーの物理メモリが枯渇し、kernelのOOM Killerが発動してサービスは沈黙する。
—
3. トランスポート層・TLSハンドシェイクとHTTP/2マルチプレクシングのジレンマ
この脆弱性の厄介なところは、HTTP/2が持つ「パフォーマンス追求のためのアーキテクチャそのもの」が攻撃の踏み台になる点にある。
TCPバッファとウィンドウ制御
HTTP/2は1本のTCPコネクション上で多重化を行うため、TCPのフロー制御（ウィンドウサイズ）とHTTP/2独自のストリームレベルのフロー制御（`WINDOW_UPDATE` フレーム）が存在する。
アタッカーは、TCPの輻輳制御ウィンドウ内において、不正なHPACKペイロードを含んだHEADERSフレームを大量に流し込む。TCP層としては「正常なデータ受信」であるためパケットを快く受け入れ、アプリケーション層（HTTP/2パーサー）へと渡してしまう。そのため、L4（トランスポート層）のファイアウォールやWAFのシグネチャ検知を容易にすり抜ける。
TLS 1.3の暗号化の壁
現代のインフラストラクチャにおいて、HTTP/2は原則としてTLS 1.3（最低でもTLS 1.2）の上で稼働する（ALPNによるネゴシエーション）。
通信が暗号化されているため、ネットワーク経路上の一般的なパケットキャプチャや安易なディープ・パケット・インスペクション（DPI）機器では、HTTP/2のフレーム内部、ひいてはHPACKの動的テーブル操作をリアルタイムに検知・ブロックすることが極めて困難である。つまり、「終端するリバースプロキシやロードバランサー自身が、厳格なメモリ防衛ロジックを持っていなければならない」という結論に行き着く。
—
4. 現場で即座に実装すべき防衛策とパラメーターチューニング
では、我々インフラエンジニアはこの脅威に対してどのように対抗すべきか。教科書的な「アップデートをしましょう」という抽象論ではなく、実務の現場で直面するNginxやEnvoy、あるいはLinuxカーネルレベルの具体的な設定とコード断片を通じて、鉄壁の防衛線を構築しよう。
① Webサーバー / リバースプロキシの設定最適化 (Nginxの例)
Nginxは強力なHTTP/2実装を持つが、デフォルトのままだとリソース枯渇攻撃に対して脆弱な場合がある。`http`ブロックや`server`ブロックにおいて、HPACKの動的テーブルサイズやヘッダーの制限を厳格に絞る必要がある。
http {
# HTTP/2接続あたりの最大同時ストリーム数を制限し、攻撃の並行度を抑え込む
http2_max_concurrent_streams 128;
# HPACK動的テーブルの最大サイズをデフォルト（通常4096バイト）から厳しく制限、
# あるいは大きすぎるサイズ要求を拒絶する。
# ※Nginxのバージョンやモジュールに依存しますが、過大なテーブルを許容しない設定が不可欠
http2_max_field_size 4k;
http2_max_header_size 32k;
server {
listen 443 ssl http2;
server_name api.example.com;
# SSL/TLSの硬化
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
# タイムアウトを適切に設定し、スローloris的な嫌がらせを防ぐ
client_header_timeout 10s;
client_body_timeout 10s;
keepalive_timeout 65s;
location / {
proxy_pass http://backend_cluster;
# バックエンドへ転送する際のヘッダーサイズも必ず制限
proxy_buffers 8 16k;
proxy_buffer_size 32k;
}
}
}
② Envoy Proxyを用いる場合のサーキットブレーカーとリソース制限
マイクロサービスアーキテクチャの要塞であるEnvoyでは、過大なHTTP/2ヘッダーや動的テーブルに対する明確な制限値（`max_decoder_table_size`など）が用意されている。以下はYAML設定のキタスニペットだ。
static_resources:
listeners:
- name: http2_edge_listener
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
http2_protocol_options:
# HPACKの動的テーブルサイズの最大値を厳格に制限（例: 4096バイトに固定）
max_decoder_table_size: 4096
max_encoder_table_size: 4096
# 同時ストリーム数の上限設定
max_concurrent_streams: 100
# 初期流動ウィンドウサイズ
initial_stream_window_size: 65535
initial_connection_window_size: 1048576
route_config:
name: local_route
virtual_hosts:
- name: secure_backend
domains: [“”]
routes:
- match: { prefix: “/” }
route: { cluster: service_backend }
③ Linuxカーネルパラメータのチューニング（メモリ保護の観点）
アプリケーション層だけでなく、万が一メモリ枯渇（OOM）が発生した際のカーネル挙動や、ネットワークバッファの暴走を防ぐためのチューニングも忘れてはならない。`/etc/sysctl.conf` に以下のパラメータを記述し、システムのレジリエンスを高める。
TCPのメモリ割り当ての自動チューニング（最小値、デフォルト値、最大値：ページ単位またはバイト単位）
攻撃による異常なバッファ肥大化をカーネルレベルで一定抑制する
net.ipv4.tcp_mem = 786432 1048576 2677716
ソケットごとの受信バッファの最大値（過大なウィンドウによるメモリ圧迫を防ぐ）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
OOM Killerが発生した際、パニックさせずに迅速に該当プロセスを刈り取る設定
vm.oom_kill_allocating_task = 1
—
5. アーキテクトが心に刻むべき「効率性と安全性のトレードオフ」
HTTP/2のHPACK圧縮爆弾という脅威は、私たちにひとつの重要な真理を突きつけている。
「プロトコルにおける最適化と効率化は、常にアタックサーフェス（攻撃対象領域）の拡大と表裏一体である」ということだ。
動的テーブルという「文脈を記憶する機構」を持たせたことが、裏を返せば「受信側にステート（状態）を強烈に維持させる隙」を生んだ。HTTP/3（QUIC）およびそのヘッダー圧縮機構であるQPACKでは、この教訓を活かし、パケットの順序逆転によるHead-of-Line Blockingを防ぎつつ、動動的テーブルの参照エラーやメモリ枯渇に対するより堅牢な設計（ブロッキング制御の導入など）がなされている。しかし、最新のプロトコルに移行したからといって、インフラストラクチャの適切なリソース制限の重要性が消え去るわけではない。
私たちが構築するネットワークは、ただ速いだけでは価値がない。いかなる悪意あるパケットの洪水や、巧妙に仕組まれた圧縮爆弾が飛来しようとも、それを冷静にいなし、コアサービスを守り抜く「堅牢性」があって初めて、真に世界最高峰のインフラストラクチャと胸を張ることができるのだ。
今夜も、サーバーのログに潜む微小な異常値を見逃さぬよう、プロトコルのパルスに耳を澄まそう。
コメント