SYN Flood 是當(dāng)前最流行的 DoS(拒絕服務(wù)攻擊)與 DDoS(分布式拒絕服務(wù)攻擊)的方式之一，這是一種利用 TCP 協(xié)議缺陷，發(fā)送大量偽造的 TCP 連接請求，從而使得被攻擊方資源耗盡(CPU 滿負(fù)荷或內(nèi)存不足)的攻擊方式。要明白SYN Flood 的基本原理，還是要從 TCP 連接建立的過程開始說起：

　　大家都知道，TCP 與 UDP 不同，它是基于連接的，也就是說：為了在服務(wù)端和客戶端之間傳送 TCP 數(shù)據(jù)，必須先建立一個虛擬電路，也就是 TCP 連接，建立 TCP 連接的標(biāo)準(zhǔn)過程是這樣的：

　　首先，請求端(客戶端)發(fā)送一個包含 SYN 標(biāo)志的 TCP 報文，SYN 即同步(Synchronize)，同步報文會指明客戶端使用的端口以及 TCP 連接的初始序號;

　　第二步，服務(wù)器在收到客戶端的 SYN 報文后，將返回一個 SYN+ACK 的報文，表示客戶端的請求被接受，同時 TCP 序號被加一，ACK 即確認(rèn)(Acknowledgement)。

　　第三步，客戶端也返回一個確認(rèn)報文 ACK 給服務(wù)器端，同樣 TCP 序列號被加一，到此一個 TCP 連接完成。

　　以上的連接過程在 TCP 協(xié)議中被稱為三次握手(Three-way Handshake)。問題就出在 TCP 連接的三次握手中，假設(shè)一個用戶向服務(wù)器發(fā)送了 SYN 報文后突然死機或掉線，那么服務(wù)器在發(fā)出 SYN+ACK 應(yīng)答報文后是無法收到客戶端的 ACK 報文的(第三次握手無法完成)，這種情況下服務(wù)器端一般會重試(再次發(fā)送 SYN+ACK 給客戶端)并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為 SYN Timeout，一般來說這個時間是分鐘的數(shù)量級(大約為 30 秒-2 分鐘);一個用戶出現(xiàn)異常導(dǎo)致服務(wù)器的一個線程等待 1 分鐘并不是什么很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務(wù)器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數(shù)以萬計的半連接，即使是簡單的保存并遍歷也會消耗非常多的 CPU 時間和內(nèi)存，何況還要不斷對這個列表中的 IP 進行 SYN+ACK 的重試。

　　實際上如果服務(wù)器的 TCP/IP 棧不夠強大，最后的結(jié)果往往是堆棧溢出崩潰---即使服務(wù)器端的系統(tǒng)足夠強大，服務(wù)器端也將忙于處理攻擊者偽造的 TCP 連接請求而無暇理睬客戶的正常請求(畢竟客戶端的正常請求比率非常之小)，此時從正常客戶的角度看來，服務(wù)器失去響應(yīng)，這種情況我們稱作：服務(wù)器端受到了 SYN Flood 攻擊(SYN 洪水攻擊)。從防御角度來說，有幾種簡單的解決方法：

　　第一種是縮短 SYNTimeout 時間

　　由于 SYNFlood 攻擊的效果取決于服務(wù)器上保持的 SYN 半連接數(shù)，這個值=SYN攻擊的頻度 x SYN Timeout，所以通過縮短從接收到 SYN 報文到確定這個報文無效并丟棄改連接的時間，例如設(shè)置為 20 秒以下(過低的 SYN Timeout 設(shè)置可能會影響客戶的正常訪問)，可以成倍的降低服務(wù)器的負(fù)荷。

　　第二種方法是設(shè)置 SYN Cookie

　　就是給每一個請求連接的 IP 地址分配一個Cookie，如果短時間內(nèi)連續(xù)受到某個 IP 的重復(fù) SYN 報文，就認(rèn)定是受到了攻擊，以后從這個 IP 地址來的包會被一概丟棄。

　　可是上述的兩種方法只能對付比較原始的 SYNFlood 攻擊，縮短 SYNTimeout時間僅在對方攻擊頻度不高的情況下生效，SYN Cookie 更依賴于對方使用真實的 IP 地址，如果攻擊者以數(shù)萬/秒的速度發(fā)送 SYN 報文，同時利用 SOCK_RAW隨機改寫 IP 報文中的源地址，以上的方法將毫無用武之地。

　　以上是對SYN Flood 的基本原理的簡單介紹，更多關(guān)于網(wǎng)絡(luò)安全培訓(xùn)的問題，歡迎咨詢千鋒教育在線名師，如果想要了解我們的師資、課程、項目實操的話可以點擊咨詢課程顧問，獲取試聽資格來試聽我們的課程，在線零距離接觸千鋒教育大咖名師，讓你輕松從入門到精通。