Distributed Denial-of-Service Attacks and You

The more technical term for a zombie attack is a distributed denial-of-service (DDoS) attack. This sounds like an intimidating term, but it's actually pretty simple. Let's start with the "denial of service" part. Imagine that your town's emergency response center only had one phone line, and that a prankster kept calling it and hanging up. During the time the phone line was in use, no one else could report a legitimate emergency. That's denial of service.

Of course, this would not be a recommended way to design an emergency service, so it's safe to assume that even small towns have several inbound lines. Let's say you live in a mid-size town that has 100 inbound 911 lines. What would happen if a coordinated gang of 120 bad actors went to pay phones and simultaneously called 911. The call center would be flooded, and legitimate inbound calls wouldn't be able to get through. Unlike the earlier attack, though, it's harder to prevent coordinated action from many people at once, especially if you don't know who or where they are. That's where the "distributed" in DDoS comes from.

What does this have to do with zombies? Simple. Imagine that you're a malicious attacker who can trick someone into running a program of your choice. That program can lie dormant, like a monster-movie zombie, until you send it a signal; at that point, it can begin generating network traffic sent to a particular target. If you can recruit enough zombies, you can flood even very large services like Yahoo! or CNN, for example.

Top of page

This may seem counterintuitive at firsthow can a few individual systems tie up a behemoth like CNN? The answer is twofold: scale and bandwidth. Let's say you can get 500 machines, each of which is on a garden-variety DSL line, to attack a single host. A typical DSL line allows 256Kb/s of upstream bandwidth, so let's conservatively say that the 500 machines can generate 500 * 128Kb/s = 64000 Kb/s = 62.5 Mb/s. As it turns out, this is roughly the size of 42 T1 lines, or about 1.4 T3 linesa considerable amount of bandwidth. If the target only has a single T1 (or even only a dozen), it's toast. Of course, varying the number of hosts and their average bandwidth changes the traffic volume that can be brought to bear, but the important point is that a moderate number of independent systems, acting together, can easily flood even very large networks. There are other tricks that can be used to increase the effectiveness of these attacks, but you don't have to understand them to protect yourself. (If you do want more details, SANS maintains an excellent summary of attack methods.)

Top of page

I mentioned earlier that DDoS attacks depend on getting the DDoS client to run on a wide range of machines. The usual trick is to package it as a " Trojan horse", an innocuous-looking but secretly malicious program that unsuspecting people will run. The key word is "unsuspecting". Many computer users don't think twice about running executable programs or attachments that they get from unknown sources, especially if they think that the program they've downloaded will give them something (like free porn or lottery winnings) for nothing. For example, I know of one DDoS attacker who would pose in AOL chat rooms as a teenage girl, offering self-running slide shows of "herself" to people who chatted with her. Of course, the "slide show" was actually a disguised Trojan; over time, this attacker was able to bag a large number of DDoS clients to do his bidding. Of course, someone who's trying to build an arsenal of DDoS clients doesn't want to waste time sending Trojans to well-educated security professionals; better to send them to people who will run the malicious code without a second thought, especially if they aren't likely to notice that their machine is infected.

Once a Trojan is activated, one of the first things it typically does is register its presence somewhere, usually by sending TCP/IP packets to a well-known destination. The popular SubSeven Trojan registers itself by sending messages to an attacker-selected IRC channel. These registration messages usually indicate the IP address of the zombied machine, and it may include some useful information like the apparent bandwidth between the zombie and a preselected target.

Once a machine's infected, it typically stays that way. Depending on the Trojan, it may actively attempt to disguise itself (as with the recent Code Red variant that added a second, bogus copy of explorer.exe to infected machines), or it may depend on user inattention to stay hidden. Whenever the attacker desires to, he can send a trigger command to one, or all, infected zombies; that command will tell the Trojan to attack a designated target by sending it lots of packets. The Trojan may also attempt to spread itself, and many Trojans offer an attacker direct remote control of a compromised machine.

Top of page

It's hard to defend against DDoS attacks. There are actually two separate issues: keeping your network from being attacked by others and hardening your machines so they can't be compromised and used in attacks.

The first step is to protect your own network against being attacked. This is hard to do, since any network is vulnerable to being overloaded by seemingly-legitimate traffic. Turning on ingress filtering (as described in RFC 2267) will help screen out junk packets. In addition, there are a number of settings for the Windows NT/2000 TCP/IP stack that you can adjust to harden it against common attacks. Here's what to do:

Unfortunately, protecting your machines against attacks can be difficult because attackers keep changing their modus operandi. It's simpler to prevent your computers from becoming zombies and contributing to the DDoS problem. A few simple steps that you can take now will do the trick:

Top of page

Paul Robichaux is the principal of Robichaux & Associates, Inc., which provides programming, technical communications, and security services to customers ranging in size from local auto dealerships to Microsoft. He's glad to have his latest book (Managing Microsoft Exchange Server, published by O'Reilly & Associates) on the shelves so he can spend more time with his family.

For any feedback or comments in regards to the content of this article, please send them to Microsoft TechNet.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.