從FTP建立連接配接模式想到的TCP SYNFlood防禦

今天正在看有關幾種常見攻擊及其防禦手段的文章，講到TCP SynFlood的攻擊模式時，忽然突發奇想，為何不使用FTP所應用的反向連接配接技術，來取代原有的TCP三向交握呢？這樣子做會不會有更高的防禦效率呢？

對于TCP三次連接配接的過程，我想閣下應了如指掌，但為了做出比較，我也簡單回顧一下。

1、由發起TCP連接配接的A段發送TCP SYN封包到B端。封包内容為Seq Num等，SYN置位。

2、B端接收到該封包後，發送一個TCP SYN/ACK封包到A端，其中Seq Num=Seq Num+1，SYN、ACK置位。

3、A端收到該封包後，發送TCP ACK封包到B端，ACK置位。

這樣，整個TCP連接配接算是建立完畢。

TCP SynFlood攻擊原理，便是利用B端等待A端ACK封包時所需要比監聽狀态占用更多CPU中斷、記憶體等資源的結果進行DoS攻擊。這樣一來，由于建立連接配接的主動權在“需要TCP服務”的A端，提供TCP服務的B端必須進行處理等待。無論是減少TCP半開連接配接時間，或者增大TCP處理緩存，都屬于治标不治本的方式。一方面，由于無法判斷那類連接配接屬于有效連接配接，盲目的減少等待時間等于間接造成了DoS；而增加緩存對于大規模DDoS來說，幾乎沒有任何意義。

<a href="http://golehuang.blog.51cto.com/attachment/201104/6/7499_13021082479Hlw.jpg"></a>

回到FTP的話題。之是以提及FTP，主要是因為FTP的連接配接建立機制很獨特。Client一端在建立連接配接初期，僅僅向Server表明了建立連接配接的要求，包括所用到的等待連接配接端口号。真正建立連接配接，是有Server端開始建立的。具體流程如下（port）：

1、Client向Server TCP 21發送連接配接申請，其中包含有本地開放連接配接用的TCP Port；

2、Server向Client指定TCP Port發起連接配接，連接配接成功後，再進行認證等操作。

這樣一來，在Server端無須保留任何資源，因為Client在申請連接配接階段已經準備好了連接配接所需資源（端口的保留與監聽）。倘若攻擊者作為Client，根本沒有打開上述端口，對于Server而言，也僅僅是浪費了生成一個“連接配接發起”所需要的資源。

對于TCP而言，生成一個SYN的資源往往比生成一個ACK的資源少。是以，為確定所有需要TCP服務的Client端已經保證了向Server端提供相應資源，TCP連接配接可以做一下修改（為作對比，稱發起TCP連接配接的一端為tcpClient，接受TCP連接配接的一端為tcpServer）：

1、tcpClient向tcpServer發送tcpReq，請求tcpServer建立TCP連接配接，其中Req内包含有建立連接配接用的Port；

2、tcpServer向tcpClient所提供的Port發送SYN，提供seq，以要求建立TCP連接配接；

3、tcpClient向tcpServer發送SYN/ACK，确認seq，并傳回seq+1；

4、tcpServer向tcpClient發送ACK，确認seq+1。

上述過程比起“3次握手”，主要優點在于tcpServer不需要在本地保留建立連接配接時所需的資源。隻有收到了tcpClient的ACK後，tcpServer才需要開始進行連接配接處理。這樣一來，tcpClient端需要更多資源以确認tcpServer所提供的TCP連接配接，這也間接減緩了TCP連接配接時tcpServer端的防禦能力。

上述内容純屬個人愚解，若有雷同，實屬巧合。希望能對本文提出您的批評指正。

本文轉自 gole_huang 51CTO部落格，原文連結:http://blog.51cto.com/golehuang/536952