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

访问搜狐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) 浏览(9851)

我的CSNA认证专家文档-某地税网上申报业务系统故障分析报告

作者:易隐者 发布于:2012-7-6 9:34 Friday 分类:案例讨论

       虽然我个人一直认为证书对于自己的真实水平没有什么意义,但是想到我搞网络分析这些年,做科来做了这些年,连我带的徒弟10年初都已经拿到CSNA认证专家证书了,自己却没拿个分析专家证书,一时冲动,直接想飞到成都参加科来的培训拿下证书,还好高总让直接发个分析文档,鉴定一下,就通过了,在此感谢科来高总的信任,顺便把我的分析案例在此共享!

故障环境
1 网络拓扑
       故障环境大体的网络拓扑如下图所示:
 

点击查看原图

       说明:
1,网上申报服务器的地址是192.168.1.1,经过网闸后转换为X.X.16.73;
2,前置机的IP地址为X.X.16.56,征管服务器的IP地址为X.X.16.200。

阅读全文>>

标签: 地址冲突 reset ARP

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

TCP异常终止(reset报文)

作者:易隐者 发布于:2012-4-25 21:42 Wednesday 分类:网络分析

TCP异常终止(reset报文)

TCP的异常终止是相对于正常释放TCP连接的过程而言的,我们都知道,TCP连接的建立是通过三次握手完成的,而TCP正常释放连接是通过四次挥手来完成,但是有些情况下,TCP在交互的过程中会出现一些意想不到的情况,导致TCP无法按照正常的四次挥手来释放连接,如果此时不通过其他的方式来释放TCP连接的话,这个TCP连接将会一直存在,占用系统的部分资源。在这种情况下,我们就需要有一种能够释放TCP连接的机制,这种机制就是TCPreset报文。reset报文是指TCP报头的标志字段中的reset位置一的报文,如下图所示:

点击查看原图

阅读全文>>

标签: TCP异常终止 RST reset

评论(15) 引用(0) 浏览(59055)

IPS在线升级故障分析案例

作者:易隐者 发布于:2012-2-29 20:32 Wednesday 分类:案例讨论

  1 故障环境

故障的网络拓扑结构主要如下图所示:

点击查看原图

说明:

1,防火墙做NAT,上网行为、IPS都工作在透明模式下,串接在核心互联网出口链路上;

2,防火墙内口地址为192.168.0.3IPS管理口地址为192.168.0.4,上网行为管理地址为192.168.0.5

2 故障现象

     IPS离线升级包升级正常,但是在线自动升级提示失败,如下图所示:

点击查看原图

 

3 故障分析

3.1 常规分析

    IPS地址、网关、DNS设置全部正常,具有访问互联网的权限,将升级失败情况跟厂家沟通,厂家已将IPS升级为最新的版本,并确认升级服务器端都是正常的,暂时无法下结论是否是IPS本身问题导致的。万般无赖之下,我觉得还是先抓包分析一下IPS升级时的数据交互情况。

3.2 数据包分析

IPS在线升级时,我们在防火墙上通过tcpdump命令抓包,如下所示:

XX酒厂.system% tcpdump -i any host 202.85.219.10  -evv

//这条语句是在防火墙上抓取升级服务器地址的交互报文,并且显示报文的详细信息。

tcpdump: WARNING: Promiscuous mode not supported on the "any" device

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 bytes

 

08:15:51.553847 R@eth12  In 00:0b:ab:2a:f5:1d ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl  64, id 28482, offset 0, flags [DF], proto: TCP (6), length: 60)

 192.168.0.4.46461 > 202.85.219.10.80: S 2350953923:2350953923(0) win 5840 <mss1460,sackOK,timestamp 69524097[|tcp]>

//这个报文为IPS地址192.168.0.4发往升级服务器的SYN报文,这个报文出现在防火墙内口-eth12口。

 

08:15:51.553943 X@eth10 Out 00:13:32:06:8c:d4 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl  63, id 28482, offset 0, flags [DF], proto: TCP (6), length: 60)

 xx.242.83.189.46461 > 202.85.219.10.80: S 2350953923:2350953923(0) win 5840 <mss 1460,sackOK,timestamp 69524097[|tcp]>

//防火墙转发了IPSSYN报文,经外网口NAT后发往服务器,走网通接口地址走的。

08:15:51.577559 R@eth10  In 00:25:9e:83:a3:2f ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 117, id 29778, offset 0, flags [none], proto: TCP (6), length: 64)

202.85.219.10.80 > xx.242.83.189.46461: S 1891282156:1891282156(0) ack 2350953924 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙外口收到服务器的SYN/ACK报文

08:15:51.577588 X@eth12 Out 00:13:32:06:8c:d2 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 116, id 29778, offset 0, flags [none], proto: TCP (6), length: 64)

202.85.219.10.80 > 192.168.0.4.46461: S 1891282156:1891282156(0) ack 2350953924 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙将上面的报文从外网口的转发至内口,此时升级服务器的TTL116

 

08:15:51.579264 R@eth12  In 00:0b:ab:2a:f5:1d ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl  64, id 28483, offset 0, flags [DF], proto: TCP (6), length: 52)

 192.168.0.4.46461 > 202.85.219.10.80: ., cksum 0x1c80 (correct), 1:1(0) ack 1 win 46 <nop,nop,timestamp 69524099 0>

//IPS地址192.168.0.4对服务器的确认报文,至此,IPS与升级服务器三次握手完毕。

 

08:15:51.579269 X@eth10 Out 00:13:32:06:8c:d4 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl  63, id 28483, offset 0, flags [DF], proto: TCP (6), length: 52)

 xx.242.83.189.46461 > 202.85.219.10.80: ., cksum 0x4e7d (correct), 1:1(0) ack 1 win 46 <nop,nop,timestamp 69524099 0>

//防火墙将上面的报文从内口转发至防火墙外口eth10

 

08:15:51.580889 R@eth12   P 00:22:46:08:c2:b1 ethertype IPv4 (0x0800), length 230: (tos 0x0, ttl 128, id 22566, offset 0, flags [DF], proto: TCP (6), length: 214)

 202.85.219.10.80 > 192.168.0.4.46461: FP 1:175(174) ack 151 win 65535

//防火墙内口收到来自服务器IP地址的FIN标志置1的报文。

此处,我们发现几点异常:

1IPS与升级服务器刚完成TCP三次握手过程,连接刚建立成功,服务器为什么紧接着发送FIN报文,这不符合常规的情况;

2,如果这个报文是来自外网的IPS升级服务器的,那么应该首先出现在防火墙的外网口上,而后再经防火墙转发,出现在防火墙内口上,但是防火墙外口eth10并未出现这个报文,而是直接在防火墙内口eth12口上出现;

3,如果eth12收到防火墙转发的来自升级服务器的报文,eth12应该是转发这个报文给内网的IPS地址,此处的应该显示为X@eth12,而不是R@eth12R@eth12R表示eth12口收到报文,X表示接口转发报文

4,前面已经分析发现升级服务器经过多跳路由后,至防火墙内口时,其IP报文的TTL值应为116,但是此处的TTL值为128

 

综合以上疑问,我们可以肯定,这个FIN报文根本不是升级服务器自己发送的,而是来自内网的某个设备伪造的

是什么设备发送的呢?我们在抓包的时候使用了-e参数,tcpdump会将报文的源MAC地址显示出来,我们可以看到这个伪造报文的源MAC00:22:46:08:c2:b1

 

08:18:03.823668 R@eth10  In 00:25:9e:83:a3:2f ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 117, id 14719, offset 0, flags [none], proto: TCP (6), length: 40)

202.85.219.10.80 > 58.242.83.189.46461: R, cksum 0x6666 (correct), 1:1(0) ack 1 win 0

//132秒后,防火墙外口收到的来自升级服务器的RST报文,此时为升级服务器长时间未收到IPS的升级请求,连接超时发送的RST报文

 

08:18:03.823673 X@eth12 Out 00:13:32:06:8c:d2 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 116, id 14719, offset 0, flags [none], proto: TCP (6), length: 40)

 202.85.219.10.80 > 192.168.0.4.46461: R, cksum 0x3469 (correct), 1:1(0) ack 1 win 0

//防火墙将上面的RST报文转发至内口

     我们通过防火墙的ARP表,发现00:22:46:08:c2:b1对应的IP192.168.0.5,如下图所示:

点击查看原图

    192.168.0.5是上网行为管理设备的IP地址,结合上网行为管理设备的工作原理,我们基本上可以得出结论,是上网行为管理设备发送的伪造报文,导致IPS升级错误。

    我们可以通过跳开上网行为管理设备,直接升级IPS来验证我们分析的结论。

4 故障解决

    IPS在线升级的故障原因确定清楚了,那么我们解决问题的方式也就出来了,主要有以下几种选择:

1,调整上网行为产品的相关检测策略,让上网行为管理设备完全放行IPS地址对互联网的访问;

2,让IPS升级地址跳过上网行为管理设备,直接访问互联网;  

阅读全文>>

标签: 中间设备劫持 RST reset tcpdump IPS

评论(0) 引用(0) 浏览(13223)

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