SYN Flood攻擊的基本原理(轉)

SYN Flood攻擊的基本原理(轉)[@more@]

　　SYN Flood是當前最流行的DoS（拒絕服務攻擊）與DdoS（分散式拒絕服務攻擊）的方式之一，這是一種利用TCP協議缺陷，傳送大量偽造的TCP連線請求，從而使得被攻擊方資源耗盡（CPU滿負荷或記憶體不足）的攻擊方式。

　　要明白這種攻擊的基本原理，還是要從TCP連線建立的過程開始說起：

　　大家都知道，TCP與UDP不同，它是基於連線的，也就是說：為了在服務端和客戶端之間傳送TCP資料，必須先建立一個虛擬電路，也就是TCP連線，建立TCP連線的標準過程是這樣的：

　　首先，請求端（客戶端）傳送一個包含SYN標誌的TCP報文，SYN即同步（Synchronize），同步報文會指明客戶端使用的埠以及TCP連線的初始序號；

　　第二步，伺服器在收到客戶端的SYN報文後，將返回一個SYN+ACK的報文，表示客戶端的請求被接受，同時TCP序號被加一，ACK即確認（Acknowledgement）。

　　第三步，客戶端也返回一個確認報文ACK給伺服器端，同樣TCP序列號被加一，到此一個TCP連線完成。

　　以上的連線過程在TCP協議中被稱為三次握手（Three-way Handshake）。

　　問題就出在TCP連線的三次握手中，假設一個使用者向伺服器傳送了SYN報文後突然當機或掉線，那麼伺服器在發出SYN+ACK應答報文後是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下伺服器端一般會重試（再次傳送SYN+ACK給客戶端）並等待一段時間後丟棄這個未完成的連線，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數量級（大約為30秒-2分鐘）；一個使用者出現異常導致伺服器的一個執行緒等待1分鐘並不是什麼很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，伺服器端將為了維護一個非常大的半連線列表而消耗非常多的資源----數以萬計的半連線，即使是簡單的儲存並遍歷也會消耗非常多的CPU時間和記憶體，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果伺服器的TCP/IP棧不夠強大，最後的結果往往是堆疊溢位崩潰---即使伺服器端的系統足夠強大，伺服器端也將忙於處理攻擊者偽造的TCP連線請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，伺服器失去響應，這種情況我們稱作：伺服器端受到了SYN Flood攻擊（SYN洪水攻擊）。

　　從防禦角度來說，有幾種簡單的解決方法：

　　第一種是縮短SYN Timeout時間，由於SYN Flood攻擊的效果取決於伺服器上保持的SYN半連線數，這個值=SYN攻擊的頻度 x　SYN Timeout，所以透過縮短從接收到SYN報文到確定這個報文無效並丟棄改連線的時間，例如設定為20秒以下（過低的SYN Timeout設定可能會影響客戶的正常訪問），可以成倍的降低伺服器的負荷。

　　第二種方法是設定SYN Cookie，就是給每一個請求連線的IP地址分配一個Cookie，如果短時間內連續受到某個IP的重複SYN報文，就認定是受到了攻擊，以後從這個IP地址來的包會被丟棄。

　　可是上述的兩種方法只能對付比較原始的SYN Flood攻擊，縮短SYN Timeout時間僅在對方攻擊頻度不高的情況下生效，SYN Cookie更依賴於對方使用真實的IP地址，如果攻擊者以數萬/秒的速度傳送SYN報文，同時利用SOCK_RAW隨機改寫IP報文中的源地址，以上的方法將毫無用武之地。