No Denying It

Generally a DoS attack will focus on denying a system its network connectivity or bandwidth. This can be accomplished in a variety of ways. You may recall a recent train wreck in Baltimore that took out a major fiber optic cable. The destruction of that cable disrupted Internet access in Baltimore and throughout the east coast. A DoS attack? No-but the end result was the same. When an external event affects the performance of a Web site, the owner needs to fix it regardless of whether the attacker was a train wreck…or a 13-year-old with a piece of illegal software.

Let's take a quick look at the different types of nasty-bad things that can happen to your Web servers. I'll use the list of what the Security and Networking Research Group at the Sandia National Laboratories and the CERT Coordination Center at Carnegie Mellon University call "unauthorized results"-the consequences of undeterred attacks on a network system.

- Increased access: an unauthorized access on a computer or network. In itself this is not damaging-in fact many an enlightened hacker has obtained unauthorized access to systems simply to prove that it can be done. Some even claim they are providing a useful service as they show the corporate world how their Web sites can be compromised! I don't know that I buy that rationale, and I know the justice system doesn't, but it does have a certain savoir-faire to it.

- Disclosure of information: dissemination of information to anyone who is not authorized to access that information. The primary target here is credit card information. Even though the credit card owner is ultimately not liable for unauthorized use, the damage in confidence in the site (and the enterprise) is immense. The possible legal liabilities for unintentional release of sensitive customer information are endless.

- Corruption of information: unauthorized alteration of data on a computer or network. We saw a massive example of this in the spring of2001 when the SADMIN/IISworm defaced thousands of Microsoft servers, much to the embarrassment of many of us.

- Theft of resources: unauthorized use of system resources. SMTP servers are commonly hacked to provide unauthorized mail forwarding or spam services. FTP sites may be hacked for distribution of illegally obtained software.

- Denial of service: intentional degradation or blocking of computer or network resource.

The first four items above can be effectively controlled with a proper security policy, properly configured Web server hardware, properly configured software, and reasonable vigilance. The reason we can protect against these attacks is that they all involve some entity-human and/or software-actually touching the hardware or software and effecting a compromise. Prevention consists of keeping the intruder off your boxes: a tangible goal you can pursue with specific actions.

But the final item, DoS, is difficult to control. A denial of service attack is designed to keep users off your servers, and that's an entirely different beast.

Let's look at some of the ways you can deny users access to a Web resource:

- Flood a Web server with so many "innocent" requests that all server resources are consumed responding to those requests, and legitimate users are blocked out;

- Flood a Web site with so many "innocent" requests that all bandwidth is used up by those requests and the resultant responses;

- Physically compromise system components;

- Disrupt network connectivity;

- Destroy or alter configuration files.

The first two attacks above can be accomplished using the same methods. Sophisticated equipment and software are not required to bombard a server with multiple continuous page requests. Software to coordinate distributed denial of service attacks is readily available on the Internet. This allows that 13-year-old hacker to bring corporate Webs to their knees.

What is a Distributed Denial of Service Attack?

A distributed denial of service (DDoS) attack uses many computers to launch a coordinated attack against one or more targets. One master computer uses "robot" software to find vulnerable computers, which can be hacked and then configured to run agent programs. Once that's in place, the agent software is triggered to launch a coordinated and distributed attack against the target Web server.

Thus the DDoS is launched from multiple servers whose system people don't realize that they're being used to perpetrate attacks. (I say "system people" rather than IT professionals because an IT professional would never leave a Web box open to an unsophisticated attack from a teenager.)

How do you protect against DDoS attacks? You can't. The very nature of the Internet makes it easy to transmit multiple distributed requests from anywhere at any time. The Internet is designed to route packets to their destination using any path available. It is designed to ensure delivery of traffic-not control it.

The best solution is for every server connected to the Net to be properly hardened and protected against unauthorized access. The chances of that happening are about as good as me winning the Powerball lottery without buying a ticket (a reasonable way to deal with the lottery, in my opinion).

The problem is compounded by the ready access to low-security computers on college campuses and many Third World countries. (I am not equating our ivory tower friends to Third World countries. I suspect the security in Azerbaijan is probably better than at most state universities.) Student types are probably more prone to hacking or pranking than most people, and they frequently have access to servers administered by other 20-year-olds. Put effective server security in place at educational institutions and Internet attacks will decrease significantly.

Fighting Back?

The only real way to control DDoS attacks is through cooperation between server users, ISPs, and governments. Internet service providers provide the best chance of nipping the problem, as they funnel through 100-megabit connections down to our T1s and thinner trunks. Malicious packets can, and should, be identified and filtered out at that level, because by the time those attacking packets hit a T1, they can be seriously degrading bandwidth. ISPs also have a responsibility to ensure that they are using the most efficient, secure, and up-to-date hardware and software.

A friend of mine runs a small Web farm and provides Internet services to friends and small businesses. A few weeks ago the Code Red II worm was busy making the nightly news as it re-launched itself in an effort to find vulnerable Web servers. My friend had hardened and protected his servers against almost any known threat.

Nevertheless, Code Red II slowed his sites to a crawl. It accomplished this by sending continuous requests to his servers (where they were denied access) but which compromised the router that his ISP forced him to use. The router manufacturer had issued a firmware update that corrected the problem, but the ISP was unable or unwilling to use the upgraded version. In fact, it claimed that it could not provide service for the upgraded routers. The result was a denial of service attack by a worm that wasn't even designed as such.

The only option left for my friend was to reboot his router every 20 minutes or hack the firmware to reconfigure and rename the affected ports. I will leave it to your imagination to decide which route he took. The point is that the problem would have been averted had the ISP supported the latest hardware and software. Universal cooperation and coordination are necessary to control unwanted Internet activity.

We are left with a few seemingly ineffective solutions. Talk to your ISP about security. Protect all your servers so they can't be used as agents to launch attacks themselves. And don't forget about your test servers: Those babies probably have weaker security and stranger configurations than your live boxes. Use commercial scanning software to be aware of unusual frequency or types of requests. Monitor system resources closely to determine unusual activity. Know your systems and know what to expect of them.

When I was an operations officer in the U.S. Navy, it was not unusual to see engineering officers responsible for the nuclear reactors on submarines to literally sleep on top of the reactor so that nothing happened to that "box" without their knowledge. I suspect that this was largely the result of the paranoia among nuclear types fostered by their sometimes bizarre mentor, Admiral Hyman Rickover, but the lesson is clear: Know your systems and you stand a much better chance of keeping them running as designed.