It’s been over six months since the September, 2001 release the Nimda worm and longer since Code Red chugged onto the scene. Considering the high press visibility, and readily available security patches, most assume these worms are all but eradicated. Although activity is significantly lower than the peak of the outbreak, these worms are very much alive--in fact they appear to be growing, not declining in numbers.
The number of Code Red infected host appears to be holding at around 15,000 as evidenced by the spike in unique source address during Code Red's hard-coded propagation window (the 1st - 19th day of each month). When Code Red's propagation efforts are dormant (the remaining days of the month) we can see that the number of unique addresses has increased from around 3,000 in early Feb 2002, to 6,000 by the end of March 2002--these are likely Nimda infected hosts which attempt to propagate every day of the month. This indicates that Code Red infections are persisting and Nimda infections are actually growing.
Though there are a lot of reasons why these worms continue to persist, I suspect the biggest reason is the case where a host behind a firewall becomes infected.
Nimda and Code Red propagate primarily by targeting IP addresses in similar ranges. Over 75% of the targeted IP addresses are similar to the infected host’s address, and less than 25% are randomly selected. For example, an infected host with an address of 24.128.1.1 will target hosts with addresses of 24.*.*.* and/or 24.128.*.*. The rationale is to distribute the propagation effort among as many hosts as possible and prevent overlapping efforts---this enables the worm to spread quickly throughout the entire Internet.
When an infected web server has a direct Internet connection (with a public IP address), most of the propagation attempts are directed at neighboring addresses—often the same address is targeted dozens or even hundreds of times a day. Due to the focused nature of this targeting method, it triggers firewall alarms at some neighboring addresses. Eventually infected users (or their ISP) are notified by a third party whose firewall has been barraged with propagation attempts. Nimda also infects web pages causing propagation attempts when users surf to the site…again triggering notifications to the site’s administrator.
Conversely, infected hosts which are indirectly Internet connected have a private IP address and access the Internet through a firewall’s or router's public address. This affects large organizations using corporate firewalls, and even a consumer Internet users with a cable modem or DSL routers (Linksys alone has sold several million of these).
Because the infected host has a private address, that also means that 75% of the targeted IP addresses will be similar private addresses. A small number of those may be other internal systems, but most targeted addresses are likely unassigned and unused. Thus, most of the propagation attempts target unused internal addresses and since few organizations monitor internal port scanning activity, it is often undetected.
The balance of targeted addresses are selected at random (most of which will be public addresses). So public hosts will still be probed, but the pattern is completely random instead of focused on similar addresses. This propagation pattern is much quieter…hardly ever connecting to any given IP address (or even several addresses in the same target organization) more than once over a period of days. This pattern is unlikely to raise alarms and trigger notification by third parties.
Even when activity is detected by a third party and the owner of the infected host is notified, the system owner often can’t locate the host. The reporting party can only identify that probes were sourced from the owner's firewall address. It’s up to the firewall owner to figure out which of the hundreds (or thousands) of hosts behind the firewall originated the activity. Many smaller and medium-sized organizations either don’t have firewalls that provide the level of logging required to perform this backtracking, or the feature isn't not enabled. So even if they get notified of a compromised host, they are at a loss of how to track it down.
Another important factor is that the infected server is often NOT a public web server, rather it is some server that the owner is staging or testing, or doesn’t even know they’re running a web server at all (e.g. DSL and cable modem user). Therefore, there’s no chance of users surfing to these servers and noticing that a web page is contaminated. Also, someone who receives a propagation attempt who then tries to connect to the server to identify its owner, will be blocked by the owner’s firewall.
So ironically, while firewalls provide a necessarily level of protection, they can have the unintended consequence of hiding the existence of compromised hosts.
Corporate User:
Take heed when someone reports that your firewall IP is spraying the Internet with port 80 probes....it could mean you are infected. You may need to enable additional firewall logging so that you can more easily back trace the source of this activity. A firewall is not a panacea, you need to monitor what is going on behind the firewall. Check your web server logs for Code Red and Nimda exploit requests which are sourced from *internal* addresses...this is probably the easiest way to identify infected hosts.
Home user:
Watch your cable, DSL, or analog modems activity lights every now and then---if they are blinking furiously even when you're not surfing, that is a major sign that you could be infected with a worm. Though the network address translation (NAT) functionality of popular cable/DSL routers provides great protection against inbound port scans, they provide ZERO protection against being infected by rogue email attachments or infected web pages...and once you are infected, NAT provides no protection against the worm flooding the net with *outbound* scans.
Supplement your NAT protection with a personal firewall (e.g. free version of Zone Alarm is a good choice) on EVERY computer on your local network. Make sure you have your browser security settings configured to prevent infections from normal surfing. And lastly, Run regular virus scans (with daily signature updates) for when your kids open up an attachment they shouldn't have....yeah, let's blame it on the kids.