欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

端系统对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 端系统

评论(2) 引用(0) 浏览(13996)

访问搜狐163时主页变为2008年某日主页面故障分析案例

作者:易隐者 发布于:2012-8-13 22:26 Monday 分类:网络分析

1 故障环境

        故障环境的拓扑结构示意图如下:
 

点击查看原图


        防火墙做NAT通过电信接入线路访问互联网,核心交换机上接入的设备和线路比较多,内部网络规模比较大。

2 故障现象

       故障现象主要体现在以下几个方面:
1,用户在内网访问搜狐和163主页时,页面变为2008年某日的主页面,所有连接均为2008年的新闻连接,如下图所示: 

点击查看原图


其他网站页面访问均正常。
2,使用笔记本配置为公网地址直接访问搜狐和163正常;
3,在防火墙的一个空闲端口设置地址,通过防火墙NAT地址转换后访问搜狐163主页正常;

       此故障已经持续了数周。

阅读全文>>

标签: 端口镜像 交换机 疑难故障 TCP 天融信 RST reset HTTP会话劫持 会话劫持 TTL

评论(1) 引用(0) 浏览(10521)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1