ACK Flood

基本介紹

ACK Flood攻擊。在TCP連線建立之後，所有的數據傳輸TCP報文都是帶有ACK標誌位的，主機在接收到一個帶有ACK標誌位的數據包的時候，需要檢查該數據包所表示的連線四元組是否存在，如果存在則檢查該數據包所表示的狀態是否合法，然後再向套用層傳遞該數據包。如果在檢查中發現該數據包不合法，例如該數據包所指向的目的連線埠在本機並未開放，則主機作業系統協定棧會回應RST包告訴對方此連線埠不存在。通常狀態檢測防火牆所做的事情與此類似，只不過防火牆只攔截非法的數據包，而不主動回應。

對比主機以及防火牆在接收到ACK報文和SYN報文時所做動作的複雜程度，顯然ACK報文帶來的負載要小得多。所以在實際環境中，只有當攻擊程式每秒鐘傳送ACK報文的速率達到一定的程度，才能使主機和防火牆的負載有大的變化。當發包速率很大的時候，主機作業系統將耗費大量的精力接收報文、判斷狀態，同時要主動回應RST報文，正常的數據包就可能無法得到及時的處理。這時候客戶端（以IE為例）的表現就是訪問頁面反應很慢，丟包率較高。但是狀態檢測的防火牆通過判斷ACK報文的狀態是否合法，藉助其強大的硬體能力可以較為有效的過濾攻擊報文。當然如果攻擊流量非常大（特別是千兆線路上，我們曾經觀察到200~300Mbps左右的ACK Flood），由於需要維護很大的連線狀態表同時要檢查數量巨大的ACK報文的狀態，防火牆也會不堪重負導致全網癱瘓。

現狀

目前ACK Flood並沒有成為攻擊的主流，而通常是與其他攻擊方式組合在一起使用。回顧前面描述的SYN Cookie算法，其核心思想是主動回應SYN/ACK包，然後校驗第3次握手的ACK報文是否合法，目前大多數實現中校驗ACK報文的合法性都涉及到較為複雜的算法。當SYN Flood與ACK Flood一起發生的時候， 主機和防火牆將耗費大量的精力來計算ACK報文是否合法以致不堪重負。

判定

從以上的描述可以看到ACK Flood具有"單包攻擊"的特點。但我們仍然可以從TCP/IP協定的特性以及數據傳輸特性中得到一定的統計規律。在現實世界中，正常數據傳輸的兩個方向（客戶端à伺服器，伺服器à客戶端）上的報文數量基本上是均衡的，同時數據報文的內容是較為隨機的。因此，當數據傳輸兩個方向上的報文數量發生傾斜的時候，基本上可以判定發生了攻擊。並且在大多數情況下，由於為了追求發包的速率，攻擊報文的內容是較為固定的。因此，防護設備可以通過學習攻擊報文的特徵，當某個特徵在一段時間的採樣內大量重複出現，那么基本上可以判定符合此特徵的數據報文為攻擊報文。當然，統計的方法不可避免會帶來誤判，因此將統計方法與連線狀態檢測結合起來是比較合理的做法。