SYNフラッド攻撃とは？TCPの弱点を突くDDoSの仕組みとLinuxサーバーの防御設定ガイド

ある朝、Webサービスの応答が急に遅くなり、SSHでサーバーに繋がらなくなった——。アクセス集中でもないのに、こういった事態が起きたとき、SYNフラッド攻撃が原因であるケースがあります。

SYNフラッドは1990年代から知られている古典的な攻撃ですが、シンプルな仕組みのまま現在も多くのDDoS攻撃で使われ続けており、インターネットに公開しているLinuxサーバーが標的になることは珍しくありません。

この記事では、SYNフラッド攻撃の仕組みをTCPハンドシェイクの動作から解説し、今日から設定できるLinuxサーバーの防御手順を具体的にお伝えします。ネットワーク担当者やインフラエンジニアが明日から使える内容を目指しました。

SYNフラッド攻撃とは？

SYNフラッド攻撃（SYN Flood Attack）とは、TCP（Transmission Control Protocol）の接続確立プロセスを悪用し、大量の接続要求でサーバーのリソースを枯渇させる攻撃手法です。DDoS攻撃（分散型サービス拒否攻撃）の代表的な種類の一つで、WebサーバーやSSHサーバーなど、TCPを利用するあらゆるサービスが標的になります。

攻撃自体のコードはシンプルで、安価なツールでも実行できるため、スキルの低い攻撃者による攻撃でも頻繁に確認されます。また、ボットネット（マルウェアに感染した多数の端末群）と組み合わせることで、規模の大きな攻撃にもなります。

DDoS攻撃の全体像については、「DDoS攻撃とは？仕組み・種類・対策をわかりやすく解説」も参考にしてください。

攻撃の仕組み——TCPハンドシェイクの弱点

SYNフラッドを理解するには、TCPの接続確立プロセス（スリーウェイハンドシェイク）を知っておく必要があります。

正常なTCPスリーウェイハンドシェイク

TCPで接続を確立するとき、クライアントとサーバーは次の3ステップでやりとりします。

・① SYN（接続要求）: クライアントがサーバーへSYNフラグを立てたパケットを送る
・② SYN-ACK（接続確認）: サーバーがSYN-ACKパケットで応答し、ACKを待つ「ハーフオープン」状態になる
・③ ACK（確認応答）: クライアントがACKを返すとセッションが確立される

サーバーはSYN-ACKを返してからACKが届くまでの間、接続情報をSYN待ちキュー（バックログ）に保持しています。このキューには容量の上限があります。

SYNフラッド攻撃の流れ

攻撃者はこの「ハーフオープン」状態の弱点を突きます。

・① 偽装IPでSYNを大量送信: 攻撃者は実在しないIPアドレス（IPスプーフィング）に偽装したSYNパケットをサーバーへ送り続ける
・② サーバーがSYN-ACKを返す: サーバーは各SYNに対してSYN-ACKを返し、ハーフオープン接続をキューに積む
・③ ACKが戻ってこない: 偽装されたIPアドレスは存在しないため、ACKは届かない。サーバーはタイムアウトまでキューにエントリを持ち続ける
・④ SYNキューが溢れる: 大量のハーフオープン接続でキューが満杯になり、正規ユーザーからの接続要求を受け付けられなくなる

IPスプーフィングによって攻撃者は追跡されにくくなり、応答パケットを受け取ることもないため検知が難しくなります。攻撃者視点では、少ないリソースで大きな被害を与えられる「コスパの良い」手法です。

具体的な防御手順

Linuxサーバーでは、OSレベルでSYNフラッドに対抗する複数の手段が提供されています。段階的に設定していきましょう。

1. SYN Cookiesを有効化する

SYN Cookiesは、Linuxカーネルに組み込まれたSYNフラッド対策の仕組みです。SYNキューが満杯になったとき、サーバーはSYN-ACKのシーケンス番号に接続情報をエンコード（Cookie）して返します。正規のクライアントからACKが届いたとき、そのCookieを検証して接続を確立できるため、キューを消費せずにハンドシェイクを完了できます。

まず現在の設定を確認します。

# SYN Cookiesの有効/無効を確認（1=有効、0=無効）
sysctl net.ipv4.tcp_syncookies

値が0の場合は有効化します。まず即時反映させるコマンドを実行し、次に再起動後も設定が残るよう永続化します。

# 即時有効化（再起動で元に戻る）
sudo sysctl -w net.ipv4.tcp_syncookies=1

# /etc/sysctl.conf に追記して永続化
echo "net.ipv4.tcp_syncookies = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Ubuntu 20.04以降やRHEL 8以降など、多くの現代的なLinuxディストリビューションではデフォルトで有効になっています。変更前に必ず現在値を確認してください。

sysctlによるLinuxカーネルパラメータのセキュリティ強化全般については、「Linuxのsysctlセキュリティ設定｜カーネルパラメータで攻撃を防ぐ実践ガイド」も参照してください。

2. SYNバックログのサイズとタイムアウトを調整する

SYNキューのサイズを増やし、ハーフオープン接続のタイムアウトを短縮することで、攻撃の影響を抑えられます。次の値を/etc/sysctl.confに追記してください。

# SYN待ちキューの最大サイズを拡大（デフォルト: 1024）
net.ipv4.tcp_max_syn_backlog = 4096

# SYN-ACKの再送回数を減らしタイムアウトを短縮（デフォルト: 5）
net.ipv4.tcp_synack_retries = 2

# SYNの再送回数を減らす（デフォルト: 6）
net.ipv4.tcp_syn_retries = 2

# 設定を即時反映
sudo sysctl -p

注意: tcp_synack_retriesを下げすぎると、ネットワーク遅延の大きい正規クライアントが接続できなくなる場合があります。値は2～3程度を目安にしてください。

3. nftablesでSYNパケットのレート制限を設定する

ファイアウォールレベルでSYNパケットのレートを制限し、短時間に大量のSYNが来た場合にドロップするルールを追加します。次の例はnftablesでの設定です。

# /etc/nftables.conf への追記例（既存のtableとchainに合わせて調整する）

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    # 確立済みの接続は許可（ステートフル）
    ct state established,related accept

    # SYNパケットを毎秒200パケットまでに制限、超過はドロップ
    tcp flags & (fin|syn|rst|ack) == syn \
      limit rate 200/second burst 100 packets accept

    tcp flags & (fin|syn|rst|ack) == syn drop
  }
}

nftablesの基本的なセットアップについては「nftablesの設定入門｜iptablesの後継でLinuxファイアウォールを構築する実践ガイド」を参照してください。また、LinuxのSSHやシステムコール制限など、サーバー全体の堅牢化については姉妹サイトLinuxMaster.JPでも詳しく解説しています。

中小企業でも今日からできること

Linuxの細かい設定変更が難しい環境でも、次のアプローチで段階的に対策を進められます。

・SYN Cookiesの確認から始める: sysctl net.ipv4.tcp_syncookiesを確認し、0なら1に変更するだけ。作業時間は5分以内で、多くの環境ですでに有効です。
・CDNやDDoS緩和サービスを活用する: CloudflareなどのCDNを前段に置くと、SYNフラッドを含む多くのDDoS攻撃をCDN側で吸収してくれます。無料・低コストのプランでも基本的な保護が得られます。
・クラウドプロバイダの保護を確認する: AWS ShieldのStandardプランやAzure DDoS Protectionの基本層はデフォルトで有効です。クラウドを使っている場合は追加設定なしで一定の保護が受けられます。
・上流プロバイダへの連絡先を把握しておく: 大規模な攻撃ではサーバー単体での対処が難しいため、VPSプロバイダやISPのDDoS通報窓口を事前に調べておきましょう。攻撃発生後に慌てて探すと対応が遅れます。

よくある誤解と注意点

【誤解1】攻撃元IPをブロックすれば防げる

SYNフラッドはIPスプーフィングと組み合わせることが多く、攻撃パケットの送信元IPは無数に変化します。特定のIPをブロックしても別のIPで来るため、IPブロック単体では効果がありません。GeoIPブロッキングも同様で、送信元が偽装されていれば無力です。

【誤解2】ステートフルファイアウォールを通せば安全

ステートフルファイアウォール自体もTCP接続の状態を追跡するためにメモリを消費します。SYNフラッドの量が多いと、ファイアウォール側の接続追跡テーブルが先に上限に達し、正規の通信まで遮断されてしまうことがあります。ファイアウォールの内側にサーバーを置いているからといって安心はできません。

【誤解3】SYN Cookiesを入れればDDoSは完全に防げる

SYN Cookiesはサーバーのリソース枯渇を防ぐ有効な手段ですが、回線帯域自体が攻撃パケットで埋まってしまうような大規模な帯域消費型攻撃には無力です。帯域を使い切る規模の攻撃には上流（CDN・ISP・クラウドプロバイダ）でのフィルタリングが不可欠です。「100%安全」な単一の対策はなく、多層防御が基本です。

【注意】SYN Cookiesにはトレードオフがある

SYN Cookiesが動作している間は、TCPオプション（Window Scaling・SACKなど）の一部情報がエンコードされないため、接続の最大スループットが低下することがあります。通常のトラフィック量では問題になりませんが、高スループットが求められる大規模DBサーバーなどでは、設計段階から考慮が必要です。

本記事のまとめ

SYNフラッド攻撃の仕組みと対策を整理します。

SYNフラッドは古典的な攻撃でありながら、シンプルさゆえに今も企業のサーバーを狙い続けています。まずSYN Cookiesが有効になっているかを5分で確認し、nftablesでのレート制限を加えることで、多くの攻撃シナリオに対して耐性を持たせられます。それでも大規模な帯域攻撃には上流での緩和が不可欠です。段階的に対策を積み重ねていきましょう。