CDN Tsunamiとは？HTTP/3→HTTP/1.1変換を悪用するHBA・HCAの仕組みと対策

CDN Tsunamiとは？HTTP/3→HTTP/1.1変換を悪用するHBA・HCAの仕組みと対策

最終確認日：2026年8月10日
本記事は、Linらが2026年7月29日に公開した論文 CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks を中心に、RFC、CDN事業者、MITRE、Webサーバー各社の一次情報を照合して作成しています。
第三者システムへの攻撃手順やPoCは掲載せず、防御・確認・運用の観点に限定しています。

---

CDNは、本来Webサイトを高速化し、DDoS攻撃からオリジンサーバーを守るためにも使われます。

しかし、2026年7月に公開された研究「CDN Tsunami」は、そのCDN自身が持つHTTPプロトコル変換処理を増幅器として利用できる可能性を示しました。論文は、クライアントからCDNまでのHTTP/3と、CDNからオリジンまでのHTTP/1.1という「通信方式の差」に注目しています。

研究者は、次の2種類を提示しました。

• HBA（HTTP/3 Bandwidth Amplification）：オリジンへ転送されるデータ量を増幅する
• HCA（HTTP/3 Connection Amplification）：オリジンが保持する接続数・接続時間を増幅する

重要なのは、マルウェアをオリジンサーバーへ感染させる攻撃ではないことです。

また、「CDN Tsunami」という名称は論文著者が研究上付けた名称です。一般的な脆弱性分類名やCVE名ではありません。論文v1にはCVE番号やCVSSスコアは記載されておらず、2026年8月10日時点で本件固有のCVEは確認できません。

---

結論・要点

この記事の要点

• CDN TsunamiはHTTP/3とHTTP/1.1のプロトコル変換差を利用するDoS研究である。
• HBAはQPACKで圧縮されたHTTP/3ヘッダーがHTTP/1.1へ展開される際の帯域増幅を狙う。
• HCAはHTTP/3の多数ストリームからオリジン側の接続資源を長時間占有させる。
• 論文ではHBAが調査対象6 CDNすべて、HCAが6 CDN中5 CDNで成立した。
• Tranco Top 1M調査では42,330サブドメインが潜在的な攻撃条件を満たすと報告された。
• 42,330件は実際に侵害されたサイト数でも、個別に攻撃成功を確認したサイト数でもない。
• CDN Tsunamiには2026年8月10日時点で本件固有のCVEを確認できない。
• Cloudflareの現在の公式仕様ではHTTP/2 to Originがデフォルトで有効であり、論文測定時の状態を現在へそのまま適用してはいけない。
• WAFだけではHBA・HCAを完全に防げず、プロトコル変換・接続管理・オリジン保護を組み合わせる必要がある。
• オリジンへの直接アクセスを遮断し、CDN経由だけを許可する設計はCDN Tsunami以外の攻撃対策としても重要である。

論文では、HBAでQPACK Static Table利用時に最大約66倍、Dynamic Tableを利用した実験では最大約350倍の帯域増幅を観測しています。HCAについては、HTTP/3のHEADERSを受信した時点でオリジン接続を作るCDNの挙動と、低速なDATA転送を組み合わせることで接続資源を長時間保持できると報告しています。

---

この記事で分かること

この記事では次の内容を整理します。

• CDN Tsunamiとは何か
• HBAとHCAの違い
• QPACKがなぜ関係するのか
• CDNとオリジン間のプロトコル変換がなぜ問題になるのか
• Tranco Top 1Mの42,330件という数字の意味
• Cloudflare・CloudFront・Fastlyなどの現在の仕様との違い
• MITRE ATT&CKへどう整理できるか
• 自社サイトが影響を受けやすい構成か確認する方法
• CDN・WAF・Nginx・Apache・IISで行える対策
• WAF・IPS・EDRだけでは不十分な理由
• インシデント発生時の緊急対応
• 再発防止策

---

対象読者・前提環境

主な対象は次の担当者です。

• Webサーバー管理者
• インフラエンジニア
• SRE
• SOC担当者
• CSIRT担当者
• CDN運用担当者
• セキュリティエンジニア
• Nginx / Apache / IIS管理者
• Cloudflare / CloudFront / Fastlyなどを利用しているWebサイト運営者

特定のCDNを利用しているだけで「脆弱」と断定することはできません。

実際に使用されているプロトコル、CDN側の修正状況、オリジン構成を確認する必要があります。

---

用語と全体像

CDNとは

CDNは、Webサイトの手前に置かれる「世界中に配置された代理サーバー」のような仕組みです。

通常は次のように通信します。

利用者
  ↓
CDN Edge
  ↓
Origin Server

CDNはキャッシュを利用することで、同じコンテンツを毎回オリジンサーバーまで取りに行かずに返せます。

一方、ログイン処理、API、POST、動的ページなどでは、CDNからオリジンへ通信する必要があります。

---

HTTP/3とは

HTTP/3はQUICを利用するHTTPです。

HTTP/1.1やHTTP/2が主としてTCP上で動作するのに対し、HTTP/3はQUICを利用します。

HTTP/3では、1つのQUIC接続の中に複数の独立したストリームを作れます。RFC 9114では、HTTPリクエストのヘッダーはHEADERS frame、本文はDATA frameによって運ばれます。

---

QPACKとは

QPACKは「毎回長い住所を書く代わりに、住所録の番号だけ送る」ような仕組みです。

正式には、HTTP/3で利用されるHTTP Field Compression方式です。

たとえば長いヘッダー情報を毎回全部送信するのではなく、

「前に登録した番号5を使う」

のように小さなインデックスで表現できます。

RFC 9204では、QPACKにStatic TableとDynamic Tableが定義されています。

Static Table

あらかじめ決められている頻出HTTPヘッダーの一覧です。

Dynamic Table

通信中に追加されるヘッダー一覧です。

動的テーブルへ長い値を登録した後、そのインデックスを参照すれば、通信上は小さい表現で同じヘッダーを再利用できます。

CDN TsunamiのHBAは、この圧縮された表現とHTTP/1.1へ戻した後のサイズ差へ注目しています。

---

何が起きたのか

2026年7月29日、Ziyu Linらは、

CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks

をarXivへ公開しました。

論文はIEEE International Symposium on Reliable Distributed Systems（SRDS）2026への採択も記載しています。

研究対象は次の6 CDNでした。

論文の実験では、

と報告されています。

ただし、これは論文の実験環境における結果です。

各CDNの現在の設定・実装へそのまま当てはめることはできません。

---

CDN Tsunamiに関係する公開情報の時系列

Cloudflareの現在の公式文書と論文の実験結果には差があります。Cloudflareは2026年7月23日更新の公式文書で、HTTP/2 to Originをデフォルト有効と説明しています。したがって、論文の「CDN→OriginがHTTP/1.1だった」という測定結果を現在の全Cloudflare環境へ一般化するのは適切ではありません。

測定時期、プラン、オリジン側対応、設定差のどれが差異を生んだかは、公開情報だけでは確定できません。

---

Tranco Top 1Mで報告された42,330件とは

論文ではTranco Top 1Mをもとに大規模測定を行っています。

その結果、

• 脆弱と評価したCDN上に存在：151,685サブドメイン
• HTTP/3など攻撃前提条件を満たすと分類：42,330サブドメイン

と報告しています。

内訳は次のとおりです。

この数字は論文のFigure 5および本文に記載されています。

「42,330サイトが攻撃された」という意味ではない

ここは非常に重要です。

42,330は侵害件数ではありません。

論文では、

vulnerable CDN上に存在し、HTTP/3が有効で攻撃前提条件を満たした

ものを「potentially vulnerable」と分類しています。

したがって、

42,330件
=
攻撃成功確認済み

ではありません。

---

技術分析：HBA・HCA・攻撃チェーン

CDN Tsunamiでは、攻撃者がオリジンサーバーへマルウェアを感染させる必要はありません。

論文のThreat Modelは次の3者です。

攻撃者は通常のWeb利用者として、形式上有効なHTTP/3リクエストをCDNへ送信できることを前提としています。CDNがHTTP/3からHTTP/1.1へ変換する際に増幅が発生し、オリジンが被害を受けるというモデルです。

---

攻撃全体の流れ

---

HBA：HTTP/3 Bandwidth Amplification

HBAは帯域増幅型です。

簡単なたとえでは、

「CDNには小さな番号だけ渡したのに、CDNがオリジンへ巨大な文章として書き直して送る」

状態です。

---

HBAの仕組み

HTTP/3ではQPACKによってヘッダーを圧縮できます。

一方、論文が調査したHTTP/1.1 Originへの転送では、このQPACK表現をそのまま使えません。

そのためCDNは、

QPACK index
        ↓
元のHTTP Headerへ展開
        ↓
HTTP/1.1としてOriginへ転送

という処理を行います。

論文は、小さなQPACK indexが大きなHTTP/1.1 raw headerへ展開される差をHBAへ利用しています。

---

Static Tableを利用したHBA実験

論文のTable Vでは次の結果が報告されています。

Static Tableによる最大値は、論文実験では約66倍でした。

---

Dynamic Tableの場合

論文実験では、

• Alibaba
• Baidu
• Tencent

の3 CDNでQPACK Dynamic Tableを利用できたとしています。

実験上の設定では、

• Dynamic Table：4KB
• 最大Entry：3,072 bytes
• 最大Streams：128

でした。

Dynamic Tableを利用した実験では、同時Stream数の増加に伴って増幅率が上がり、約64 Stream付近で最大約350倍を観測しています。

それ以上増やすとCDN側のヘッダー展開処理そのものがボトルネックになり、増幅率が伸びなくなったと説明されています。

注意

「すべてのCDNで350倍」という意味ではありません。

350倍はDynamic Tableを利用した論文実験の最大観測値です。

---

HCA：HTTP/3 Connection Amplification

HCAは接続資源増幅型です。

簡単なたとえでは、

「利用者側では1本の高速道路なのに、CDNから先では大量の駐車スペースを長時間占有させる」

ような攻撃です。

---

HTTP/3のMultiplexing

HTTP/3では、1つのQUIC connection内で複数のrequest streamを並行処理できます。

RFC 9114でも、HTTP/3ではQUICのStreamをHTTP Transactionへ対応させる構造が定義されています。

---

HCAの問題

論文が調査した一部CDNは、HTTP/3のHEADERS frameを受信すると、リクエスト本文がまだ完了していなくてもCDN→Origin接続を開始していました。

攻撃者がその後DATA frameを非常にゆっくり送ると、

HTTP/3 Stream
      ↓
CDN
      ↓
Origin Connection
      ↓
まだRequestが終わっていない
      ↓
接続を保持

という状態になります。

多数のStreamが同様の状態になることで、オリジン側の、

• TCP connection
• socket
• worker
• request slot
• keep-alive関連資源

などが圧迫されます。

---

CloudflareだけHCAの挙動が異なった

論文の6 CDN実験では、CloudflareはHTTP/3 Request全体を受信してからOrigin接続を開始しました。

そのため研究者は、CloudflareについてHCAに対してimmuneだったと評価しています。

一方、Fastlyは最初の10 StreamについてOrigin接続を早期に開始し、その後のRequestをqueueへ回す挙動を示しました。

これはHCAの増幅を抑える方向ではありますが、論文ではFastlyを含む5 CDNをHCAの影響対象として評価しています。

---

HBAとHCAの違い

---

根本原因

論文は根本原因を、

HTTP/3がEnd-to-Endで利用されず、CDNでHTTP/3→HTTP/1.1変換が必要になること

と整理しています。

HTTP/3には、

• QPACK
• Multiplexing

という効率化機能があります。

しかしHTTP/1.1へ変換すると、その効率性が失われます。

CDN Tsunamiは、この「効率の落差」を逆方向に利用します。

---

現在のCDN仕様は論文実験時と同じとは限らない

ここは今回の修正版で特に重要な部分です。

Cloudflare

Cloudflareは現在、利用者→Cloudflare間でHTTP/3をサポートしています。

一方、Cloudflare公式文書ではHTTP/3 to Originはまだサポートしていないと明記されています。

ただし、2026年7月23日更新の公式資料では、

HTTP/2 to Origin is enabled by default

とされています。

つまり現在は、

Client
 HTTP/3
   ↓
Cloudflare
 HTTP/2
   ↓
Origin

となる構成も存在します。

これは論文が主に扱った、

HTTP/3
 ↓
HTTP/1.1

という条件とは異なります。

結論

「Cloudflareを使っているから現在もHBA対象」と単純には判断できません。

実際のOrigin protocolを確認する必要があります。

---

Amazon CloudFront

現在のAWS公式文書では、Custom OriginへのRequestについて、

CloudFront forwards requests to your custom origin using HTTP/1.1.

と明記されています。

またCloudFrontではHTTP/3をViewer側で利用できます。

そのためプロトコル構造としては、

Viewer HTTP/3
       ↓
CloudFront
       ↓
Origin HTTP/1.1

という論文が問題視した構成が現在も成立し得ます。

ただし、AWS側の追加緩和策や実装変更まで含めて現在の脆弱性をこの記事だけで断定することはできません。

---

Fastly

FastlyはHTTP/3をEnd User→Fastly間で提供しています。

公式文書は、

FastlyとOrigin Server間ではHTTP/3をサポートしない

と明記しています。

論文ではFastlyについて、

• HBA成立
• HCA成立
• HCAのBackend fan-outを10 Stream程度に抑制

という挙動を報告しています。

現在の個別サービス設定については別途確認が必要です。

---

Akamai

AkamaiはClient→Edge間のHTTP/3を公式にサポートしています。

しかし、CDN Tsunami論文の6 CDNにAkamaiは含まれていません。

したがって、

AkamaiもCDN Tsunamiに脆弱

と結論づける根拠はありません。

---

Azure Front Door

Azure Front DoorもCDN Tsunami論文の評価対象ではありません。

現在のMicrosoft公式FAQではAzure Front Doorが、

• HTTP
• HTTPS
• HTTP/2

をサポートし、Edge→OriginについてHTTP/1.1を利用すると説明されています。

2026年のMicrosoft Q&AでもHTTP/3は現在サポートされていないと回答されています。

したがって2026年8月10日時点では、論文のClient→CDN HTTP/3という前提条件を満たさないため、CDN TsunamiそのものをAzure Front Doorへ直接当てはめることはできません。

---

CVE・深刻度・悪用状況

Baiduは論文著者の報告に対してHBAをHigh、HCAをMediumと評価し、TencentはHCAをMediumとして扱ったと記載されています。両社はbug bountyを支払い、緩和策を導入したとされています。

これはCVSS評価とは別物です。

---

MITRE ATT&CKとの関係

ここも表現に注意が必要です。

MITRE ATT&CKは2026年8月10日時点で、

CDN Tsunami = T1498

のような公式マッピングを公開しているわけではありません。

以下は技術的性質からの筆者整理です。

MITREはT1498をNetwork Denial of Service、T1499をEndpoint Denial of Serviceとして定義しています。

T1498.002 Reflection Amplificationとは区別した方がよい

CDN Tsunamiでは通常のDNS/NTP Reflection攻撃のようなIP Spoofingを前提としていません。

そのため、

HBA = T1498.002

と機械的に決めるより、まずT1498親Techniqueとして整理する方が安全です。

---

自分のサイトに関係するか確認する

以下を順番に確認します。

---

HTTP/3が公開されているか確認する

目的

Client→CDNでHTTP/3が利用可能か確認します。

実行場所

管理者PC。

コマンド

curl --http3 -I https://www.example.com/

正常例

HTTP/3 200

異常・確認対象例

curl: option --http3: the installed libcurl version does not support this

この場合、Webサイトではなくcurl自身がHTTP/3非対応です。

判断

HTTP/3で正常に応答する場合、Client→CDN側ではCDN Tsunamiの前提条件の一つを満たします。

ただしHTTP/3が利用できるだけでは脆弱性確定にはなりません。

---

Alt-Svcを確認する

目的

HTTP/3が広告されているか確認します。

実行場所

管理者PC。

コマンド

curl -sSI https://www.example.com/ | grep -i '^alt-svc:'

正常例

alt-svc: h3=":443"; ma=86400

異常例

何も表示されない。

判断

h3が含まれていればHTTP/3が広告されています。

ただしHTTP/3の発見方法はAlt-Svcだけではないため、Alt-SvcがないことだけでHTTP/3非対応とは断定しないでください。

---

CDN→Originで実際に使われているプロトコルを確認する

CDN管理画面だけでなく、可能ならOriginログでも確認します。

Nginxでは$server_protocolをログへ記録できます。

目的

Originが実際にHTTP/1.1、HTTP/2のどちらでCDNからRequestを受けているか確認します。

実行場所

Origin Server。

現在のログ設定確認

sudo nginx -T 2>/dev/null | grep -nE 'log_format|server_protocol'

正常例

log_format main '$remote_addr ... $server_protocol ...';

判断

$server_protocolがログへ含まれていれば、実アクセスログから、

HTTP/1.1
HTTP/2.0

などを確認できます。

注意

nginx -Tは設定内容を表示するだけですが、秘密情報を含む設定が出力される場合があります。

結果をそのまま外部へ公開しないでください。

---

Originが直接公開されていないか確認する

CloudflareなどのCDNを使っていても、Origin IPへ直接アクセスできればCDNを迂回できます。

Cloudflare自身もOrigin IPを保護し、Cloudflare経由だけを許可する構成を推奨しています。Authenticated Origin PullsではmTLSによりCloudflareからのOrigin Requestを認証できます。

目的

CDNを経由しないアクセスが遮断されているか確認します。

実行場所

自社管理PC。

注意

自分が管理しているOrigin以外へ実行してはいけません。

コマンド

curl -I \
  --resolve www.example.com:443:ORIGIN_IP \
  https://www.example.com/ \
  --max-time 10

望ましい結果

403 Forbidden

または、

Connection refused
Connection timed out
TLS client certificate required

要注意

HTTP/1.1 200 OK

判断

Originが直接200を返す場合、CDN迂回アクセスが可能な可能性があります。

CDN Tsunami対策とは別に、Origin保護を見直すべき状態です。

---

Originの接続数を確認する

目的

HCA型の接続資源枯渇を監視します。

実行場所

Origin Server。

ss -Htan state established '( sport = :443 )' | wc -l

正常

通常時ベースライン付近。

異常

Request数の増加に比べて、Origin Connection数だけが急上昇する。

判断

Connection数だけで攻撃と断定してはいけません。

通常トラフィック、Batch処理、Health Check、CDN POP変更などでも増加します。

---

Origin帯域を確認する

目的

HBA型の異常を確認します。

実行場所

Origin Server。

sysstatが導入済みの場合、

sar -n DEV 1 5

正常

平常時のRX/TX帯域周辺。

異常

CDN側Request件数の増加が小さいにもかかわらず、Originへの受信帯域が急増する。

判断

単純な帯域増加だけではHBAとは断定できません。

Request size、header size、CDNログ、Origin connectionを併せて確認します。

---

対策方法

対策は、

1. 緊急対応
2. 短期対策
3. 中長期対策

に分ける方が安全です。

---

緊急対応

CDN事業者へ現在の緩和状況を確認する

まずCDNベンダーへ、

CDN Tsunami
HTTP/3 Bandwidth Amplification
HTTP/3 Connection Amplification
arXiv:2607.26589

を示し、

• 自分の契約プランが影響するか
• HBA mitigationが実装済みか
• HCA mitigationが実装済みか
• Origin protocol
• Request buffering
• Backend connection fan-out limit
• QPACK limit

を確認します。

論文ではBaiduとTencentが緩和策を導入済みとされています。その他のベンダーは論文v1時点で内部検討中と記載されています。

---

HTTP/3を一時停止する

攻撃を受けており、ベンダー側の修正状況も確認できない場合、

HTTP/3を一時的に無効化

することで論文の前提条件を一つ取り除けます。

CloudflareやFastlyにはHTTP/3を無効化する設定があります。

ただし、恒久対策としてHTTP/3を無効化することは推奨しません。

HTTP/3の性能上の利点を失いますし、HTTP/2→HTTP/1.1変換を研究した過去の類似攻撃も存在します。

---

論文が提案するHBA対策

論文はHBAに対して、プロトコル変換レイヤーで増幅率を制限することを提案しています。

Dynamic Table Entryの最大サイズを制限

論文例：

1 Header Entry ≦ 512 bytes

注意

512 bytesは論文の提案例です。

すべてのサービスへそのまま設定すべき標準値ではありません。

---

同じHeader Indexの参照回数を制限

論文例：

同一Dynamic Table Entry
≦ 10 references / stream

これにより、同じ大きなHeaderを大量参照して増幅する手法を制限します。

---

QPACK展開後のRequest Sizeを制限

論文例：

decompressed HTTP/1.1 request
≦ 64 KB

QPACK解凍後に上限を超えたRequestをOriginへ送らず、CDN EdgeでRejectする考え方です。

最も重要な点

この対策はCDN事業者側で実装するのが最も効果的です。

Originに到達した時点では、すでに増幅後だからです。

---

論文が提案するHCA対策

Store-then-forward

HTTP/3 Request全体、

HEADERS
+
DATA

を受信してからOrigin Connectionを作ります。

論文ではCloudflareがこの方式に近い動作をしており、HCAが成立しなかったと報告しています。

---

Backend Fan-outを制限する

1 HTTP/3 Client Connection
        ↓
作成可能なOrigin Connection数
        ↓
上限設定

とします。

論文ではFastlyが最初の10 StreamにOrigin Connectionを制限していたと報告しています。

---

Origin Connection TimeoutをClientから独立させる

Client→CDN connectionが長時間続いていても、

CDN→Origin connection

まで無期限に維持しないようにします。

論文では「30秒」などを例として提示しています。

30秒は参考値です。

アプリケーションの、

• File Upload
• Streaming
• Long Polling
• WebSocket
• AI inference
• 大規模API

などでは長い時間が必要になる場合があります。

---

Cloudflareで行う対策

HTTP/2 to Originを確認する

Cloudflareでは現在HTTP/2 to Originがデフォルト有効です。

OriginがHTTP/2へ対応している場合は、実際にHTTP/2が利用されているか確認します。

論文のHBA/HCAが前提としたHTTP/3→HTTP/1.1変換を避ける方向の設計になります。

ただし、HTTP/2だから自動的に安全と断言することはできません。

---

Authenticated Origin Pullsを利用する

Cloudflare AOPはmTLSでOrigin RequestがCloudflareから来たことを確認できます。

Internet
   ↓
Cloudflare
   ↓ mTLS
Origin

とすることで、Originへの直接アクセスを制限できます。

---

Cloudflare IPだけを許可する

Origin firewallでもCloudflare IP Rangeだけを許可します。

CloudflareもOrigin保護策としてCloudflare IPのallowlistを案内しています。

ただし可能なら、

IP Allowlist
+
Authenticated Origin Pull

の二重構成が望ましいです。

---

Rate Limitingを利用する

Cloudflare WAFではRate Limiting Ruleを設定できます。

ただし、単純に、

100 requests / IP

のような固定値をこの記事からコピーしないでください。

通常トラフィックのp95/p99を確認し、正規ユーザーを遮断しない値を設定します。

---

Amazon CloudFrontで行う対策

CloudFront Custom Originへの通信は現在HTTP/1.1です。

そのため次の対策が重要です。

---

Origin Request Policyを最小化する

Originへ送る、

• Headers
• Cookies
• Query Strings

を必要なものだけに限定します。

CloudFrontではOrigin Request PolicyでOriginへ転送する情報を制御できます。

---

Custom HeaderでOrigin直接アクセスを防ぐ

CloudFrontはOrigin RequestへCustom Headerを追加できます。

Origin側でそのHeaderを持つRequestだけ許可すれば、直接アクセスを制限できます。

---

AWS上のOriginならCloudFront Prefix Listを利用する

AWS VPC内のOriginでは、CloudFront origin-facing server用Managed Prefix ListによってCloudFront以外からの接続を制限できます。

---

AWS WAF Rate-Based Rule

AWS WAFではRequestを集計してRate Limitを適用するRate-Based Ruleがあります。

CDN Tsunami対策だけでなく、

• API Abuse
• Credential Stuffing
• Scraping
• L7 DoS

などにも有効です。

---

Fastlyで行う対策

FastlyではEdge Rate Limitingを利用できます。

Fastly公式文書もDDoSやBot abuseからOriginを保護する用途を示しています。

またFastlyでは現在、HTTP/3はEnd User Connectionのみで提供され、OriginへのHTTP/3はサポートされていません。

したがって、

• Backend Connection制御
• Rate Limiting
• Edge WAF
• Shielding
• Origin認証

を併用します。

---

Nginxで行う対策

NginxにはRequest Header、Body、Connection、Request Rateを制御する仕組みがあります。

---

現在の設定を先に確認する

sudo nginx -T 2>/dev/null | \
grep -E 'client_header_timeout|client_body_timeout|large_client_header_buffers|client_max_body_size|limit_conn|limit_req'

目的

既存設定を変更する前に現状を把握します。

正常

想定した制限値が表示される。

異常

制限が一切なく、アプリケーション要件も把握できていない。

判断

数値を決める前に正常通信を計測します。

---

設定変更前にBackupを取得する

sudo cp -a /etc/nginx /etc/nginx.backup-$(date +%Y%m%d-%H%M%S)

---

設定後は必ずSyntax Checkする

sudo nginx -t

正常

syntax is ok
test is successful

異常

emerg
configuration file test failed

異常の場合はReloadしません。

---

limit_connの注意

Nginxのlimit_connは接続数制限に利用できます。

しかしOriginがCDNの後ろにある場合、

$remote_addr
=
CDN Edge IP

になっている可能性があります。

その状態でCDN IP単位に厳しいlimit_connを掛けると、

大量の正規ユーザーまでまとめて遮断する可能性があります。

これはHCA対策で特に注意すべき点です。

---

Apache HTTP Serverで行う対策

Apacheにはmod_reqtimeoutがあります。

Request HeaderやBodyの受信Timeoutと最低転送速度を指定できます。

代表的なDirectiveは、

RequestReadTimeout

です。

Apache公式の例には、

RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

などがあります。

ただし、この値をそのまま本番環境へコピーしないでください。

Uploadや低速回線ユーザーへ影響する可能性があります。

---

Microsoft IISで行う対策

IISではRequest FilteringのrequestLimitsによって、

• Request size
• URL length
• Query string
• HTTP Header

を制限できます。

特にheaderLimitsはHTTP Headerごとの最大サイズを設定できます。

HBAのような「展開後Headerが大きくなる」状況に対して、Origin側の最後の防御層として利用できます。

---

WAFは有効か

有効ですが、WAFだけでは不十分です。

Cloudflare、AWS、FastlyはいずれもEdge Rate Limiting機能を提供しています。

しかしCDN Tsunamiの本質は、

Client Request
        ↓
CDN内部で変換
        ↓
Origin Requestが増幅

です。

WAFがClient Requestだけを見ている場合、

Client側では小さいRequest

に見える可能性があります。

したがって、

• 展開後Header Size
• Backend fan-out
• Backend Connection lifetime
• Origin egress/ingress bytes
• Cache MISS
• Origin Request rate

まで監視する必要があります。

---

IPSは有効か

Origin手前のIPSでは、

CDN
 ↓
IPS
 ↓
Origin

という位置になります。

この場所で見える通信はすでに、

HTTP/3
↓
HTTP/1.1またはHTTP/2

へ変換された後です。

つまりQPACK indexや元のHTTP/3 Stream情報を確認できない場合があります。

さらに論文自身も、Originから見ると攻撃Trafficが「正規のCDNから来た通信」に見えるため従来型DDoS Detectionが難しいと指摘しています。

IPSは補助対策として有効ですが、CDN Edge Telemetryとの連携が重要です。

---

EDRは有効か

EDRは主にEndpoint内部を監視します。

そのためCDN Tsunamiの通信を入口で止める装置ではありません。

一方で、

• Web Server process CPU
• Memory
• Socket
• File Descriptor
• Worker saturation
• 5xx
• Process restart
• Network throughput

を監視することで、HCA/HBAによる異常を検知するEvidence sourceとして利用できます。

つまり、

WAF / CDN
=
予防・遮断

IPS
=
Network補助検知

EDR
=
Origin異常検知・Evidence収集

という役割分担が適しています。

---

キャッシュ設定も重要

論文では、OriginへRequestを到達させるためにCDN Cacheを回避できる複数のRequest特性を調査しています。

そのため、

キャッシュ率を上げれば100%防げる

とは言えません。

ただしOriginへ転送されるRequestそのものを減らすことは有効です。

確認する項目は、

• Cache Key
• Query String
• Cookie
• Authorization
• Dynamic Route
• TTL
• POST/PUT
• API endpoint
• Cache bypass rule

です。

---

動作確認

対策後は攻撃再現ではなく、正常Trafficによる安全なVerificationを行います。

---

HTTP/3確認

curl --http3 -I https://www.example.com/

意図的に無効化した場合はHTTP/3接続できないことを確認します。

---

通常HTTPS確認

curl -I https://www.example.com/

期待値：

HTTP/2 200

または環境に応じた正常Status。

---

Origin直接アクセス確認

curl -I \
  --resolve www.example.com:443:ORIGIN_IP \
  https://www.example.com/ \
  --max-time 10

期待値：

403

または接続拒否。

---

Nginx Configuration確認

sudo nginx -t

期待値：

syntax is ok
test is successful

---

Monitoring確認

変更前後で最低でも、

を比較します。

---

再発防止

CDN→Origin Protocolを定期監査する

CDN事業者は機能を更新します。

今回のCloudflareのように、論文測定時の挙動と現在の公式仕様が一致しない場合があります。

そのため、

Client → CDN
CDN → Origin

を別々に監査します。

---

OriginをInternetへ直接公開しない

理想形は、

Internet
   ↓
CDN / WAF
   ↓
認証
   ↓
Origin

です。

IP allowlistだけでなく、

• mTLS
• Private Link
• VPC Origin
• Authenticated Origin Pull
• Secret Header

などを利用します。

Cloudflare AOPやCloudFront Custom Header/VPC Originはこの目的に利用できます。

---

Origin Capacityを監視する

少なくとも、

Bandwidth
Connections
Sockets
Workers
CPU
Memory
5xx
Latency

を監視します。

HBAとHCAでは枯渇する資源が違うため、Request数だけの監視では不十分です。

---

Runbookを作る

例：

HTTP/3異常検知
      ↓
CDN Status確認
      ↓
Origin Connection確認
      ↓
Origin Bandwidth確認
      ↓
CDN Supportへ連絡
      ↓
Rate Limit強化
      ↓
必要ならHTTP/3一時停止
      ↓
Origin Capacity保護
      ↓
復旧
      ↓
Postmortem

---

注意点・よくある誤解

誤解1：42,330サイトが攻撃された

違います。

42,330は論文が、

潜在的に攻撃条件を満たす

と分類したサブドメイン数です。

個別のAttack Successを42,330件確認したわけではありません。

---

誤解2：Cloudflareは現在も必ずHTTP/1.1 Originだから危険

現在は正しくありません。

Cloudflare公式文書ではHTTP/2 to Originがデフォルト有効です。

実際の環境を確認してください。

---

誤解3：WAFを入れていれば安全

安全とは言えません。

CDN TsunamiはCDN内部のProtocol Conversion自体を利用する研究です。

WAFは重要ですが、Backend Connection制御やOrigin監視も必要です。

---

誤解4：CDN Tsunamiはマルウェア

違います。

VirusやTrojanではありません。

HTTP/3とCDNのプロトコル変換を利用するDoS手法です。

---

誤解5：必ずDDoSと呼ぶべき

論文タイトルはDoS Attacksです。

研究では一般的なLaptopからの攻撃でも成立可能としています。一方でCDN Edgeが分散しているため、結果として複数CDN NodeからOriginへTrafficが届く可能性があります。

したがって、

HTTP/3 amplification DoS

と呼ぶ方が原論文に忠実です。

---

否定的・批判的に見るべき点

「CDN Tsunami」という名前だけが先行する危険がある

インパクトの強い名称ですが、単一のCVEでもマルウェアキャンペーンでもありません。

技術的には、

HTTP/3
+
QPACK / Multiplexing
+
CDN Protocol Conversion
+
Origin Resource Exhaustion

という問題です。

名前だけで判断すると対策を誤ります。

---

WAF導入だけで完了させるのは危険

HBA/HCAはRequest数だけでは特徴が見えにくい可能性があります。

Origin Connectionや転送Byteまで見る必要があります。

---

マルチCDNは万能ではない

複数CDNへ切り替えられる構成は可用性上の利点があります。

しかし複数CDNが同じ、

HTTP/3 Edge
→
HTTP/1.1 Origin

構成を持っていれば、同じ種類の問題を共有する可能性があります。

さらに、

• DNS切替
• Cache Rule差異
• Header差異
• WAF Rule差異
• Log形式差異
• Certificate管理

が増えます。

「マルチCDNにすれば解決」と考えるのは危険です。

---

HTTP/3を永久に無効化するのも適切ではない

HTTP/3を止めれば今回の攻撃前提を一つ外せます。

しかしHTTP/3の性能メリットも失います。

さらに過去にはHTTP/2→HTTP/1.1変換を扱う類似研究もあります。

恒久策はProtocol Conversion LayerそのもののHardeningです。

---

Originで単純なIP Rate Limitを掛けると逆効果になる

CDNの後ろでは、多数のUserが同じCDN Edge IPからOriginへ到達します。

そのCDN IPへ厳しいConnection Limitを設定すると、

攻撃者1人
+
正規利用者数千人

をまとめて遮断する可能性があります。

Rate LimitはEdge側のClient Identityを利用できる場所で行う方が安全です。

---

まとめ

CDN Tsunamiは、CDNのDDoS防御能力そのものを破る単純なTraffic Floodではありません。

ポイントは、

HTTP/3の効率性
        ↓
CDNでProtocol変換
        ↓
HTTP/1.1側では非効率な形へ展開
        ↓
Origin資源が増幅消費される

という構造です。

HBAはQPACK Header Compressionを帯域増幅へ利用します。

HCAはHTTP/3 MultiplexingとBackend Connectionの生成タイミングをConnection Resource Exhaustionへ利用します。

論文では、

HBA
6 / 6 CDN

HCA
5 / 6 CDN

Potentially vulnerable
42,330 subdomains

という結果を報告しています。

しかし2026年8月現在、CDN各社の仕様は論文測定時から変化している可能性があります。

特にCloudflareではHTTP/2 to Originが現在デフォルト有効であり、論文の実験結果を現在の全環境へそのまま当てはめるべきではありません。

最も重要なのは「自分の環境で何が実際に起きているか」を確認することです。

HTTP/3利用状況
       ↓
CDN→Origin Protocol
       ↓
Cache Behavior
       ↓
Origin直接アクセス
       ↓
Header Size
       ↓
Connection数
       ↓
Bandwidth
       ↓
5xx / Latency

まで一貫して監視してください。

---

FAQ

Q. CDN TsunamiにはCVEがありますか？

2026年8月10日時点で、本件固有のCVEを確認できません。

論文v1にも共通CVE番号は記載されていません。

---

Q. CVSSはいくつですか？

共通CVSSは確認できません。

論文ではBaiduがHBAをHigh、HCAをMedium、TencentがHCAをMediumと評価したことが記載されていますが、これは共通CVSSとは異なります。

---

Q. Cloudflareを使っている場合は危険ですか？

それだけでは判断できません。

論文実験ではHBAが成立しましたが、現在のCloudflareはHTTP/2 to Originをデフォルト有効としています。実際のOrigin Protocolを確認してください。

なお論文のHCA実験ではCloudflareだけがRequest全体を受け取ってからOrigin接続を行い、HCAが成立しませんでした。

---

Q. CloudFrontはどうですか？

現在のAWS公式仕様ではCustom OriginへのRequestはHTTP/1.1です。

Viewer側ではHTTP/3を利用できます。

したがってProtocol構成は論文の研究対象と近いですが、現在のAWS実装が未修正であるとこの記事だけで断定することはできません。

---

Q. HTTP/3を止めれば完全に安全ですか？

いいえ。

今回のHTTP/3攻撃条件を外す効果は期待できますが、他のHTTP/1.1・HTTP/2 DoS攻撃まで防げるわけではありません。

一時的な緊急対応として考えるべきです。

---

Q. WAFだけで防げますか？

完全ではありません。

WAF、Rate Limitに加えて、

• Backend Connection limit
• Request buffering
• QPACK展開後Size制限
• Origin access restriction
• Timeout
• Monitoring

が必要です。

---

Q. IPSだけで検知できますか？

難しい場合があります。

Origin側IPSにはProtocol Conversion後のTrafficしか到達しない可能性があります。

CDN LogとOrigin Logを相関させることが重要です。

---

Q. EDRは役に立ちますか？

遮断装置としては主役ではありません。

しかし、

• socket急増
• worker枯渇
• CPU
• Memory
• Network throughput
• Process failure

を検出するEvidence Sensorとして有効です。

---

Q. OriginがHTTP/2なら安全ですか？

論文の中心であるHTTP/3→HTTP/1.1変換条件からは外れる方向です。

ただし「HTTP/2であればすべてのDoS攻撃に安全」という意味ではありません。

CDN事業者の現在の実装確認が必要です。

優先参考情報