possible SYN flooding on port 7244. Sending cookie

kernel: possible SYN flooding on port 80. Sending cookies.

以上是系統日誌中的信息，多是遭到SYN洪水攻擊（SYN Flood）。

那什麼是SYN Flood呢?

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）。

在 最多見的SYN Flood攻擊中，攻擊者在短期內發送大量的TCP SYN包給受害者，這時攻擊者是TCP客戶機，受害者是TCP服務器。根據上面的描述，受害者會爲每一個TCP SYN包分配一個特定的數據區，只要這些SYN包具備不一樣的源地址（這一點對於攻擊者來講是很容易僞造的）。這將給TCP服務器系統形成很大的系統負擔， 最終致使系統不能正常工做。  

那又爲何發送cookie呢？這個cookie是什麼呢？

這 個cookie是指SYN Cookie。在目前以IPv4爲支撐的網絡協議上搭建的網絡環境中，SYN Flood是一種很是危險而常見的DoS攻擊方式。到目前爲止，可以有效防範SYN Flood攻擊的手段並很少，而SYN Cookie就是其中最著名的一種。SYN Cookie原理由D. J. Bernstain和 Eric Schenk發明。在不少操做系統上都有各類各樣的實現。其中包括Linux。  

SYN Cookie原理 

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

從上面的介紹能夠看出，SYN Cookie的原理比較簡單。到實際的應用中，它有多種不一樣的實現方式。  

打 開或關閉SYN Cookie功能，能夠設置/proc/sys/net/ipv4/tcp_syncookies的值（或在/etc/sysctl.conf中 net.ipv4.tcp_syncookies的值），值爲0關閉SYN Cookie功能，值爲1打開SYN Cookie功能。

若是系統資源還沒問題的話，應該多數不是受到SYN Flood攻擊，而是併發鏈接過多。若是日誌裏有不少這樣的警告信息，而且是由於服務器負載太高而產生的，應該調整如下幾個參數，直到這個警告消失：

 tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow，這三個文件都是基於/proc/sys/net/ipv4目錄下 

tcp_max_syn_backlog變量告訴你在內存中能夠緩存多少個SYN請求。該變量須要打開tcp_syncookies纔有效。若是服務器負載很高，能夠嘗試提升該變量的值。

 tcp_synack_retries變 量用於TCP三次握手機制中第二次握手，當收到客戶端發來的SYN鏈接請求後，服務端將回復SYN+ACK包，這時服務端處於SYN_RCVD狀態，並等 待客戶端發來的回覆ACK包。若是服務端沒有收到客戶端的ACK包，會從新發送SYN+ACK包，直到收到客戶端的ACK包。該變量設置發送 SYN+ACK包的次數，超過這個次數，服務端將放棄鏈接。默認值是5。

 tcp_abort_on_overflow變 量的值是個布爾值，默認值爲0（FALSE關閉）。若是開啓，當服務端接收新鏈接的速度變慢時，服務端會發送RST包（reset包）給客戶端，令客戶端 從新鏈接。這意味着若是忽然發生溢出，將重獲鏈接。僅當你真的肯定不能經過調整監聽進程使接收鏈接的速度變快，能夠啓用該選項。該選項會影響到客戶的連 接。

 

通常狀況下，只增長tcp_max_syn_backlog的值就能夠解決問題。例如執行命令：

# echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog

修改方法:/    proc/sys/net/ipv4/tcp_max_syn_backlog對於那些依然還未得到客戶端確認的鏈接請求，須要保存在隊列中最大數目。對於超過 128Mb 內存的系統，默認值是 1024，低於 128Mb 的則爲 128。若是服務器常常出現過載，能夠嘗試增長這個數字。警告！假如您將此值設爲大於1024，最好修改 include/net/tcp.h 裏面的 TCP_SYNQ_HSIZE，以保持TCP_SYNQ_HSIZE*16 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(若是tcp_adv_win_scale 128Mb 32768-610000)則系統將忽略全部發送給本身的ICMP ECHO請求或那些廣播地址的請求。