病毒引起路由器过载故障解决方法

病毒引起路由器过载故障解决方法

　　一天，接到一个同事的求助电话，说他的机器不能上网了。这个同事的主机所在的虚网和网络中心不在同一个虚网中。同事介绍说5分钟前还是好的(能够上网)，现在不知道为什么就不能上网了。而且他的机器(安装的系统为Windows XP)最近没有安装什么新的程序，没有移动过电脑，也没有拔过网线。

　　首先，排查网络客户端的错误配置。进入MSDOS方式使用IPCONFIG命令检查主机的IP地址配置：

 C:> ping 210.16.2.30
Reply from 210.16.2.30: bytes=32 time<1ms TTL=128
Reply from 210.16.2.30: bytes=32 time<1ms TTL=128

　　再使用Ping命令，测试从本机到网关的连接情况：

C:> ping 210.16.2.1 –t
Reply from 210.16.2.1: bytes=32 time<1ms TTL=128
Reply from 210.16.2.1: bytes=32 time<1ms TTL=128

　　这回问题集中到路由器上了。急忙回到网络中心，从路由器的外部指示灯上看，没什么异常现象。在网管机上Ping路由器的地址(网管机是直接连在路由器的百兆模块上的)，也是时通时断。又继续观察了一段时间，发现每过4～10分钟，路由器所有模块的指示灯都会同时熄灭，接着控制模块上的“HBT”灯闪烁，然后“OK”灯亮起，最后所有模块的指示灯均显示Online。“HBT”灯闪烁表示路由器正在启动，也就是说正在自动重启，而且40秒左右的网络断开时间正好是路由器的重启所需的时间。现在问题的查找工作已经结束，肯定是路由器出了故障。具体是什么问题，还需要进一步的检测。

　　在路由器正常工作的时候，把笔记本电脑的COM口使用路由器的专用CONSOLE线连接起来，建立超级终端。在管理模式下使用命令“system show bootlog”查看系统的启动记录，发现各个模块的加载均属正常。造成路由器重启的原因，最大的可能就是CPU的利用率达到100%。使用“system show cpu-utilization”命令查看CPU的使用率：

　　SSR# system show cpu-utilization

　　CPU Utilization (5 seconds): 50%(60 seconds): 60%(前者是指5秒钟内CPU平均使用率为50%，后者是60秒钟内CPU平均使用率为60%。)

　　果然，连续使用此命令后得知CPU利用率正在逐渐上升，当达到95%的时候路由器便自动重启。看来路由器的负载太大了，因为平时正常情况下，CPU的使用率仅为1%～6%左右。当网络使用高峰期的时候CPU的利用率会稍微高一点。但到底是什么让路由器过载呢?幸好以前曾经给路由器设置过日志记录，并把日志发送到一个日志服务器上。但是打开这台服务器所记录的日志并未能找到有用的线索。因为当路由器负载过大时，它已经不能往日志服务器上发送日志了，只能用“system show syslog buffer”命令来查看当前系统缓存中的日志记录：

　　很明显，“210.16.3.82”这台在使用ICMP协议向其他主机发起攻击。据此判断，这台主机要么是中毒，要么是被黑客利用了。鉴于当时的情况分析，可能是网络中存在中了“冲击波杀手”病毒的主机。该病毒使用类型为echo的ICMP报文来Ping根据自身算法得出的IP地址段，以此检测这些地址段中存活的主机，并发送大量载荷为“aa”，填充长度92字节的icmp报文，从而导致网络堵塞。而且病毒一旦发现存活的主机，便试图使用135端口的rpc漏洞和80端口的webdav漏洞进行溢出攻击。溢出成功后会监听69(TFTP专业端口，用于文件下载)端口和666～765(通常是707端口)范围中的一个随机端口等待目标主机回连。

　　根据该病毒的传播机理，立刻在路由器上设置访问控制列表(ACL)，以阻塞UDP协议的69端口(用于文件下载)、TCP的端口135(微软的DCOM RPC端口)和ICMP协议(用于发现活动主机)。具体的ACL配置如下：

　　! --- block ICMP

　　acl deny-virus deny icmp any any

　　! --- block TFTP

　　acl deny-virus deny udp any any any 69

　　! --- block W32.Blaster related protocols

　　acl deny-virus deny tcp any any any 135

　　acl deny-virus permit tcp any any any any

　　acl deny-virus permit udp any any any any

　　最后再把deny-virus这个ACL应用到上连接口(uplink)上：

　　acl deny-virus apply interface uplink input output

　　这样就可以把“冲击波杀手”从网络的出口处堵截住。为了防止已经感染“冲击波杀手”的主机在校内各个虚网之间传播，还要把这个ACL应用到校内各虚网的接口上。这时使用并查看CPU的使用率，恢复到了正常状态，等待一段时间后，没有出现重启现象。

　　由于路由器不能自动丢弃这种病毒发出的攻击数据包，而导致了路由器重启。记得两年前在“红色代码”病毒盛行的时候，也出现过路由器因过载而不断重启的现象，升级IOS以后就恢复正常了。为了彻底解决问题，还应升级路由器的IOS(可以使用“system show version”来查看当前使用的IOS的版本)。与设备供应商取得联系并获得最新的IOS映像文件。至此，路由器故障全部解决。

　　从此例故障处理中，我们可以得到这样的教训：时刻关注网络上事态的发展，并做出相应的解决方案，而且付诸实施。教育网用户可以在http://www.ccert.edu.cn网站上订阅安全公告服务，一旦有新的漏洞出现，CCERT安全响应小组会自动发送邮件给用户。该例中由于当时暑假期间得知“冲击波”后，及时在路由器上做了设置，所以“冲击波”病毒没有在网内泛滥，但没有及时设置相应的ACL，随后的“冲击波杀手”导致了这次网络瘫痪。实际上，在这次“冲击波”和“冲击波杀手”的袭击中，很多城域网也因此陷入瘫痪。这些经历警告我们：时刻关注网络安全，及时积极地应对。

【病毒引起路由器过载故障解决方法】相关文章：

软件系统引起的路由器故障08-15

路由器故障及解决方法11-11

因冲突引起的网络故障解决方法11-12

网吧路由器接口故障的解决方法08-15

路由器物理故障08-20

内存引起故障的原因分析10-09

氧化引起的故障硬盘电极07-04

网卡引起的网络故障05-19

路由器故障解决思路08-18