はじめに
通信の仕組みを学習していると、必ず耳にするスリーウェイハンドシェイクですが、 実はこの「接続要求が来れば、リソースを確保して返事を待つ」というTCPの基本的な設計そのものが、脆弱性になり得ることをご存知でしょうか？
自宅のパソコン1台からでも実行できてしまうような攻撃が、実際にサーバーにどれほどの影響を与えるのか？ それを防御するまでにどれだけの作業が必要なのか？
本記事では、仮想環境(VirtualBox)を使ってスリーウェイハンドシェイクの仕組みを逆手にとる攻撃「SYNフラッド攻撃」を実際に再現し、サーバーが受ける影響と、OS標準の防御機能である「SYN Cookies」によって問題を解決するプロセスをハンズオン形式で検証していきます。
PC1台があれば簡単に試せる内容となっていますので、ぜひ一緒に手を動かしてチャレンジしてみてください。
各主要技術の仕組み
ハンズオンに入る前に、今回使用する主要技術のポイントを3点簡単におさらいします。
スリーウェイハンドシェイクの仕組み
TCP通信では、データを送る前に必ず挨拶(SYN, SYN-ACK, ACKパケット)を交わしてコネクションを確立します。
Step 1. クライアント: 「通信したいです！」(SYN)
Step 2. サーバー: 「いいですよ！そちらも準備できてますか？」(SYN-ACK)
Step 3. クライアント: 「OKです！」(ACK) → 【接続完了】
サーバーは「Step 2(SYN-ACK)」の段階で、クライアントからの「Step 3(ACK)」の返事を待つために、メモリ上に専用の待機スペース(SYNキュー)を確保し、「ハーフオープン(半開状態)」で待機します。
SYNフラッド攻撃の仕組み
SYNフラッド攻撃は、このスリーウェイハンドシェイクのStep 2状態の「返事待ち」の仕組みを悪用します。 攻撃者は大量の「Step 1(SYN)」だけを送りつけ、サーバーからの「Step 2(SYN-ACK)」に対して意図的に「Step 3(ACK)」を返しません。
さらにIP偽装(IP Spoofing)を組み合わせると、サーバーは偽装用に設定された宛先にSYN-ACKを返し続けることになり、偶然そのIPを持っていたどこかのPCは、身に覚えのないSYN-ACKには「Step 3(ACK)」を返しません。
結果として、サーバーの待機スペース(SYNキュー)が架空の接続要求で溢れ(SYNフラッド)、サーバー側で防御策を実施するか、または攻撃者が攻撃を止めるまで正規のユーザーからの接続要求を受け付けられなくなってしまいます。
SYN Cookiesの仕組み
SYN Cookiesは、Step 2の段階でサーバーのSYNキューに接続待ち状態を保持せず、接続に必要な情報から生成したハッシュ値をSYN-ACKの初期シーケンス番号として送り返す技術です。
クライアントから正当な「Step 3(ACK)」が返ってきた際、サーバーはその数値を検証して初めてAcceptキューとしてメモリを確保し、TCP接続を確立します。これにより、SYNフラッド攻撃で待機スペースが溢れている状態でも、正規ユーザーの接続を破棄せず処理を継続できます。
本検証では手動で無効化し、攻撃を受けている最中に有効化するため「通信が復旧した」ように見えますが、実際の運用環境ではそもそも無効化することは基本的にありません。
有効化されていればSYNキューが溢れた時点で自動的に処理が切り替わるため、正規の通信は一度も途絶えることなく「そのまま維持される」のが実態です。
ハンズオン
事前準備：環境の構成
今回は、外部ネットワークから隔離された安全な検証環境を作ります。
VirtualBox上に3台の仮想マシン(VM)を構築し、ネットワーク設定を「内部ネットワーク(例: syn-lab)」に統一します。
| 役割 | OS (推奨) | 任意のIPアドレス | 使用ツール・用途 |
|---|---|---|---|
| ターゲット (WEBサーバー) | Ubuntu Server | 192.168.10.10/24 | Nginx, ss, sysctl |
| 攻撃者 | Kali Linux | 192.168.10.20/24 | hping3 (パケット生成) |
| 正規クライアント | Ubuntu Desktop | 192.168.10.30/24 | Webブラウザ, curl |
※本検証は、攻撃パケットの影響を直接観察するためにあえて同一ネットワーク内で実施しています。実運用環境においては、通信回線側の制限や、FWやクラウドなど手前の防御機器によってサーバー到達前に遮断されるケースが大半です。
検証手順：攻撃の再現と防御
それでは、実際に検証を進めていきます。本章では、以下の4ステップで攻撃の再現から防御までを検証します。
Step 1. ベースラインの構築: 正常時にターゲットサーバーへアクセスできることを確認する
Step 2. サーバーを脆弱な状態に設定する: SYN Cookiesを無効化し、攻撃が通る状態にする
Step 3. SYNフラッド攻撃の実行と被害の確認: 実際に攻撃を発生させ、サーバーが応答不能になる様子を確認する
Step 4. SYN Cookiesによる防御: 攻撃検知中にSYN Cookiesを有効化し、即座に復旧する様子を確認する
(※各VMのOSインストール、IPアドレス設定は完了している前提で進めます。ただし、Kali LinuxのIPアドレス固定設定では筆者もつまずいたため、参考までに手順を残しておきます。)
💻 Kali LinuxのIPアドレス固定でつまずいたポイント
Kali Linuxは公式サイトのVMwareイメージをダウンロード、フォルダ解凍後、.vboxの拡張子ファイルを起動しました。しかし、IPアドレスを設定するコマンドを実行しても他のPCにpingが通らず、ネットワーク接続もdisconnectedのままという状態になってしまいました。
Linuxにおいて一時的にIPアドレスを変更するコマンド(ip addr add など)は、メモリ上でのみ設定が保持されるため、OSの再起動やネットワークの再起動時に設定が初期化してしまいます。
OS再起動後も設定を維持させるには、ネットワーク管理デーモンであるNetworkManagerを介して設定ファイルへ変更を書き込む必要があります。 原因の切り分けと解決までの手順を残しておきます。
# Kali側のインターフェースにIPアドレスを割り当て、IPアドレスが正しく反映され、インターフェースのステータスがUPになっているか確認します sudo ip addr add 192.168.10.20/24 dev eth0 sudo ip link set eth0 up ip a # ※上記のipコマンドでのインターフェースの設定だけではOS再起動時に消去されてしまうので、併せてnmcliコマンドも実行します # NetworkManager側の設定もすることで設定が固定化され再起動時の再設定が不要になります。コマンドラインツールではnmcliで固定IPアドレスを適用できます。 nmcli connection show # NetworkManagerで認識されている接続プロファイル名やUUID、デバイスとの紐付き状況の確認。 nmcli connection modify "eth0" ipv4.addresses 192.168.10.20/24 # 固定IPを登録 nmcli connection modify "eth0" ipv4.method manual # IP取得方式をDHCPから手動に変更 nmcli connection down "eth0" nmcli connection up "eth0" # 一度接続を切断し、再接続することで変更したプロファイル設定を即座に適用
Step 1: 環境構築
まずは、ターゲットサーバーにWebサーバー(Nginx)を立てて、正常にアクセスできることを確認します。
💻 ターゲットサーバー側
# Nginxのインストールと起動 sudo apt update && sudo apt install -y nginx sudo systemctl start nginx # 80番ポートが待機(LISTEN)状態か確認 ss -ant | grep 80
出力例: LISTEN 0 511 0.0.0.0:80 0.0.0.0:* となっていることを確認してください。
💻 正規クライアント側
# Webサーバーへアクセス確認 curl -I http://192.168.10.10
出力例: HTTP/1.1 200 OK が返ってくれば、正常な通信ができています。
Step 2: サーバーを脆弱な状態に設定する
最近のLinuxはデフォルトでSYNフラッド対策が有効になっていることが多いので、検証のために一時的に制限を緩和させます。具体的にはSYN Cookiesの無効化と、SYNキューの容量を小さくすることで、SYNキューをフラッディングさせ易くします。 また、VirtualBoxの内部ネットワークでは、Ubuntu Serverのファイアウォール(ufw)が80番ポートへの着信パケットを遮断していることが多いため、後続のStep 3で送信元IPを偽装(--rand-source)した攻撃パケットを通すために、あわせて無効化しておきます。
※今回は検証のため手動でSYN Cookiesなどの設定を変更していますが、セキュリティ上のリスクがあるため、通常利用時は設定を変更しないでください。
💻 ターゲットサーバー側
# SYN Cookiesを無効化 sudo sysctl -w net.ipv4.tcp_syncookies=0 # SYNキューの容量を小さく制限(少ない攻撃で溢れさせるため) sudo sysctl -w net.ipv4.tcp_max_syn_backlog=10 # ファイアウォール(ufw)を無効化(80番ポートへの着信パケット遮断を防ぐため) sudo ufw disable
Step 3: SYNフラッド攻撃の実行と被害の確認
ここからは攻撃を実行します。Kali Linuxの高速パケット生成ツール hping3 を使用します。hping3のコマンドは継続実行させておきます。
💻 攻撃者側 (Kali Linux)
# ポート80宛に、送信元IPをランダムに偽装(--rand-source)して送信インターバル0で(--flood) SYNパケット(-S)を送信 sudo hping3 -S -p 80 --flood --rand-source 192.168.10.10
(※実行するとプロンプトでは見えませんが、裏でパケットを大量に送信し続けています。)
💻 ターゲットサーバー側で状態を確認
サーバー側でTCPコネクションの状態を確認してみましょう。
sudo tcpdump -i any port 80 -n ss -ant | grep SYN-RECV | wc -l
対象サーバー上でハーフオープン接続(SYN-RECV)が0のままになっています。
調査の結果、tcpdumpで観測できるパケットがSYN-RECVに反映されていないことから、IP層でのカーネルドロップが発生していることと、かつ送信元IPを偽装している点から、OS(Linuxカーネル)の逆経路フィルタリング機能により、送信元が偽装された通信がネットワークレイヤーで正しく検知・破棄されている可能性が高いことが判明しました。
次のステップとして、検証シナリオに沿った負荷状態を再現するため、カーネルパラメータを調整して一時的に防御機能を解除し、再検証を実施します。
ポイント：逆経路フィルタリングとは
Linuxカーネルの「逆経路フィルタリング(rp_filter)」とは、ランダムに偽装された送信元IPに対して「ルーティングテーブル上、そのパケットが届くはずのないIFから来ている」とOSが判断し、TCP層に届く前のネットワーク層で自動的にパケットを破棄するシステムです。
💻 ターゲットサーバー側
# 1. IP偽装フィルター(rp_filter)を無効化する。ランダムな送信元IP(--rand-source)のパケットを通すため、逆経路フィルタリングを無効化します。 sudo sysctl -w net.ipv4.conf.all.rp_filter=0 sudo sysctl -w net.ipv4.conf.default.rp_filter=0 # コマンド実行時は enp0s3 を実際のインターフェース名に置き換えて実行してください。 sudo sysctl -w net.ipv4.conf.enp0s3.rp_filter=0 # 2. ダミーのデフォルトゲートウェイ(ルーティング)を設定する。ランダムなIPアドレス宛への返答(SYN-ACK)の送信先として、自身のNICを指定するデフォルトルートを追加します。(※enp0s3 は実際のNIC名に変更してください) # さらにデフォルトゲートウェイを設定することで、ルーティング経路の無いランダムなアドレス宛でもTCP層で破棄されないようにします。 sudo ip route add default dev enp0s3
【検証状況：サーバー負荷の急増】
設定変更を行ったSYNキュー(上限10件)において、現在9件まで使用率が上昇しています。ランダムな送信元からの接続要求(SYNパケット)が集中しており、接続待ちキューが枯渇寸前の状態となっています。
💻 正規クライアント側でアクセスを試みる
この状態で、正規のユーザーがWebサイトを見ようとするとどうなるでしょうか。
curl --connect-timeout 2 http://192.168.10.10
結果: Connection timeout
サーバーのキューがいっぱいになり、正規の接続要求に対応できない、サービスダウン(DoS状態)に陥ってしまいました。
Step 4: SYN Cookiesによる防御
この状況下で、Linuxカーネルに組み込まれた防御メカニズム「SYN Cookies」を有効にします。
💻 ターゲットサーバー側
# SYN Cookiesを有効化 sudo sysctl -w net.ipv4.tcp_syncookies=1
💻 正規クライアント側で再度アクセス
curl -I http://192.168.10.10
結果: HTTP/1.1 200 OK
裏ではSYNフラッド攻撃が続いているにもかかわらず、正規クライアントから正常にWebページにアクセスできるようになりました。
(※確認が終わったら、Kali Linux側で Ctrl+C を押して攻撃を停止してください)
💻 ターゲットサーバー側で検証環境を元に戻す
検証のために変更した設定は、ハンズオン終了後に元の状態へ戻しておきましょう。
# rp_filter(逆経路フィルタリング)を再度有効化する。 sudo sysctl -w net.ipv4.conf.all.rp_filter=1 sudo sysctl -w net.ipv4.conf.default.rp_filter=1 sudo sysctl -w net.ipv4.conf.enp0s3.rp_filter=1 # 追加したダミーのデフォルトルートを削除 sudo ip route del default dev enp0s3 # ファイアウォール(ufw)を再度有効化する。 sudo ufw enable
その他の主要な防御方法
今回はサーバーOSレベルでの対策(SYN Cookies)を検証しましたが、実際の運用環境では、サーバーへパケットが届く前段の各種ネットワーク機器や外部インフラを活用した「多層防御」が基本となります。
下記に代表例を提示します。
- SYN Proxy (ファイアウォール/ロードバランサー)
サーバーの代わりにネットワーク機器がスリーウェイハンドシェイクを代行し、正常に確立された通信(ACKまで確認できた通信)だけを背後のサーバーに流す仕組みです。 - BCP 38 (Ingress Filtering)
「IPスプーフィング(IP偽装)」を防ぐためのネットワーク機器の設定基準です。送信元IPが明らかに不正なパケットをネットワークの境界で破棄します。 - クラウド型DDoS緩和サービス (AWS Shield, Cloudflareなど)
巨大な帯域幅を持つクラウドのエッジネットワークで攻撃トラフィックを検知・遮断し、サーバー本体に攻撃を到達させない現代の防御の要です。
まとめ
本記事では、SYNフラッド攻撃について、プロトコルの仕組みから攻撃・観察・防御まで、下記の様に確認しました。
サーバーでSYN Cookiesが無効な場合、スリーウェイハンドシェイクで接続要求(SYN)を受けたサーバーはACKの返答を待つため、メモリ上のSYNキューに待機状態を保持していることが確認できた
攻撃者が意図的に最後のACKを返さず大量のSYNパケットを送り続けることで、このSYNキューを容易に枯渇させられた
hping3とIP偽装を組み合わせることで、単一の端末からでもサーバーを簡単にサービス不能へ追い込めた
- ターゲットサーバーでSYN Cookiesを有効化したことで、攻撃検知中でも問題なく正規クライアントとの接続を完了できることを確認した
SYNフラッド攻撃は特別な脆弱性を突くものではなく、信頼性を重視したTCPの基本的な仕様そのものを逆手にとった攻撃です。だからこそ、サーバーOS側のSYN Cookiesだけに依存するのではなく、SYN ProxyやBCP 38、クラウド型DDoS緩和サービスといった前段のネットワーク機器・インフラを組み合わせた多層防御が重要になります。
検証を通じての所感
今回のハンズオンを通して、以下の様な認識の再確認ができました。
- 標準仕様に潜む弱点の再確認
TCPの標準的なハンドシェイク仕様そのものを悪用してサービス停止を引き起こせる点に、基盤プロトコルにおける脅威の深刻さを再認識しました。 - ハッシュ化の活用によるリソース保護の有用性
ハードウェアリソースの増強といった物理的対処に頼るのではなく、ハッシュ技術を用いて接続状態をサーバーに保持しないSYN Cookiesなど、ハッシュ化の活用による根本的な防御方法の有効性を学びました。
ぜひ皆様も、実際に手を動かして検証してみてください
We Are Hiring!
今回は技術的な関心からSYNフラッド攻撃とSYN Cookiesによる防御の仕組みに触れてみましたが、こうしたネットワークプロトコルの基礎を体系的に理解しておくことは、設計・構築を行う上でも欠かせない土台になると感じました。
FindConsultingでは、ネットワークの基礎知識や実機での経験をベースに、大規模なネットワーク設計・構築や高度なインフラ領域など、エンジニアがさらにステップアップできる環境を整えています。また、資格取得支援や実案件への早期参画など、成長を後押しするサポートも充実しています。
こういったネットワークやクラウドインフラの知識を活かした仕事に興味がある方は、ぜひ一緒に働きませんか？
現在、FindConsultingではネットワークやクラウドインフラの技術に興味のある仲間を募集しています。
まずはカジュアル面談からでも、ぜひお気軽にお声がけください！
