一、為什麼Syn Flood會造成危害

　　這要從作業系統的TCP/IP協議棧的實現說起。當開放了一個TCP埠後，該埠就處於Listening狀態，不停地監視發到該埠的Syn報文，一旦接收到Client發來的Syn報文，就需要為該請求分配一個TCB（Transmission Control Block），通常一個TCB至少需要280個位元組，在某些作業系統中TCB甚至需要1300個位元組，並返回一個SYN ACK命令，立即轉為SYN-RECEIVED即半開連線狀態，而某些作業系統在SOCK的實現上最多可開啟512個半開連線（如Linux2.4.20核心）。這種過程如下圖所示：

　　從以上過程可以看到，如果惡意的向某個伺服器埠傳送大量的SYN包，則可以使伺服器開啟大量的半開連線，分配TCB，從而消耗大量的伺服器資源，同時也使得正常的連線請求無法被相應。而攻擊發起方的資源消耗相比較可忽略不計。

　　SYN flood攻擊目前有兩種方法，不過都與伺服器端沒收到ACK有關。惡意使用者可以跳過傳送最後的ACK資訊；或者在SYN裡通過欺騙來源IP地址，這讓伺服器送SYN-ACK到假造的IP地址，因此永不可能收到ACK。這兩個案例伺服器會花點時間等抄收通知，故一個簡單的網路壅塞可能是由於沒有ACK造成的。

　　如果這些半開通連線繫結伺服器資源，通過海量SYN資訊淹沒伺服器是有可能耗盡其資源。一旦所有資源都撥給半開通連線所保留，沒有新的連線（不管合法不合法）可被建立，導致阻斷服務攻擊。某些系統可能會故障得很糟糕，甚至宕機如果其他作業系統函式渴望這種形式的資源。

　二、如何防禦Syn Flood攻擊

　　我們先來看一下Syn Flood有哪些種類，如下圖所示：

• 1． Direct Attack 攻擊方使用固定的源地址發起攻擊，這種方法對攻擊方的消耗最小；
• 2． Spoofing Attack 攻擊方使用變化的源地址發起攻擊，這種方法需要攻擊方不停地修改源地址，實際上消耗也不大；
• 3． Distributed Direct Attack 這種攻擊主要是使用僵屍網路進行固定源地址的攻擊；

　　對於第一種攻擊的防範可以使用比較簡單的方法，即對SYN包進行監視，如果發現某個IP發起了較多的攻擊報文，直接將這個IP列入黑名單即可。當然下述的方法也可以對其進行防範。

　　對於源地址不停變化的攻擊使用上述方法則不行，首先從某一個被偽裝的IP過來的Syn報文可能不會太多，達不到被拒絕的閾值，其次從這個被偽裝的IP發來的真實請求會被拒絕掉。因此必須使用其他的方法進行處理。

• 無效連線監視釋放： 這種方法不停監視系統的半開連線和不活動連線，當達到一定閾值時拆除這些連線，從而釋放系統資源。這種方法對於所有的連線一視同仁，而且由於SYN Flood造成的半開連線數量很大，正常連線請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬於入門級的SYN Flood方法。

• 延緩TCB分配方法： 從前面SYN Flood原理可以看到，消耗伺服器資源主要是因為當SYN資料報文一到達，系統立即分配TCB，從而佔用了資源。而SYN Flood由於很難建立起正常連線，因此，當正常連線建立起來後再分配TCB則可以有效地減輕伺服器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術。

  • Syn Cache技術： 這種技術是在收到SYN資料報文時不急於去分配TCB，而是先回應一個SYN ACK報文，並在一個專用HASH表（Cache）中儲存這種半開連線資訊，直到收到正確的迴應ACK報文再分配TCB。在FreeBSD系統中這種Cache每個半開連線只需使用160位元組，遠小於TCB所需的736個位元組。在傳送的SYN ACK中需要使用一個己方的Sequence Number，這個數字不能被對方猜到，否則對於某些稍微智慧一點的Syn Flood攻擊軟體來說，它們在傳送Syn報文後會傳送一個ACK報文，如果己方的Sequence Number被對方猜測到，則會被其建立起真正的連線。因此一般採用一些加密演算法生成難於預測的Sequence Number。Syn Cookie技術對於SYN攻擊，Syn Cache雖然不分配TCB，但是為了判斷後續對方發來的ACK報文中的Sequence Number的正確性，還是需要使用一些空間去儲存己方生成的Sequence Number等資訊，也造成了一些資源的浪費。

  • Syn Cookie技術： 完全不使用任何儲存資源，這種方法比較巧妙，它使用一種特殊的演算法生成Sequence Number，這種演算法考慮到了對方的IP、埠、己方IP、埠的固定資訊，以及對方無法知道而己方比較固定的一些資訊，如MSS、時間等，在收到對方的ACK報文後，重新計算一遍，看其是否與對方迴應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。
    ;
    從上圖（左圖）中可以看出，防火牆在確認了連線的有效性後，才向內部的伺服器（Listener）發起SYN請求，在右圖中，所有的無效連線均無法到達內部的伺服器。而防火牆採用的驗證連線有效性的方法則可以是Syn Cookie或Syn Flood等其他技術。採用這種方式進行防範需要注意的一點就是防火牆需要對整個有效連線的過程發生的資料包進行代理，如下圖所示：
    
    因為防火牆代替發出的SYN ACK包中使用的序列號為c，而伺服器真正的迴應包中序列號為c’，這其中有一個差值|c-c’|，在每個相關資料報文經過防火牆的時候進行序列號的修改。

  • TCP Safe Reset技術： 這也是防火牆Syn代理的一種方式，其工作過程如下圖所示：
    
    這種方法在驗證了連線之後立即發出一個Safe Reset命令包，從而使得Client重新進行連線，這時出現的Syn報文防火牆就直接放行。在這種方式中，防火牆就不需要對通過防火牆的資料報文進行序列號的修改了。這需要客戶端的TCP協議棧支援RFC 793中的相關約定，同時由於Client需要兩次握手過程，連線建立的時間將有所延長。