The trouble within

I couldn't get an IP address. I knew that meant trouble because the Advanced Network Computing Laboratory at the University of Hawaii (http://ancl.ics.hawaii.edu), the newest addition to the labs of the InfoWorld Test Center, contains an industrial-strength, high-performance test enterprise network that is rarely bothered by something as simple as a dead DHCP server. Still, I couldn't get an IP address.

I was on the way to ask about this when, at the front door, I met Brian Chee, who runs the lab. "We have a denial-of-service attack going on right now," he said, anticipating my question. Sure enough, a glance at the network monitoring equipment showed clearly that our network utilization was approximately 90 percent. It wasn't surprising that I couldn't reach the DHCP server.

After a few minutes, it was clear that this would go on for a while. "I wonder where this is coming from," Chee said to himself. He started checking with a Fluke Networks (www.flukenetworks.com) OptiView Integrated Network Analyzer. In a matter of seconds he looked at me. "It's you," he said.

Actually, it wasn't me, personally — it was a server we received for testing. We had fired up the server to take a look at the management interface and, in our haste, hadn't bothered to set up a firewall for it. As a result, this server was out there, unprotected, on the Internet. In a matter of minutes, we had a nice case of the Slammer worm.

Because this was a test system, we immediately solved the problem by disconnecting the Ethernet cable and then powering down the server. Later, we were able to restore power and clean up the server.

Embarrassing? Of course. But it served to reinforce some lessons that are easy to forget. First of all, we had made no effort to examine the Windows 2000 Server software for updates to known vulnerabilities. We'd also made no effort to shut down unneeded services. And, of course, we'd made no effort to protect the server with a firewall. In other words, we did a couple of fairly stupid things, and we got caught.

We have plenty of excuses, of course. It's a review, and we can always redo the server. We don't put test servers on the real Internet. We don't need firewalls on the test networks we use. There are probably a lot more excuses. But the fact is, we weren't paying attention, and as fast as you can say "shazam," we got hit. Now we're pretending it was a learning experience, hence this column.

Fortunately, for you, it really can be a learning experience. Just because we're out here in the mid-Pacific doing things we shouldn't doesn't mean you must to make the same mistakes. Instead, create a procedure for bringing a new server online. Make a checklist that includes things such as installing the latest patches and checking that every possible feature and service is turned off unless you actually must have it for the server to do its job.

And whatever you do, don't connect to the unprotected Internet, or you could be your own worst enemy.