TCP SYNフラッド攻撃とは？種類・仕組み・進化・Linux防御を詳しく解説

はじめに

TCP SYNフラッド攻撃は、TCP通信を開始するための「3ウェイ・ハンドシェイク」を途中で止め、サーバーやファイアウォールに大量の未完了接続を抱えさせるDoS・DDoS攻撃です。

この攻撃は1990年代から知られています。しかし、過去の攻撃になったわけではありません。

現代のSYNフラッドは、単純にサーバーの接続キューを埋めるだけではありません。大量のパケットで回線やネットワーク機器を圧迫する攻撃、ボットネットから低レートで分散送信する攻撃、複数のIPアドレスへ広く散布するカーペット・ボミングなどへ発展しています。

Cloudflareの2025年第1四半期DDoSレポートでも、SYNフラッドはネットワーク層における最も多く観測された攻撃ベクトルと報告されています。したがって、SYN Cookieを有効にするだけではなく、サーバー、ネットワーク機器、CDN、DDoS対策事業者を組み合わせた多層防御が必要です。

結論・要点

TCP SYNフラッド攻撃の本質は、次の2種類に分けて考えると理解しやすくなります。

1つ目は、サーバーやファイアウォールに未完了接続の状態を大量に保持させる状態枯渇型です。

2つ目は、大量のSYNパケットを送り込み、回線帯域、ルーター、NIC、CPU、パケット処理能力を使い切らせる帯域・パケットレート枯渇型です。

現代の大規模攻撃では、両方が同時に発生します。

大量のSYN
   │
   ├─ 接続状態を大量に作らせる
   │      └─ SYN backlog、FWセッション表の枯渇
   │
   └─ 大量のパケットを処理させる
          └─ 回線、NIC、CPU、ルーターの枯渇

防御では、次の順序が重要です。

送信元IP詐称を上流ネットワークで防ぐ
CDNやDDoS対策サービスで攻撃を手前に吸収する
SYN ProxyやSYN Cookieで接続元を確認する
OSの接続キューと再送設定を確認する
PPS、SYN/ACK比率、SYN_RECV数を継続監視する
大規模攻撃では、自サーバーへ到達する前に遮断する

この記事で分かること

この記事では、次の内容を解説します。

TCP SYNフラッド攻撃で何が起きるのか
正常なTCP接続との違い
直送型、IP偽装型、分散型、反射型などの分類
SYNフラッド攻撃がどのように進化してきたか
SYN CookieとSYN Proxyの違い
Linuxで確認すべき項目
CDN、Anycast、XDPなどを使った現代的な防御
誤検知を防ぎながら監視する方法
インシデント発生時の対応方法

対象読者・前提環境

対象読者は次のとおりです。

Linuxサーバーを運用している人
WebサービスやAPIを公開している人
AWS、VPS、自宅サーバーを運用している人
DDoS対策を学びたい人
基本情報技術者試験や情報処理安全確保支援士を学習している人
Nginx、ロードバランサー、ファイアウォールを管理している人

確認例ではLinuxを使用します。

ディストリビューションやカーネルのバージョンによって、標準値や表示内容が異なる場合があります。設定値を変更する前に、現在値と通常時の通信量を記録してください。

何が起きたか

TCP SYNフラッドは接続開始処理を途中で止める攻撃

TCP通信では、クライアントとサーバーが通信を始める前に、3段階の確認を行います。

荷物を送る前に、電話で次の確認をする場面を想像すると分かりやすくなります。

クライアント：「通信を始めてもよいですか」
サーバー：「よいです。こちらも準備できました」
クライアント：「確認しました。始めます」

正式には、次のパケットを交換します。

クライアント                          サーバー
     │                                  │
     │ -------- SYN ------------------> │
     │                                  │ SYN_RECV
     │ <------- SYN-ACK --------------- │
     │                                  │
     │ -------- ACK ------------------> │
     │                                  │ ESTABLISHED

SYN：接続開始要求
SYN-ACK：接続開始要求への応答
ACK：応答を受け取ったことの確認

SYNフラッド攻撃では、攻撃者が大量のSYNを送信した後、最後のACKを返しません。

攻撃者                               サーバー
  │                                     │
  │ -------- SYN ---------------------> │
  │ <------- SYN-ACK ------------------ │
  │                                     │
  │              ACKを返さない          │
  │                                     │
  │ -------- SYN ---------------------> │
  │ -------- SYN ---------------------> │
  │ -------- SYN ---------------------> │

サーバー側には、完了していない接続要求が大量に残ります。

RFC 4987は、SYNフラッドを「SYNを受け取った後にTCPが一定時間保持する状態を悪用し、正規接続に必要な資源を使い切らせる攻撃」と説明しています。

自分に関係するか

インターネットへTCPサービスを公開していれば対象になる

次のようなサービスはSYNフラッドの対象になり得ます。

サービス	主なポート例
HTTP	TCP 80
HTTPS	TCP 443
SSH	TCP 22
SMTP	TCP 25、587
PostgreSQL	TCP 5432
MySQL	TCP 3306
VPN	製品による
独自TCPサービス	任意

ただし、危険度は構成によって異なります。

影響を受けやすい構成

サーバーのグローバルIPを直接公開している
回線帯域が小さい
VPSの前段にCDNやDDoS対策がない
ステートフルファイアウォールの接続表が小さい
TCPサービスを広範囲へ公開している
SYN_RECV数やPPSを監視していない
上流事業者とのDDoS対応手順が決まっていない

比較的影響を抑えやすい構成

Web通信をCDNやリバースプロキシ経由に限定している
オリジンサーバーへの直接通信を遮断している
Anycast型DDoS対策を利用している
SYN Proxyが前段にある
SSHや管理画面をVPN内に限定している
上流で攻撃トラフィックを破棄できる

原因

原因はTCPの状態管理と攻撃コストの非対称性

SYNフラッドの根本には、攻撃側と防御側の負担差があります。

攻撃者は、SYNパケットを1個送るだけで済みます。

一方、受信側は次の処理を行います。

TCPヘッダーを検証する
接続要求を管理する
SYN-ACKを生成して返す
ACKを待つ
必要に応じてSYN-ACKを再送する
タイムアウトまで状態を管理する

つまり、攻撃者が小さな負担で、防御側へより大きな処理を発生させます。

この構造を、状態保持の非対称性と表現できます。

Linuxでは未完了接続をSYN backlogで管理する

TCPの待ち行列は、初心者向けには次の2段階で考えると理解しやすくなります。

SYN受信
  │
  ▼
SYN backlog
未完了の接続要求
  │ ACK受信
  ▼
accept queue
接続完了済みだがアプリが未受領
  │ accept()
  ▼
アプリケーション

Linuxでは、ACKをまだ受け取っていない接続要求がSYN_RECV状態として管理されます。

net.ipv4.tcp_max_syn_backlogは、ACKを受け取っていない接続要求を、リスニングソケットごとにどれだけ記憶するかに関係する設定です。

Linuxカーネル資料では、SYN_RECVのrequest socketは約304バイトを消費すると説明されています。したがって、「SYNを1件受けるたびに完全なTCPソケットと同じ大きさのTCBを割り当てる」と説明するのは、現在のLinux実装としては単純化しすぎです。

SYN backlogとaccept queueは別物

次の2つは混同しやすい項目です。

キュー	保持するもの	主な関連設定
SYN backlog	ハンドシェイク未完了の要求	`tcp_max_syn_backlog`
accept queue	接続完了後、アプリ未acceptの接続	`somaxconn`、`listen()`のbacklog

SYNフラッドが直接狙う中心はSYN backlogです。

一方、アプリケーションの処理が遅く、確立済み接続を取り出せない場合はaccept queueが問題になります。

両者を同じ「backlog」として説明すると、原因調査を誤る可能性があります。

タイムアウトは常に数分とは限らない

Linuxのtcp_synack_retriesは、受動接続でSYN-ACKを再送する回数を制御します。

現行Linuxのカーネル資料では、標準値5の場合、最後の再送まで約31秒、接続要求が最終的に破棄されるまで約63秒と説明されています。

ただし、次の条件で時間は変わります。

OSとカーネルの種類
カーネルバージョン
再送回数の設定
SYN Cookieの使用状態
ファイアウォールやロードバランサーの実装
クラウド事業者の前段防御

そのため、「通常75秒」「必ず数分」と固定して書くのは適切ではありません。

TCP SYNフラッド攻撃の分類

分類は「送信方法」と「枯渇させる資源」を分けて考える

SYNフラッドは、1つの軸だけでは整理できません。

次の4つの軸で分類すると、現代の攻撃を理解しやすくなります。

分類軸	例
送信元	単一ホスト、ボットネット、反射サーバー
IPアドレス	実IP、偽装IP、被害者IPへの偽装
宛先	単一IP、複数ポート、サブネット全体
狙う資源	SYN backlog、FW状態表、CPU、PPS、帯域

1. 直送型SYNフラッド

直送型は、攻撃端末から標的へ直接SYNを送る方法です。

攻撃端末 ── 大量のSYN ──> 標的サーバー

送信元IPが固定されている場合は、比較的検知しやすい攻撃です。

特徴

単一または少数の送信元から届く
送信元IPが実在する場合がある
SYNに対してACKが戻らない
送信元別のレート制限が有効になりやすい

ただし、単純にIPを遮断すれば必ず解決するわけではありません。

攻撃元が多数存在する場合、正規利用者と同じNATやクラウド環境を共有している場合、IP単位の遮断は誤検知につながります。

MITRE ATT&CKでは、攻撃元から標的へ直接大量のネットワークパケットを送る攻撃をDirect Network Floodとして分類しています。TCPもこの攻撃に使用できます。

2. IP偽装型SYNフラッド

IP偽装型では、SYNパケットの送信元IPアドレスを書き換えます。

攻撃者
  │ 送信元IPを偽装したSYN
  ▼
標的サーバー
  │
  └─ SYN-ACKは偽装されたIPへ送信

攻撃者本人にはSYN-ACKが戻りません。

偽装先が応答しないIPアドレスであれば、標的はタイムアウトまで接続要求を保持しやすくなります。

一方、偽装先に実在する端末があり、その端末がRSTを返した場合、未完了状態が早く解放されることがあります。RFC 4987も、効果的な攻撃ではSYN-ACKへ応答しないアドレスを選ぶことが重要だと説明しています。

防御上の問題

送信元IPが毎回変化する
IPブラックリストが機能しにくい
攻撃者の追跡が難しい
SYN-ACKが外部へ大量送信される
送信元国やASNだけでは判定できない

3. 分散型SYNフラッド

分散型では、ボットネットなどの多数の端末が攻撃へ参加します。

ボット1 ─┐
ボット2 ─┤
ボット3 ─┼─> 標的
ボット4 ─┤
ボット5 ─┘

各端末の送信量を小さくしても、全体では非常に大きなPPSになります。

特徴

送信元が地理的に分散する
実在するIPアドレスから届く場合がある
1IPあたりのレートが低い
IP単位のしきい値を回避しやすい
正規ユーザーとの区別が難しい

MITRE ATT&CKも、大規模ボットネットでは1台ごとの送信量が少なくても、全体として十分な攻撃量を生成できると説明しています。

4. 低レート分散型SYNフラッド

低レート型は、短時間に一気に送るのではなく、未完了接続が解放される速度を少し上回る量を継続して送る方法です。

攻撃成立の条件は、単純化すると次のように表せます。

新しい未完了接続の増加速度
        >
タイムアウトやRSTで解放される速度

RFC 4987も、SYNが瞬間的な集中ではなく継続的に到着する場合でも、新規SYNの速度が状態解放速度を上回れば攻撃が成立すると説明しています。

低レート型では、単純な「1秒あたりの急増」だけを監視すると見逃す可能性があります。

5. マルチベクター型SYNフラッド

現代のDDoSでは、SYNフラッドだけを単独で使うとは限りません。

次の攻撃を同時に組み合わせることがあります。

TCP SYN flood
TCP ACK flood
TCP RST flood
UDP flood
DNS flood
TLS handshake flood
HTTP GET・POST flood
キャッシュ回避型HTTP flood

L3/L4：回線・ルーター・FWを圧迫
   │
   ├─ SYN flood
   ├─ ACK flood
   └─ UDP flood
   │
   ▼
L7：Webサーバー・DB・アプリを圧迫
   ├─ TLS接続
   ├─ HTTPリクエスト
   └─ 重いAPI

下位層の攻撃が注意を引いている間に、アプリケーション層へ別の攻撃を行う場合もあります。

6. TCP SYN/ACK反射攻撃

SYN/ACK反射攻撃では、攻撃者が被害者のIPアドレスを送信元として偽装し、第三者のTCPサーバーへSYNを送ります。

攻撃者
  │ 送信元IP＝被害者
  │ SYN
  ▼
第三者TCPサーバー
  │
  │ SYN-ACK
  ▼
被害者

被害者には、多数の第三者サーバーからSYN-ACKが届きます。

「反射」と「増幅」を分けて考える

SYN/ACK反射は、第三者へ送信元を偽装して応答を被害者へ向けるため、反射攻撃です。

ただし、DNSやNTPの反射増幅攻撃とは性質が異なります。

DNSやNTPでは、小さな要求に対して大きな応答が返る場合があります。一方、TCP SYNとSYN-ACKのパケットサイズは通常大きく変わりません。

TCPで増幅が発生する主な理由は、第三者サーバーがSYN-ACKを再送することです。

したがって、次のように表現する方が正確です。

SYN/ACK反射では、応答サイズそのものより、複数の反射元とSYN-ACK再送によって攻撃量が増える。

MITRE ATT&CKでは、被害者IPを偽装して第三者サーバーから応答を返させる方法をReflection Amplificationとして整理しています。ただし、実際の増幅率はプロトコルや実装によって異なります。

7. カーペット・ボミング型SYNフラッド

カーペット・ボミングは、1つのIPだけではなく、組織が保有する複数のIPアドレスへ攻撃を広く散布する方法です。

攻撃トラフィック
   │
   ├─ 192.0.2.1
   ├─ 192.0.2.2
   ├─ 192.0.2.3
   ├─ 192.0.2.4
   └─ 192.0.2.0/24 全体

各IPに到達する量を小さくすることで、単一IP単位のしきい値を超えにくくします。

しかし、組織全体や上流回線で集計すると、大量のトラフィックになります。

狙われる資源

組織の上流回線
BGP接続
エッジルーター
ファイアウォールクラスタ
ロードバランサー群
DDoS検知の集計ロジック

防御側は、ホスト単位だけでなく、次の単位でも監視する必要があります。

サブネット単位
ASN単位
回線単位
ポート単位
TCPフラグ単位
総PPS
総CPS

8. 複数ポート・サービス分散型

1台のサーバーでも、複数のTCPポートへSYNを分散する場合があります。

TCP 22
TCP 80
TCP 443
TCP 5432
TCP 8080

ポート別のしきい値だけを監視すると、各ポートは正常範囲に見えても、サーバー全体では過負荷になる場合があります。

特に、ファイアウォールやロードバランサーが接続状態を装置全体で共有している場合、複数サービスへの分散攻撃でも状態表が枯渇します。

9. Land攻撃

Land攻撃は、送信元IPと宛先IPを標的自身にし、送信元ポートと宛先ポートも同一にした異常なSYNパケットを送る歴史的攻撃です。

送信元IP   = 標的IP
宛先IP     = 標的IP
送信元Port = 宛先Port
TCP Flag   = SYN

古いTCP/IP実装では、この異常なパケットによってループ、フリーズ、クラッシュが発生する場合がありました。

ただし、Land攻撃は通常のSYN backlog枯渇型とは原理が異なります。

そのため、現在の記事では次のように分類する方が適切です。

TCPを悪用するDoS
├─ SYN状態枯渇型
│  └─ SYNフラッド
├─ 帯域・PPS枯渇型
│  └─ 大規模TCP flood
└─ 実装バグ悪用型
   └─ Land攻撃など

Land攻撃をSYNフラッドの一種として完全に同列へ並べると、攻撃原理の違いが分かりにくくなります。

10. Living off the Land（環境寄生型）

Living off the Land（リビング・オフ・ザ・ランド、LOTL）とは、攻撃対象のOSや社内環境に最初から存在する正規ツール、管理機能、スクリプト実行環境を悪用する攻撃手法です。

攻撃者が専用のマルウェアを大量に持ち込むとは限りません。PowerShell、WMI、rundll32、mshtaなど、管理者やシステムが日常的に使用する機能を「攻撃用の道具」として転用します。

「環境寄生型」は仕組みを理解しやすくするための説明的な呼び方です。一般にはLiving off the Land、略してLOTLと呼ばれます。Windows上で悪用される正規バイナリ、スクリプト、ライブラリは、LOLBinsまたはLOLBASと呼ばれることがあります。CISAも、LOTLをシステム固有のツールやプロセスを悪用する活動として整理しています。

Land攻撃とは別の攻撃

前節の「Land攻撃」と名前が似ていますが、目的も仕組みも異なります。

比較項目	Land攻撃	Living off the Land
主な対象	古いTCP/IP実装	侵入後のOSや社内環境
攻撃方法	送信元と宛先を同一にした異常パケット	正規ツールや管理機能を悪用
主な目的	フリーズ、クラッシュ、DoS	コード実行、情報収集、横展開、検知回避
必要な条件	脆弱なプロトコル実装	端末やアカウントへの侵入
防御の中心	更新、パケットフィルタリング	実行制御、ログ監視、EDR、権限管理

Living off the Landは、SYNフラッド攻撃の一種でもありません。本記事では、TCPやシステム機能の「通常の仕組みが攻撃へ転用される例」として取り上げています。

TCP SYNフラッドの技術的進化

第1段階：単一ホストからの状態枯渇

初期のSYNフラッドは、単一ホストから大量のSYNを送信し、サーバーの未完了接続キューを埋める攻撃でした。

SYNフラッドの弱点自体は1994年ごろには認識され、1996年にPhrackで説明と攻撃コードが公開されたことで広く知られるようになりました。RFC 4987は、1996年9月までに実際の攻撃が観測されていたと記録しています。

第2段階：IPスプーフィングによる追跡回避

攻撃者は送信元IPを偽装し、単純な送信元IP遮断を回避するようになりました。

これに対し、ネットワーク事業者側ではBCP 38として知られるingress filteringが推奨されました。

BCP 38は、ISPなどの集約点で送信元IPを検証し、そのネットワークから出てくるはずのない送信元アドレスを持つパケットを破棄する考え方です。

ただし、BCP 38がインターネット全体で完全に実施されているわけではありません。

第3段階：ボットネットによる分散化

マルウェアに感染したPC、サーバー、IoT機器を利用し、多数の実在IPから攻撃する方法が一般化しました。

この段階では、送信元IP詐称を使わなくても大規模な攻撃が可能です。

防御側は、次の課題に直面します。

送信元IPが正規の端末に見える
国や地域が分散している
各IPの送信量が少ない
単純なIPレート制限では止めにくい
誤検知で正規ユーザーを遮断しやすい

第4段階：回線とPPSを狙う大規模攻撃

OSのSYN Cookieが普及すると、サーバーのSYN backlogだけを狙う攻撃は効きにくくなりました。

そこで攻撃対象は、より手前の資源へ広がりました。

Internet
   │
   ▼
上流回線         ← 帯域枯渇
   │
   ▼
エッジルーター   ← PPS・ルート処理
   │
   ▼
ファイアウォール ← セッション表・CPU
   │
   ▼
ロードバランサー ← 接続処理
   │
   ▼
サーバー         ← SYN backlog・CPU

RFC 4987も、高PPSによってネットワーク処理能力や回線容量を狙う攻撃は、ホストのTCP実装だけを狙う古典的SYNフラッドとは分けて考える必要があるとしています。

第5段階：エッジ分散と超高速データプレーン防御

現代の防御では、攻撃パケットをアプリケーションやOSの通常ネットワークスタックまで到達させない設計が重視されます。

代表例は次のとおりです。

Anycast
CDN
スクラビングセンター
SYN Proxy
SmartNIC
DPU
ASIC
eBPF/XDP
AF_XDP
ハードウェアACL
上流フロー制御

LinuxのAF_XDPは、高性能なパケット処理向けに最適化されたアドレスファミリーです。XDPプログラムからパケットをユーザー空間のUMEMへリダイレクトでき、対応ドライバーではゼロコピー動作も利用できます。

ただし、XDPを導入すれば自動的に大規模DDoSを防げるわけではありません。

VPSの回線が1Gbpsで、上流から10Gbpsの攻撃が来た場合、サーバー内でXDPにより破棄する前に回線が埋まります。

攻撃量 10Gbps
      │
      ▼
契約回線 1Gbps  ← ここで既に詰まる
      │
      ▼
XDP

この場合は、上流ネットワーク、CDN、クラウド、DDoS対策事業者での遮断が必要です。

防御技術の進化

1. SYN backlogを増やす

tcp_max_syn_backlogを増やすことで、より多くの未完了接続を管理できます。

ただし、これは防御の本質ではありません。

バケツを大きくしても、流入量が増え続ければ最後にはあふれます。

RFC 4987も、単純なbacklog拡大やタイマー短縮には問題があり、SYN cacheやSYN Cookieの方が有効な方式として扱われています。

2. SYN-ACK再送回数を減らす

tcp_synack_retriesを減らすと、未完了接続が解放されるまでの時間を短縮できます。

ただし、次の正規利用者へ影響する可能性があります。

遅延の大きい回線
パケットロスがあるモバイル回線
海外からの通信
混雑したネットワーク
一時的に応答が遅れた端末

攻撃対策だけを理由に極端な値へ変更するのは避けるべきです。

3. SYN Cache

SYN Cacheは、未完了接続に必要な情報を、通常の完全なTCP接続より小さな構造で管理する方法です。

特徴は次のとおりです。

完全な接続状態よりメモリを節約できる
TCPオプションを比較的維持しやすい
一定の状態はサーバー側へ残る
大量攻撃ではキャッシュ自体が狙われる

RFC 4987では、SYN Cacheは1996年にBSD系OSへ実装され、その後の実装の基礎になったと説明されています。

SYN Cookieは、未完了接続の情報をサーバー側へ保持する代わりに、SYN-ACKのシーケンス番号へ必要な情報を符号化する方法です。

クライアント                     サーバー
    │                               │
    │ -------- SYN ---------------> │
    │                               │ 状態を保持しない
    │ <---- SYN-ACK + Cookie -------│
    │                               │
    │ ---- ACK + Cookie情報 ------> │
    │                               │ Cookieを検証
    │                               │ 接続状態を生成

SYN Cookieの考え方

一般化すると、Cookie値は次の情報から生成されます。

Cookie = F(
  送信元IP,
  宛先IP,
  送信元ポート,
  宛先ポート,
  時刻情報,
  サーバー秘密値,
  TCPオプション情報の一部
)

正確なビット配置や使用するハッシュは実装に依存します。

「暗号化して格納する」というより、接続情報と秘密値から検証可能な値を生成し、初期シーケンス番号へ符号化すると説明する方が適切です。

SYN Cookieの制約

SYN Cookieは万能ではありません。

RFC 4987は、SYN CookieにはTCPオプションとの互換性や将来拡張への制約があり得ると指摘しています。

Linuxでも、SYN Cookieは通常の高負荷を処理するための性能向上機能ではなく、SYN backlogがあふれた場合のフォールバック機能とされています。

5. SYN Proxy

SYN Proxyは、ファイアウォール、ロードバランサー、DDoS対策基盤などが、保護対象サーバーの代わりに3ウェイ・ハンドシェイクを処理する方式です。

クライアント
    │
    ▼
SYN Proxy
    │  接続元がACKを返すか確認
    │
    ├─ 未完了 → 破棄
    │
    └─ 完了
         │
         ▼
      オリジンサーバー

攻撃者がACKを返さなければ、オリジンサーバーには接続が到達しません。

AWS ShieldのTCP SYN Proxyは、SYN Cookieで新規接続を検証し、継続的なフルプロキシ状態を維持せずに接続状態をAWSサービスへ引き渡すステートレス構成と説明されています。

6. Anycastとスクラビング

Anycastでは、同じIPアドレスを複数の拠点から広告し、利用者や攻撃トラフィックを近い拠点へ分散させます。

攻撃元A ─> 東京エッジ
攻撃元B ─> 大阪エッジ
攻撃元C ─> シンガポールエッジ
攻撃元D ─> 米国エッジ

1拠点へ攻撃を集中させず、複数拠点の容量で吸収できます。

AWSは、CloudFrontがDNSトラフィック制御とAnycastルーティングを組み合わせ、攻撃元に近い場所で緩和すると説明しています。また、CloudFrontはオリジンへの持続接続を維持し、ShieldのSYN Proxyと統合してSYNフラッドを自動緩和します。

確認方法

1. SYN_RECV状態を確認する

目的

ハンドシェイクが完了していない接続要求が急増していないか確認します。

実行場所

対象のLinuxサーバー上で実行します。

コマンド

ss -Hant state syn-recv | wc -l

正常例

通常時の値が0～数件であれば、3件は異常とは限りません。

異常例

通常時より大幅に多く、継続して増えている場合は調査が必要です。

判断方法

1回の値だけで攻撃と断定しません。

次の要素を合わせて確認します。

通常時のSYN_RECV数
SYN受信PPS
接続成功数
応答時間
パケットロス
CPU使用率
同一ポートへの集中
送信元IPの分散度

2. SYN_RECVの送信元を確認する

目的

特定IPに集中しているか、広く分散しているか確認します。

実行場所

対象Linuxサーバー上です。

コマンド

ss -Hant state syn-recv \
  | awk '{print $5}' \
  | sed 's/:[^:]*$//' \
  | sort \
  | uniq -c \
  | sort -nr \
  | head

IPv6アドレスや環境によっては、IP抽出処理を調整してください。

正常例

4 203.0.113.10
2 198.51.100.20
1 192.0.2.15

異常例

5000 198.51.100.20
4300 203.0.113.50

判断方法

少数IPへ集中：直送型の可能性
多数IPから少量ずつ：分散型の可能性
ランダムなIPが非常に多い：IP偽装型の可能性
特定サブネット全体が攻撃される：カーペット・ボミングの可能性

ただし、NAT、プロキシ、CDNのIPが上位になることもあります。

3. カーネル設定を確認する

目的

SYN Cookie、SYN backlog、SYN-ACK再送設定を確認します。

実行場所

Linuxサーバー上です。

コマンド

sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_synack_retries
sysctl net.core.somaxconn

出力例

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 5
net.core.somaxconn = 4096

判断方法

tcp_syncookies = 1は、Linuxでは通常、SYN backlogあふれ時にSYN Cookieを利用する設定です。

ただし、値が1であるだけでDDoS対策が完了したとは判断できません。

4. SYN Cookieの発動状況を確認する

目的

SYN Cookieが実際に送信されたか確認します。

実行場所

Linuxサーバー上です。

コマンド

nstat -az | grep -E 'Syncookies|ListenOverflows|ListenDrops'

環境によっては次も利用できます。

netstat -s | grep -i -E 'cookie|listen|overflow'

正常例

TcpExtSyncookiesSent 0
TcpExtSyncookiesRecv 0
TcpExtListenOverflows 0
TcpExtListenDrops 0

要調査例

TcpExtSyncookiesSent 152400
TcpExtListenOverflows 98400
TcpExtListenDrops 76000

判断方法

値は累積値である場合があります。

測定前後の差分を確認してください。

nstat -r
sleep 60
nstat -az | grep -E 'Syncookies|ListenOverflows|ListenDrops'

SyncookiesSentが増えていても、必ず攻撃とは限りません。正規アクセスの急増や、アプリケーション処理遅延でも発生する可能性があります。

5. パケットを短時間だけ確認する

目的

SYNだけが大量に到達しているか確認します。

注意事項

tcpdumpは高トラフィック時にCPUやディスクへ負荷を与える可能性があります。

長時間保存せず、パケット数や時間を制限してください。

コマンド

sudo timeout 10 tcpdump -nn -i any \
  'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack = 0' \
  -c 1000

正常例

通常の接続開始が少量表示されます。

異常例

非常に短時間で1000件へ達し、送信元や宛先ポートが不自然に分散している場合は要調査です。

判断方法

パケットキャプチャだけでは断定しません。

フローログ、NIC統計、SYN_RECV、SYN Cookie発動、上流回線使用率と合わせて判断します。

対処方法

対処1：オリジンサーバーを直接公開しない

Webサイトでは、CDNやリバースプロキシを前段に置きます。

Internet
   │
   ▼
CDN・DDoS対策
   │
   ▼
ファイアウォール
   │
   ▼
Nginx
   │
   ▼
アプリケーション

オリジンサーバーのファイアウォールでは、CDN事業者の正式な接続元IPだけを許可します。

ただし、CDNのIPレンジは更新される可能性があります。自動更新、差分監視、誤遮断時の復旧手順が必要です。

対処2：管理サービスをVPN内へ移す

SSH、DB、管理画面をインターネット全体へ公開しないようにします。

推奨構成は次のとおりです。

管理端末
   │
   ▼
WireGuard・ZTNA・VPN
   │
   ▼
管理用ネットワーク
   │
   ├─ SSH
   ├─ DB
   └─ 管理画面

公開サービスを減らすほど、SYNフラッドを受ける入口も減ります。

対処3：SYN Proxyを前段へ配置する

nftables、ファイアウォール、ロードバランサー、クラウドDDoS対策などでSYN Proxyを利用します。

ただし、導入時には次を検証してください。

TCPオプションの扱い
MSS
ウィンドウスケーリング
タイムスタンプ
IPv6対応
非対称ルーティング
ロードバランサーとの競合
クライアントIP保持
TLS終端位置
正常時の遅延

本番へ直接適用せず、ステージング環境で負荷試験を行います。

対処4：OS設定は実測値に基づいて調整する

設定例をそのままコピーしてはいけません。

調整候補には次があります。

net.ipv4.tcp_syncookies
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_synack_retries
net.core.somaxconn

ただし、それぞれ別の目的を持ちます。

設定	主な役割
`tcp_syncookies`	キューあふれ時のSYN Cookie
`tcp_max_syn_backlog`	未完了要求の上限
`tcp_synack_retries`	SYN-ACK再送回数
`somaxconn`	listen backlogの上限

注意

tcp_max_syn_backlogを無制限に大きくしても、大規模な帯域攻撃は防げません。

また、メモリに余裕がないサーバーでは、キュー拡大によるメモリ消費も評価する必要があります。

対処5：上流遮断を利用する

攻撃量が契約回線を超えた場合、サーバー内のiptables、nftables、XDPでは間に合いません。

必要になるのは次の対策です。

ISPのDDoSフィルタリング
クラウド事業者のDDoS対策
Anycast CDN
スクラビングセンター
BGP FlowSpec
RTBH
専門事業者によるトラフィック洗浄

MITRE ATT&CKも、攻撃量が対象回線の容量を超える場合、ISPやCDNなど上流で攻撃トラフィックを遮断する必要があるとしています。

RTBHは正規通信も含めて対象IPへの通信を破棄する可能性があります。最終手段として、実施条件と解除手順を事前に決めてください。

動作確認

正常通信が維持されているか確認する

対策後は、攻撃パケットが減ったかだけではなく、正規ユーザーが接続できるか確認します。

確認項目は次のとおりです。

確認項目	判断
TCP接続成功率	対策前より悪化していない
SYN_RECV数	平常範囲へ戻る
応答時間	SLO内
パケットロス	許容範囲
SYN Cookie発動	必要時のみ
ListenDrops	増加していない
CDN経由率	想定どおり
オリジン直接接続	遮断される
海外・モバイル回線	正常に接続できる
IPv6	IPv4と同様に保護される

外部からポート到達性を確認する

オリジンへの直接接続を禁止した場合は、許可経路と禁止経路の両方を確認します。

正常なCDN経由

curl -I https://example.com/

正常例：

HTTP/2 200

オリジンIPへの直接接続

curl -kI --resolve example.com:443:203.0.113.10 \
  https://example.com/

期待する結果は、タイムアウトまたは明示的な拒否です。

ただし、作業元IPを一時許可している場合は、テスト条件を明確にしてください。

再発防止

通常時の基準値を保存する

攻撃を検知するには、正常時の値が必要です。

最低限、次を記録します。

TCP SYN PPS
TCP SYN-ACK PPS
TCP ACK PPS
新規接続数
接続成功率
SYN_RECV数
ESTABLISHED数
ListenDrops
SyncookiesSent
NICのdrop
CPU softirq使用率
conntrack使用率
上流回線使用率
送信元IP数
送信元ASN数
宛先IP数
宛先ポート数

単一しきい値ではなく複数の指標を組み合わせる

SYN数だけで攻撃判定すると、イベント開始時やテレビ放送後のアクセス急増を攻撃と誤認する可能性があります。

次の比率も利用できます。

ハンドシェイク完了率
= ESTABLISHEDへ進んだ接続数 ÷ SYN受信数

SYN/ACK不均衡
= SYN受信数 − 正常ACK受信数

送信元分散度
= 一定時間内のユニーク送信元IP数

宛先分散度
= 攻撃対象になったIPアドレス数

カーペット・ボミング対策では、宛先IP単位ではなくサブネット全体で集計することが重要です。

DDoS対応手順を事前に作る

攻撃が始まってから事業者の連絡先を探すと対応が遅れます。

事前に次を決めます。

誰が異常を判断するか
どの数値でインシデントと判定するか
ISPやクラウドへ連絡する条件
CDNの緊急モードを有効にする条件
RTBHを使う条件
一時的に閉鎖するサービス
顧客への告知方法
証跡の保存方法
復旧判定
事後レビューの担当者

注意点・よくある誤解

誤解1：SYN Cookieを有効にすれば完全に防げる

SYN Cookieは、主にサーバー側の状態枯渇を軽減します。

次の問題は別に残ります。

回線帯域の枯渇
NICのPPS限界
CPUやsoftirqの高負荷
ファイアウォールの状態表
ロードバランサーの限界
SYN-ACK送信帯域
マルチベクター攻撃

誤解2：WAFでSYNフラッドを防げる

一般的なWAFはHTTPリクエストを解析するL7対策です。

SYNフラッドはHTTPリクエストが成立する前のTCP接続段階で発生します。

TCP SYN flood
   ↓
L3/L4 DDoS対策・SYN Proxyが担当

HTTP flood
   ↓
WAF・アプリケーション対策が担当

クラウド製品では、WAFとDDoS対策が統合されて見えることがあります。しかし、実際には異なる層の防御機能が処理しています。

誤解3：IPを永久BANすればよい

SYNフラッドでは、送信元IPが偽装されている可能性があります。

偽装された正規企業、クラウド、家庭回線のIPを永久BANすると、無関係な利用者を遮断します。

IPの信頼度情報は補助材料として使用し、次の情報と組み合わせます。

TCPハンドシェイク完了率
攻撃継続時間
過去の観測
ASN
接続先ポート
パケットレート
TCPフラグ
CDNやプロキシ経由の有無
スプーフィングの可能性

誤解4：backlogを増やせば安全になる

backlog拡大は、短いアクセス集中や一時的な過負荷には役立つ場合があります。

しかし、攻撃者が送信量を増やせば再びあふれます。

さらに、正規の大量アクセスが原因であれば、アプリケーション、ワーカー数、ロードバランサー、DBなど別のボトルネックを調査する必要があります。

Linuxカーネル資料も、SYN Cookieを正規の高接続レートへ耐えるための機能として使うべきではないと明記しています。

誤解5：SYN backlogの枯渇で必ずOOMやカーネルパニックになる

SYN_RECV要求はメモリを消費しますが、Linuxでは上限管理、軽量なrequest socket、SYN Cookieなどの防御があります。

設定や実装に問題があればメモリ圧迫の一因にはなり得ます。しかし、SYN backlogが埋まったことから、直ちにOOM Killerやカーネルパニックが発生すると断定することはできません。

通常は先に次の症状が現れます。

新規接続の失敗
接続タイムアウト
ListenDropsの増加
SYN Cookieの発動
CPUやsoftirqの上昇
ファイアウォール状態表の枯渇
回線帯域の飽和

まとめ

TCP SYNフラッドは、TCPの3ウェイ・ハンドシェイクを途中で止め、未完了接続を大量に作る攻撃です。

しかし、現代の攻撃はサーバーのSYN backlogだけを狙うとは限りません。

ボットネット、IPスプーフィング、SYN/ACK反射、カーペット・ボミング、マルチベクター化によって、次の資源が同時に狙われます。

回線帯域
パケット処理能力
ルーター
ファイアウォール
ロードバランサー
SYN backlog
CPU
アプリケーション

防御の中心は、次の多層構成です。

BCP 38・送信元検証
        │
        ▼
Anycast・CDN・スクラビング
        │
        ▼
ACL・レート制御・異常判定
        │
        ▼
SYN Proxy・SYN Cookie
        │
        ▼
OSキュー調整
        │
        ▼
アプリケーション監視

SYN Cookieだけで防ごうとせず、攻撃トラフィックを可能な限り上流で吸収することが重要です。

FAQ

Q1. SYNフラッドは現在でも多い攻撃ですか？

はい。

Cloudflareの2025年第1四半期レポートでは、SYNフラッドがネットワーク層で最も多く観測されたDDoSベクトルとされています。

Q2. Cloudflareの通常プロキシでSSHも守れますか？

一般的なWeb向けリバースプロキシは、主にHTTP・HTTPSを対象とします。

SSHや独自TCPサービスは、対応するL4プロキシ、トンネル、VPN、Magic Transit相当のサービスなどが必要です。

製品と契約プランによって対応範囲が変わるため、利用中サービスの公式仕様を確認してください。

Q3. `tcp_syncookies=1`なら安全ですか？

完全ではありません。

SYN backlogの状態枯渇を軽減できますが、回線、NIC、CPU、ファイアウォールの状態表は別に狙われます。

Q4. SYN_RECVが多ければ攻撃ですか？

必ずしも攻撃ではありません。

正規アクセスの急増、通信障害、パケットロス、アプリケーション過負荷でも増える可能性があります。

通常値、接続完了率、送信元分布、PPSなどを組み合わせて判断します。

Q5. iptablesやnftablesで防げますか？

小規模攻撃や特定パターンには有効です。

ただし、攻撃量が回線容量を超える場合、サーバーへ届く前に上流で遮断する必要があります。

Q6. XDPなら大規模DDoSも防げますか？

XDPはLinuxネットワークスタックの早い段階でパケットを処理できるため、サーバー内の高速フィルタリングに有効です。

ただし、契約回線が先に飽和する攻撃は防げません。

上流DDoS対策との併用が必要です。

Q7. SYN/ACK反射は何倍に増幅しますか？

固定値ではありません。

SYNとSYN-ACKのサイズ差は通常大きくありません。主な増幅要因は、複数の反射サーバーとSYN-ACK再送回数です。

OS、TCPオプション、再送設定、反射元の数によって変わるため、一律の増幅率を断定できません。

参考情報

2026年7月30日追記：本サイトのSYNフラッド耐性監査

この記事の公開後、記事ページだけではなく、本サイト全体の公開経路を対象にTCP SYNフラッド耐性を再点検しました。CDN・上流側の保護、オリジンサーバーへの到達経路、Linuxの接続待ち行列、ファイアウォール、Webサーバー、監視・運用手順を層ごとに確認しています。

監査結果と改善

Web通信には前段のDDoS緩和とオリジン保護が適用され、LinuxのSYN Cookieも有効でした。一方、接続待ち行列の基準を構成管理へ明示することと、SYN_RECVやカーネルのドロップ指標を継続監視することに改善余地があったため、設定と監視を追加しました。

SYN backlogとaccept queueを区別し、レビュー済みのカーネル基準を再起動後も維持するようにしました。
SYN_RECV、SYN Cookieの発動・失敗、listen queueのoverflow・drop、接続追跡テーブルの圧迫を定期的に集計します。
監視データは集計値に限定し、送信元IPアドレスをこの監視機能へ保存しません。
監視機能に障害が起きても本線通信を止めないfail-open構成としました。

安全な確認方法

確認では実際のSYNフラッド、送信元IP偽装、大量パケット送信は行っていません。現在値の読み取り、設定の構文検証、合成したカウンタによる警報テスト、通常のHTTPS疎通確認で検証しています。

多層防御を継続する

SYN Cookieやサーバー設定だけでは、回線容量を超える攻撃を吸収できません。Web以外のTCPサービスも含め、CDN、VPS事業者、上流DDoS対策、ファイアウォール、OS監視、インシデント対応手順を組み合わせる必要があります。

この追記では、悪用や回避に使われ得る具体的な閾値、公開サービスの詳細、IPアドレス、ファイアウォール規則、内部パスは掲載していません。今後も平常時の基準値を蓄積し、誤検知と見逃しの両方を抑えるよう継続的に見直します。