DDoS防禦之TCP防禦

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

TCP協議，相信對於每個開發工程師都不陌生。因爲該協議是一個面向鏈接，可靠的特性，普遍應用於如今互聯網的應用中。如常見的Web、SSH、FTP等都是基於TCP協議。目前TCP協議佔全網的流量達到80%，所以這也成爲黑客主要攻擊的類別。

例如在2016年，形成美國大半個互聯網下線的Dyn事件，10月21日，提供動態DNS服務的Dyn DNS遭到了大規模DDoS攻擊，攻擊主要影響其位於美國東區的服務。這次攻擊致使許多使用DynDNS服務的網站遭遇訪問問題，其中包括 GitHub、Twitter、Airbnb、Reddit、Freshbooks、Heroku、SoundCloud,、Spotify 和 Shopify。攻擊致使這些網站一度癱瘓，Twitter甚至出現了近24小時0訪問的局面。過後據Dyn產品部門執行副總裁的深刻剖析本輪攻擊就是利用TCP協議的數據包進行攻擊。一開始就成功打破了Dyn的防禦，並對其內部系統形成了嚴重破壞。該公司並未披露本次攻擊的確切規模，外界估計它可能大大超過了針對OVH的那次DDoS攻擊。（峯值達到了1.1Tbps，這也是迄今所知最大的一次DDoS攻擊。）

那麼這些針對TCP的攻擊都是如何發起的呢？下面首先咱們先回顧一下TCP報文的交互過程。

下面是本機瀏覽器訪問http://www.163.com，使用wireshark抓包的結果：

這裏咱們忽略中間的數據傳輸過程，重點先關注一下頭尾處的鏈接創建我斷開鏈接的部分。

TCP鏈接的創建：主要的目的是爲了互相通知對方本身的初始化的sequence Number,這個序號用於IP數據包在網絡上亂序到達的時，便於TCP對IP數據包的重排序。

客戶端的第一個報文以下圖：

TCP中的syn標誌位置爲1，序號爲 612417286（記爲i）。

　服務端接收到報文後，對該報文進行確認，併發送本身的sequence number給客戶端，故爲SYN_ACK包,以下圖：

能夠看到tcp中syn,ack標誌位同時被置爲1，服務端確認客戶端的報文,Acknowledgement number（確認號）爲612417287（i+1），並帶上本身的sequence number 爲 522111292（記爲j）。

客戶端收到後會對發送確認報文，對服務端報文進行確認。如圖：

TCP的ack標誌位被置爲1，確認號爲522111293（j+1）。

這樣通過這3個報文，客戶端和服務端都獲取到了對方的初始sequence number，鏈接就創建了。

TCP鏈接斷開: TCP是一個全雙工的數量傳輸協議，因此TCP鏈接的斷開其實是2個方向上的傳輸關閉過程。接下來看看報文的交互過程，本例爲服務端發起的關閉：

首先服務端發送一個FIN報文。通知客戶端，服務端不在有數據發送給客戶端。

這裏咱們能夠忽略ack和Acknowledgement number，這個爲對前一次客戶端報文的確認。咱們能夠看到TCP中的FIN標誌位置爲1，sequence number 爲522230043（記爲k）。

客戶端收到fin報文後，回覆一個ack包確認。

這樣從服務端到客戶端這個方向上的數據傳輸通道就被關閉，即服務端應用不能夠在經過這條鏈接發送數據給客戶端。

接下來就是關閉客戶端到服務端的傳輸通道，客戶端首先發送fin包

服務端收到後發送確認報文給客戶端。

這樣一來從客戶端到服務端的傳輸通道也關閉了，那麼此時兩個方向上的傳輸通道都關閉了，TCP的通訊雙方就都斷開了鏈接。

簡略的交互示意圖以下：

從上述的鏈接創建和斷開方式咱們會發現TCP鏈接的創建和斷開涉及多個報文，多個狀態之間的轉換。那麼從攻擊者角度看上述過程，咱們該怎麼利用交互過程進行DDOS攻擊呢？

TCP攻擊能夠簡單的分爲如下三類：

1. FLOOD類攻擊，例如發送海量的syn,syn_ack,ack,fin等報文，佔用服務器資源，使之沒法提供服務。

2. 鏈接耗盡類攻擊，如與被攻擊方，完成三次握手後再也不發送報文一直維持鏈接，或者馬上發送FIN或RST報文，斷開鏈接後再次快速發起新的鏈接等，消耗TCP鏈接資源。

還有一類則比較巧妙，是在咱們上述沒有作分析的數據傳輸過程當中的利用TCP自己的流控，可靠性保證等機制來達到攻擊的目的，即：

3. 利用協議特性攻擊：例如攻擊這建好鏈接以後，基於TCP的流控特性，立馬就把TCP窗口值設爲0，而後斷開鏈接，則服務器就要等待Windows開放，形成資源不可用。或者發送異常報文，可能形成被攻擊目標奔潰。

那麼上述三種類型的攻擊具體的實時和防護原理是怎樣的呢？

FLOOD類攻擊與防護

Flood類攻擊中最多見，危害最大的是syn_flood攻擊，也是歷史最悠久的攻擊之一。所以咱們先來看看syn_flood攻擊。

syn_flood攻擊：SYN-Flood攻擊是當前網絡上最爲常見的DDoS攻擊，也是最爲經典的拒絕服務攻擊，它利用了TCP協議實現上的一個缺陷，經過向網絡服務所在端口發送大量的僞造源地址的攻擊報文，就可能形成目標服務器中的半開鏈接隊列被佔滿，從而阻止其餘合法用戶進行訪問。這種攻擊早在1996年就被發現，但至今仍然顯示出強大的生命力。不少操做系統，甚至防火牆、路由器都沒法有效地防護這種攻擊，並且因爲它能夠方便地僞造源地址，追查起來很是困難。

從上文咱們能夠知道客戶端發起鏈接的報文即爲syn報文。當攻擊者發送大量的僞造IP端口的syn報文時，服務端接收到syn報文後，新建一共表項插入到半鏈接隊列，併發送syn_ack。但因爲這些syn報文都是僞造的，發出去的syn_ack報文將沒有迴應。TCP是可靠協議，這時就會重傳報文，默認重試次數爲5次，重試的間隔時間從1s開始每次都番倍，分別爲1s + 2s + 4s + 8s +16s = 31s,第5次發出後還要等32s才知道第5次也超時了，因此一共是31 + 32 = 63s。

也就是說一共假的syn報文，會佔用TCP準備隊列63s之久，而半鏈接隊列默認爲1024，系統默認不一樣，可 cat /proc/sys/net/ipv4/tcp_max_syn_backlog c 查看。也就是說在沒有任何防禦的狀況下，每秒發送200個僞造syn包，就足夠撐爆半鏈接隊列，從而使真正的鏈接沒法創建，沒法響應正常請求。

而一臺普通的每秒就能夠輕鬆僞造100w個syn包。所以即便把隊列大小調大最大也無濟於事。那麼應該如何區防禦呢？

Syn_flood防護：一般針對syn_flood 有2種比較通用的防禦機制

1. cookie源認證：

原理是syn報文首先由DDOS防禦系統來響應syn_ack。帶上特定的sequence number （記爲cookie）。真實的客戶端會返回一個ack 而且Acknowledgment number 爲cookie+1。 而僞造的客戶端，將不會做出響應。這樣咱們就能夠知道那些IP對應的客戶端是真實的，將真實客戶端IP加入白名單。下次訪問直接經過，而其餘僞造的syn報文就被攔截。下面爲防禦示意圖：

2.reset認證：

Reset認證利用的是TCP協議的可靠性，也是首先由DDOS防禦系統來響應syn。防禦設備收到syn後響應syn_ack,將Acknowledgement number (確認號)設爲特定值（記爲cookie）。當真實客戶端收到這個報文時，發現確認號不正確，將發送reset報文，而且sequence number 爲cookie + 1。

而僞造的源，將不會有任何迴應。這樣咱們就能夠將真實的客戶端IP加入白名單。

一般在實際應用中還會結合首包丟棄的方式結合源認證一塊兒使用，首包丟棄原理爲：在DDOS防禦設備收到syn報文後，記錄5元組，而後丟棄。正經常使用戶將重傳syn報文，防禦設備在收到報文命中5元組，而且在規定時間內，則轉發。當重傳syn報文到達必定閥值時，在啓用上述的源認證。這樣就能減小反射syn_ack報文的數量，緩解網絡擁堵，同時對防禦不產生影響。

以上是TCP的syn_flood的攻擊和防護原理，後續將分析TCP其餘類型的攻擊和防禦，敬請期待。

延伸閱讀：

理解DDoS防禦本質：基於資源較量和規則過濾的智能化系統

DDoS高防服務-DDOS攻擊防護-DDos壓力測試_網易雲

DDoS高防_DDoS攻擊防護_DDoS壓力測試_網易雲

相關文章：
【推薦】 快速登陸機器&數據庫
【推薦】 測試環境docker化（一）—基於ndp部署模式的docker基礎鏡像製做