频道栏目
首页 > 网络 > 网络协议 > 正文

巧用排除法进行中故障的排除简介

2007-05-03 10:10:54           
收藏   我要投稿

由于地域限制的原因,我城域网分布在两个地区,由A网络和B网络构成,通过Router1 和Router2的广域网接口互连,并通过两个ISP出Internet,而且在一端Internet或防火墙有问题时,可以互转至另一端出Internet,所有核心设备的路由采用的是OSPF。网络系统结构如图所示。

本网络的安全系统部署了防御外部攻击的防火墙和一套不完善的防病毒系统,没有安装IDS和相应网络管理及监控软件。


上网出现异常


某日21:00,用户故障台申报A网络不能上外部Internet,但是A网络访问B网络提供的Web服务及其他应用服务正常,同时B网络一切正常。


我们远程进入系统检测发现防火墙出了问题,按照常规重启防火墙,结果还是不行;再通过系统设置将我们A网络的外网出口转至B网络出口,发现B网络上网突然变慢,而且有中断的情况。开始我们认为那是流量较大的原因导致PIX2处理不及,但是后来PIX2瘫痪,A、B网络都不能上Internet,这和我们平时互转Internet不一样,我们分析A网络有问题,结果我们一撤消互转,PIX2即恢复正常。


日志中找到蛛丝马迹


1.故障信息的获得


1)进入核心Router1


Recent 1 sec: average 15%, peak 23%
 Recent 5 secs: average 14%, peak 29%
 

系统正常。


2)进入核心Switch1


系统资源占有率为11%,而且ARP和IPReceive占用CPU分别为0.09%和2%,一切和平时基本一样,没有异常现象。


3)近端进入PIX1防火墙的审计系统观察到如下大量的信息,如表1所示。

 

表1

序号   内核  事件类型   事件来源    事件内容                   用户      时间
 1      √    Error      内核事件   从119.206.107.154(351)到   SYSTEM   21:03
                                    69.56.141.67(80)的TCP包
                                    未找到相应的连接
 
 2      √    Error      内核事件  从117.75.118.170(551)到     SYSTEM   21:03
                                   69.56.141.67(80)的TCP包
                                   未找到相应的连接
 
 3      √    Error      内核事件  从118.149.67.172(39)到      SYSTEM   21:03
                                   69.56.141.67(80)的TCP包
                                   未找到相应的连接
 

进入防火墙安全控制台,调出生成的NAT记录全部如下:


nat.c[2839] 164.30.123.28(715) -> 69.56.141.67(80) TCP not NAT
 nat.c[2839] 65.135.150.204(379) -> 69.56.141.67(80) TCP not NAT
 nat.c[2839] 62.161.122.93(259) -> 69.56.141.67(80) TCP not NAT
 
 …………
 

该类记录一直出现 ,同时显示防火墙资源耗尽。


故障分析


1)常规经验


根据我们的经验,冲击波或震荡波等网络病毒发作攻击防火墙时一般不带隐蔽性,通过防火墙的审计系统和部署的防病毒服务器可以查出病毒源头的IP或占用的TCP端口,在系统里通过Router和三层Switch的ACL将源IP和所占用的TCP端口封闭然后再找源IP即可解决问题。


2)故障表现


这次故障从整个系统来看,交换机路由器、防病毒服务器的所有记录没有显示出有大规模的病毒发作,因此我们排除了是病毒发作的可能性。


从防火墙的信息可以看出,整个防火墙的内核事件全部为:


“从119.206.107.154(351)到69.56.141.67(80)的TCP包未找到相应的连接”,NAT记录也显示了同样的信息,源IP和源TCP端口在不断地变化,源IP为外部地址,目标IP也是外部地址,目标TCP为80端口,整个故障现象给人的感觉不像网络病毒发作,更不像通常的冲击波蠕虫病毒和震荡波蠕虫病毒,而且将A网络的出口一转至B网络上就导致B网络上Internet不正常。


3)故障类型


由于防火墙的工作机理使得在网络中被攻击对象一般是具有默认路由选择的防火墙,根据故障表现、防火墙的信息和分析,我们初步判定为内部攻击防火墙,是A网络里用户在攻击防火墙PIX1,转至B网络出口该用户又攻击防火墙PIX2,导致外网的阻断。


该次攻击可能是某个用户安装黑客软件恶意攻击防火墙,也可能是该用户无意中安装了或感染了非法的木马程序导致了攻击的发生,而且该攻击具有很大的欺骗性,该用户将源地址转换成不断变化的外部公用IP,而且TCP变为HTTP占用的80端口,使得我们无从下手。


用排除法解决故障


为了保证用户的利益,必须在最短的时间内查出故障源,同时影响范围要尽可能小。由于攻击有很大的欺骗性,从获得的信息我们不能得知攻击源的具体位置和网段,因此我们采用逐步排除法由大到小查找攻击源,而且在解决过程中考虑系统的可操作性和OSPF的收敛对网络系统构成的影响。


1.排查核心路由器以外的网络


进入Router1,将Router1中连接A网络和B网络的端口关闭,PIX1中仍旧有以上信息出现,因此我们打开该接口。再在Router1里将Router1和Router3的接口关闭,发现攻击仍然没有停止。因此我们判定攻击源不在Router1以外的用户。


2.排查Router 4、Router 5上的用户


进入核心Switch1,关闭Switch1与Router 4、Router 5的接口,发现问题还存在。经过以上操作,范围进一步缩小,攻击源确定在Switch1和Switch2自带的用户上,由于防火墙挂在Switch1上,因此我们先排除Switch2的用户。


3.排查核心Switch2上的用户


先进入Switch1和Router 1,采用扎口袋的办法将它们与Switch2的接口关闭,打破自愈环,造成Switch2独立成网络,这时发现防火墙工作正常,故障现象消失,用户能正常上Internet。因此初步判定攻击源是Switch2上的用户,但是具体网段还需要进一步的判定。


4.进一步排查具体网段和单机


1)超级终端进入核心Switch2,先将它上面的所有业务和用户接口全部关闭,再远程进入核心Switch1和Router 1打开它们与核心Switch2的接口。


2)远程进入核心Switch2,逐步打开Switch2上各个二级单位的接口,当打开与勘探公司的千兆接口时,防火墙上的审计系统立刻出现故障信息,外网立刻受阻不畅,终于查明攻击源具体在勘探公司的小范围网络内,于是打开其他正常的所有二级单位的网络接口。


3)勘探公司的处理


由于勘探公司具有两个C网段,计300多个用户,而且远离我们核心网络40多公里,立刻联系该公司的网络管理员配合进行处理。


我们远程登录入该公司三层交换机,也采用先关闭后逐步打开的办法将故障源定位到了一台楼层接入层交换机上,由于该公司的网络建设不规范,对于下层的交换机不能远程管理,于是先采用Sniffer软件进行跟踪抓包,希望能从捕获的数据流报文查出故障源的IP,结果也得出和防火墙审计系统相似的数据,不能查出具体IP和TCP端口。


最后采用物理拔网线的办法查出了故障源,该用户最近安装了叫lonseled的软件,它是一种以黑客方式检查并探测网络的软件,导致了故障的发生。

 

这次故障影响面很大,有两千多个用户不能上外网,中断时间长,部分用户中断达两个半小时,虽然经过逐步排查终于水落石出,但是给我们带来了惨痛的教训,主要有以下几点。


1.冷静处理故障


在出现网络攻击时不要惊慌失措,要学会冷静思考分析问题,采用围追堵截和逐步排查的办法由大到小地查出故障源。


2.网络安全建设的必要性和重要性


在网络建设和运营中我们不只是重视外部对网络构成的威胁和网络规模的扩大,随着互联网的迅猛发展,内部网络中的网络非法流量也是不可忽视的,因此内部构建一套完整的

相关TAG标签 排除法 故障 简介
上一篇:人体局域网-数据云技术
下一篇:PHPmyAdmin无法运行的解决方法
相关文章
图文推荐
文章
推荐
热门新闻

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站