syn flood攻擊是一種典型的拒絕服務型（Denial of Service）攻擊。所謂拒絕服務型攻擊就是通過進行攻擊，使受害主機或網路不能夠良好的提供服務，從而間接達到攻擊的目的。

syn flood攻擊利用的是IPv4中TCP協議的三次握手（Three-Way Handshake）過程進行的攻擊。大家知道協議規定，如果一端想向另一端發起TCP連線，它需要首先發送TCP SYN 包到對方，對方收到後傳送一個TCP SYN+ACK包回來，發起方再發送TCP ACK包回去，這樣三次握手就結束了。我們把TCP連線的發起方叫作"TCP客戶機（TCP Client）"，TCP連線的接收方叫作"TCP伺服器（TCP Server）"。值得注意的是在TCP伺服器收到TCP SYN request包時，在傳送TCP SYN+ACK包回TCP客戶機前，TCP伺服器要先分配好一個數據區專門服務於這個即將形成的TCP連線。一般把收到SYN包而還未收到ACK包時的連線狀態成為半開連線（Half-open Connection）。

TCP三次握手流程圖：

在最常見的SYN Flood攻擊中，攻擊者在短時間內傳送大量的TCP SYN包給受害者，這時攻擊者是TCP客戶機，受害者是TCP伺服器。根據上面的描述，受害者會為每個TCP SYN包分配一個特定的資料區，只要這些SYN包具有不同的源地址（這一點對於攻擊者來說是很容易偽造的）。這將給TCP伺服器系統造成很大的系統負擔，最終導致系統不能正常工作。
Syn Flood 基本都是以 DDOS 模式展開攻擊。

目前處理Syn Flood的問題由幾個方式：

1、SYN cookies技術

我們知道，TCP協議開闢了一個比較大的記憶體空間backlog佇列來儲存半連線條目，當SYN請求不斷增加，並這個空間，致使系統丟棄SYN連線。為使半連線佇列被塞滿的情況下，伺服器仍能處理新到的SYN請求，SYN cookies技術被設計出來。

SYN cookies應用於linux、FreeBSD等作業系統，當半連線佇列滿時，SYN cookies並不丟棄SYN請求，而是通過加密技術來標識半連線狀態。

在TCP實現中，當收到客戶端的SYN請求時，伺服器需要回復SYN＋ACK包給客戶端，客戶端也要傳送確認包給伺服器。通常，伺服器的初始序列號由伺服器按照一定的規律計算得到或採用隨機數，但在SYN cookies中，伺服器的初始序列號是通過對客戶端IP地址+客戶端端囗+伺服器IP地址+伺服器端囗以及其他一些安全數值等要素進行hash運算，加密得到的，稱之為cookie。當伺服器遭受SYN攻擊使得backlog佇列滿時，伺服器並不拒絕新的SYN請求，而是回覆cookie（回覆包的SYN序列號）給客戶端

在RedHat linux中，啟用SYN cookies是通過在啟動環境中設定以下命令來完成：
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

2、增加最大半連線數

大量的SYN請求導致未連線佇列被塞滿，使正常的TCP連線無法順利完成三次握手，通過增大未連線佇列空間可以緩解這種壓力。當然backlog佇列需要佔用大量的記憶體資源，不能被無限的擴大。
 

Syn Cookie：

SYN Cookie是對TCP伺服器端的三次握手協議作一些修改，專門用來防範SYN Flood攻擊的一種手段。它的原理是，在TCP伺服器收到TCP SYN包並返回TCP SYN+ACK包時，不分配一個專門的資料區，而是根據這個SYN包計算出一個cookie值。在收到TCP ACK包時，TCP伺服器在根據那個cookie值檢查這個TCP ACK包的合法性。如果合法，再分配專門的資料區進行處理未來的TCP連線。
 

Syn Cookie Firewall ( TCP 六次握手 )：

SYN Cookie機制主要的功能是防止本機遭受SYN Flood攻擊的，但是在很多情況下，僅僅實現這樣的SYN Cookie機制是不夠的。如果我們要考慮的是一個閘道器模式的防火牆，它不僅要保護本機免受各種網路攻擊，還要保護它後面的所有對外有開放TCP埠的主機免受這些攻擊。比如一個區域網中有個伺服器開放了FTP服務給外界，這個伺服器主機就有可能遭受到來自網際網路上的SYN Flood攻擊。而這時的防火牆會將所有的攻擊SYN包轉發給受害主機。

一種杜絕這種情況的方法是SYN Cookie Firewall。它是SYN Cookie的一種擴充套件形式。總的來說，它是利用原來SYN Cookie的原理在內網和外網之間實現TCP三次握手過程的代理（proxy）的機制。

為了方便描述，我們假定一個外在的TCP客戶機C希望通過防火牆F連線到區域網中的一個TCP伺服器S。

在防火牆收到來自外網的SYN包時，它並不直接進行轉發，而是快取在本地，再按照原來SYN Cookie的機制製作好一個針對這個SYN包的SYN+ACK包，注意，這個SYN+ACK包中的ack順序號為特製的cookie值c，更重要的是這個包的的源地址被偽造成了S的地址（為了描述方便，我們這裡暫時不考慮NAT等其他因素）。這樣C會接收到這個SYN+ACK包，並認為是從S反饋回來的。於是C再響應一個ACK包，並認為與S的TCP連線已經建立起來。這時防火牆F收到這個ACK包，按照前面的描述的SYN Cookie原理來檢查這個ACK中的ack順序號。如果認為合法，F將本地快取的來自C的SYN包傳送給S，這時S會響應一個SYN+ACK包到C，其中也攜帶一個seq號， 我們設為c`。當然這個包不會到達C，而是由防火牆F擷取，F根據這個包中的序列號等資訊，造一個ACK包響應到S。這時的情況是：C認為自己已經與S建立了TCP連線；S認為自己與C建立了TCP連線。以後的TCP資料內容可以直接穿過防火牆F，在S和C之間互動。

（圖片來源：http://blog.chinaunix.net/uid-24148050-id-315346.html）

上圖是SYN Cookie Firewall的工作原理，它相當於在TCP Server與TCP Client之間實現了對三次握手協議的代理。第一次"三次握手"在TCP Client與防火牆之間進行，第二次"三次握手"在防火牆與TCP Server之間。在第一次"三次握手"時使用前面介紹的SYN Cookie流程。

有一個問題在進行兩次"三次握手"時出現了：如圖所示，進行第一次"三次握手"後，TCP Client認為後續資料包的seq值從c+1開始，而進行第二次"三次握手"後，TCP Server認為後續發來的資料包的seq值從c`+1開始， c是cookie，c`是TCP Server隨機產生的。c和c`幾乎不可能相等，也就是說在完成上面的兩個"三次握手"後，如果不進行其他操作，後續從TCP Client到TCP Server的資料包都將被認為順序號不對而被丟掉。一種補救方法就是在防火牆本地儲存一個值δ ，δ ＝ |c - c`| ，利用這個差值，在每個資料包經過防火牆時，將其seq值修改一下，這樣，後續的資料流量可以完美地在TCP Server和TCP Client之間傳輸了。

對於Syn Cookie的本地防護，在Linux系統的本地已經可以通過Linux內建的Syn Cookie機制來完成。

Syn Cookie Firewall技術又被廣泛的稱為 TCP六次握手、TCP Syn Proxy。在上面的那張圖我們看到Firewall首先跟ClientSide進行三次握手，然後再跟ServerSide進行三次握手，因此被形象地稱之為 TCP六次握手。同時我們看到這就是像是一個 Proxy，接受ClientSide的請求，然後轉遞給ServerSide，因此在OpenBSD平臺我們看到已經成功實現的此種技術被稱為 TCP SYN PROXY ( http://www.openbsd.org/faq/pf/filter.html )

但是對於Linux平臺，好像還沒有實現Syn Cookies Firewall，不過在Linux 2.2平臺出現過一個ip_scfw的東西。