网络通信 频道

Nachi蠕虫-冲击波杀手抵御建议

    【IT168 安全频道】目前,一种新蠕虫正在互联网上肆虐,思科客户的网络上出现了来自内外系统的巨额流量。这种蠕虫引发的许多问题的根源都在于,网络上出现了大量92字节的ICMP 8型(回声请求)包。思科设备的症状包括(但不局限于)CPU使用率升高,输入接口上的流量减少。本文将重点介绍蠕虫抵御技术、用于抵御蠕虫的思科软件或Microsoft操作系统补丁。

    这种蠕虫被称为“Nachi”-冲击波杀手,它利用Microsoft以前发现的两个漏洞发动攻击。欲知详情,请访问:

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

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

    目前,有两种蠕虫瞄准了没有安装用于应付MS03-026的补丁的系统,它们是Nachi冲击波杀手和Blaster冲击波。本文将重点介绍抵御Nachi冲击波杀手的各种技术,其它文档将重点介绍抵御Blaster冲击波的各种技术,其网址为:

    点击查看网址

    这些文档的目的都是利用相关技术抵御各类蠕虫。

    详细情况

    如果想了解蠕虫的详细情况,请访问Microsoft的Web站点:

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

    抵御这种蠕虫的方法是,挡住它需要的协议和用于传播自己的端口,通过扫描寻找新的感染对象,然后传播可执行代码。本文将重点介绍内部网络受感染之前或之后应怎样阻挡蠕虫的传播。由于这种蠕虫利用合法协议和端口传播,因此,阻挡这些端口可能会影响正常功能,例如网络监控、文件共享或TFTP。无论您使用的是哪种网络配置,思科都建议您在操作正常时建立基线流量文档,并利用此文档决定是否阻挡端口或网络中的流量。为避免影响网络功能,阻挡端口时要特别谨慎。这些端口的简要正常使用说明如下。

    ICMP 8型协议也称作回声请求,人们熟知的“ping”实用程序用它执行连接测试和网络监控。阻挡这种协议可以防止蠕虫的传播,但会引发某些网络诊断问题。

    TCP端口135用于MS RPC协议,许多基于RPC的应用都使用这个端口提供Windows互联网名称服务(WINS)、DHCP服务器、终端等服务。这个端口是蠕虫通过MS03-026描述的MS RPC DCOM漏洞最初使用的漏洞,是完全感染整台机器的开始。阻挡端口135可以防止最初感染,但会中断网络中的其它正常功能。

    TCP端口80由超文本传输协议(HTTP)使用,主要使用者是Worldwide Web(WWW)服务器。Nachi蠕虫试图利用MS03-007描述的漏洞感染机器。阻挡端口80可以防止最初感染,但会中断基于Web的各种应用。

    蠕虫将TCP端口707 作为控制通道,各种命令通过这个通道从受感染的服务器下载名为svchost.exe 和dllhost.exe的文件。 阻挡端口707可以防止将命令传递到易损目标,使其无法下载蠕虫二进制文件,从而避免受到感染。

    UDP端口69由普通文件传输协议(TFTP)使用,通常用于向联网设备加载新软件图像或配置。感染了Nachi蠕虫的主机将打开这个端口,将svchost.exe和 dllhost.exe文件从受感染的机器传输到其它干净机器。挡住这个端口可以防止蠕虫从已经感染的机器传播到易损主机上,但会中断网络内的正常TFTP功能,包括某些IP语音功能。

    TCP和/或UDP端口137、138、139和593都有薄弱环节,很可能会使主机受到感染,但据目前所知,这还不是传播Nachi蠕虫的直接原因。思科建议,为防止被遥控,所有不需要的端口,尤其是自身有弱点的端口,都应该在边缘网络处挡住内外通路。

    检 测

    使用启用了NetFlow的IOS检测受感染的主机

    NetFlow可以找到受感染的主机。在接口上,NetFlow必须用ip route-cache flow命令启用。在下例中,受感染的主机使用ICMP 8型分组扫描IP地址空间。

    Router>show ip cache flow | include 0000 0800
    SrcIf   SrcIPaddress   DstIf  DstIPaddress   Pr  SrcP    DstP  Pkts
    Fa2/0  XX.XX.XX.242  Fa1/0  XX.XX.XX.119  01  0000   0800  1
    Fa2/0  XX.XX.XX.242  Fa1/0  XX.XX.XX.169  01  0000   0800  1
    Fa2/0  XX.XX.XX.204  Fa1/0  XX.XX.XX.63  01  0000   0800  1
    Fa2/0  XX.XX.XX.204  Fa1/0  XX.XX.XX.111  01  0000   0800  1
    Fa2/0  XX.XX.XX.204  Fa1/0  XX.XX.XX.95  01  0000   0800  1
    Fa2/0  XX.XX.XX.204  Fa1/0  XX.XX.XX.79  01  0000   0800  1

    注意:在输出中将列出通过路由器的所有ICMP 8型(回声)流量,而且并非所有ICMP流量都与蠕虫有关。受Nachi感染的主机将作为去往随机目的地的多股流量的源头显示。

    使用Catalyst 6500上的CatOS和IOS以及MLS检测受感染的主机

    MLS统计数据可以用于跟踪受感染的主机。如下例所示,为查看源端口和目标端口,应在全流中启用NetFlow。

    注意:并非输出中的所有ICMP流都与蠕虫相关。受Nachi感染的主机将作为去往随机目的地的多股流量的源头显示。

    在混合设备上:

    Router>(enable)set mls flow full
    Router>show mls statistics entry ip protocol icmp
    Last   Used
    Destination IP   Source IP   Prot  DstPrt  SrcPrt  Stat.Pkts   Stat.Bytes
    ................ ............... ..... ...... ...... ......... ...........
    XX.XX.XX.28  XX.XX.XX.10  ICMP  0   0   0     0
    XX.XX.XX.58  XX.XX.XX.28  ICMP  0   0   0     0
    XX.XX.XX.141  XX.XX.XX.223 ICMP  0   0   0     0
    XX.XX.XX.189  XX.XX.XX.1   ICMP  0   0   0     0
    XX.XX.XX.12  XX.XX.XX.19  ICMP  0   0   0     0
    XX.XX.XX.245  XX.XX.XX.137  ICMP  0   0   0     0
    XX.XX.XX.29  XX.XX.XX.22  ICMP  0   0   0     0

    在本地设备上:

    注意:这个命令将显示所有协议的流,读者需要寻找协议为ICMP的流。

    Router(config)# mls flow ip full
    Router> show mls ip
    Displaying Netflow entries in Supervisor Earl
    DstIP SrcIP Prot:SrcPort:DstPort Src i/f:AdjPtr
    ....................................................................
    Pkts Bytes Age LastSeen Attributes
    ...................................................
    XX.XX.XX.254 XX.XX.XX.14 icmp:0 :0 0 : 0
    0 0 821 16:05:30 L3 . Dynamic
    XX.XX.XX.254 XX.XX.XX.10 icmp:0 :0 0 : 0
    0 0 149 16:05:31 L3 . Dynamic
    XX.XX.XX.254 XX.XX.XX.25 icmp:0 :0 0 : 0
    0 0 817 16:05:32 L3 . Dynamic
    XX.XX.XX.254 XX.XX.XX.10 icmp:0 :0 0 : 0
    1040 58240 821 16:05:36 L3 . Dynamic
    XX.XX.XX.254 XX.XX.XX.10 icmp:0 :0 0 : 0
    0 0 821 16:05:33 L3 . Dynamic

    CSIDS签名

    如果使用了思科安全入侵检测系统,注册客户就可以在以下位置利用签名更新文件:
    • For Version 4.x_http://www.cisco.com/cgi.bin/tablebuild.pl/ids4 (只限注册客户使用)
    • For Version 3.x_http://www.cisco.com/cgi.bin/tablebuild.pl/ids3.app(只限注册客户使用)

    Cisco Secure IDS Signature 3327可以检测对MS03-026的利用企图。

    为降低虚警率,应将签名3327设置为只检测端口135,而不检测139或445。

    为对付这种蠕虫,还可以添加定制签名字串。

    简要指令如下:
    Engine STRING.UDP
    SigName MS Blast Worm TFTP Request
    ServicePorts 69
    RegexString \x00\x01[Mm][Ss][Bb][Ll][Aa][Ss][Tt][.][Ee][Xx][Ee]\x00
    Direction ToService

    Cisco Secure IDS Signature 5364可以检测对MS03-007的利用企图。

    为对付这种蠕虫,还可以添加定制签名字串。

    简要指令如下:
    Signature Name = IIS WebDAV Overflow
    Engine = SERVICE.HTTP
    AlarmThrottle = FireOnce
    DeObfuscate = True
    Direction = ToService
    HeaderRegex = [Tt][Rr][Aa][Nn][Ss][Ll][Aa][Tt][Ee][:][ \t][Ff]
    MaxUriFieldLength = 65000
    MinHits = 1
    ResetAfterIdle = 15
    ThrottleInterval = 15

    症 状

    如果想了解受感染的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

    为IOS开发的ACL

    除特别声明以外,这种产品适用于多数路由器平台。

    注意:如果想跟踪源地址,应使用Sampled NetFlow,而不是ACL中的“log”语句,因为高流量与log语句可能会压垮路由器。

    如果ICMP分组没有象上述情况那样被基于策略的路由功能滤除,可以利用访问表挡住ICMP分组。请注意,ICMP分组会使广为使用的ping实用程序及其它类似的诊断工具无法正常工作。

    ! ... block ICMP
    ! ...
    ! ... you do not need to deny ICMP packets if you already filter
    ! ... them by using PBR
    ! ...
    ! ... blocking ICMP packets with access lists will cause ping utility and
    ! ... other similar diagnostic tools not to work
    access.list 115 deny icmp any any echo
    access.list 115 deny icmp any any echo.reply
    ! ... block vulnerable protocols
    ! ... Nachi related
    access.list 115 deny tcp any any eq 135
    access.list 115 deny udp any any eq 135
    ! ... block TFTP
    access.list 115 deny udp any any eq 69
    ! ... block other vulnerable MS protocols
    access.list 115 deny udp any any eq 137
    access.list 115 deny udp any any eq 138
    access.list 115 deny tcp any any eq 139
    access.list 115 deny udp any any eq 139
    access.list 115 deny tcp any any eq 445
    access.list 115 deny tcp any any eq 593
    ! ... Allow all other traffic .. insert
    ! ... other existing access list entries here
    access.list 115 permit ip any any
    interface <interface>
    ip access.group 115 in
    ip access.group 115 out

    蠕虫将尝试着将分组送至随机IP地址,但某些地址并不存在。发生这种情况时,路由器将回复以“ICMP unreachalbe”分组。某些情况下,对大量无效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。

    Cisco 12000

    接收ACL特性――在Cisco 12000(GSR)系列路由器上,去往路由器ip地址的包将“前往”千兆位路由处理器(GRP)接受处理。为保护GRP,可以使用rACL。rACL将对去往GRP的流量进行过滤,只有经过批准的流量才能由GRP处理,未通过批准的流量将被丢弃。一般情况下,rACL不影响经过路由器的流量,而只影响去往路由器本身的流量,从而保护GRP不会由于流量过大无法工作。

    rACL能够有效减少去往GRP的大量攻击流量的影响。欲知详情,请参考:GSR:接收访问控制表。

    6500上的VACL

    思科建议在Cisco Catalyst 4000上使用IOS ACL,并使用Cisco Catalyst 6500的Sup3、Hybrid和Native配置。为方便用户使用,我们提供了VACL配置实例。另外,我们还建议用户使用“no ip unreachables”。

    小心:与修改配置相同,组合使用VACL和IOS ACL时也要谨慎。要注意,VACL适用于VLAN内各方向的所有流量。

    配置:

    ! ... block ICMP
    set security acl ip NACHI deny icmp any any echo
    set security acl ip NACHI deny icmp any any echo.reply
    ! ... block vulnerable protocols
    ! ... Nachi related
    set security acl ip NACHI deny tcp any any eq 135
    set security acl ip NACHI deny udp any any eq 135
    set security acl ip NACHI deny udp any any eq 69
    ! ... block worm control channels
    set security acl ip NACHI deny tcp any any eq 4444
    set security acl ip NACHI deny tcp any any eq 707
    ! ... Non.Nachi related
    set security acl ip NACHI deny tcp any any eq 137
    set security acl ip NACHI deny udp any any eq 137
    set security acl ip NACHI deny tcp any any eq 138
    set security acl ip NACHI deny udp any any eq 138
    set security acl ip NACHI deny tcp any any eq 139
    set security acl ip NACHI deny udp any any eq 139
    set security acl ip NACHI deny tcp any any eq 445
    set security acl ip NACHI deny tcp any any eq 593
    ! ... Allow all other traffic
    ! ... insert other existing access list entries here
    set security acl ip NACHI permit any any
    ! .. applies both inbound and outbound
    commit security acl NACHI
    set security acl map NACHI <vlans>

    核查:

    show security acl info all

    删除:

    clear security acl BLASTER
    commit security acl BLASTER

    Catalyst 3550

    将IOS ACL应用于属于VLAN第3层接口的交换机虚拟接口(SVI)、物理第3层接口以及出入方向上的第3层EtherChannel接口上,保证接口上配置了“no ip unreachable”。

    只有IOS ACL也没有应用于第3层接口的输入时(否则将产生错误信息),才应在交换机的第2层接口应用IOS ACL。对于第2层接口,只有物理接口支持IOS ACL,EtherChannel接口不提供支持。它只能应用到向内的方向上。

    Catalyst 2950

    将IOS ACL应用到接口上。注意,ACL只在向内方向上支持。为将ACL应用到物理接口,必须安装增强软件图像(EI)。

    Catalyst 2900XL和3500XL

    它们属于不支持第3层访问表的第2层交换机。

    PIX

    PIX的默认行为是阻挡流量从安全等级较低的接口(外部)进入安全等级较高的接口(内部),除非访问表或管线明确允许受感染的端口和协议通过。

    另外,思科还建议阻止流量从安全等级较高的接口(内部)传输到安全等级较低的接口(外部)。

    客户应拒绝通过这些端口外出:

    access.list acl_inside deny icmp any any echo
    access.list acl_inside deny icmp any any echo.reply
    access.list acl_inside deny tcp any any eq 135
    access.list acl_inside deny udp any any eq 135
    access.list acl_inside deny udp any any eq 69
    access.list acl_inside deny tcp any any eq 137
    access.list acl_inside deny udp any any eq 137
    access.list acl_inside deny tcp any any eq 138
    access.list acl_inside deny udp any any eq 138
    access.list acl_inside deny tcp any any eq 139
    access.list acl_inside deny udp any any eq 139
    access.list acl_inside deny tcp any any eq 445
    access.list acl_inside deny tcp any any eq 593
    ! ... insert previously configured acl statements here,
    ! ... or permit all other traffic out
    access.list acl_inside permit ip any any
    access.group acl_inside in interface inside

    虽然可以使用相应的外出表,但最好用ACL替代外出表。

    思科安全代理(CSA)

    利用CSA内的台式机和默认服务器策略可以自动成功地消除这种漏洞/蠕虫。

    讨论与公开宣布  

    这个问题已得到广泛关注,并已经过多次公开讨论,参考网站如下:

 http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.html

 http://vil.nai.com/vil/content/v_100559.htm

0
相关文章