一、為什麼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攻擊
我們先來看一下syn flood有哪些種類，如下圖所示：
1．direct attack攻擊方使用固定的源位址發起攻擊，這種方法對攻擊方的消耗最小
2．spoofing attack攻擊方使用變化的源位址發起攻擊，這種方法需要攻擊方不停地修改源位址，實際上消耗也不大
3．distributed direct attack這種攻擊主要是使用殭屍網路進行固定源位址的攻擊
對於第一種攻擊的防範可以使用比較簡單的方法，即對syn包進行監視，如果發現某個ip發起了較多的攻擊報文，直接將這個ip列入黑名單即可。當然下述的方法也可以對其進行防範。
對於源位址不停變化的攻擊使用上述方法則不行，首先從某乙個被偽裝的ip過來的syn報文可能不會太多，達不到被拒絕的閾值，其次從這個被偽裝的ip（真實的）的請求會被拒絕掉。因此必須使用其他的方法進行處理。
1． 無效連線監視釋放
這種方法不停監視系統的半開連線和不活動連線，當達到一定閾值時拆除這些連線，從而釋放系統資源。這種方法對於所有的連線一視同仁，而且由於syn flood造成的半開連線數量很大，正常連線請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬於入門級的syn flood方法。
2． 延緩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資源。
3． 使用syn proxy防火牆
syn cache技術和syn cookie技術總的來說是一種主機保護技術，需要系統的tcp/ip協議棧的支援，而目前並非所有的作業系統支援這些技術。因此很多防火牆中都提供一種syn**的功能，其主要原理是對試圖穿越的syn請求進行驗證後才放行，下圖描述了這種過程：
從上圖（左圖）中可以看出，防火牆在確認了連線的有效性後，才向內部的伺服器（listener）發起syn請求，在右圖中，所有的無效連線均無法到達內部的伺服器。而防火牆採用的驗證連線有效性的方法則可以是syn cookie或syn flood等其他技術。
採用這種方式進行防範需要注意的一點就是防火牆需要對整個有效連線的過程發生的資料報進行**，如下圖所示：
因為防火牆代替發出的syn ack包中使用的序列號為c，而伺服器真正的回應包中序列號為c』，這其中有乙個差值|c-c』|，在每個相關資料報文經過防火牆的時候進行序列號的修改。
tcp safe reset技術：
這也是防火牆syn**的一種方式，其工作過程如下圖所示：
這種方法在驗證了連線之後立即發出乙個safe reset命令包，從而使得client重新進行連線，這時出現的syn報文防火牆就直接放行。在這種方式中，防火牆就不需要對通過防火牆的資料報文進行序列號的修改了。這需要客戶端的tcp協議棧支援rfc 793中的相關約定，同時由於client需要兩次握手過程，連線建立的時間將有所延長。
( 參考文獻
1. traffic anomaly detector and guard (riverhead networks) faq
2. syn cookie原理及其在linux核心中的實現
3. defenses against tcp syn flooding attacks
SYN Flood 攻擊及防禦方法
一 為什麼syn flood會造成危害 這要從作業系統的tcp ip協議棧的實現說起。當開放了乙個tcp埠後，該埠就處於listening狀態，不停地監視發到該埠的syn報文，一旦接收到client發來的syn報文，就需要為該請求分配乙個tcb transmission control block ...
SYN Flood攻擊及防禦方法
syn flood攻擊及防禦方法 一 為什麼syn flood會造成危害 這要從計算機網路的tcp ip協議棧的實現說起。當開放了乙個tcp埠後，該埠就處於listening狀態，不停地監視發到該埠的syn報文，一旦接收到client發來的syn報文，就需要為該請求分配乙個tcb transmiss...
SYN Flood攻擊的基本原理及防禦
1.tcp中的syn flooding攻擊原理 要明白這種攻擊的基本原理，還是要從 tcp連線建立的過程開始說起。由於 tcp基於連線的，為了在服務端和客戶端之間傳送tcp資料，必須先建立乙個虛擬電路，也就是tcp連線，建立tcp連線的過程也就是我們熟悉的 三次握手 過程 首先，請求端 客戶端 傳送...