SECURITY ADVISER                           InfoWorld.com

Thursday, April 3, 2003

Network protection commentary by:           Wayne Rash



Posted March 28, 2003 12:00 AM Pacific Time

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.

main page ATTRITION feedback