Flooding attacks have one simple rule: the one that has the most bandwidth at its command wins. In its simplest form, a flooding attack occurs when one system sends packets, possibly with a spoofed source address, endlessly at the victim. That’s all there is to it. In DDoS attacks, a number of systems are used in concert to consume the bandwidth of the victim.

A DDoS attack can be launched in a couple of ways. One approach is to take over a large number of systems (known as zombies) using one or more widespread vulnerabilities, install attack software on those systems, and make the systems send large numbers of packets at the victim, preferably using different characteristics and random, spoofed source addresses. Unlike a single source attack, you will have a much harder time dealing with the attack by applying filtering rules.

A second approach to launch a DDoS attack is to use an asymmetric condition, in which one packet originating from the attacker results in many packets being sent to the victim. The classic Smurf attack works by sending a single ping packet to the network broadcast address (see the "What is a network broadcast address?" sidebar), which causes a large number of echo responses to be received. The source address is spoofed to the victim. This type of attack, shown in Figure 16-1, is also sometimes called an amplification attack.

Figure 16-1. A Smurf DDoS attack.

Let’s take a look at how the Smurf attack works. The attacker locates the IP address of a victim, and then sends a ping packet to the network broadcast address of a misconfigured network. All the systems on the network receive the echo request packet, and some of them respond with an echo response that bounces back to the victim. If the misconfigured network is a large one, one ping packet can theoretically produce thousands of responses, so an attacker using a dial-up connection with 56-Kb bandwidth could potentially consume 56-Mb worth of bandwidth on the other end. If the victim is connected with, for example, a T-1 connection that provides 1.5-Mb worth of bandwidth, an attacker could effectively take the victim off the Internet. If the victim is a larger company with much more bandwidth, the company might not notice, or the attacker would have to start using zombies.

One variant of a flooding attack causes many systems on the same network to respond to one another without end, a condition sometimes referred to as a "network food fight." This type of attack, shown in Figure 16-2, relies on a vulnerability being present. For example, Microsoft Windows NT 4.0 systems had a flaw where a malformed packet sent to the UDP RPC port (135) provoked an error response. If the system receiving the error response didn’t expect the error, it responded with another error. The CPUs of both systems would hit 100 percent, and all the available network bandwidth was consumed.

Figure 16-2. Example of a network food fight involving echo and chargen.

Another example of a network food fight comes from people finding inventive ways to combine the echo and chargen service. A packet sent to echo gets the packet reflected to what the echo service believes is the sender, and a packet sent to the chargen service results in a packet full of characters. If you can spoof a packet from one system’s echo service to another’s chargen service, those systems will exchange lots of packets until someone shuts down one of the services. If an attacker can send a request to all of the chargen services on a subnet using a broadcast packet, so much the better for the attacker. This is probably the most extreme version of an asymmetric attack—just one packet disrupting an entire network. Most currently available implementations of both echo and chargen do not respond to requests with a source address in the reserved range (below port 1024), and they should not respond to broadcast packets at all.

Resource starvation attacks are DoS attacks that attempt to consume a resource on a target system so that the resource isn’t available to legitimate users. This section discusses three types of this attack: CPU starvation, memory starvation, and disk storage consumption.

Unlike many other forms of attack, where service resumes when the attack stops, a crash results in a service outage until you restart the system or service yourself. Crashes are almost always something you’d like to avoid. As with many other types of denial of service, the cure for disruption of service is to apply patches, and the way to detect the potential for a problem is through normal patch compliance auditing. You might sometimes inadvertently create a crash when doing penetration testing. For example, let’s say you have a nice new exploit against a service that has a recent problem. The only catch is that you have to guess remotely which service pack has been applied to the service, and fingerprinting doesn’t help. You’ve got a 50-50 shot, so you give it a whirl, and splat! Down it goes. Now you need to find the owners of the system and let them know that you brought it down.

If you do encounter a system that is crashing for unknown reasons, check the application logs and consider the possibility that the cause is an exploit that isn’t quite working yet. In one case, some sharp system administrators discovered a new, non-public exploit this way.

Another way an attacker can cause a denial of service is through intentionally misconfiguring a system. The Doom worm (launched in early 2004) utilized this approach to add entries to the host file of a system so that the host could reach resources to obtain patches and update antivirus software. A live attacker might do the same thing.

One of the many variants of denial of service is to inject packets into an existing data stream between two servers to reset the connection. To accomplish this, the attacker either needs access to the network traffic or needs to be able to take advantage of a sequence number–guessing attack. This is covered in more detail in Chapter 20.