为什么服务器突然回复RST——⼩⼼⽹络中的安全设备
RST产⽣原因
  ⼀般情况下导致TCP发送RST报⽂的原因有如下3种：
      1、 SYN数据段指定的⽬的端⼝处没有接收进程在等待。
提供web服务的是什么        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初始
值⽆迹可寻，这时候只能逐跳排查了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。