SYN flood

SYN flood或稱SYN洪水、SYN洪泛是一種阻斷服務攻擊，起因於攻擊者傳送一系列的SYN請求到目標系統。^[1][2]

用戶（Alice）與伺服器之間正常連線狀況。三向交握正確的進行。

SYN Flood。攻擊者（Mallory）傳送許多封包就是不送"ACK"回到伺服器。該連線因此處於半開狀態並吞食伺服器資源。因為阻斷服務攻擊的結果合法用戶Alice與伺服器嘗試建立連線遭拒。

當用戶端試着與伺服器間建立TCP連線時，正常情況下用戶端與伺服器端交換一系列的資訊如下：

1. 用戶端透過傳送SYN同步（synchronize）資訊到伺服器要求建立連線。
2. 伺服器透過響應用戶端SYN-ACK以抄收（acknowledge）請求。
3. 用戶端答應ACK，連線隨之建立。

這即是所謂TCP三向交握，並且這是每個使用TCP傳輸協定建立連線的基礎。

SYN flood是一種廣為人知的攻擊，一般對現代網絡不太有效。這種攻擊只有在伺服器在收到SYN後分配資源，但在收到ACK之前這個區段有效。

SYN flood攻擊目前有兩種方法，不過都與伺服器端沒收到ACK有關。惡意用戶可以跳過傳送最後的ACK資訊；或者在SYN裏透過欺騙來源IP地址，這讓伺服器送SYN-ACK到假造的IP地址，因此永不可能收到ACK。因為沒有ACK也可能是因為一次簡單的網絡堵塞造成的，所以伺服器會花點時間等抄收通知。

如果這些半開通連線（英語：TCP half-open）綁定伺服器資源，透過海量SYN資訊淹沒伺服器是有可能耗盡其資源。一旦所有資源都撥給半開通連線所保留，沒有新的連線（不管合法不合法）可被建立，導致阻斷服務攻擊。如果系統呼叫函數需要使用到此類被消耗資源，某些系統可能會出現極為嚴重的故障，甚至宕機。

過去(1996年)用來分配資源給半開通連線的技術牽涉到通常相當短的佇列^[3]。佇列的每個空位可在連線完成、或者到期時^[4]被清空。當佇列滿時，新進來的連線建立會失敗。以上面的範例來說，所有新進來的連線在總共8個封包被送出之前會被阻擋下來。也就是說，每3分鐘正時算好的8個封包將阻斷所有新進的TCP連線完成。這讓這種阻斷服務攻擊只須佔很小的傳輸量。

建議的反制方法包括SYN cookie或者限定某一段時間內來自同一來源請求新連線的數量，不過因為現代的TCP/IP堆疊沒有上面所述的瓶頸，因此介於SYN flood與其它種基於通道容量類型的攻擊應該會只有很小或幾乎沒有差別。

反射路由器亦可以被攻擊者所利用，以取代客戶端機器。SYN講的是黑客利用TCP協定傳送大量的半連接請求去攻擊目標伺服器或者主機，致使目標伺服器發生阻斷服務，或者藍畫面。

對策

在 RFC 4987 中有許多著名的對策，包括：

1. 過濾
2. 增加積壓
3. 減少SYN-RECEIVED定時
4. 複用古老的半開通TCP（英語：TCP_half-open）
5. SYN快取
6. SYN Cookie
7. 混合方法
8. 防火牆和代理

相關概念

• 阻斷服務攻擊
• 互聯網控制訊息協定
• IP位址欺騙
• Smurf attack（英語：Smurf attack）
• Ping flood（英語：Ping flood）

參考資料

1. RFC4987 （頁面存檔備份，存於互聯網檔案館） TCP SYN Flood攻擊與一般對策
2. New York's Panix Service Is Crippled by Hacker Attack （頁面存檔備份，存於互聯網檔案館）, New York Times, September 14, 1996
3. 例如：8個空位長 （頁面存檔備份，存於互聯網檔案館）
4. 例如：3分鐘後 （頁面存檔備份，存於互聯網檔案館）

外部連結

• CERT官方對SYN攻擊的建議（頁面存檔備份，存於互聯網檔案館）
• Iptables protege contra SYN FLOOD?. [2008-09-25]. （原始內容存檔於2008-06-28） （巴西葡萄牙語）.