| |
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应用到校内各虚网的接口上。这时使用再“system show cpu-utilization”查看CPU的使用率，它又恢复到正常状态，等待了一段时间后，再没有出现重启现象。
由于路由器不能自动丢弃这种病毒发出的攻击数据包，而导致了路由器重启。为了彻底解决问题，还得升级路由器的IOS（可以使用“system show version”来查看当前使用的IOS的版本）。记得两年前在“红色代码”病毒盛行的时候，也出现过路由器因过载而不断重启的现象，升级IOS以后就恢复正常了。于是立刻和设备供应商取得联系并获得最新的IOS映像文件。至此，路由器故障全部解决。
从这场故障处理中，我们可以得到这样的教训：时刻关注网络上事态的发展，并作出相应的解决方案，而且付诸实施。教育网用户可以在http://www.ccert.edu.cn网站上订阅安全公告服务，一旦有新的漏洞出现，CCERT安全响应小组会自动发送邮件给你。当时暑假期间得知“冲击波”后，由于及时在路由器上做了设置，所以“冲击波”病毒没有在网内泛滥，但随后的“冲击波杀手”没有及时设置相应的ACL，所以才导致这次的网络瘫痪。实际上，在这次的“冲击波”和“冲击波杀手”的袭击中，很多城域网也因此陷入瘫痪。这些经历一次又一次的警告我们：时刻关注网络安全，及时积极的应对。
故障二：ICMP Redirect
这是个什么问题呢？首先给大家描述一下。虽然路由器在运行时没有出现明显的异常现象，但是却经常看到这样的日志： |
|
|
| 【收藏】【打印】【进入论坛】 |
|
|
|
|
| |
|
|
|
