- 相关推荐
病毒引起路由器过载故障解决方法
一天,接到一个同事的求助电话,说他的机器不能上网了。这个同事的主机所在的虚网和网络中心不在同一个虚网中。同事介绍说5分钟前还是好的(能够上网),现在不知道为什么就不能上网了。而且他的机器(安装的系统为Windows XP)最近没有安装什么新的程序,没有移动过电脑,也没有拔过网线。
首先,排查网络客户端的错误配置。进入MSDOS方式使用IPCONFIG命令检查主机的IP地址配置:
C:>ipconfig Windows IP Configuration Ethernet adapter 本地连接: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 210.16.2.30 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . 210.16.2.1 |
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”命令来查看当前系统缓存中的日志记录:
SSR# system show syslog buffer 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 210.55.37.72 2003-09-10 09:28:32 %ACL_LOG-I-PERMIT, ACL [out] on "uplink" ICMP 210.16.3.82 -> 61.136.65.13 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 202.227.100.65 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 193.210.224.202 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 218.32.21.101 |
很明显,“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-28
因冲突引起的网络故障解决方法08-18
CPU故障及解决方法07-30
电源引起的内存报警故障10-28
电源故障引起的电脑问题08-05
内存引起的故障有哪些10-19
氧化引起的故障硬盘电极10-16
内存引起故障的原因分析10-01
硬件故障的解决方法09-06
SATA硬盘故障的解决方法08-12