从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来说，几乎没有任何意义。

回到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端的防御能力。

上述内容纯属个人愚解，若有雷同，实属巧合。希望能对本文提出您的批评指正。