Geek Style

I am not a linux guru, but if you are using linux as your network border router, you can block Nachi worm using netfilter (explained here).
But if you are running FreeBSD as your gateway, you should have IPFW2 (instead of standard ipfw in 4.x branch) in order to be able to filter 92 bytes ICMP packets.

pilot:~# ipfw add 50 deny icmp from any to any iplen 92
00050 deny icmp from any to any iplen 92

and then check if it works fine:

pilot:~# ipfw show
00050     10      920 deny icmp from any to any iplen 92
00100 300093 64940563 allow ip from any to any
65535      0        0 deny ip from any to any

So we caught 10 packets (920 bytes in total) after a short while.

iplen is only supported in IPFW2 which is enable by default in FreeBSD 5.x but you should enable it manually if you are using 4.x series.

ipfw man page explains more detailed information about new enhancements in ipfw2 and how to enable it in 4.x kernel:

ipfw2 is standard in FreeBSD CURRENT, whereas FreeBSD STABLE still uses ipfw1 unless the kernel is compiled with options IPFW2, and /sbin/ipfw and /usr/lib/libalias are recompiled with -DIPFW2 and reinstalled (the same effect can be achieved by adding IPFW2=TRUE to /etc/make.conf before a buildworld).

OpenBSD gurus may provide a solution to do the same using pf.

After implementing the Nachi filter (blocking 92 bytes ICMP packets) , you may have noticed that traceroute from your local network no internet stops on your edge router. This is because traceroute uses 96 bytes ICMP packets (including header) to probe hosts, so filter drops the ICMP packets.
I have no solution for windows tracert command since it does not support altering ICMP packet size, and you should use third-party traceroute utilities that support changing ICMP packet size (i.e. PingPlotter). But in *nix workstation, the ICMP packet size in traceroute command is configurable. Choose a smaller packet size to bypass the filter.

Worms are hot topic of day. Blaster and Nachi are making trouble for ISPs as well as end users worldwide.
There are diffrent ways to combat these worms. If you are a network administrator utilizing Cisco gear in your network, you can reduce the effect of these worms using some simple tricks. I have already posted an article on blocking Blaster worm in a cisco router.
But blocking Nachi is a little bit tricky since it uses ICMP echo/reply to map your network and propagate its code. This will cause a heavy ICMP storm in your netowork (that you may have already noticed). The most simple way is blocking all ICMP traffic which is not a good solution and harms your customers (They won’t be able to do PING measurement in this case).

Here is what I did to protect against Nachi (in a Cisco router):

Setup your NULL0 interface like this:

!
interface Null0
no ip unreachables
!

Then make an access-list that matches ICMP echo/reply packets:

!
ip access-list extended nachi-list
permit icmp any any echo
permit icmp any any echo-reply
!

Now the trick:

!
route-map nachi permit 10
match ip address nachi-list
match length 92 92
set interface Null0
!

Fortunately, Nachi uses fixed size ICMP packets (92 bytes, including IP header) as reachability probe. Above route-map will forward all ICMP packets with size of 92 bytes to Null0 interface. Null0 will not return any unreachable code and just drops the packet.

You should put this route-map on your network interface, like this (necessary parts listed only):

!
interface FastEthernet0/0
description Connected to Local Network
ip route-cache policy
ip policy route-map nachi
!

That “ip route-cache policy” is very important because it asks the router to cache all policy-route information in order to reduce processor load. (CEF won’t be useful here).

This is the result after 5 minutes:

router#sh route-map nachi
route-map nachi, permit, sequence 10
Match clauses:
ip address (access-lists): nachi-list
length 92 92
Set clauses:
interface Null0
Policy routing matches: 190909 packets, 20236354 bytes

Congratulations! Your network is saved.