最后再把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

　　这是个什么问题呢？首先给大家描述一下。虽然路由器在运行时没有出现明显的异常现象，但是却经常看到这样的日志：

     Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 219.157.38.52
Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 219.167.139.16
Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 61.132.1.43
Jul 09 15:54:23 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 24.232.18.109
Jul 09 15:54:23 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 211.146.112.211
…………………….

　　其中“209.24.79.200”是路由器的上联接口地址，我不知道为什么会出现这么多从路由器发到这些没有规律的IP的ICMP数据包。查查这些IP，有的来自国内各省，有的来自日本，有的来自美国、阿根廷、新加坡，毫无规律。难道是有人在攻击路由器？或者是内部有肉机被人用来攻击？而且奇怪的是只有出去的数据包的记录，却没有记录进入的数据包？
　　说起ICMP，大家肯定是熟悉不过的了。最常见的ping命令就是使用ICMP的。ICMP的全称是Internet Control Message Protocol（网间报文控制协议），它是IP不可分割的一部分，用来提供错误报告。一旦发现各种错误类型就将其返回原主机，基于ICMP的攻击方法也多种多样。到底是什么原因导致生成这样的日志？让我带大家一起来查一查。

　　我校的拓扑结构是一个简单的星型结构，中心节点就是一台三层交换式路由器（Enterasys 公司的SSR8000）。其中一个端口上联到CERNET，其他端口都是内部连接，且为内部网络基于端口划分了多个VLAN。为了查看该信息是否从网络内部发出，又给内部VLAN的各个接口设置了日志，还是没有相关的ICMP记录（原先的日志只是记录上联接口的数据）。排除了内部计算机发出ICMP数据包的可能，那问题就可能出现在上联接口上，而日志记录只能记录到协议层的信息，不能记录更深层次的数据包。如何查看上联接口的数据包呢，比较方便的方法就是使用端口镜像功能，利用连接在镜像端口上的计算机来抓取和分析数据包。

上一页  [1] [2] [3] [4] [5] [6] [7] [8]  下一页