TCP安全之——RST复位攻击简析_tcp rst攻击

以下为阶段学习协议分析的一些flag :

一、TCP基础：三次握手、滑动窗口和四次挥手

先上图说明：

a)三次握手

　　简单讲，TCP是基于IP网络层之上的传输层协议，用于端到端的可靠的字节流传输。
端到端：IP层只负责数据包从IP传向另一IP，而在TCP传输层加上端口后，就变为面向进程的方式寻找对应用户的进程。
字节流：TCP将应用进程的字节流数据切割成多个数据包，但在网络传输中可能会出现顺序错乱，TCP协议可以对其进行编号并排序保证其正确性。
　　那么何为三次握手连接呢？
例如：
1.C向S发送连接请求，标记位SYN设为1，且随机设置序列号seq
2.S返回确认消息，ACK设为seq+1，标记位SYN设为1，随机序列号seq
3.C返回确认消息，ACK设为seq+1
此时链接建立

图：三次握手示例

备注：为什么需要三次握手？
　　C发送的第一个请求报文段可能在网络结点中阻塞滞留，而一段时间后C/S连接已经中断，但此时C的请求报文到达S，S误认为是C发的链接请求,就会建立链接，但C没有发出建立连接请求，所以会无视s，也不会向s发送数据，这样S会一起等待C的数据，浪费资源。

b)滑动窗口

　　诞生滑动窗口的目的主要是为了在保证“可靠”的前提提高传输效率，如果我们每个包都等待ack那么效率过低，所以我们可以在发送完数据后不等待ack，在滑动窗口大小内可继续发送其它数据包。上图中的WIN即为滑动窗口大小。

c)四次挥手

四次挥手指正常连接中断的情况：
1.C向S发送FIN seq=上次发送的seq+1
2.S回复C ACK=seq+1 此时C停止向S发送信息，但仍可以接收S的消息，此时为半双工（即单向中断）
3.当S剩余的数据包发送完毕后，向C发送FIN包
4.C收到消息后返回ACK确认，S收到后中断向C发送消息,此时完全中断连接

备注：四次挥手的主要目的？
　　四次挥手的目的在于如果客户端因为数据发送完毕而想要关闭，便发送FIN。服务端收到FIN后，但可能还存在数据需要发给客户端，所以服务端先发ACK作为应答。当服务端也发送完毕之后，再发回FIN作为关闭连接。客户端收到FIN后，发送ACK，然后关闭连接。

本文主要讨论安全问题，所以我们要关注TCP的六个标志位：

其中RST位是关键：何为RST标识位？

二、TCP安全之——RST复位攻击

1.什么是RST标识位

　　RST表示复位，用来异常的关闭连接。发送RST包关闭连接时，不必等缓冲区的包都发出去（FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。TCP处理程序会在自己认为的异常时刻发送RST包。
　　举2种情况：
a）C向S发起连接，但S之上并未监听相应的端口，这时S操作系统上的TCP处理程序会发RST包。（UDP没有连接，没有RST）
b）C和S已经正常建立连接，正在通讯时，C向S发送了FIN包要求关连接，S发送ACK后，C网断了，C通过若干原因放弃了这个连接（例如进程重启）。网络恢复之后，S又开始或重发数据包，C不知道这连接哪来的，就发RST包强制把连接关闭，S收到后会出现connect reset by peer错误。

图：Reset标识
　　备注：异常中断连接后，由于TCP是虚拟连接，如果低层物理链路断开，只要不引起keepalive retry timeout，TCP连接会一直健在。

此处简单 科普一下长链接与短链接的问题：

短连接
连接->传输数据->关闭连接
　　HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。

长连接
连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。
　　长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

什么时候用长连接，短连接？
　　 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。总之，长连接和短连接的选择要视情况而定。

2.RST复位报文段

　　TCP在下列三种情况下产生RST复位报文段。
　　1.到不存在的端口的连接请求
　　产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在监听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息；而TCP则使用复位。
　　2.异常终止一个连接
　　终止一个连接的正常方式是一方发送FIN，这也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接，这也称为异常释放。异常终止一个连接对应用程序来说有两个优点：（1）丢弃任何待发数据并立即发送复位报文段；（2）RST的接收方会区分另一端执行的是异常关闭还是正常关闭。

3.检测半关闭连接

　　如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称为半打开的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。

４.RST复位攻击

　　A和服务器B之间建立了TCP连接，如果此时C伪造了一个TCP包发给B，使B异常的断开了与A之间的TCP连接，就是RST攻击。
伪造这样的TCP包能造成什么后果？
　　1、假定C伪装成A发过去的包，这个包如果是RST包，冲区上所有数据B将会丢弃与A的缓，强制关掉连接。
　　2、如果发过去的包是SYN包，那么，B会表示A已经是正常连接却又来建新连接，B主动向A发个RST包，并在自己这端强制关掉连接。
如何伪造成A发给B的包？
这里有两个关键因素，源端口和序列号。
　　一个TCP连接都是四元组，由源IP、源端口、目标IP、目标端口唯一确定一个连接。所以，如果C要伪造A发给B的包，要在上面提到的IP头和TCP头，把源IP、源端口、目标IP、目标端口都填对。
　　1）这里B作为服务器，IP和端口是公开的；
　　2）A是我们要下手的目标，IP当然知道，但A的源端口就不清楚了，因为这可能是A随机生成的。当然，如果能够对常见的OS如windows和linux找出生成source port规律的话，还是可以进行碰撞。
　　3）序列号问题是与滑动窗口对应的，伪造的TCP包里需要填序列号，如果序列号的值不在A之前向B发送时B的滑动窗口内，B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决，因为一个sequence长度是32位，取值范围0-4294967296，如果窗口大小像上图中我抓到的windows下的65535的话，只需要相除，就知道最多只需要发65537（4294967296/65535=65537）个包就能有一个序列号落到滑动窗口内。RST包是很小，IP头＋TCP头才40字节，算算我们的带宽就知道这实在只需要几秒钟就能搞定。
那么，序列号不是问题，源端口会麻烦点，如果各个操作系统不能完全随机的生成源端口，或者黑客们能通过其他方式获取到source port，RST攻击存在可能。

4.预防

　　通过防火墙简单设置。可以使用防火墙将进来的包带RST位的包丢弃。
　　部分参考网上资料，作为此段学习的总结的梳理。