路由器一般故障到特殊故障的解决2

路由器一般故障到特殊故障的解决2内容摘要：

CPU 的利用率达到 100％。 使用 “system show cpuutilization” 命令查看 CPU 的使用率： C: ping – t Reply from : bytes=32 time1ms TTL=128 Reply from : bytes=32 time1ms TTL=128 „„ SSR system show cpuutilization 果然，连续使用此命令后得知 CPU 利用率正在逐渐上升，当达到 95％的时候路由器便自动重启。 看来路由器的负载太大了，因为平时正常情况下， CPU的使用率仅为 1％ — 6％左右。 当网络使用高峰期的时候 CPU 的利用率会稍微高一点。 但到底是什么让路由器过载呢。 幸好以前曾经给路由器设置过日志记录，并把日志发送到一个日志服务器上。 但是打开这台服务器所记录的日志并未能找到有用的线索。 因为当路由器负载过大时，它已经不能往日志服务器上发送日志了，我只能用 “system show syslo g buffer” 命令来查看当前系统缓存中的日志记录： 很明显， “” 这台在使用 ICMP 协议向其他主机发起攻击，据此判断，这台主机要么是中毒，要么是被黑客利用了。 鉴于当时的情况分析，可能是网络中存在中了 “ 冲击波杀手 ” 病毒的主机。 该病毒使用类型为 echo 的ICMP 报文来 ping 根据自身算法得出的 ip 地址段，以此检测这些地址段中存活的主机，并发送大量载荷为 “aa” ，填充长度 92字节的 icmp 报文，从而导致网络堵塞。 而且病毒一旦发现存活的主机，便试图 使用 135 端口的 rpc 漏洞和 80端口的 webdav 漏洞进行溢出攻击。 溢出成功后会监听 69（ TFTP 专业端口，用于文件下载）端口和 666765（通常是 707端口）范围中的一个随机端口等待目标主机回连。 根据该病毒的传播机理，立刻在路由器上设置访问控制列表（ ACL），以阻塞 UDP协议的 69 端口（用于文件下载）、 TCP 的端口 135（微软的 DCOM RPC 端口）和ICMP 协议（用于发现活动主机）。 具体的 ACL 配置如下： CPU Utilization (5 seconds): 50% (60 seconds): 60%（前者是指 5 秒钟内 C。