SYN泛洪攻擊

TCP SYN泛洪發生在OSI第四層，這種方式利用TCP協議的特性，就是三次握手。攻擊者發送TCP SYN，SYN是TCP三次握手中的第一個數據包，而當服務器返回ACK後，該攻擊者就不對其進行再確認，那這個TCP連接就處於掛起狀態，也就是所謂的半連接狀態，服務器收不到再確認的話，還會重複發送ACK給攻擊者。這樣更加會浪費服務器的資源。攻擊者就對服務器發送非常大量的這種TCP連接，由於每一個都沒法完成三次握手，所以在服務器上，這些TCP連接會因為掛起狀態而消耗CPU和內存，最後服務器可能死機，就無法為正常用户提供服務了。

大家都知道一個TCP連接的啓動需要經歷三次握手的過程。正常情況下客户端首先向服務端發送SYN報文，隨後服務端回以SYN+ACK報文到達客户端，最後客户端向服務端發送ACK報文完成三次握手，後續就是上層業務數據交互，直到某一方斷開連接。

那麼假如在這“握手”的過程中，客户端程序因為莫名崩潰等原因，收到SYN+ACK報文後不再回以ACK，服務端將如何處置呢？這時服務端會“優雅地”再等等，會不會是發送的包丟失了呢？於是重新發送一遍SYN+ACK，再收不到來自客户端的ACK響應的話，就把這次連接丟棄掉。這個過程大約會“優雅地”持續分鐘級，這個持續時間被稱作SYN timeout時間。如果只有個別這樣的異常情況，目標服務端處理起來自是毫不費力；可如果大量這樣的情況出現，對服務端來説就不堪重負了。這是為什麼呢？

如果大量的握手請求湧向TCP服務端，而它們只發出SYN報文而不以ACK響應結束握手，服務端就要為這每一個請求都維持約一分多鐘的連接去等待ACK，也就形成所謂的“半連接”。維護這些半連接是需要消耗很多服務器的網絡連接資源的。如果短時間內這些資源幾乎都被半連接佔滿，那麼正常的業務請求在這期間就得不到服務，處於等待狀態。

更進一步的，如果這些半連接的握手請求是惡意程序發出，並且持續不斷，那麼就會導致服務端較長時間內喪失服務功能——這就形成了DoS（Denial of Service拒絕服務）攻擊。這種攻擊方式就稱為SYN泛洪（SYN flood）攻擊。

由於正常的TCP三次握手中發出去多少SYN報文，就會收到多少SYN+ACK報文。攻擊方需要將這些消息丟棄，同時為了隱藏自己，於是需要大量偽造泛洪攻擊的源地址，隨機改成其它地址。為達到SYN泛洪攻擊的效果，這些偽造的源地址最好無法響應SYN+ACK，如這些源地址的主機根本不存在，或者被防火牆等網絡設施攔截，等等。

對於SYN泛洪攻擊的防範，優化主機系統設置是常用的手段。如降低SYN timeout時間，使得主機儘快釋放半連接的佔用；又比如採用SYN cookie設置，如果短時間內連續收到某個IP的重複SYN請求，則認為受到了該IP的攻擊，丟棄來自該IP的後續請求報文。此外合理地採用防火牆等外部網絡安全設施也可緩解SYN泛洪攻擊。