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

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オプション、再送設定、反射元の数によって変わるため、一律の増幅率を断定できません。

参考情報

• RFC 4987: TCP SYN Flooding Attacks and Common Mitigations

• RFC 2827 / BCP 38: Network Ingress Filtering

• Linux Kernel Documentation: IP Sysctl

• Linux Kernel Documentation: AF_XDP

• MITRE ATT&CK T1498: Network Denial of Service

• MITRE ATT&CK T1498.001: Direct Network Flood

• MITRE ATT&CK T1498.002: Reflection Amplification

• AWS Shield DDoS mitigation documentation

• Cloudflare DDoS Threat Report 2025 Q1・Q2

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アドレス、ファイアウォール規則、内部パスは掲載していません。今後も平常時の基準値を蓄積し、誤検知と見逃しの両方を抑えるよう継続的に見直します。