端系统对RST报文的过滤

作者：易隐者发布于：2012-10-8 17:00 Monday 分类：网络分析

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

在这个交互的过程中，我们可以看到一个比较奇怪的现象，那就是客户端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连接的场景下，可能会对性能产生一定的影响。

标签: TCP RST icmp差错会话劫持 TTL FIN type 3 code 10 端系统

您对本文的评分:

当前平均分: 10.0(11 次打分)

QQ空间新浪微博腾讯微博人人网更多

相关日志：

SharkFest'19 Retrospective

关于《DDoS攻击原理及防护方法论》一文的疑问

MOTS攻击之TCP攻击

某省厅门户网站A市局访问异常应急处置

MOTS攻击技术分析

« 多次RST以及不同场景下的RST报文的差异 | ACK flood攻击的影响»

评论：

寒风
2013-12-24 15:57

测试一下

123
2013-12-10 22:17

第一个报文是211.151.123.8给10.16.137.56可以看出其发送的报文中FIN+ACK位都置一，我们看到10.16.137.56回应的报文仅仅是RST位置一，其ACK位并没有置一，传输层在收到这个报文以后，首先应该对这个报文进行ACK确认，如果不确认直接RST的话，这能说明10.16.137.56收到211.151.123.8发过来的报文吗？个人感觉第一个RST位的ACK位也应该置一，后续再过来的包的话只需要RST位置一就可以了。不知道是不是应该这样理解？

发表评论：

蚂蚁网-多维人生，三实而立！

真实-不弄虚，不做假，做自己，不违心；踏实-不浮躁，不盲从，不急功，不近利；实学-不投机，不取巧，勤于学，精于业。