Syn Flood攻撃の実験をしてみた

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

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

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

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

Metasploitable2 は起動するとデフォルトで Web サーバー (Apache) が稼働している。これらは、Web アプリケーションの脆弱性診断 (ペネトレーションテスト) の技術を学習・訓練するために、意図的に脆弱な設定や古いバージョン、脆弱なアプリケーションを含んだ状態で用意されている。

被害者側 (Metasploitable2) の設定 #

1. SYN Cookies の無効化 (実験のため) — Linux には SYN Flood への耐性を持つ SYN Cookies 機能がある。この機能の有無を確認し、有効だった場合は実験の効果を明確にするため無効化する (1 なら有効、0 なら無効)。

# 現在の設定を確認
sysctl net.ipv4.tcp_syncookies

# 無効化する場合 (攻撃が効きやすくなる)
sudo sysctl -w net.ipv4.tcp_syncookies=0

2. リソースモニターの表示 (任意) — top コマンドや vmstat などで、CPU やネットワークの負荷を監視しておくと、攻撃の影響が視覚的に分かりやすくなる。

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

攻撃の実行 (1 回目) #

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

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

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

観察結果 (1 回目) #

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

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

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

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

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

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

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

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

攻撃の実行 (2 回目) #

そこで 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: 上記の条件に一致するパケットを破棄(送信しない)

観察結果 (2 回目) #

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

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

実験が終了したら以下のコマンドで設定を元に戻す (-A を -D に変えるだけ)。

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

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

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

脅威・リスク #

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

対策・対処 #

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