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

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

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

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

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

C:> ping  –tReply from : bytes=32 time<1ms TTL=128Reply from : 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”命令来查看当前系统缓存中的日志记录：

很明显，“”这台在使用ICMP协议向其他主机发起攻击。据此判断，这台主机要么是中毒，要么是被黑客利用了。鉴于当时的情况分析，可能是网络中存在中了“冲击波杀手”病毒的主机。该病毒使用类型为echo的ICMP报文来Ping根据自身算法得出的IP地址段，以此检测这些地址段中存活的主机，并发送大量载荷为“aa”，填充长度92字节的报文，从而导致网络堵塞。而且病毒一旦发现存活的主机，便试图使用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 ter 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映像文件。至此，路由器故障全部解决。

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