端系统对RST报文的过滤

2012-10-08 · 网络分析 · 网络分析 · 20317 次阅读

前段时间在分析网上一个兄弟传给我的报文时，发现了几个有意思的现象，我觉得值得分析讨论，我们首先来看一个服务器与客户端交互的会话：

在这个交互的过程中，我们可以看到一个比较奇怪的现象，那就是客户端10.16.137.56在收到来自服务器的FIN报文之后，紧接着向服务器端发送RST报文，但是服务器给其回应了一个ICMP主机管理性禁止差错报文，并且不断尝试向服务器发送FIN报文。
我们来看一下服务器给客户端回应的ICMP主机管理性禁止差错报文的解码：

Type 3，Code 10——主机管理性禁止差错，其封装的原始报文报头信息显示，该ICMP差错报文正是由客户端发往服务器端的RST报文引起的。下图为客户端发往服务器端的RST报文解码：

另外，我们注意到，服务器发送给客户端的ICMP差错报文的TTL值为48，而服务器端发送给客户端的FIN报文报头中的TTL值也是48，如下图所示：

这从侧面说明这个ICMP差错报文的确是服务器端系统发送的，而不是中间设备发出的。

那么为什么服务器端系统会过滤掉客户端的RST报文呢？

想想TCP会话劫持和TCP RST攻击，大家就能够体会，服务器管理员为什么这么做了。

TCP会话劫持的实施者经常会扮演对端的身份分别向客户端或服务器端发送RST报文，以达到干扰客户端与服务器端正常交互的目的。有些服务器的管理员可能遇到过这种TCP会话劫持的攻击，因此在服务器端系统上利用相关工具设置了过滤RST报文的策略，当服务器收到RST报文时，直接忽略掉，因此服务器端系统的传输层并不会收到这个RST报文。

其交互过程大致如下图所示：

过滤RST报文可能带来的影响

服务器传输层无法收到客户端的RST 报文，只能在多次尝试重传FIN报文直至超时，然后主动向客户端发送RST报文。如此带来的影响就是执行过滤策略的端系统无法正常处理来自于TCP连接对端的异常释放行为（RST），这将导致端系统的TCP连接释放需要更长的时间，在有大量对端通过RST报文异常释放TCP连接的场景下，可能会对性能产生一定的影响。