为什么服务器突然回复RST——小心网络中的安全设备

RST产生原因

　　一般情况下导致TCP发送RST报文的原因有如下3种：

　　　   1、 SYN数据段指定的目的端口处没有接收进程在等待。

　　       2、TCP想放弃一个已经存在的连接。

　　　   3、TCP接收到一个数据段，但是这个数据段所标识的连接不存在。

　　对于第一种情况，常见的例子是终端访问服务器未开放的端口，服务器回复RST报文。比如，访问Web服务器的21端口（FTP），如果该端口服务器未开放或者阻断了到该端口的请求报文，则服务器很可能会给终端SYN报文回应一个RST报文。因此，服务器对终端的SYN报文响应RST报文在很多时候可以作为端口扫描器判断目标端口未开放的一个可靠依据。当然，在大多数场景下，服务器对到达自身未监听端口的报文进行丢弃而不响应是一种更为安全的实现。

　　第二种情况比较好理解，正常拆除一个已有TCP连接的方式是发送FIN，FIN报文会在所有排队数据都发出后才会发送，正常情况下不会有数据丢失，因此，这也被称为是有序释放。另外一种拆除已有TCP连接的方式就是发送RST，这种方式的优点在于无需等待数据传输完毕，可以立即终结连接，这种通过RST拆除连接的方式被称为异常释放。大多数时候服务器需要针对两种不同的拆链方式提供不同的处理方法，也有很多服务器无法识别RST方式的拆链，这时候就需要格外小心，因为一旦出现这种情况，尤其是大量终端使用RST方式拆链，可能会导致服务器侧连接无法得到有效释放，影响其正常业务侧处理能力。

　　最后一种情况，TCP通过4元组（源目IP，源目端口）唯一的标识一个连接，由于TCP状态机的存在，触发TCP连接建立的第一个报文标志位一定是SYN置位，因此，当服务器接收到一个新四元组（服务器本地没有这个连接）的非SYN首包就会丢弃该报文并向终端响应一个RST报文。最后一种情况，TCP通过4元组（源目IP，源目端口）唯一的标识一个连接，由于TCP状态机的存在，触发TCP连接建立的第一个报文标志位一定是SYN置位，因此，当服务器接收到一个新四元组（服务器本地没有这个连接）的非SYN首包就会丢弃该报文并向终端响应一个RST报文。

问题现象

　　通过终端登录Web，输入用户名密码后Web页面显示连接被重置。抓包报文如下：

　　终端10.153.47.104访问服务器10.153.42.65的8051端口，三次握手建立完成后，终端向服务器发送认证请求，提交用户名和密码，而后服务器立即回应RST拆除已有连接。

问题分析

　　通过对比前述3种情况，发现只能匹配上原因2，但从原因2来看也只是说明服务器在这个位置确实可以回复RST报文，无法解释为什么服务器要回复RST。

　　这个时候我们需要考虑一个问题：这个RST报文是不是真的是服务器回复的？从RST报文的seq来看确实可以和前序报文对应得上（由于SYN标志位在逻辑上占用1字节序号，所以RST报文的序号是第二个报文的序号加1）。一个很好的判断一条流是否是同一个服务器发送的方法是对比同一个方向的报文的IP头中的TTL值。由于TCP对乱序非常敏感，而网络设备逐包转发数据会引入更严重的乱序，因此网络中的设备一般都是逐流转发（按五元组，源目IP、源目端口、协议），所以，大部分情况下，在捕获的数据流中，同一条流的同一个方向的报文总是有相同的TTL值，我们基于这个判断来看一下上方截图中的第二个和第五个报文的TTL值：

　　第二个报文的TTL值为251：

　　第五个报文的TTL为122：

　　因此，基本可以判断RST报文为中间传输设备发出。排查流量路径上的安全设备，在IPS中找到对应的日志：

　　由于用户名和密码都是admin且明文传输，因此触发了Web用户登录弱口令的防御规则，连接被重置，IPS冒充服务器向终端发送RST报文拆链，如果在IPS设备抓包，可以看到IPS也同时冒充终端发送了RST给服务器。

　　在很多环境中，中间安全设备通过RST拦截报文时初始TTL一般是64、128、255，这时候根据终端抓包的TTL就能反推出进行拦截的安全设备所处的位置。当然也有一些安全设备进行拦截的时候TTL初始值无迹可寻，这时候只能逐跳排查了。