访问搜狐163时主页变为2008年某日主页面故障分析案例 - 蚂蚁网-多维人生,三实而立!

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

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

1 故障环境

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

点击查看原图


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

2 故障现象

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

点击查看原图


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

       此故障已经持续了数周。

3 故障分析

3.1 故障测试点分析,定位故障原因

       由于此故障现象实在是怪异,从一些基本的分析方式入手,根本没有什么进展,我们需要站在网络运行本质的角度——数据包的层面对此故障进行分析。
       我们首先找一个故障点,并在故障点测试主机上还原故障,同时在还原时抓取测试主机访问搜狐时的数据包,我们通过科来网络分析系统的“会话”功能视图,查看流量最大的TCP会话(之所以选择查看流量最大的会话主要是因为这个会话才是打开搜狐主页的会话),如下图所示: 

点击查看原图


双击流量最大的会话,打开其数据包交互的详细过程,通过数据包TTL值的解码功能,我们发现了问题所在,如下图所示: 

点击查看原图


       通过上图,我们可以知道,在测试客户端访问搜狐时,在TCP三次握手时,搜狐服务器返回的TTL值为52,但当客户端发出get请求后,搜狐返回的TTL值却为62,两个TTL值相差如此之大,应该是HTTP会话劫持(HTTP会话劫持的原理在此不做进一步的阐述,可以网上搜索相关的知识)。
3.2 定位劫持发生在内网还是外网

       定位出了问题的类型,那么接下来就要判断一下HTTP劫持发生在内网还是外网了。
我们通过在电信接入交换机上的端口镜像功能抓取防火墙接电信接口的数据包,如下图所示:
 

点击查看原图


并在客户端访问搜狐异常时,抓取数据包,同样,我们通过科来网络分析系统的“TCP会话”视图,查看如下所示: 

点击查看原图


       在这个视图里,我们可以清楚的看到在TCP三此握手以及HTTP应用层数据响应时,搜狐服务器返回的TTL值都是55,因此,HTTP劫持并不是在互联网发生的,那么是发生在内网还是跟防火墙有关?我们下面将进行进一步的分析。
3.3 定位是否与防火墙有关

为了判断会话劫持是否跟防火墙有关,我们在测试客户端与防火墙内网口同时抓包,如下图所示:
 

点击查看原图


看防火墙内网口搜狐服务器给测试客户端回包时的TTL值是否正常(我们在防火墙内网口的抓包直接使用天融信防火墙自带的tcpdump抓包功能),我们在防火墙内网口抓包情况如下图示:
08:16:12.378859 R@eth11 IP (tos 0x0, ttl 126, id 9045, offset 0, flags [DF], proto: TCP (6), length: 48) X.X.12.43.1778 > 114.80.130.32.80: S, cksum 0xf456 (correct), 3856409923:3856409923(0) win 16384 <mss 1460,nop,nop,sackOK>
//客户端向搜狐服务器发送的syn请求报文//
08:16:12.387831 X@eth11 IP (tos 0x0, ttl  54, id 0, offset 0, flags [DF], proto: TCP (6), length: 44) 114.80.130.32.80 > X.X.12.43.1778: S, cksum 0xbd5e (correct), 3713767362:3713767362(0) ack 3856409924 win 5840 <mss 1460>
//搜狐服务器向客户端发送的syn+ack响应报文,其TTL值为54//
08:16:12.389483 R@eth11 IP (tos 0x0, ttl 126, id 9047, offset 0, flags [DF], proto: TCP (6), length: 40) X.X.12.43.1778 > 114.80.130.32.80: ., cksum 0xa77b (correct), 1:1(0) ack 1 win 17520
08:16:12.391601 R@eth11 IP (tos 0x0, ttl 126, id 9048, offset 0, flags [DF], proto: TCP (6), length: 1037) X.X.12.43.1778 > 114.80.130.32.80: P 1:998(997) ack 1 win 17520
//客户端向搜狐服务器发送的get请求报文,其应用层数据长度为1037字节//
08:16:12.400178 X@eth11 IP (tos 0x0, ttl  54, id 54302, offset 0, flags [DF], proto: TCP (6), length: 40) 114.80.130.32.80 > X.X.12.43.1778: ., cksum 0xd51b (correct), 1:1(0) ack 998 win 4843
//搜狐服务器向客户端发送应用层响应报文,其TTL值为54,长度为40字节//
08:16:12.400306 X@eth11 IP (tos 0x0, ttl  54, id 54303, offset 0, flags [DF], proto: TCP (6), length: 505) 114.80.130.32.80 > X.X.12.43.1778: P 1:466(465) ack 998 win 4843
08:16:12.400550 X@eth11 IP (tos 0x0, ttl  54, id 54304, offset 0, flags [DF], proto: TCP (6), length: 1500) 114.80.130.32.80 > X.X.12.43.1778: . 466:1926(1460) ack 998 win 4843

       通过分析这个数据交互的过程,我们知道,防火墙内网口在转发搜狐服务器的应用响应数据时并没有问题,说明HTTP的劫持跟防火墙无关。劫持应该发生在防火墙防护的内网。

3.4 定位实施劫持的主机或设备应该接在核心交换机上

在防火墙外口抓包,发现搜狐服务器回包的TTL值为55,在防火墙内网口抓包,发现搜狐服务器回包的TTL值为54,在测试主机上抓包,发现搜狐服务器正常回包的TTL值为52,这说明,从防火墙内网口到测试主机需要经过两跳路由。如下图所示:

点击查看原图

同时,我们在分析测试主机劫持的数据包时,发现HTTP劫持注入的主机为unix系统,如下图所示(红线部分):
 

点击查看原图


       UNIX系统默认的TTL值为64,而在测试主机上抓取的劫持数据包的TTL值为62(参见上图蓝线部分)。这说明从实施劫持的主机到测试主机的路由跳数为两跳,这说明这个实施劫持的主机应该跟防火墙一样是接在核心交换机上,那么这个实施HTTP劫持的主机到底是接在核心交换机的哪个端口上呢?

       我们可以在核心交换机上通过端口镜像抓取劫持的数据包,分析出实施劫持主机的源MAC地址,再通过核心交换机的MAC地址表找到实施劫持主机在核心交换机上所接的端口。

3.5 定位具体劫持的位置和设备

       当用户为我们在核心交换机上做好端口镜像后,我们再进行相关的抓包和测试,却发现故障现象消失了。正当我们惊讶之余,突然之间想到,所谓的劫持,必须建立在会话监听分析的基础之上,否则就失去了劫持的基础,那么是否是这个核心交换机不支持多组镜像,导致原来的镜像失效了呢?

       我们跟用户进一步的确认发现,核心交换机上原来就存在一个端口镜像组,专门针对防火墙接入核心交换机的流量进行监听,用户在给我们做镜像时,把原先的镜像设置暂停了。这个镜像口接的是一个安全监听设备,由此,我们基本上可以肯定就是这个监听设备实施了HTTP会话劫持,从而导致了这个故障的产生。

3.6 问题源头验证

       为了验证我们分析的结果,我们将原先核心交换机上的端口镜像功能启用,再在测试客户端上访问搜狐163等页面,发现故障现象再次出现。至此,我们完全将导致此次怪异故障的问题根源定位清晰了。

4 故障解决

       由于此故障是由某个安全监听设备针对搜狐和163主页面实施HTTP劫持导致的,因此有如下两种解决的方法和思路:
 1)将这个安全监听设备下线;
 (2)安全监听设备本身的问题可请设备厂商检查更改相关设置和版本解决。

5 总结

       此故障相对比较怪异,首先怀疑的就是缓存服务器的问题或者是HTTP劫持,我们需要通过网络分析的方式找到明确的证据以确认导致问题的原因。

       我们在遇到一些疑难故障,利用常规的技术手段根本无法找到问题的原因和源头,这时需要站在网络运行本质的角度——数据包的层面进行深入的分析,才可以快速的定位问题的根源,大大提高故障解决和网络运维的效率。


 

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


您对本文的评分:
当前平均分: 9.0(13 次打分)

版权所有:《蚂蚁网-多维人生,三实而立!》 => 《访问搜狐163时主页变为2008年某日主页面故障分析案例
本文地址:http://www.vants.org/?post=89
除非注明,文章均为 《蚂蚁网-多维人生,三实而立!》 原创,欢迎转载!转载请注明本文地址,谢谢。

评论:

寒风
2013-12-24 10:29
学习了

发表评论:

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