Burned by the CodeRed Worm

We in the Windows & .NET Magazine Lab take security seriously. In the Lab, any successful breach of our network defenses destroys our ability to accurately test the products we review. Thus, we were concerned when we found that the CodeRed Worm had slithered into our network.

Generally, we use standard security practices in the Lab. To a great extent, we rely on the simple but effective practice of physically isolating our test networks. When a product we're testing requires Internet access or WAN links, we simulate these connections by using routers or special emulation software such as SHUNRA Software's The Cloud, which emulates WAN links. In these situations, we strive to custom-build test networks that are never physically exposed to outside threats. And even on these networks, we're careful to keep service packs and hotfixes up-to-date.

When products we test require Internet access, we use a network with an ISDN circuit and protect the network with a firewall that we lock down except for ports we temporarily open for testing. When we open a port, we use Network Address Translation (NAT) and filters to minimize our exposure. On our internal network, we manually update service packs, patches, and hotfixes for each host. This arrangement seemed adequate—we'd never recorded a successful attack on our network. However, a combination of human error and the extraordinary sophistication of the CodeRed Worm opened the door to an attack.

I was responsible for the error: I failed to delete a NAT external-to-internal IP address mapping that I'd created for a test. No internal host had the mapped IP address, so this oversight wasn't an immediate problem. But then we assigned that IP address to a new Windows 2000 server that was still vulnerable to a Microsoft IIS buffer overrun attack. You can predict the rest of the story: A CodeRed-infected IIS server on the Internet was attempting to connect to any responding IIS server on a list of randomly generated IP addresses, and it found and infected our exposed server. (If you're unfamiliar with the gory details of CodeRed, check out http://www.eeye.com/html/research/advisories/al20010717.html.) Like a zombie in a bad horror flick, our Win2K server then began probing for victims from its own list of random IP addresses. In no time, Web traffic clogged our ISDN circuit.

Besides this story's obvious moral of "Don't leave a big hole in your firewall, dummy," two other points bear mentioning. First, human errors are inevitable, especially when busy administrators wear several hats (e.g., network administrator, security administrator, Web master). A tool such as a vulnerability scanner can help offset the human factor by automatically checking your network and notifying you of configuration changes and known security threats. Second, don't rely entirely on perimeter security to protect your network. CodeRed wouldn't have infected our server if we'd applied the most recent patch. Hardening your internal network by maintaining service packs, patches, and hotfixes is good insurance. Unfortunately, it can also be a headache. Again, vendors offer tools to make this task easier—e-business technology's PoliVec Scanner is just one example of a product that can help keep your Windows hosts updated and securely configured.

End of Article