概要

今回の実験は、DoS (Denial of Service) 攻撃の一種である「SYN Flood 攻撃」を仮想環境で実行します。

攻撃者（Kali Linux）から、意図的に脆弱性を残されたターゲット（Metasploitable2）に対し、hping3 ツールを用いて大量のSYNパケットを送信します。

この実験を通じて、TCPの3ウェイハンドシェイクの仕組みと、それを悪用したリソース枯渇攻撃の原理、および攻撃強度とサーバーの処理能力の関係性を理解することを目的とします。

thumbnail

1. SYN Flood 攻撃とは

SYN Flood 攻撃は、TCP接続確立のプロセス（3ウェイハンドシェイク）を悪用した攻撃です。

攻撃者は、接続要求の最初のパケットである `SYN` のみを大量に送りつけます。サーバーは律儀に `SYN/ACK` を返信し、攻撃者からの最後の `ACK` を待ちますが、攻撃者は意図的に `ACK` を返しません。

これにより、サーバー側では「ACK待ち」の状態（SYN_RECV状態）の接続が大量に発生します。この「ハーフオープン接続」を保持するためのリソース（接続キュー）が枯渇すると、サーバーは新規の正規な接続を受け入れられなくなり、サービス拒否（DoS）状態に陥ります。

2. 環境構築

両仮想マシンを「ホストオンリーアダプター」または「ブリッジアダプター」に設定し、同一ネットワークセグメントに参加させます。

  • 攻撃者: Kali Linux (IP: 192.168.2.175)
  • 被害者 (Webサーバー): Metasploitable2 (IP: 192.168.2.177)
  • 攻撃ツール: hping3

被害者側 (Metasploitable2) の設定

Metasploitable2は起動すると、デフォルトでWebサーバー（Apache）が稼働しています。

これらは、Webアプリケーションの脆弱性診断（ペネトレーションテスト）の技術を学習・訓練するために、意図的に脆弱な設定や古いバージョン、脆弱なアプリケーションを含んだ状態で用意されています。

img0
img1
  1. 1. SYN Cookies の無効化 (実験のため):
    LinuxにはSYN Floodへの耐性を持つ「SYN Cookies」機能があります。この機能の有無を確認し、有効だった場合は実験の効果を明確にするため無効化します。（1なら有効、0なら無効） 
    # 現在の設定を確認
sysctl net.ipv4.tcp_syncookies

# 無効化する場合 (攻撃が効きやすくなる)
sudo sysctl -w net.ipv4.tcp_syncookies=0
  2. 2. リソースモニターの表示 (任意):
    top コマンドや vmstat などで、CPUやネットワークの負荷を監視しておくと、攻撃の影響が視覚的に分かりやすくなります。

3. 攻撃の実行と観測

攻撃者（Kali Linux）側で、パケットを観測する `Wireshark` と、攻撃を実行するターミナルを準備します。Wiresharkでは ip.addr == 192.168.2.177 などのフィルターをかけておきます。

攻撃の実行

まず、`hping3` を一つのプロセスで実行し、`--flood` オプションで可能な限りの速度で送信します。

なお、今回の攻撃はあくまで実験なのでIPアドレスの偽装は行いません。Syn Flood攻撃はレスポンスを受け取ることを前提としません。なので実際の攻撃ではこの時点でIPアドレスを偽装してFWでのブロックやログの分析を逃れようとするのが一般的です。

# -S (SYNフラグ), -p 80 (ポート80), --flood (最速送信)
sudo hping3 -S -p 80 --flood 192.168.2.177

結果

Wiresharkには膨大な量のSYNパケットが観測され、Metasploitable2のリソースモニターでもCPUやネットワーク使用率の上昇が確認できます。

img2

Metasploitable 2で以下のコマンドを実行すると現在のSYN_RECV状態にあるTCP接続の総数が表示されます。

# 現在、ACK待ちのハーフオープン接続が、合計でいくつあるか
netstat -nat | grep SYN_RECV | wc -l

これにより、通常時（攻撃を受けていないとき）と比べてSYN_RECVの数が多くなっていることが観測できます。

・攻撃前

img3

・攻撃後

img4

しかし、ホストOSのブラウザから http://192.168.2.177 にアクセスすると、多少の遅延は感じるものの、Webページは表示されてしまいました。

攻撃が失敗した原因の考察

Wiresharkの観測結果をもう一度よく見てみました。

すると、KaliからMetasploitable 2宛にSynが送られた後、Metasploitable 2からのレスポンスとしてSyn/Ackが帰ってきています。これはTCPの3ウェイハンドシェイクの2段階目です。ここまでは想定内ですが、この後KaliがRSTを返してしまっています。

img5

おそらく、hping3が特殊な方法でパケットを生成しているため、カーネルは「自分が開始した正規の接続」としてこのパケットを管理しておらず、「身に覚えのないSYN/ACKが届いた」と判断し、「この通信は無効です」と伝えるために、自動的に RST (リセット) パケットをサーバーに返信しているのだと考えられます。この動作のせいでMetasploitable 2の方ではSYN_RECVが溜まらず消費され続け正常に動作できてしまったものと思われます。

そこでKaliがRSTを返さないように以下の設定をします。

sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
# -A OUTPUT: 送信（OUTPUT）パケットのルールに追加
# -p tcp: TCPプロトコルを対象
# --tcp-flags RST RST: RSTフラグが立っているパケットを指定
# -j DROP: 上記の条件に一致するパケットを破棄（送信しない）

再度攻撃を実行した結果

先ほどと同じくSYN_RECVを確認してみるとMetasploitable 2のデフォルトのSYNキューの最大値（上限）である 256に到達し、消費されることなく張り付いていることが分かります。

img6

この状態でホストOSのブラウザからアクセスすると、Metasploitable2からのレスポンスが一切なくなり、最終的にタイムアウトエラーとなりました。

img7

なお、実験が終了したら以下のコマンドで設定を元に戻してください。（-A を -D に変えるだけです）

sudo iptables -D OUTPUT -p tcp --tcp-flags RST RST -j DROP

4. 考察と対策

今回の実験では、SYN Flood攻撃の成否に、攻撃側のOSカーネルの動作が大きく影響することが確認できました。

単に `hping3` でパケットを送信するだけでは、OSが自動的に RST を返信してしまうため、サーバー側の SYNキュー が溜まりません。iptables を用いてこの自動応答を遮断することで、初めてサーバーのリソース（SYNキュー）を枯渇させることに成功しました。

脅威・リスク

  • サービス停止: 正規のユーザーがサービスを利用できなくなり、ビジネス上の機会損失や信用の失墜に繋がります。
  • 金銭的被害: クラウドサービス（AWS, GCPなど）上でサーバーを運用している場合、攻撃によって発生した大量のトラフィック（データ転送量）に対しても課金が発生し、莫大な請求に繋がる可能性があります。

対策・対処

SYN Floodは非常に古典的ですが、今なお強力な攻撃手法です。

サーバー・ネットワーク管理者側の対策:

  • SYN Cookiesの有効化: 最も基本的な対策です。OSレベルでSYN Cookiesを有効（net.ipv4.tcp_syncookies = 1）にすることで、SYNキューが溢れることを防ぎます。
  • ファイアウォール / IPS: 単一IPからの異常なSYNパケットを検知し、レート制限（一定時間内の接続数を制限）やIPアドレスの遮断を行います。
  • DDoS保護サービスの利用: AWS Shield, Cloudflare, Akamaiなどの専門的なDDoS対策サービスを利用することが、最も現実的かつ強力な対策となります。これらのサービスは、巨大なネットワーク帯域幅で攻撃トラフィックを「洗浄」し、正常な通信のみをサーバーに届けます。