TCP Split Handshake Attack

一种规避攻击方式，传统的，网络中绝大部分的tcp三次握手都是由3个包来完成的。但是实际上一个tcp会话的建立，在三次握手的交互方式上，还有很多其他的方式。

有一个比较典型的方法，就是服务器在收到了客户端的syn包之后，返过来再给客户端发送一个syn包，类似于服务器在收到了客户端的syn之后，重新向客户端的对应端口发起三次握手。具体交互过程如下：

刚接触这个规避攻击方式时，觉得还挺新鲜的，但是文档上说这种实现方式在当前的主流windows、linux上都适用，所以就想试一下三次握手是否真的可以这样建立。

适用测试仪表bps在进行攻击测试时，可以选择这种规避方式。仪表上使用的名称是sneak-ack。不过抓包看了一下，bps仪表打出来的攻击包和原始的定义还有些不符。假设客户端最初的syn包，seq值为1000，那么在收到服务器发过来的syn之后，客户端回给服务器的syn/ack包中，seq值应该还是1000。但是bps抓包来看，这个包的seq的值却为1001，比上一个客户端发出的syn包里的seq多了1。

 

为了验证真实的环境下，客户端在收到服务器的syn包后是如何处理的，只好通过脚本来模拟服务器了。传统的tcp socket肯定实现不了这个功能，因为syn、ack包如何发送是我们控制不了的，我们只能从tcpsocket里面读取和发送数据。之后用到了raw socket，发出去的包的整个tcp头包括数据部分都要自己进行拼接，还要计算校验和，然后计算seq、ack的值，真的很麻烦。最后想到了一个投机取巧的方法，在收到客户端的第一个syn包之后，可以用用raw socket获取这个包的源端口。然后在服务器端，直接开一个tcp socket，绑定源端口80，像客户端的对应端口发起链接，接下来的过程就和描述的一样的。相当于在服务器上开启一个tcp socket作为客户端，然后向真正的客户端再次发起三次握手。

不过在使用raw_socket的时候，有一个问题需要注意。当运行server脚本的操作系统在收到一个syn包后，如果80端口没有被监听，那么操作系统本身就会发一个rst、ack的报文回去，把这个会话断掉。需要使用iptables来屏蔽这类包，使用如下命令：

iptables -A OUTPUT -p tcp --tcp-flag RST ACK,RST ACK -j DROP

这样一来，iptables会自动将操作系统发出的rst包给丢掉。

 

经过试验证明，win7作为客户端，使用脚本模拟服务器，客户端在发送一个syn请求之后，如果收到服务器发过来的syn包，会使用原始的seq值，作为syn、ack包中的seq发送给服务器，而不是bps里面的加1。至于是bps的实现有问题，还是我的理解有问题，还有待讨论。