SYN Flood的基本原理

　　SYN Flood是當前最流行的DoS(拒絕服務(wù)攻擊)與DDoS(分布式拒絕服務(wù)攻擊)的方式之一，它是利用TCP協(xié)議缺陷，發(fā)送大量偽造的TCP連接請求，從而使得被攻擊方資源耗盡(CPU滿負荷或內(nèi)存不足)的攻擊方式，最終導(dǎo)致系統(tǒng)或服務(wù)器宕機。

　　在討論SYN Flood原理前，我們需要從TCP連接建立的過程開始說起：

　　TCP與UDP不同，它是基于連接的，為了在服務(wù)端和客戶端之間傳送TCP數(shù)據(jù)，必須先建立一個虛擬電路，也就是TCP連接。也就是我們經(jīng)常聽說的TCP協(xié)議中的三次握手（Three-way Handshake），建立TCP連接的標準過程如下：

　　首先，客戶端發(fā)送一個包含SYN標志的TCP報文，SYN即同步（Synchronize），同步報文會指明客戶端使用的端口以及TCP連接的初始序號;

　　其次，服務(wù)器在收到客戶端的SYN報文后，將返回一個SYN+ACK（即確認Acknowledgement）的報文，表示客戶端的請求被接受，同時TCP初始序號自動加一。

　　最后，客戶端也返回一個確認報文ACK給服務(wù)器端，同樣TCP序列號被加一，到此一個TCP連接完成。

　　SYN Flood攻擊正是利用了TCP連接的三次握手，假設(shè)一個用戶向服務(wù)器發(fā)送了SYN報文后突然死機或掉線，那么服務(wù)器在發(fā)出SYN+ACK應(yīng)答報文后是無法收到客戶端的ACK報文的(第三次握手無法完成)，這種情況下服務(wù)器端一般會重試(再次發(fā)送SYN+ACK給客戶端)并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數(shù)量級(大約為30秒-2分鐘)；一個用戶出現(xiàn)異常導(dǎo)致服務(wù)器的一個線程等待1分鐘并不會對服務(wù)器端造成什么大的影響，但如果有大量的等待丟失的情況發(fā)生，服務(wù)器端將為了維護一個非常大的半連接請求而消耗非常多的資源。我們可以想象大量的保存并遍歷也會消耗非常多的CPU時間和內(nèi)存，再加上服務(wù)器端不斷對列表中的IP進行SYN+ACK的重試，服務(wù)器的負載將會變得非常巨大。如果服務(wù)器的TCP/IP棧不夠強大，最后的結(jié)果往往是堆棧溢出崩潰。相對于攻擊數(shù)據(jù)流，正常的用戶請求就顯得十分渺小，服務(wù)器疲于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求，此時從正常客戶會表現(xiàn)為打開頁面緩慢或服務(wù)器無響應(yīng)，這種情況就是我們常說的服務(wù)器端SYN Flood攻擊(SYN洪水攻擊)。

　　從防御角度來講，存在幾種的解決方法：

      第一種是縮短SYN Timeout時間，由于SYN Flood攻擊的效果取決于服務(wù)器上保持的SYN半連接數(shù)，這個值=SYN攻擊的頻度 x SYN Timeout，所以通過縮短從接收到SYN報文到確定這個報文無效并丟棄改連接的時間，例如設(shè)置為20秒以下，可以成倍的降低服務(wù)器的負荷。但過低的SYN Timeout設(shè)置可能會影響客戶的正常訪問。

　　第二種方法是設(shè)置SYN Cookie，就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內(nèi)連續(xù)受到某個IP的重復(fù)SYN報文，就認定是受到了攻擊，并記錄地址信息，以后從這個IP地址來的包會被一概丟棄。這樣做的結(jié)果也可能會影響到正常用戶的訪問。

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

　SYN Flooder源碼解讀

　　下面我們來分析SYN Flooder的程序?qū)崿F(xiàn)。

　　首先，我們來看一下TCP報文的格式：

      0 1 2 3 4 5 6
　　0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| IP首部 | TCP首部 | TCP數(shù)據(jù)段　　 |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　                                             圖一 TCP報文結(jié)構(gòu)

　　如上圖所示，一個TCP報文由三個部分構(gòu)成：20字節(jié)的IP首部、20字節(jié)的TCP首部與不定長的數(shù)據(jù)段，實際操作時可能會有可選的IP選項，這種情況下TCP首部向后順延，由于我們只是發(fā)送一個SYN信號，并不傳遞任何數(shù)據(jù)，所以TCP數(shù)據(jù)段為空。TCP首部的數(shù)據(jù)結(jié)構(gòu)為：

      0 1 2 3
　　0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 十六位源端口號 | 十六位目標端口號 |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 三十二位序列號 |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 三十二位確認號 |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 四位 | |U|A|P|R|S|F| |
　　| 首部 |六位保留位 |R|C|S|S|Y|I| 十六位窗口大小 |
　　| 長度 | |G|K|H|T|N|N| |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 十六位校驗和 | 十六位緊急指針 |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 選項(若有) |
　　+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　| 數(shù)據(jù)(若有) |