While many people understand how Access Control Lists (ACLs) work, ACLs can't look inside packets for bad data. A PIX can examine several applications for certain contents; but while it can check HTTP traffic for the presence of Java or Active X and filter the packets, there is no setting for worms. Intrusion detection equipment can be configured to look for packets that contain worms and, when detected, have a router filter the connection; however, in order for the IDS sensor to detect the worm, it has to get inside the network -- something we want to avoid.

This is where Network Based Application Recognition (NBAR) comes in. NBAR, first introduced in experimental versions of IOS v12.1, is a "classification engine" designed to analyze packets for Quality of Service purposes. It's an ideal solution for filtering worm packets, although you'll want to avoid code versions earlier than 12.1(5)T.

Implementing NBAR
The first thing you need to do is decide what type of traffic you want to deny. In the case of Code Red and Nimda, we want to prevent HTTP packets containing a URL. We don't want to filter every URL though, just incoming requests for certain URLs. To do this, filter requests for ".ida," "cmd.exe," "root.exe" and "readme.eml." You need to build all of this into a class map like so:

Router(config)#class-map match-any worms
Router(config-cmap)#match protocol http url "*.ida*"
Router(config-cmap)#match protocol http url "*cmd.exe*"
Router(config-cmap)#match protocol http url "*root.exe*"
Router(config-cmap)#match protocol http url "*readme.eml*"

Notice the asterisks before and after each of the strings we're looking for. By doing this, we can find the given string in the middle of other text.

Once we've figured out what we want to look for, we need to tell the router what to do with this traffic once it finds it -- i.e., create a policy map that will router very specific traffic to a given destination. We could route this traffic directly to null0, but I prefer to have some sort of indication that these requests are being made. In order to log this info, we need to be a bit trickier. The class "worms" is what we referenced above in the "class-map" configuration. The command "set ip dscp 1" sets a marker in the IP header to a value that isn't likely to be seen in most networks. I recommend that if your network has complex QoS that you use a DSCP number not in use. If you haven't implemented QoS then there's nothing to worry about.

Router(config)#policy-map worm-requests
Router(config-pmap)#class worms
Router(config-pmap)#set ip dscp 1

We'll configure an access list to log whenever we block the offending traffic. We want to deny any traffic that has the DSCP set to 1 and log that this was done.

Router(config)#access-list 100 deny ip any any dscp 1 log
Router(config)#access-list 100 permit ip any any

Finally, we need to paste the access list on interfaces we don't want the traffic leaving from.

Router(config)#interface ethernet 0/0
Router(config-if)#ip access-group 100 out

Note that you will need to enable Cisco Express Forwarding (CEF) in order to make use of NBAR.

Design Considerations
The design issues for this are simple: Implementing it will soak up a large amount of available processor time. If you are currently running at greater than 40 percent processor utilization, I recommend extreme caution. You may wish to place a router in your network just for the purpose of monitoring how much of a processing hit your perimeter router would take.