病毒路由器故障 路由器过载解决方案，病毒路由器故障是一个很普通的问题，但我们如何对病毒路由器故障进行更精确的解决，给我们的使用到来方便呢？
此次故障发生地的拓扑结构是这样的：使用一台EnterasysSSR8000作为边界路由器，同时也用它把校园内部划分为8个虚网，每个虚网各有一个堆叠的二层交换机作为台式机和笔记本的接入设备，主干为千兆，百兆到桌面。
那天，我接到一个同事的求助电话，说他的机器不能上网了。这个同事的主机所在的虚网和网络中心不在同一个虚网中。听同事介绍说5分钟前还好的（能够上网），现在不知道为什么就不好上网了。而且他的机器（安装的系统为WindowsXP）最近没有安装什么新的程序，没有移动过电脑，也没有拔过网线。
首先，排查网络客户端的错误配置。进入MSDOS方式使用IPCONFIG命令检查主机的IP地址配置：上面显示的配置是正确的，然后ping自己的IP地址这说明IP地址是生效的，网卡工作正常。再使用PING命令，测试从本机到网关的连接情况：
从主机向网关发送的数据包，全部都得到了回应，线路是连通的。打开浏览器，也能够正常上网，一点儿都没问题。现在的网络是正常的！？正在怀疑的时候，发现网络又不通了！发现ping出的数据包未能到达网关。
奇怪，刚才还好的，怎么现在又不通了呢？难道是网卡或者系统有问题？谁知过了一会儿，发现又通了。幸亏那天带了笔记本，于是我把台式机上的网线插到我的电脑上，配置好IP地址后ping网关，也出现时断时续的情况。
断开的现象大概持续了50秒钟，然后又恢复正常。这回可以基本排除主机的问题了，因为两台不相干主机同时出现同样此类问题的几率几乎为零。鉴于此现象，我首先排除了连接线缆的病毒路由器故障，因为连接的线缆不可能出现这种时断时续的情况，病毒路由器故障最有可能会出在线缆的另一端——二层交换机上。
于是来到这栋楼的设备间，查看交换机的状态，这是一个由两台交换机的堆叠，其中一台交换机上有一个上联的千兆端口。我把笔记本接到交换机的其中一个端口上，再ping网关。还是同样的病毒路由器故障，而且还发现每过4分钟到10分钟，网络就会断一次，并且40到50秒后又恢复正常。
经过观察发现：没有发现端口指示灯的异常情况，说明交换机的各个端口均正常。难道真是交换机的内部系统出现故障了？算了，索性把交换机重启一下。谁知重启后，病毒路由器故障依旧。可能交换机真的出了问题，我正想是否要把堆叠模块换到另外一个交换机上的时候，我的手机响了，又一个同事告诉我他的机器也出现相同的故障现象。
而这个同事的主机在另外一个虚网中，同时出现相同的时通时断情况，那极有可能是连接这两个虚网的路由器出了问题。这回问题集中到路由器上了。我急忙回到网络中心，从路由器的外部指示灯上看，没什么异常现象。在我的网管机上ping路由器的地址（我的网管机是直接连在路由器的百兆模块上的），也是时通时断。
我又继续观察了一段时间，发现每过4分钟到10分钟，路由器所有模块的指示灯都会同时熄灭，接着控制模块上的“HBT”灯闪烁，然后“OK”灯亮起，最后所有模块的指示灯均显示Online。
我解释一下，“HBT”灯闪烁表示路由器正在启动，也就是说正在自动重启，而且40秒左右的网络断开时间正好是路由器的重启所需的时间。现在问题的查找工作已经结束，肯定是路由器出了病毒路由器故障。具体是什么问题，还需要进一步的检测。
趁着路由器正常工作的时候，把笔记本的COM口使用路由器的专用CONSOLE线连接起来，建立超级终端。在管理模式下使用命令“system show bootlog”查看系统的启动记录，发现各个模块的加载均属正常。造成路由器重启的原因，最大的可能就是CPU的利用率达到100％。使用“system show cpu-utilization”命令查看CPU的使用率：
果然，连续使用此命令后得知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配置如下：
最后再把deny-virus这个ACL应用到上联接口（uplink）上：这样就可以把“冲击波杀手”从网络的出口处堵截住。为了防止已经感染“冲击波杀手”的主机在校内各个虚网之间传播，还得把这个ACL应用到校内各虚网的接口上。这时使用再“system show cpu-utilization”查看CPU的使用率，它又恢复到正常状态，等待了一段时间后，再没有出现重启现象。
由于路由器不能自动丢弃这种病毒发出的攻击数据包，而导致了路由器重启。为了彻底解决问题，还得升级路由器的IOS（可以使用“system show version”来查看当前使用的IOS的版本）。记得两年前在“红色代码”病毒盛行的时候，也出现过路由器因过载而不断重启的现象，升级IOS以后就恢复正常了。于是立刻和设备供应商取得联系并获得最新的IOS映像文件。至此，病毒路由器故障全部解决。
从这场故障处理中，我们可以得到这样的教训：时刻关注网络上事态的发展，并作出相应的解决方案，而且付诸实施。教育网用户可以在http://www.ccert.edu.cn网站上订阅安全公告服务，一旦有新的漏洞出现，CCERT安全响应小组会自动发送邮件给你。
当时暑假期间得知“冲击波”后，由于及时在路由器上做了设置，所以“冲击波”病毒没有在网内泛滥，但随后的“冲击波杀手”没有及时设置相应的ACL，所以才导致这次的网络瘫痪。实际上，在这次的“冲击波”和“冲击波杀手”的袭击中，很多城域网也因此陷入瘫痪。这些经历一次又一次的警告我们：时刻关注网络安全，及时积极的应对。
