我的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。
疑难杂症分析案例-启明星辰竟然用的是我08年制作的PPT
作者：易隐者 发布于：2012-7-3 18:04 Tuesday 分类：案例讨论
下班后，在网上查找启明防火墙的命令行手册，没想到竟然在百度文档里发现了下面这个系列的培训PPT，这个是我08年写的疑难杂症分析案例培训PPT，哈哈，启明基本上没做改动。如有人对原PPT有兴趣，可给我留言。标签: 疑难杂症 丢包 icmp差错 分片 sack 可选择性确认 tcpdump
高新区房产局房产管理业务故障分析解决报告
作者：易隐者 发布于：2012-4-28 10:27 Saturday 分类：案例讨论
高新区房产业务系统运行的网络环境如下图所示：
说明：
1，房产业务系统主要是用于在线办理各种房产相关证件的业务信息系统，是房产业务的核心组成部分，其办理业务的客户端一般分布在各个区县房产业务大厅或行政服务中心；
2，高新区房产局业务机器主要通过管委会的政务专网出口与市房产局的业务服务器进行数据交互；
3，业务客户端通过防火墙NAT访问业务服务器，业务服务器的真实地址为192.168.10.41，但是其通过防火墙的地址映射功能映射成10.12.168.197供业务客户端访问；
4，房产业务系统为C/S架构，客户端需要向服务器上传业务相关的数据和图片。
某部队部分网段访问总部网站故障分析案例
作者：易隐者 发布于：2012-4-25 22:00 Wednesday 分类：案例讨论
产生故障的网络拓扑如下所示：
其数据访问流程如下：
客户端经过核心交换机转发，再经过防火墙的访问控制，然后经过加速器的加速处理和加密机的加解密后，再通过专网访问服务器。
网段为X.X.8.0/23的机器全部无法访问总部的网站，网页...
IPS在线升级故障分析案例
作者：易隐者 发布于：2012-2-29 20:32 Wednesday 分类：案例讨论
1 故障环境
故障的网络拓扑结构主要如下图所示：
说明：
1，防火墙做NAT，上网行为、IPS都工作在透明模式下，串接在核心互联网出口链路上；
2，防火墙内口地址为192.168.0.3，IPS管理口地址为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]>
//防火墙转发了IPS的SYN报文，经外网口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报文
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]>
//防火墙将上面的报文从外网口的转发至内口，此时升级服务器的TTL为116。
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。
//防火墙内口收到来自服务器IP地址的FIN标志置1的报文。
此处，我们发现几点异常：
1，IPS与升级服务器刚完成TCP三次握手过程，连接刚建立成功，服务器为什么紧接着发送FIN报文，这不符合常规的情况；
2，如果这个报文是来自外网的IPS升级服务器的，那么应该首先出现在防火墙的外网口上，而后再经防火墙转发，出现在防火墙内口上，但是防火墙外口eth10并未出现这个报文，而是直接在防火墙内口eth12口上出现；
3，如果eth12收到防火墙转发的来自升级服务器的报文，eth12应该是转发这个报文给内网的IPS地址，此处的应该显示为X@eth12，而不是R@eth12（R@eth12，R表示eth12口收到报文，X表示接口转发报文）；
4，前面已经分析发现升级服务器经过多跳路由后，至防火墙内口时，其IP报文的TTL值应为116，但是此处的TTL值为128；
综合以上疑问，我们可以肯定，这个FIN报文根本不是升级服务器自己发送的，而是来自内网的某个设备伪造的。
是什么设备发送的呢？我们在抓包的时候使用了-e参数，tcpdump会将报文的源MAC地址显示出来，我们可以看到这个伪造报文的源MAC是00: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对应的IP为192.168.0.5，如下图所示：
192.168.0.5是上网行为管理设备的IP地址，结合上网行为管理设备的工作原理，我们基本上可以得出结论，是上网行为管理设备发送的伪造报文，导致IPS升级错误。
我们可以通过跳开上网行为管理设备，直接升级IPS来验证我们分析的结论。
4 故障解决
IPS在线升级的故障原因确定清楚了，那么我们解决问题的方式也就出来了，主要有以下几种选择：
1，调整上网行为产品的相关检测策略，让上网行为管理设备完全放行IPS地址对互联网的访问；
2，让IPS升级地址跳过上网行为管理设备，直接访问互联网；
-
QQ邮箱订阅
-
搜索
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情，那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道，真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望，它终归还是把我们引到我们看不见的目的地。（茨威格《昨日世界》）
2019-03-16 21:27
- 如果你渴望得到某样东西，你得让它自由，如果它回到你身边，它就是属于你的，如果它不会回来，你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧：一个是没有得到你心爱的东西；另一个是得到了你心爱的东西。人生有两大快乐：一个是没有得到你心爱的东西，于是可以寻求和创造；另一个是得到了你心爱的东西，于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想，发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)
标签
blogger
