コンテンツにスキップ 
TCP SYNクッキー Linuxカーネルでは、状態情報を初期シーケンス番号（ISN）に暗号的にエンコードし、有効なACKが受信されて初めて接続を完全に確立することで、ハンドシェイクの負荷を低く抑えています。 これにより、SYNフラッドによって半開状態の接続キューが詰まり、正当なクライアントがブロックされるのを防いでいます。.
中心点
- 機能性: ISN内のクッキー、ACK受信後のみ状態が確定
- Linux制御: net.ipv4.tcp_syncookies（モード 0/1/2）
- ベネフィット: 攻撃負荷時のメモリ使用量が少ない
- バウンダリー: 帯域幅攻撃やアプリ攻撃に対しては効果がない
- チューニング: バックログ値とリトライ値を慎重に設定する
SYNフラッドがTCPハンドシェイクを遅らせる仕組み
攻撃者がサーバーに大量の SYNパケット そして、その後のSYN/ACK応答を無視するため、半開のエントリがSYNキューを占有してしまいます。その結果、新しい正当なリクエストが収容されず、タイムアウトが頻発する現象に遭遇します。まさにこの点で、 Syncookies 概要：カーネルは当初、接続状態を保存せず、必要なデータをシーケンス番号に格納する。正しいACKが受信されて初めて、相手側が実在することが確認され、接続確立が通常通り進行する。 LWN.net や TUM の資料では、この原理を、メモリ消費量を抑えつつ確立された効果的なハンドシェイク保護として説明しています。このアーキテクチャでは、コストのかかる状態を非常に遅い段階でしか作成しないため、サーバーはトラフィックが殺到している状況下でも処理能力を維持できます。.
技術的な流れ：従来のステートマシンに代わるクッキー
カーネルは、ある SYN 特別にエンコードされたSYN/ACKを使用します。そのISNは、秘密鍵、TCPオプション、およびタイムスライスから導出されます。一致する番号を持つACKが届いた場合、ISNからセッションパラメータを復元し、通常通りソケットを開きます。 応答がない場合、占有された「半オープン」状態は存在しないため、メモリとCPUの負荷を軽減できます。このアプローチにより、通常の処理パスを恒久的に変更することなく、接続受け入れフェーズの脆弱性を劇的に低減できます。 UbuntuおよびRed Hatのドキュメントによると、この技術は長年にわたりカーネルの各世代で確実に機能しており、キューが溢れそうになった場合にのみ作動する。.
有効化と検証：tcp_syncookiesの実践
sysctl スイッチについて net.ipv4.tcp_syncookies この設定で動作を制御します：0 = オフ、1 = 過負荷時のみ、2 = 常時有効。本番環境では、標準のハンドシェイクが維持され、必要な場合にのみ保護が機能するように、通常はモード1に設定しています。 ステータスはシェル上で素早く確認でき、変更はsysctlで即座に反映するか、/etc/sysctl.d/に記述して永続化します。ソケットの挙動や攻撃パターンに関する関連記事は、全体を計画する際に役立ちます。詳細については、別の記事で詳しく解説しています。 SYN洪水防御. 私が日常的に使っているコマンドは以下の通りです：
# のステータスを表示
sysctl net.ipv4.tcp_syncookies
# を一時的に有効にする（再起動まで）
sudo sysctl -w net.ipv4.tcp_syncookies=1
# を永続的に設定
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
限界：SYNクッキーではできないこと
SYNクッキーは主に Syn-Queue また、半開状態がメモリを占有するのを防ぎます。ただし、回線の過負荷、アプリケーションロジックの処理能力超過、あるいはCPUの飽和に対しては効果がありません。ボリューム型攻撃に対しては、上流側のフィルタ、QoS、そして必要に応じてスクラビングが必要です。 また、HTTP GETフラッドのようなアプリケーション層への攻撃に対しても、追加の制御、制限、キャッシュが必要です。そのため、私は常にSyncookie対策を、ネットワーク層、カーネル層、サービス層を統合した多層防御の一環として位置づけています。.
チューニング：バックログ、キュー、リトライ
いざという事態に備えて、私は…… バックログ また、正当なトラフィックの急増によって保護モードが不必要に発動しないよう、再試行回数を制限します。tcp_max_syn_backlogは半開接続のキューに影響し、somaxconnはaccept()を待機している接続の受け入れキューの最大長を指定します。 tcp_synack_retries パラメータでは、カーネルが SYN/ACK の再送信を諦めるまでの試行回数を指定します。 バックログを大きく設定すると一時的な負荷の急増に対応できますが、メモリを消費します。リトライ回数を減らすとスロットが早く解放されますが、切断されたクライアントに過度な影響を与えるリスクがあります。私は、hping3 や tcp_syn_flooder などのツールを使用し、隔離されたネットワーク環境において、現実的な負荷条件下でこれらのトレードオフを検証しています。.
# 負荷ピーク時の設定
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
動作モードの比較：影響と用途
日常使いには、私は モード 意識しておく必要があります。これらは、診断、メトリクス、および負荷下での動作に影響を与えるからです。永続クッキー（2）は初期の状態設定を回避しますが、リトライの測定値を変更し、TCPオプションによるまれなエッジケースに影響を与える可能性があります。 適応モード（1）は、スタックを通常通り動作させ、オーバーランの危険がある場合に介入します。「オフ」（0）は、せいぜい実験室環境や閉じたネットワークでのみ意味があります。以下の表にその概要をまとめています：
| モード | 説明 | メリット | 起こりうる副作用 | 例 |
|---|---|---|---|---|
| 0 | 無効, クッキーなし | 明確なベースラインの挙動 | 攻撃者がSynキューを埋める | 隔離されたテストネットワーク |
| 1 | 適応型, オーバーフロー時のみ | アイドル時の通常のTCP | 切り替え点の校正 | 公共サービス |
| 2 | 強制, 常にアクティブ | 早期の負担軽減 | 分析値にばらつきが生じる | 厳しい攻撃局面 |
測定可能な効果：レイテンシと成功率
圧力がかかると、その値は低下する メモリ要件 接続の確立時に、ハーフオープン状態が発生しないため、その効果が顕著に現れます。これにより、SYNクッキーが受諾率を高く維持し、短いバーストによる接続切断が減少します。トラフィックの急増時でも、送信元が途絶えるとすぐに回復が早まることを確認しています。 UbuntuおよびTenableのガイドラインでは、通常のクライアントの動作に影響を与えないよう、適応的な運用を推奨しています。回帰テストでは、クッキーモードへの移行時に、再送信、ドロップ率、およびサーバーの遅延を確認しています。.
追加の保護層：ファイアウォールと制限
Syncookiesは次のように解決します フィルタルール また、負荷がそもそもTCPスタックに及ばないように、レート制限も設定しています。Linuxでは、接続レートに基づいて違反者を抑制したり、早期に拒否したりするために、nftablesルールを優先して使用しています。最新のパケットフィルタに関する簡潔な概要については、以下のガイドを参照してください。 nftables 対 Netfilter. さらに、エッジファイアウォールでのSYNPROXYシナリオも有効です。これにより、ハンドシェイクを終了させ、有効な接続のみを通過させることができます。露出しているポートについては、厳格な開放設定、ログ記録のしきい値、および送信元アドレスごとの最大接続試行回数を定義しています。.
高性能なアプローチ：XDPなど.
ボリューム攻撃が PPSレート 負荷を軽減するため、XDP を使用してフィルタリングロジックを NIC のネットワークエッジに移行します。これにより、ソケット層に到達する前に不審な SYN パケットを破棄できるため、CPU 負荷が軽減され、受信キューの負荷も軽減されます。この技術の導入を容易にするための入門ガイドとして、 XDPパッケージ処理. SYNクッキーと組み合わせることで、2段階のシステムが構築されます。まずカード上で大まかな選別を行い、次にカーネル内で確実なハンドシェイク検証を行います。この一連の処理により、攻撃対象領域が著しく縮小され、サービスへのアクセスが維持されます。.
診断：メトリクスとログ情報を正しく読み解く
目立つ場合は タイムアウト netstat/ssの統計情報、dmesgのメッセージ、および接続レートを表示するGrafanaのパネルを確認します。 SYN-RECVの割合の増加、高い再送信率やドロップ率は、保護モードへの移行を示しています。私はSYNバックログオーバーフローのメッセージに注意を払い、それらをCPUおよびIRQの負荷と照らし合わせて分析します。 tcpdumpによるパケットキャプチャは、シーケンス番号のロジックを裏付け、誤検知の特定に役立ちます。さらに、iptables/nftablesのカウンターを使用して、レート制限ルールへのヒット状況を測定しています。.
互換性：TCPオプションとエッジケース
現代のカーネルのコーディング オプション MSS、SACK、タイムスタンプなど、クッキーが再構築可能な状態で転送されるように設定します。古いスタックや特殊なスタックでは特有の挙動が見られる可能性があるため、本番環境への導入前には重要な処理経路を検証しています。 特にプロキシ、NAT、およびエニーキャスト・トポロジーでは、その挙動を徹底的に観察しています。LWN.netでは、現在の実装が信頼性高く動作する理由を説明する設計上の詳細が議論されています。極めて特殊なシナリオにおいては、強制動作モード（2）は、私が目的を絞ってのみ使用するツールです。.
よくある誤解：私がよく訂正すること
Syncookiesは代替にはなりません DDoS防御 周辺部において、これらは主にハンドシェイクフェーズを保護する役割を果たします。SYN/ACKへの応答が一切行われない場合、somaxconnの値が高くてもオーバーフローを防ぐことはできません。 同様に、永続的なクッキー（2）が常に最良の選択であるという考えも誤りであり、診断や特殊なケースにおいて支障をきたします。モニタリングがなければ、切り替えポイントや制限値を調整するための手がかりが得られません。設定やハードウェアが実際のアクセス動勢に適合するようにするためには、負荷テストが不可欠です。.
実践チェック：信頼性の高い仮説を立てるための手順
私は次のように始める。 モード1 tcp_syncookies を設定し、負荷がかかった状態での介入ポイントを検証します。その後、tcp_max_syn_backlog と somaxconn を適度に増やしつつ、tcp_synack_retries を下げ、成功率を測定します。 ファイアウォールのレート制限やGeo／ASNフィルタにより、スタックに到達する前に不要なトラフィックを排除します。XDPやSmartNICフィルタは、リソースを的確に活用できるよう、PPSが極めて高い状況に備えて温存しておきます。 最後に、メトリクスを文書化して、後の調整がデータに基づいて行えるようにします。.
IPv6とデュアルスタック：同じスイッチ、同じロジック
デュアルスタック環境では、 IPv4 と IPv6 クッキーに関して一貫性がある。このスイッチは net.ipv4.tcp_syncookies TCP（v6ソケットも含む）の保護をグローバルに制御します。そのため、特にIPv6のアップストリーム機器が異なるフィルタリングパスを使用している場合は、両方のプロトコルでクッキーモードへの移行をテストしています。 重要：SYNクッキーはTCPのみを保護します。UDPサービスやQUICについては、トラフィック量によるCPUの過負荷を防ぐため、独自のレート制限とエッジポリシーが必要です。.
カーネル内のメトリクス：信頼性の高い指標
信頼性の高いモニタリングを行うために、私はクッキーを明示的に記録するカーネルカウンターを利用しています。そのほか、 ss -s また、状態の分布を観察するために、送信済み、受信済み、および失敗したクッキーのカウンターを確認しています。これにより、保護機能が有効に働いているか、正当なクライアントが通過できているか、設定ミスが発生していないかを把握しています。.
# の概要
ss -s
ss -ant state syn-recv | wc -l
# クッキーカウンター（カーネル：/proc/net/netstat）
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# ライブ表示
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# ログのヒント (メッセージ例)
# dmesg には、以下のようなメッセージが表示されます:
# TCP: ポート 443 で SYN フラッディングの可能性があります。クッキーを送信中。SNMP カウンタを確認してください。.
上昇する リストのオーバーフロー そして ListenDrops ～と並行して SyncookiesSent では、バックログ、リトライ、アップストリーム・フィルタを調整します。残るのは SyncookiesRecv …であれば、それは単なるボットによるスパム攻撃であることを示唆している。一方、もし SyncookiesFailed, 、NAT／プロキシの経路や、経路上の操作の可能性を確認しています。.
プロキシ、ロードバランサー、Kubernetes
時点では プロキシおよびLBチェーン クッキー保護の配置を決定します。L4／L7ロードバランサーがTCPハンドシェイクを処理する場合、SYNフラッドはバックエンドに到達しません。その場合は、エッジ側でクッキーを有効にします。 LBがパッシブモード（DSR、ECMP）でのみ動作する場合、バックエンドノードは独自に保護を行う必要があります。Kubernetesでは、特にNodePortやHostNetworkのワークロードにおいて、ワーカーノードのsysctlを設定します。独自のSYN防御機能 （SYNPROXY、eBPF）については、ポリシーが互いに干渉してパフォーマンスを低下させないよう調整します。また、テストではLBのヘルスチェックを考慮に入れます。そうしないと、リトライ回数が少なくテストウィンドウが短い場合、誤って不安定な状態と判断されてしまうためです。.
境界事例の詳細：オプション、時間スライス、NAT
クッキーは単にエンコードするだけ 制限されたパラメータ. 最近のLinux実装では、通常、MSS、SACK、およびウィンドウスケーリングは確実に再構築されますが、タイムスタンプやまれなオプションについては、カーネルのバージョンによっては制限がある場合があります。そのため、標準的な処理が優先され、オーバーフローが発生した場合にのみクッキーが適用されるよう、動作モード (1) を推奨します。 クッキーの有効期間は時間スライスに紐づいています。経路の非対称性が著しい場合や遅延のピーク時には、正当なACKがウィンドウの境界をわずかに外れてしまう可能性があります。 そのため、WANや衛星通信のシナリオでは、リトライ回数を減らす前にラウンドトリップのばらつきを測定しています。シーケンス番号やオプションを改変するNATやミドルボックスもエッジケースの要因となり得ます。ターゲットを絞ったキャプチャを行い、どの箇所でビットが失われているかを確認しています。.
ACK／RSTフラッドおよびSYNストーム以外のバリエーション
すべてではない 輸送攻撃 これは純粋なSYNフラッドです。ACKやRSTのフラッドは、ハンドシェイクをトリガーすることなく、CPUやパケット経路を標的とします。この場合、クッキーはほとんど役に立ちません。 その場合、私は状態ロジックや最小限のACKレート制限を備えた初期段階のフィルタ（nftables/XDP）を使用しています。 特に、確立済みの接続に対するRSTの波については、適切なウィンドウを持たない予期せぬRSTを破棄するルールセットを用いて遮断しています。また、半開状態の繰り返し攻撃（スプーフィングを伴うSYNと遅延ACK）に対しても、送信元ネットワーク空間ごとのレート制限によって対処しています。.
さらなるチューニング：リスト／アクセプトキューと迅速なエラー処理
従来のパラメータに加え、限界領域での挙動を左右する補助スイッチも使用しています：
- Backlog 対 somaxconn: 値は リスト（バックログ） 1プロセスあたりの値は、 net.core.somaxconn 上限を設けています。サーバーソフトウェアとカーネルが調和するように配慮しています。そうしなければ、最適化の効果が台無しになってしまいます。.
- tcp_abort_on_overflow: Acceptキューが満杯の場合、黙ってドロップするか、それともRSTを返して積極的に応答するか。処理量の多いAPIでは、迅速なエラー通知によりクライアントが素早く再試行を行えるようになる。TLSクライアントやレガシークライアントの場合は、私はたいていデフォルトのドロップを優先する。.
- ポートおよびTIME-WAITの管理: クッキーは防ぐことはできない エフェメラルポートのボトルネック. 私は計画している ip_local_port_range 余裕を持たせ、TIME-WAITの最適化は慎重に行い、再利用が予期せぬバグを引き起こさないようにする。.
- SO_REUSEPORT: ポートごとに複数のAcceptキューを設定することで、負荷をワーカープロセス全体に分散させ、個々のCPUでのオーバーフローを軽減します。.
試験方法：再現性があり、信頼性が高い
シナリオに沿った負荷シミュレーションを行い、クッキーモードへの切り替えポイント、正当な接続の成功率、および負荷ピーク後の回復時間を測定します。その際、合成SYNフラッドと実際のアプリケーションリクエストを組み合わせています。.
# フラッドを生成する（実験用！）
sudo hping3 -S -p 443 --flood --rand-source
# ネットワーク条件を変更する
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# 正規のトラフィックを混在させる
wrk -t8 -c512 -d60s https:///
# 並行して監視
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
これらの手順により、リトライの頻度が過度に低下していないか、アップストリームのファイアウォールがタイムスタンプを誤ってフィルタリングしていないか、あるいは個々のワーカーのAcceptキューが不釣り合いに溢れかえっていないかを確認しています。 指標（正当な接続の100%成功率、クッキーヒット率、レイテンシの推移など）を記録し、後日データに基づいて調整を行えるようにしています。.
運用と保守：稼働期間を通じて安定性を確保する
連続運転では、次のように計画しています シークレットローテーション （カーネル側で自動的に）実行し、タイムスライスの切り替えが、RTTが非常に長い経路に目に見える影響を与えるかどうかを観察しています。クッキー実装の改善（オプションのエンコーディングの最適化、堅牢なタイムスライスなど）が効果を発揮するよう、カーネルとドライバを最新の状態に保っています。 監査の際には、保護モードがいつ発動したか、何件の接続を通過させたか、追加のフィルタが有効化されたかどうかを記録しています。MTU、オフロード、またはNFスタック（例：新しいnftablesセット）に変更を加えた場合は、早期に相互作用の不具合を発見できるよう、簡易テストを繰り返しています。.
お急ぎの方のためのショートバージョン
SYNクッキーは、 ハンドシェイク負荷 ACKが確認されてから初めてステートを生成することで、Synキューが溢れるのを防ぎ、負荷を軽減します。 モード1を有効にし、バックログとリトライを慎重に調整し、明確な指標を用いてその効果を測定します。nftablesのレート制限、SYNPROXY、XDPといった追加のレイヤーは、TCPスタックのさらに手前でトラフィックを抑制します。 このようにして、通常のクライアントに不利益を与えることなく、Web、メール、VPN、APIサービスをSYNフラッドから保護します。これらの対策を厳格に実施することで、可用性を高め、攻撃負荷時のダウンタイムを顕著に低減できます。.
