症 状

    如果想了解受感染的Microsoft主机的症状，请查看Microsoft的公告牌：

http://www.microsoft.com/technet/security/virus/alerts/nachi.asp。

    受感染后，整个网络表现为流量增加，防火墙、路由器和交换机的负担加重，内存分配错误增多，网络稳定性降低。这种蠕虫产生的流量很大。

    未知网络故障的原因可能是用过于普通的过滤器过滤或阻挡合法服务，如果路由器或IP电话等设备无法启动，请检查它是否仍然能够接入TFTP服务器。这些设备一般不易感染Nachi蠕虫，但启动后加载软件或配置文件时将依赖开放式TFTP功能。

    在Microsoft操作系统上运行的产品较好从Microsoft加载补丁：

http://www.microsoft.com/technet/security/bulletin/MS03.026.asp

http://www.microsoft.com/technet/security/bulletin/MS03.007.asp

    开发出来的产品 

    本节将重点介绍利用网络中现有的思科产品抵御Nachi蠕虫的方法。如果确信不会影响现有网络的功能，这些技术应该在网段的接入边缘使用。由于受感染的系统仍然能够在一定的网络范围内传播，因此，最好根据Microsoft的建议为受感染的服务器打补丁。

    虽然这些例子都是说明怎样阻挡所有受感染端口的，但这种做法并不是必需的。Nachi蠕虫将首先发送ICMP 8型消息，检查主机的可到达性。如果ICMP 8型包被滤掉，蠕虫将不再尝试着感染主机。如果网络内的主机都未受感染，可以只阻挡网络边缘的ICMP 8型端口和端口135，这样会防止从网络外被感染，而且不会妨碍正常服务。利用NetFlow识别网络上的正常流量将有助于减小这些病毒抵御技术对正常操作的影响。

    如果想了解预防分布式拒绝服务袭击的一般方法，请访问：

http://www.cisco.com/warp/public/707/newsflash.html

    小心：无论要改变网络中的哪种配置，都应该先评估这种配置变化的影响。

    启用思科快速转发（CEF）

    为减小Nachi蠕虫的影响，最好启用CEF。如果没有启用CEF，为生成快速交换项，到达每个目的地的第一个分组将交换流程。这种方式不但会降低路由器的性能，还会将许多分组交换到随机目的地。

    启用CEF有助于减轻CPU的负担，避免出现内存分配错误，从而使Nachi蠕虫无机可乘。

    基于策略的IOS路由

    Nachi蠕虫检测节点是否可用的方法是先发送ICMP 8型（回声请求）包，然后利用RPC漏洞。ICMP包的大小为92字节，包括IP标头。

    下列基于策略的路由（PBR）配置可用于匹配和丢弃92字节长的ICMP 8型和0型包。ICMP 8型包由其它操作系统上的ping实用程序产生，例如Cisco IOS、Windows 2000、Linux和Solaris，其大小不是92字节。这种配置不应该滤掉由这些操作系统上的ping实用程序产生的分组。

    小心：应用之后，这种配置可能会引起所有分组在硬件上发生流程交换。

    这些平台可能不支持Catalyst 6500系列、Cisco 12000GSR或PBR，从而大大影响这些设备的性能，因此，我们建议您最好别在硬件交换平台上使用这种方法。

    小心：启动基于策略的路由可能会影响吞吐量，为改善性能，最好启用思科快速转发（CEF）。如果路由器上未启用CEF，最好在接口上执行“IP route.cache policy”命令，这样可以提高基于策略的路由的性能。

    小心：Microsoft Windows tracert实用程序使用92字节长的ICMP分组。利用PBR过滤这些分组将使tracert实用程序无法工作。

    小心：如果使用低于12.0（22）S、12.1（2）T或12.1（2）的IOS程序，请参考以下DDTS：CSCdp83614（只限注册用户使用）。版本低于上述版本的用户应该使用106字节长（92字节的IP标头加上14字节的MAC帧）而不是92字节的分组。

    access.list 199 permit icmp any any echo
    access.list 199 permit icmp any any echo.reply
    route.map nachi.worm permit 10
    ! ... match ICMP echo requests and replies (type 0 & 8)
    match ip address 199
    ! ... match 92 bytes sized packets
    match length 92 92
    ! ... drop the packet
    set interface Null0
    interface <incoming.interface>
    ! ... it is recommended to disable unreachables
    no ip unreachables
    ! ... if not using CEF, enabling ip route.cache flow is recommended
    ip route.cache policy
    ! ... apply Policy Based Routing to the interface
    ip policy route.map nachi.worm

    这种配置应该应用到设备的所有进入接口上。如果内部没有受感染的主机，也可以只应用到网络边缘。

    注意：启用这种配置后，也可能会丢弃某些92字节长的合法ICMP 8型（回声请求）分组

    蠕虫将尝试着将分组发送到随机IP地址，但某些地址可能并不存在。发生这种情况时，路由器将向路由器回复ICMP unreachable分组。某些情况下，向无效IP地址答复大量请求可能会降低路由器的性能。为防止出现这种情况，可以使用以下命令：

    Router(config)# interface <interface>
    Router(if.config)# no ip unreachables

    小心：普通网络配置，例如某些类型的通道结构，需要使用“ip unreachables”。如果路由器必须能够发送“ICMP unreachable”分组，可以用以下命令通过速率限制答复的数量：

    Router(config)# ip icmp rate.limit unreachable <millisecond>

    从Cisco IOS Software 12.0开始，默认速率设置为每秒两个分组（500ms），通常使用2000ms。

    模块化服务质量命令行界面

    小心：Microsoft Windows tracert实用程序使用92字节长的ICMP分组。使用MQC滤掉这些分组将使tracert实用程序无法工作。

    Nachi蠕虫检测节点是否可用的方法是先发送ICMP 8型（回声请求）分组，然后试着利用RPC漏洞。ICMP分组的长度为92字节，包括IP标头。

    以下模块化服务质量命令行界面（MQC）配置可用于匹配和丢弃92字节长的ICMP 8型和0型分组。ICMP 8型分组由其它操作系统上的ping实用程序产生，例如Cisco IOS、Windows 2000、Linux和Solaris，其大小不是92字节。这种配置不应该滤掉由这些操作系统上的ping实用程序产生的分组。

    access.list 199 permit icmp any any echo
    access.list 199 permit icmp any any echo.reply
    class.map match.all nachi
    match access.group 199
    match packet length min 92 max 92
    policy.map drop.nachi
    class nachi
    drop
    interface <interface>
    service.policy input drop.nachi
    service.policy output drop.nachi