Security /

Learning lessons from Code Red

By Joel Snyder
Network World, 09/10/01

Code Red is still going strong. At its peak, one of my company's Web servers saw about 13,000 Code Red attempts per day; last week, we saw about 6,000 per day. At this rate, it'll be months before Code Red goes away - it may never stop completely. What have we learned from this experience?

First, we learned that people don't read security bulletins - or if they do, they don't act on them. The vulnerability that Code Red exploits was announced by Microsoft on June 18, more than a month before Code Red hit. If we're still seeing thousands of attacks per day, a serious number of companies and people are not paying attention.

Microsoft has issued 45 security bulletins this year, more than one per week. System managers are numb from the overwhelming number of patches that need to be applied. Companies can't be expected to handle all of these manually; once patches have been approved, we need better automated tools to distribute them. Find those tools for your platforms and get them into place now. If you're running a data processing center, assign someone primary responsibility for watching for and evaluating security bulletins every day.

Second, we learned that Microsoft can't be trusted to patch its own software properly. Heavy-traffic Web servers with the correct patch might not be infected by Code Red, but they certainly have been affected. We have clients around the world complaining of instability caused by Code Red attacks. There's a fix out there, but it doesn't appear to be the universal solution.

This is where the open source people really have a leg up. If the official patch isn't solving your problem, at least you have the option of fixing it yourself - if you're running open source software. With Microsoft's Internet Information Server (IIS), the entire world is dependent on a relatively small team of people to fix any problem. If you're running IIS, maybe it's time to re-evaluate that decision. IIS is a great product, but there are other free Web servers that work, ones where you can get the source code and fix it if you absolutely have to.

Third, we learned that traditional firewalls don't help a bit here. If you open up a hole for the Web port on your Web server, then the firewall isn't defining your security perimeter; the Web server is. The question is how well you prepare, not just at the perimeter, but at every system for this kind of problem. There are dozens of tools out there to help protect individual systems, ranging from personal firewalls to kernel-level intercepts. Investigate your options and get some protection up.

Code Red continues to be a disaster. After you've patched your systems so they stop attacking mine, take a look around and see what you can learn.