DDoS攻擊--Syn_Ack/Ack_Flood等攻擊防護詳解(TCP)
前言
Syn_Ack/Ack_Flood攻擊屬於TCP攻擊，在瞭解Syn_Ack/Ack_Flood攻擊之前，可以先看看TCP攻擊詳解。
Syn_Ack Flood 攻擊:
syn_ack報文出現在連線建立的第2個報文，用來確認第一次握手的syn包。
當伺服器收到syn_ack報文後會在系統裡查詢是否屬於3次握手的範疇。如果屬於則回覆ack，並將連線設為連線狀態。若沒有查到相關資訊，則回覆reset。（這裡window協議實現與Linux有所不同，這裡僅討論Linux）。當攻擊者傳送大量的syn_ack進行攻擊時，伺服器將會為處理這些報文而消耗大量的資源。 也許你發現這裡可能還有另一種潛在的危害，就是當伺服器主動外聯時，傳送完syn,等待synack包時，收到了攻擊者傳送的synack報文而導致，連線建立失敗。其實嚴格意義上說這種情況是存在的。可這種情形傳送在攻擊的報文五元組匹配並且seq-ack也正確匹配的情況。概率極低，忽略不計。
Syn_Ack Flood 防禦:
- 如果伺服器沒有主動發起連線的需求，直接將所以syn_ack包丟棄即可。
- 如果有對外連線的需求，則可利用源認證的方式防禦，具體防護原理為： 向syn_ack的源IP，埠傳送syn報文，能在固定時間內返回，並且序列號匹配則說明該IP，埠確實提高了服務，加入白名單。多次未防護的加入黑名單。
Ack Flood 攻擊:
ACK Flood攻擊是在TCP連線建立之後，所有的資料傳輸TCP報文都是帶有ACK標誌位的，主機在接收到一個帶有ACK標誌位的資料包的時候，需要檢查該資料包所表示的連線四元組是否存在，如果存在則檢查該資料包所表示的狀態是否合法，然後再向應用層傳遞該資料包。如果在檢查中發現該資料包不合法，例如該資料包所指向的目的埠在本機並未開放，則主機作業系統協議棧會迴應RST包告訴對方此埠不存在。
這裡，伺服器要做兩個動作：查表、迴應ACK/RST。這種攻擊方式顯然沒有SYN Flood給伺服器帶來的衝擊大，因此攻擊者一定要用大流量ACK小包衝擊才會對伺服器造成影響。按照我們對TCP協議的理解，隨機源IP的ACK小包應該會被Server很快丟棄，因為在伺服器的TCP堆疊中沒有這些ACK包的狀態資訊。
如果沒有開放埠，伺服器將直接丟棄，這將會耗費伺服器的CPU資源。如果埠開放，伺服器迴應RST。
可以肯定的是，ACK Flood不但可以危害路由器等網路裝置，而且對伺服器上的應用有不小的影響。
Ack Flood 防禦:
利用對稱性判斷來分析出是否有攻擊存在。所謂對稱型判斷，就是收包異常大於發包，因為攻擊者通常會採用大量ACK包，並且為了提高攻擊速度，一般採用內容基本一致的小包傳送，這可以作為判斷是否發生ACK Flood的依據。
但是目前已知情況來看，很少有單純使用ACK Flood攻擊，都會和其他攻擊方法混合使用，因此，很容易產生誤判。
一些防火牆應對的方法是：建立一個hash表，用來存放TCP連線“狀態”，相對於主機的TCP stack實現來說，狀態檢查的過程相對簡化。例如，不作sequence number的檢查，不作包亂序的處理，只是統計一定時間內是否有ACK包在該“連線”(即四元組)上通過，從而“大致”確定該“連線”是否是“活動的”。
其他 Flood 攻擊與防禦
主要的攻擊原理都為利用大量的無效資料包，消耗伺服器資源。由於攻擊報文命中五元組和序列號的概率極低，所以對正常連線破壞有限（伺服器資源充足的情況下）。
針對這些型別的攻擊的處理方式也正是利用上面的特點。在連線建立的時候，利用syn_reset ，syn_cookie認證，認證通過之後，為每個tcp連線建立一個會話，儲存五元組和序列號資訊，只有匹配的包才轉發到伺服器，不匹配的丟棄。 關於上述認證的詳解。
End