DOS

SYN Flood***方式的分析

SYN-Flood***是當前網絡上最爲常見的DDoS***，也是最爲經典的拒絕服務***，它利用了TCP協議實現上的一個缺陷，通過向網絡服務所在端口發送大量的僞造源地址的***報文，就可能造成目標服務器中的半開連接隊列被佔滿，從而阻止其他合法用戶進行訪問。這種***早在1996年就被發現，但至今仍然顯示出強大的生命力。很多操作系統，甚至防火牆、路由器都無法有效地防禦這種***，而且由於它可以方便地僞造源地址，追查起來非常困難。它的數據包特徵通常是，源發送了大量的SYN包，並且缺少三次握手的最後一步握手ACK回覆。

SYN-Flood***原理
例如，***者首先僞造地址對服務器發起SYN請求（我可以建立連接嗎？），服務器就會迴應一個ACK+SYN（可以+請確認）。而真實的IP會認爲，我沒有發送請求，不作迴應。服務器沒有收到迴應，會重試3-5次並且等待一個SYN Time（一般30秒-2分鐘）後，丟棄這個連接。
如果***者大量發送這種僞造源地址的SYN請求，服務器端將會消耗非常多的資源來處理這種半連接，保存遍歷會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。最後的結果是服務器無暇理睬正常的連接請求—拒絕服務。

SYN Flood防護策略
目前市面上有些防火牆具有SYN Proxy功能，這種方法一般是定每秒通過指定對象（目標地址和端口、僅目標地址或僅源地址）的SYN片段數的閥值，當來自相同源地址或發往相同目標地址的SYN片段數達到這些閥值之一時，防火牆就開始截取連接請求和代理回覆SYN/ACK片段，並將不完全的連接請求存儲到連接隊列中直到連接完成或請求超時。當防火牆中代理連接的隊列被填滿時，防火牆拒絕來自相同安全區域（zone）中所有地址的新SYN片段，避免網絡主機遭受不完整的三次握手的***。但是，這種方法在***流量較大的時候，連接出現較大的延遲，網絡的負載較高，很多情況下反而成爲整個網絡的瓶頸；
Random Drop：隨機丟包的方式雖然可以減輕服務器的負載，但是正常連接的成功率也會降低很多；
特徵匹配：IPS上會常用的手段，在***發生的當時統計***報文的特徵，定義特徵庫，例如過濾不帶TCP Options 的syn 包等；
早期***工具（例如synkiller，xdos，hgod等）通常是發送64字節的TCP SYN報文，而主機操作系統在發起TCP連接請求時發送SYN 報文是大於64字節的。因此可以在關鍵節點上設置策略過濾64字節的TCP SYN報文，某些宣傳具有防護SYN Flood***的產品就是這麼做的。隨着工具的改進，發出的TCP SYN 報文完全模擬常見的通用操作系統，並且IP頭和TCP頭的字段完全隨機，這時就無法在設備上根據特定的規則來過濾***報文。這時就需要根據經驗判斷IP 包頭裏TTL值不合理的數據包並阻斷，但這種手工的方法成本高、效率低。

SYN Cookie：就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內連續受到某個IP的重複SYN報文，就認定是受到了***，以後從這個IP地址來的包會被丟棄。但SYN Cookie依賴於對方使用真實的IP地址，如果***者利用SOCK_RAW隨機改寫IP報文中的源地址，這個方法就沒效果了。

商業產品的防護算法
syn cookie/syn proxy類防護算法：這種算法對所有的syn包均主動迴應，探測發起syn包的源IP地址是否真實存在；如果該IP地址真實存在，則該IP會迴應防護設備的探測包，從而建立TCP連接；大多數的國內外抗拒絕服務產品採用此類算法。
safereset算法：此算法對所有的syn包均主動迴應，探測包特意構造錯誤的字段，真實存在的IP地址會發送rst包給防護設備，然後發起第2次連接，從而建立TCP連接；部分國外產品採用了這樣的防護算法。
syn重傳算法：該算法利用了TCP/IP協議的重傳特性，來自某個源IP的第一個syn包到達時被直接丟棄並記錄狀態，在該源IP的第2個syn包到達時進行驗證，然後放行。
綜合防護算法：結合了以上算法的優點，並引入了IP信譽機制。當來自某個源IP的第一個syn包到達時，如果該IP的信譽值較高，則採用syncookie算法；而對於信譽值較低的源IP，則基於協議棧行爲模式，如果syn包得到驗證，則對該連接進入syncookie校驗，一旦該IP的連接得到驗證則提高其信譽值。有些設備還採用了表結構來存放協議棧行爲模式特徵值，大大減少了存儲量。