9 Phase 3: Denial-of-Service Attacks

As we’ve seen in Chapter 7, Phase 3: Gaining Access Using Application and Operating System Attacks, and Chapter 8, Phase 3: Gaining Access Using Network Attacks, some attackers want to gain access to systems, using a variety of ingenious techniques to achieve their goal. Other attackers aren’t looking to gain access; they want to prevent access by legitimate users or stop critical system processes. To accomplish this objective, they utilize a variety of attack techniques to deny service. In a DoS attack, the bad guy might launch a massive flood against a victim machine, rendering it completely inaccessible to all legitimate users. Some DoS attacks are mere annoyances, as when a less-than-critical server is tied up with bogus requests, whereas others might involve life-threatening situations for very critical servers associated with health care or related computers.

Generally speaking, most DoS attacks are not technically elegant. The attacker just wants to break things, so finesse is not paramount. Most DoS attacks are merely bothersome. In many instances, the attacker causes a system to crash, annoying the system administrator or user who is forced to restart a service or reboot the machine.

However, some DoS attacks go far beyond mere annoyance. As we saw in the spoofing and hijacking attacks described in Chapter 8, some DoS techniques are elements of more elaborate attacks. Also, even by themselves, DoS attacks could cause major damage to vital systems. A company that relies on electronic transactions for its livelihood could suffer serious financial damage if its systems are taken offline for even a short duration. I’ve been involved with a case in which an e-commerce company’s competitor launched a DoS attack against the company’s Web site, hoping that customers would abandon the target’s nonresponsive servers and take their business to the attacker’s own e-commerce site. Beyond these commercial interests, in industrial, aviation, and health care operations, a DoS attack could have life-threatening impacts. Because of these possibilities, it is critical that system, network, and security personnel understand DoS attacks and how to defend against them.

As shown in Figure 9.1, DoS attacks generally fall into two categories: stopping a service and resource exhaustion. Stopping a service means crashing or shutting off a specific program or machine that users want to access. With resource exhaustion attacks, the service itself is still running, but the attacker consumes computer or network resources to prevent legitimate users from reaching the service. Furthermore, as pictured in Figure 9.1, these two categories of DoS attacks can be launched locally from an attacker-owned account on the machine or against a target across a network. The resulting categories of attack therefore make a matrix of DoS attack possibilities for the bad guys.

Figure 9.1 Denial-of-service attack categories.

To understand these different categories of DoS attacks, let’s analyze the techniques highlighted in each of the four quadrants of Figure 9.1.

Locally Stopping Services

Using a local account on a machine, an attacker has a great deal of access to create a DoS attack by stopping valuable processes that make up services. For example, on a UNIX system, an attacker with root privileges might shut down the xinetd process. As discussed in Chapter 3, Linux and UNIX Overview, xinetd is responsible for listening for network connections and running particular services such as the telnet and FTP daemons when traffic arrives for them. Shutting down xinetd prevents remote users from accessing the system through any services started with xinetd, including telnet and FTP services. In this kind of attack, the bad guy isn’t consuming resources, just shutting off a crucial component of the services.

Because attackers can run local programs and supply input directly into processes on the machine through a local account, they can often wreak havoc by having an account on a system. The attacker might have gotten access to the account as an insider, such as an employee or contractor, or through some of the methods discussed in Chapters 7 and 8. An attacker with local account access to a machine has a variety of methods for stopping local services, including the following:

• Process killing. An attacker with sufficient privileges (such as root on a UNIX system or administrator on a Windows machine) can simply kill local processes in a DoS attack.
• System reconfiguration. Attackers with sufficient privilege can reconfigure a system so that it doesn’t offer the service any more or filters specific users from the machine. For example, on a Windows file server, an attacker could reconfigure the machine, simply stopping the sharing of files across the network. This change would prevent legitimate users from remotely accessing their valuable data on the file server. Alternatively, the attacker could reconfigure a UNIX system so that an HTTP daemon doesn’t start up, effectively preventing Web access to the system.
• Process crashing. Even if the attackers don’t have super-user privileges on a machine, they might be able to crash processes by exploiting vulnerabilities in the system. For example, an attacker could exploit a buffer overflow vulnerability by inputting arbitrarily large amounts of random data into a local process. As we discussed in Chapter 7, if the attacker fills a vital return pointer with garbage, the target process will most likely crash, denying user access.

A particularly nasty example in this realm of DoS attacks that locally stop services is the logic bomb. Using an account on the target machine, an attacker plants a logic bomb program, which could be triggered based on a number of factors, such as elapsed time, the activation of certain other programs, the logging in of specific users, and so on. Once the logic bomb trigger is activated, the program will stop or crash a local process, denying service on the machine. Several organizations have been faced with logic bomb extortion threats. In these cases, the attacker places a logic bomb on the target system, and anonymously telephones the organization. The attacker then explains that the system will cease operation unless a specific action is performed by the target organization, such as the transfer of money to an anonymous offshore bank account. Consider the trade-off: you either pay $500,000 or your machine that processes $10 million in customer transactions per hour might be crashed. Do you want to cut a deal with such cyber-extortionists? What happens after they spend their money? Will they come back for more? Such situations are difficult indeed, and you should certainly involve senior management and possibly even law enforcement immediately if you face an extortion attempt.

Defenses from Locally Stopping Services

To prevent an attacker from stopping services locally, you must keep your systems patched, applying the relevant security bug fixes, so that the attacker cannot exploit and crash vulnerable local programs. Patching your systems in a timely manner also helps prevent an outside attacker from gaining an account on the machine in the first place.

Furthermore, make sure to dole out privileges carefully to users on your system. Most users do not require super-user privileges to get their jobs done. When assigning privileges to users, you should follow the principle of least privilege: Users should only be given the access that they require to get their jobs done and no more. Proper implementation of such a philosophy will prevent renegade users from stopping services or conducting other attacks.

Finally, to detect changes quickly to the configuration of the system, you need to run file-integrity-checking programs, such as Tripwire (www.tripwire.com). These programs check to make sure that critical system files (such as configuration files and sensitive executables on the machine) are not altered. If they are changed, the file-integrity-checking program will warn the system administrators, using periodic reports, e-mail, pager, SNMP trap, or other alarming mechanism.

Locally Exhausting Resources

Another common type of DoS attack involves running a program from an account on the target machine that grabs system resources on the target itself. When all system resources are exhausted, the system will grind to a halt, preventing legitimate access. Most operating systems do attempt to isolate users and processes so that actions by a rogue process do not suck up all system resources. However, a determined attacker can find ways around such isolation tactics, perhaps by using an exploit to gain super-user privileges, and then hogging resources on the target machine. Some common methods for exhausting local resources include the following:

• Filling up the process table. An attacker could write a simple program that simply forks another process to run a copy of itself. That’s it. Of course, this forked copy of the program would run, forking off another process to run the same program again, with the cycle repeating itself recursively again and again. Such attacks are sometimes called fork bombs, and they can be really annoying. Using a fork bomb, an attacker could create processes as fast as the system could fork them. Eventually, the process table on the machine could become filled, preventing other users from running processes and denying them access. Also, it’s even possible that the operating system itself might not be able to create a vital system process, causing the machine to crash completely.
• Filling up the file system. By continuously writing an enormous amount of data to the file system, an attacker could fill up every available byte on the disk partition, preventing other users from being able to write files, and potentially just crashing the system. Alternatively, instead of writing really big files to fill up all data blocks on the drive, the attacker could just create huge numbers of new files, in an attempt to exhaust the file system identification resources.
• Sending outbound traffic that fills up the communications link. The attacker could write a program that sends bogus network traffic from the target system, consuming the processor and link bandwidth. If the attacker’s program generates enough outbound packets from the victim machine, legitimate users will not be able to send traffic to or get responses from the system.

Defenses from Locally Exhausting Resources

To defend yourself from local resource exhaustion attacks, apply the principle of least privilege when creating and maintaining user accounts. If your critical operating system supports such restrictions, implement per-user limits on the consumption of file system space, memory, and CPU usage. That way, no single user will be able to hog all of your resources. Additionally, make sure that your sensitive systems have adequate resources, including memory, processor speed, and communication link bandwidth. Finally, you might want to consider deploying host-based IDSs or other system monitoring tools that can warn you when your system resources are getting low, possibly indicating this type of resource exhaustion attack.

Remotely Stopping Services

Although local DoS attacks are often very simple and quite effective, remote DoS attacks are much more prevalent. DoS attacks across the network are more popular because they do not require the attacker to have a local account on the machine.

One of the most common methods of remotely stopping a service is a malformed packet attack. Such attacks exploit an error in the TCP/IP stack or a running service on the target machine by sending one or more unusually formatted packets to the target. If the target machine is vulnerable to the particular malformed packet, it will crash, possibly shutting down a specific process, all network communication, or even causing the target’s operating system to halt. An enormous number of malformed packet attacks have been devised, with bizarre and exotic names, as described in Table 9.1.

Table 9.1 A Variety of Malformed Packet Denial-of-Service Attacks

Many items in this exploit zoo rely on a variety of techniques to create packets with a structure that the developers of many TCP/IP stacks did not anticipate. Each one of these exploits sends one or, at most, a few packets to the target, causing it to crash. Some of the attacks create unusual or illegal packet fragmentation conditions (like Teardrop and Bonk), whereas others send unexpectedly large packets (such as Ping of Death). Some send spoofed packets with unanticipated port numbers (Land), and others just plain send unexpected garbage data to an open port (Winnuke). Some of these attacks are quite old, such as Ping of Death, which was vintage 1996, and Land, discovered in 1997. Despite their age, attackers do, on occasion, stumble across systems that were not properly patched to prevent even these old attacks. Other attacks are more recent discoveries, such as Rose, which originated in 2004. Some old attacks, like Land, were fixed years ago (in 1997), yet the same mistakes are made again at a later time, as when the Land vulnerability reappeared in Windows machines in 2005. Today, new similar malformed packet vulnerabilities are constantly being discovered and shared in the computer underground.

There are even malformed packet attack suites that roll together a bunch of these exploits into one single executable. If attackers are not certain whether their target is vulnerable to Rose, Land, or anything else, they can use a malformed packet attack suite. These tools launch dozens of different varieties of DoS attacks using one convenient script. The attacker points the tool at a target, and fires away. Some of the more powerful suites of malformed packet attacks are Mixter’s Targa, Spikeman’s Spike, and Gridmark’s Toast. Toast, the most prolific of the bunch, includes 49 different individual malformed packet attacks that it spews at a target. Each of these malformed packet attack suites and a variety of other DoS attack tools are available at www.packetstormsecurity.org/DoS. These suites tend not to be super-elegant, and usually consist of a bunch of individual malformed packet attack code pasted together into one convenient package.

Another way to stop a service remotely is to prevent it from communicating across the network. ARP cache poisoning, a technique discussed in Chapter 8, is a particularly effective technique for manipulating communication on a LAN to create a DoS attack. An attacker with an account on a machine on the same LAN as the target system could use Dug Song’s arpspoof program included with Dsniff. Sending out a single spoofed ARP packet to the router on the LAN, the attacker can poison the router’s ARP cache so that it will send packets destined for the target machine’s IP address to a nonexistent MAC address on the LAN. Even though all packets will be sent to the destination LAN, the victim machine will not receive any of the traffic, resulting in a DoS attack by stopping the services on the victim from communicating. By using ARP spoofing, the target machine is effectively taken off the network. As described in Chapter 2, Networking Overview, ARP messages travel only across a LAN, and cannot be transmitted through routers. Therefore, to employ this technique, the attacker must take over a machine on the same LAN as the target system to be able to send ARP messages to the target.

Another variation of DoS attacks that render a service inaccessible involves resetting vital communication streams. These types of attacks don’t shut a service down, but instead focus on taking existing communications sessions and tearing them down so the two parties on either end are rudely interrupted. TCP connections are torn down when one of the communicating machines sends a FIN or a RESET packet to the other side. An attacker could reset a connection between two systems by sending a spoofed RESET packet, pretending to be one side of a connection. To pull this action off, the attacker would have to know the source and destination IP addresses, as well as the source and destination TCP port numbers associated with a particular active session.

The only other thing the attacker would need to know to pull off this RESET is the proper sequence number that the communicating parties are currently on for one direction of their session. If the RESET doesn’t contain an appropriate sequence number, the target will reject the packet and ignore it. With 32-bit sequence numbers, the attacker’s chance of guessing the proper sequence number is pretty slim, something like one in 4 billion, right?

Wrong. Here’s the big worry. Most operating systems and network equipment accept a FIN or RESET packet as long as its sequence number is located somewhere within the TCP window size that the machine expects. Remember, the TCP window size is a field in the header of a TCP packet that specifies the number of outstanding data octets a system will accept in a single session before the sender has to wait for an acknowledgment to reinitialize the window size. So, if a given TCP connection has a window size of, say, 65,535 (that’s 2¹⁶ - 1), the attacker’s one in 4 billion odds just came down to about one in 65,000. The attacker could just send a barrage of packets to the destination machine, sliding the sequence number up in increments of 65,535, waiting until one falls into the window, which would reset the connection. A smaller window size would require more packets, of course. This attack is called TCP RESET spoofing, and it is a big concern. Of course, however, the attacker still needs to know the source and destination IP addresses and port numbers. So, the attack still seems unlikely, right?

Wrong again. A particularly chilling example was widely publicized in April 2004, when researcher Paul Watson announced how this attack could be used to reset the Border Gateway Protocol (BGP) communications of backbone routers on the Internet. If routers cannot communicate route updates to each other, the network itself would gradually degrade and stop routing packets. Because the IP addresses of the major backbone routers are public information, the attackers already have the source and destination IP addresses for such an attack. Also, the destination port number for BGP updates is widely known, TCP port 179. For the source port, the attacker can make a reasonable assumption that it will be a number above 1024, but not too high, because it is allocated by the source operating system, a router, which doesn’t open a lot of outbound connections.

So, the bad guy could pick a hundred or so crucial backbone routers, launch a few million RESET packets, and ... wham! The Internet would have a very bad day. In April 2004, major ISPs fixed this particular problem a week or two before tools were widely released to exploit it by requiring an MD5 hash ensuring the integrity of all BGP-related packets, including session initiation and teardown. Of course, for TCP communication streams other than BGP, such as ssh, telnet, or ftp, this handy little RESET-within-the-window trick still works great on most operating systems.

Defenses from Remotely Stopping Services

As we’ve seen throughout this chapter, the best defense against many DoS attacks is to apply system patches in a quick, methodical manner. This is especially true for malformed packet DoS attacks, which rely on sloppily written programs like TCP/IP stacks and services. Vendors frequently release patches to their TCP/IP stacks to fix such problems.

Additionally, some of these attacks, such as Land and TCP RESET spoofing, rely on IP address spoofing. The antispoof filters we discussed in Chapter 8 can help thwart such attacks.

To defend against ARP spoofing attacks, you can create static ARP tables on your most sensitive networks to make sure no one can alter IP-to-MAC address mappings on your LANs. Although this technique will make management of the network more difficult, it is a very good idea to use static ARP tables on sensitive networks, such as your Internet DMZ.

Remotely Exhausting Resources

Of all the DoS attacks available today, by far the most popular technique involves remotely tying up all of the resources of the target, particularly the bandwidth of the communications link. In this type of attack, the bad guys try to suck up all available network capacity using a flood of packets. As we saw with logic bombs, extortionists are also using packet floods to force victims into paying money to head off a DoS attack. A growing trend involves threatening a massive packet flood against a Web site unless the target pays a “protection fee” to stay in business. So far, these threats have focused on offshore gambling and pornography sites, but we are starting to see them move toward e-commerce and financial institutions. In these scams, the bad guys ask for fees ranging from $1,000 all the way up to $100,000 or more! If the victim doesn’t pay, the attack ensues, possibly costing the victim far more than the extortionist’s asking price. Let’s look at the technology behind these attacks by exploring several of the most popular techniques for launching packet floods, including SYN floods, Smurf attacks, and distributed DoS attacks.

SYN Flood

As we saw in Chapter 2, all TCP connections begin with a three-way handshake, which starts with a packet with the SYN control bit set being transmitted to an open port. When the destination machine receives the SYN packet, it remembers the initial sequence number from the source, and generates a SYNACK response. To remember the initial sequence number from the source, the TCP/IP stack on the destination machine typically allocates a small piece of state to track the status of this new half-open connection. A SYN flood attack attempts to undermine this mechanism by sending a large number of SYN packets to the target system, as shown in Figure 9.2.

Figure 9.2 A SYN flood.

During a SYN flood, the attacker’s goal is to overwhelm the destination machine with SYN packets. When the target receives more SYN packets than it can handle, other legitimate traffic will not be able to reach the victim. There are two ways that a SYN flood can exhaust the communications resources of the target. The attacker really doesn’t care which of these two impacts happens first, as long as the target is unreachable by legitimate users.

The first way a SYN flood can impact the target involves filling a data structure on the target called the connection queue, a memory structure used by the end system to remember where it stands in the three-way handshakes of various connection attempts. The attacker, generating a bunch of SYNs, forces the target to allocate slots on its connection queue with bogus half-open connections. Once the target system receives the SYN packet and sends its SYN-ACK response, it waits patiently for the third part of the three-way handshake, using a timeout value that is often set to over a minute by default. Most systems have a connection queue of finite size, with typical operating system ranges from 128 to 1,024 simultaneous half-open connections. The attacker can completely fill up this connection queue while the target system dutifully waits for the completion of the three-way handshake for each outstanding half-open connection. By sending SYN packets to exhaust all slots allocated in the connection queue, no new connections can be initiated by legitimate users.

To help ensure that the connection queue gets filled, many SYN flood tools send SYN packets using spoofed source addresses that are unresponsive on the Internet. As illustrated in Figure 9.2, the attacker will choose some set of IP addresses, shown as X1, X2, and X3, that no machine connected directly to the Internet is currently using. Such addresses are used as the spoofed source because the SYN-ACK responses from the target machine will never get an answer. If the SYN flood tool spoofed using an active source address assigned to a real machine on the Internet, as shown in Figure 9.3, each SYN sent by the attacker would trigger a SYN-ACK response sent to this legitimate machine whose source address was spoofed. This legitimate, innocent machine would receive a SYN-ACK packet from the target, known as the “backscatter” from the SYN flood. The innocent machine would respond to the unexpected SYN-ACK with a RESET, because no connection was started. This RESET packet would tear down the connection on the target machine, freeing up the connection queue resources that the attacker is trying to consume. The attacker can burn up the connection queue much more easily using spoofed, unresponsive source addresses in the SYN packets.

Figure 9.3 Attackers often spoof using unresponsive addresses to prevent the RESET from freeing up the target’s connection queue resources.

A second way that SYN floods can exhaust the resources of the target goes beyond the connection queue. If the connection queue is enormous and can handle a very large number (hundreds of thousands or millions) of outstanding SYN packets, the SYN flood could just fill the entire communications link, squeezing out any legitimate traffic. To accomplish this, the attacker must have more total bandwidth than the victim machine, and the ability to generate packets to fill that bandwidth. For example, if the target has a T1 connection, which operates at 1.544 Mb per second, the attacker must be able to consume at least 1.544 Mb per second (plus a little bit extra just to make sure) to fill the whole link with traffic. Also, using the Distributed DoS (DDoS) attacks we discuss later in this chapter, consuming this amount of bandwidth is trivial.

Now that we’ve seen the two ways a SYN flood can impact a target, let’s quickly revisit the spoofed source address the attacker might use. If the attacker chooses an address assigned to a legitimate, responsive machine, that machine will receive the SYN-ACK backscatter, freeing up the connection queue, as we discussed. However, think about the impact on bandwidth. For every SYN the attacker sends, the target will send out a SYN-ACK packet, and the innocent backscatter receiver will send a RESET. Thus, by sending one packet to the target, the attacker actually forces three packets to be sent (the SYN itself, the SYN-ACK, and the RESET), consuming bandwidth faster. If the attacker chooses a nonresponsive address to spoof, the connection queue is consumed faster. If the attacker chooses a responsive address, the pipe’s bandwidth will be exhausted more quickly. Although the attacker can choose the desired effect by selecting an appropriate set of spoofed source addresses, many bad guys simply opt for nonresponsive source addresses, without understanding the reason for this choice. These attackers use nonresponsive source addresses simply because someone once told them it would work better that way. Of course, most SYN flood tools don’t use a single spoofed source address, but instead select from a pool of dozens, hundreds, or even thousands of addresses.

SYN Flood Defenses

An important first defense against a SYN flood attack is to ensure that you have adequate bandwidth and redundant paths for all of your critical systems. You don’t want a script kiddie attacker to be able to suck up all of your bandwidth easily with a simple SYN flood. If a flood attack does occur, you need to be able to redirect critical traffic quickly through another path, so redundant communications links are required. For particularly sensitive systems that must be constantly available on the Internet, you must also consider using two or more different ISPs for connectivity.

Different operating system vendors have developed a variety of techniques for handling SYN floods. Some increase the size of the connection queue, whereas others lower the amount of time the system will wait on a half-open connection. A list of different vendor approaches and patches enabling these defenses for UNIX machines can be found at www.cymru.com/Documents/ip-stack-tuning.html. Windows TCP stack tuning to lower the SYN flood threat is described in detail at http://support.microsoft.com/kb/142641/EN-US.

Another technique for defending against a SYN flood attack relies on a concept called SYN cookies, which focuses on eliminating the connection queue as a bottleneck in the face of a flood of SYN packets. If the connection queue is a problem, why not just get rid of it? That’s what SYN cookies do, by modifying a machine’s TCP/IP stack behavior to eliminate the need for the connection queue to remember all half-open connections. Although they modify the way sequence numbers are assigned by a machine, SYN cookies require changes in only the destination TCP/IP stack. SYN cookies function by carefully constructing the sequence numbers included in the SYN-ACK packet sent from the target machine, as depicted in Figure 9.4.

Figure 9.4 SYN cookies.

When a SYN packet comes to a machine that is using SYN cookies, it applies a cryptographic one-way hash function to the source and destination IP addresses, port numbers, time rounded to the nearest minute, and a secret number to create a single value, which is called the SYN cookie. The calculated SYN cookie is loaded into the initial sequence number (ISN_B) of the SYN-ACK response and transmitted across the network. The secret number used to formulate the SYN cookie is just a pseudo-random integer value stored on the server that an attacker would not know. Because the one-way hash includes a secret number in its input, the attacker shouldn’t be able to predict valid SYN cookies, thereby avoiding the TCP-sequence-number-guessing spoofing attacks we covered in Chapter 8. Remember, we certainly want ISN_B values to be unpredictable.

After transmitting the SYN-ACK response with the SYN cookie loaded into ISN_B, the machine does not remember the initial sequence number from the initiating system (ISN_A), or even this cookie value (ISN_B). In fact, the machine doesn’t remember anything about the connection at all, blissfully dropping all information associated with the now half-open connection. No space on the machine’s connection queue is allocated, because a connection queue is no longer required. In essence, the destination machine is storing a representation of the connection using a slot in the network communications, knowing that this ISN_B information will be returned in a later ACK packet if the connection is legitimate. If the SYN packet was part of a SYN flood, no ACK response will ever come back, but that’s OK. We haven’t tied up any state remembering this fake connection. In a way, SYN cookies let us exchange memory resources (a connection queue) for processor resources (the CPU capacity required to calculate the hash for ISN_B).

If the SYN packet was part of a legitimate connection, an ACK packet will be returned by the initiating system to complete the three-way handshake. The receiving machine will compute the same function based on the source and destination IP addresses, port numbers found in the ACK packet, the receiving system’s secret number, as well as recent values of time. If this calculation matches the acknowledgment number in the ACK packet minus one (remember the ISN_B is incremented in the ACK response of the third part of the handshake), the cookie is validated. The system knows that the ACK is really part of a connection that was generated using the three-way handshake. Using this SYN cookie technique, a legitimate connection has been initiated, without the need to remember half-open connections on the connection queue. Therefore, this technique limits the ability of SYN floods to fill up the connection queue by eliminating the connection queue. Of course, the attacker could launch an ACK flood to tie up the target’s processor, as it busily hashes data from each incoming ACK packet. But that’s the trade-off: no connection queue to exhaust but higher CPU usage.

SYN cookies are built into the Linux kernel. To activate SYN cookies on a Linux machine, the following line should be added to the boot sequence for the machine:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Beyond SYN cookies, there are other SYN flood defenses. For critical systems on the Internet, you might want to employ active traffic shaping tools. These tools, which are available as extra feature sets (at an additional cost) for some firewalls and load balancers, sit on the path connecting the sensitive host to the Internet, such as in front of your DMZ. In addition to having enormous connection queues themselves, traffic shapers can throttle the number of incoming SYN packets going to a protected machine, limiting the number of incoming SYN packets to a level of traffic the protected machine can handle. By slowing down the rate of connection initiations, traffic shaping tools can help avoid damaging SYN floods. Cisco IOS 11.1 and later includes a standard built-in feature called TCP Intercept that, in effect, is a very simple traffic shaper. A router administrator can configure the router to allow only a certain load of SYN packets through in a given time interval.

Smurf Attacks

Smurf attacks, also known as directed broadcast attacks, are another popular form of DoS packet floods. Named after a very popular tool that implements the technique, Smurf attacks rely on a directed broadcast to create a flood of traffic for a victim. Remember, as we discussed in Chapter 2, every IP address is made up of two components: a network address and a host address. If the host part of the IP address is set to a binary value of all 1s, the packet is destined for the broadcast IP address of the network. For example, if the network IP address is 10.1.0.0 with a netmask of 255.255.0.0, the broadcast IP address for the network would be 10.1.255.255. The two 255 numbers indicate that the host part of the address consists of 16 consecutive 1s, thereby indicating a message for the network’s broadcast IP address. When a packet destined for a network’s broadcast IP address is sent to a LAN, the router connecting this LAN to the outside world receives it first. The router can convert the IP (Layer 3) broadcast message to a MAC (Layer 2) broadcast message, by sending the packet to every system on the LAN using a destination MAC address of FF:FF:FF:FF:FF:FF, which is a MAC address made up of all 1s. An Ethernet message to a MAC address of all 1s sent across a LAN will cause every machine on the destination LAN to read the message and send a response.

Let’s consider the common ping, an ICMP Echo Request packet. A user can send a ping to the IP network broadcast address of a network. If the router on the destination network allows directed broadcasts, it will convert the IP-layer broadcast ping packet to a MAC-layer broadcast so all systems on the destination LAN will receive it. On receiving this message, all active machines on the destination LAN will send a ping response. By sending a single packet, we are able to get many response packets (one from each host on the destination network, which could have dozens, hundreds, or, theoretically, thousands of machines). Now, suppose that the initial ping request to the network broadcast address had a spoofed source IP address. All ping responses from all machines on the network would be directed to the apparent source of the packet, that is, the spoofed address. As the number of machines on the network allowing directed broadcasts increases, the number of packets that can be generated increases.

As shown in Figure 9.5, an attacker can use this amplification behavior to conduct a Smurf attack. The attacker sends a ping packet to the broadcast address of some network on the Internet that will accept and respond to directed broadcast messages, known as the Smurf amplifier. The Smurf amplifier is usually just a misconfigured network belonging to an innocent third party on the Internet. The attacker uses a spoofed source address of the victim that the attacker wants to flood. All of the ping responses are routed to the victim. If there are 30 hosts connected to the Smurf amplifier network, the attacker can send 30 packets to the victim by sending a single packet to the Smurf amplifier.

Figure 9.5 A Smurf attack results in a flood of the victim.

An attacker sends packet after packet to the Smurf amplifier, typically saturating the attacker’s link entirely to get the maximum benefit from the amplification action. If the attacker can initiate packets using a 56-kbps dial-up line, the Smurf amplifier could generate approximately 30 times that amount, or 1.68 Mbps, enough to fill up a T1 connecting the victim to the Internet. Any script kiddie attacker can exhaust a T1 without breaking a sweat simply by using a Smurf attack from a dial-up line. No cable modem, Digital Subscriber Line (DSL), or group of bot-controlled systems are even required, as long as the bad guy can find a Smurf amplifier network with a factor of 30 or so for amplification. Unlike SYN floods, no connection queue is associated with ICMP, so the flood prevents legitimate access by consuming all of the target’s communication bandwidth. Of course, the Smurf amplifier itself has a fixed maximum bandwidth connection to the Internet, so it will only be able to generate this maximum amount of traffic. Still, using this Smurf technique, the attacker can quickly and easily create a flood of ICMP packets at the target machine, all of which would be traced back to the Smurf amplifier, and not the victim.

There are several tools that let an attacker conduct a directed broadcast attack available at www.packetstormsecurity.org/DoS, including the following:

• Smurf, one of the earliest directed broadcast attack tools, which gave the technique its name.
• Fraggle, a cousin of Smurf that focuses on UDP instead of ICMP. Fraggle sends packets to an IP broadcast address with a destination UDP port set to a service that will send a response, such as the UDP echo service (port 7). When the echo service receives a packet, it simply sends back a response containing exactly the same data that it receives. That’s why it’s called echo. By using Fraggle to send a stream of packets to an IP broadcast address on UDP port 7, all machines on the network will echo the UDP traffic, resulting in the amplifying effect and flood. Alternatively, Fraggle can work by sending UDP packets to closed ports on systems on the Smurf amplifier network. Many systems respond with an ICMP Port Unreachable message when a UDP packet arrives for a closed port. Thus, for every UDP packet the attacker sends, an amplified number of ICMP Port Unreachable messages will be reflected back at the target.
• Papasmurf, a combination of the Smurf and Fraggle attacks, allowing the attacker to use multiple amplifier networks.

So how does an attacker find a broadcast amplifier to use? Some attackers share good broadcast amplifiers, whereas others hoard them. The folks behind Norway’s Powertech Web site periodically scan the Internet looking for incorrectly configured networks that can be used as Smurf amplifiers, and publish a list of them at www.powertech.no/smurf. Although most of these poorly configured networks offer a couple dozen hosts for amplification, every once in a while a network with a hundred or so amplifying machines is discovered. Additionally, the Nmap scanning tool can easily be configured to look for broadcast amplifiers by having it do a ping sweep of various target broadcast addresses, as described by Nmap’s author, Fyodor, at www.packetstormsecurity.org/9901-exploits/smurf.BIP-hunting-nmap.txt.

Smurf Attack Defenses

There are a variety of Smurf defensive techniques available, as described in Craig A. Huegen’s fantastic paper on Smurf defenses, located at www.pentics.net/denial-of-service/white-papers/smurf.cgi. As with most packet flood attacks, the first defense is to make sure that your critical systems have adequate bandwidth and redundant paths. Additionally, if you find that your network is a frequent Smurf victim, you might even want to filter ICMP messages at your border router, but keep in mind that this tactic will impair your users’ ability to ping your systems.

You also want to make sure that no one can use your network as a Smurf amplifier. You can do so by surfing to www.powertech.no/smurf and using their form to test your network. But be careful. If your network is subject to such a flood, you might be added to their list of Smurf amplifiers! If your network is indeed vulnerable to being used as a Smurf amplifier, you must stop directed broadcast packets at your border router or firewall. In Cisco parlance, the simple command no ip directed-broadcast applied to each interface at your external router will prevent your publicly exposed network from accepting packets sent to the network’s broadcast address. This command prevents your router from converting packets sent to the network’s IP broadcast address into MAC-layer broadcasts, thereby dropping all such requests as they come into your network. With all such packets being dropped, your network cannot be used as a Smurf amplifier. Whereas this configuration is the default in IOS 12.0 and later, Cisco routers with earlier operating systems and routers manufactured by other vendors must explicitly deactivate directed broadcasts in their configurations for each interface on the router. Also, even if you are using IOS 12.0 or later, make sure you verify that this syntax hasn’t been inadvertently dropped by a router administrator who was trying to clean out the router configuration.

Distributed Denial-of-Service Attacks

A simple SYN flood allowed an attacker to generate traffic from one machine. A Smurf attack raised the ante, but was still limited to the amount of traffic that could be consumed by the Smurf amplifier network. In a DDoS attack, there are no inherent limitations on the number of machines that can be used to launch the attack and how much bandwidth the attacker can consume. By allowing an attacker to coordinate the activities of arbitrarily large numbers of hosts, in a DDoS attack, the sky’s the limit. DDoS represents a nasty turn in the evolution of DoS attacks, and it also is a harbinger of a whole new class of attacks beyond DoS.

DDoS attacks first appeared publicly in 1999 and have gained popularity ever since. Indeed, in early February 2000, the profile of these attacks was raised significantly when they were used in several massive floods of high-profile Web sites, including such Internet luminaries as Amazon.com, eBay, E*Trade, and ZDNet. Despite the massive publicity surrounding these attacks, the Internet as a whole is still very much vulnerable to this type of attack. Throughout the mid-2000s these capabilities were integrated into the most popular and prolific bot tools, including variations of phatbot and agobot, which we discuss in more detail in Chapter 10, Phase 4: Maintaining Access.

DDoS Architecture

A DDoS attack harnesses the distributed nature of the Internet, with hosts run by disparate entities around the world, to create a massive flood of packets against one or more victims. To conduct a DDoS flood, the attacker first takes over a large number of victim machines, often referred to as zombies. Other terms applied to these systems controlled by the attacker to launch a flood include the more general-purpose agents and bots, but the zombie terminology seems to be the most popular in the context of DDoS attack agents. Potential zombie systems are located anywhere on the Internet and have a variety of simple vulnerabilities that the attacker can quickly exploit to take over the system and install the zombie code. In the common DDoS attacks observed to date, zombies have been installed on vulnerable servers at universities, systems at small and large companies, service provider machines, and home users’ systems connected to always-on DSL or cable-modem services. The attacker will scan large swaths of the Internet looking for vulnerable machines, exploit them, and install the zombie software on the systems. Alternatively, a worm can spread DDoS zombies to hundreds of thousands of machines. Or, an attacker could send a spam e-mail with an attachment that includes a zombie to trick a victim user into installing it on a machine. Attackers establish groups of hundreds, thousands, or even tens of thousands of zombies. One of the biggest cases I’ve handled involved over 150,000 zombie machines launching a flood.

The zombie software is the component of the DDoS tool that waits for a command from the attacker, who uses a client tool to interact with the zombies. With bot-based zombies, the client software is often an Internet Relay Chat (IRC) client injecting commands into a shared IRC channel used by all of that attacker’s bots. Alternatively, the client might be a specialized piece of software designed just to communicate with those zombies. Figure 9.6 depicts this communication for one of the most fully featured DDoS-specific tools, called the Tribe Flood Network 2000 (TFN2K), written by Mixter. If the attacker creates a DDoS network using more general-purpose bot software instead of DDoS-specific zombies, the exact same architecture is involved. The attacker uses one or more client machines to tell all of the zombies to execute a command simultaneously, usually to conduct a DoS attack against the target. All zombies dutifully respond, flooding the victim in a bloodbath of packets. So, the client communicates with the zombies, but the attacker usually accesses the client from a separate system. This technique adds another level of indirection to the architecture, making it more difficult for investigators to find the attacker. After finding zombies and locating client programs, the investigators still do not have the attacker, who is sitting at another machine, perhaps halfway around the world. Attackers might even use the Netcat relay technique described in Chapter 8 to add further levels of indirection, making capturing the attacker more difficult.

Figure 9.6 A DDoS attack using Tribe Flood Network 2000.

TFN2K: A Powerful DDoS Tool

Let’s spend more time analyzing the features of TFN2K, one of the most fully functional tools in this genre. It also includes features that have been ported into most of today’s DDoS-enabled bots, so, by analyzing TFN2K, we’ll understand the capabilities of both single-purpose zombies and get a feel for the DDoS functions of bots. Attackers using TFN2K can direct all of their zombies to launch several different attack types, including Targa, the malformed packet DoS attack suite also written by Mixter, as well as the following:

• UDP floods
• SYN floods
• ICMP floods
• Smurf attacks
• “Mix” attacks, which include UDP, SYN, and ICMP floods

If the victim doesn’t seem particularly vulnerable to ICMP floods, the attacker can switch to SYN floods. Also, if the attackers have located several Smurf amplifiers, but have a relatively small number of zombies, they can amplify their DDoS using a Smurf attack. Perhaps a really lame attacker can install only ten zombies. By configuring each zombie to bounce off of a different Smurf amplifier, each yielding a 30-fold increase in traffic, even this lame attacker can generate 300 systems worth of traffic to hurl at the target.

One of the most interesting feature sets of TFN2K involves the communication between client and zombies. To prevent other attackers or the zombie machine’s administrator from accessing the zombie, the client must authenticate to the zombies using an encrypted password. Also, all packets from the client to the zombies are sent using an ICMP Echo Reply packet. TFN2K communicates using a ping response, without ever sending a ping. Why does TFN2K use such a strange method of communicating? First, ICMP Echo Replies are allowed into many networks, because the network administrator configures routers and firewalls to allow inside users to ping the outside world. Their ping responses have to get back in, so ICMP Echo Reply packets are allowed. Another reason for using ICMP is to make the connection stealthier. There is no port number associated with ICMP; the system just listens for ICMP packets and passes them to the TFN2K application. Therefore, if the administrator runs Nmap to conduct a port scan of the zombie machine or runs the netstat -na or lsof -i commands locally to get a list of open ports (as we discussed in Chapter 6, Phase 2: Scanning), no new ports will be listed as open for TFN2K. Ports are a TCP and UDP concept, and are not associated with ICMP.

TFN2K communication supports a variety of other stealthy mechanisms. First, the source address of all traffic from the client to the zombies can be spoofed. Further, the zombies themselves spoof the traffic sent to the victim machines. With this spoofing, when investigating a DDoS attack, the end victim has to trace the attack back, router by router, ISP by ISP, to one or more of the zombies. From that point, the attack must be traced back, again, router by router, ISP by ISP to the client. Even then, we haven’t yet found the attacker, who just connected to the client using Netcat, possibly forwarded along a Netcat relay network. In other words, finding the attacker with a truly robust DDoS deployment is very difficult indeed.

In earlier DDoS tools, the client machine included a clear-text file indicating the IP addresses of all of the zombies under its control. When discovered by an investigator, this file was very helpful in locating all of the zombies to eradicate them. However, in TFN2K and most bots, the attackers upped the ante by encrypting this file at the client, so that if a client is discovered, it does not tell the investigators where all of the zombies are located. Furthermore, if the attacker uses IRC to communicate with DDoS-related bots, the client doesn’t need to know the addresses of the clients. It just injects commands into a chat channel monitored by each bot.

A final interesting TFN2K capability is a function that allows the attacker to run a single arbitrary command simultaneously on all zombies. In addition to selecting a particular DoS attack to launch, the attacker can tell all of the zombies to run one command at the same time, rather like an encrypted remote shell (rsh) tool built into TFN2K. Using this capability, the attacker could tell all zombies to FTP and install a new version of TFN2K, to delete all information on their hard drives simultaneously to throw off an investigation, or to alter the zombie environment at the attacker’s whim. With this feature, the DDoS-centric TFN2K starts to approach the functionality of a general-purpose bot, a topic we return to in the next chapter.

Obscuring the Source with Reflected DDoS Attacks

In some DDoS tools, attackers have further refined their craft by implementing reflected DDoS attacks. As shown in Figure 9.7, these reflected attacks take advantage of the TCP three-way handshake, bouncing an attack off of innocent servers using a spoofed source address, resulting in a SYN-ACK flood of the victim. In a reflected DDoS attack, the bad guy first chooses a half-dozen or more high-profile Internet servers, typically Web sites and mail servers that have a lot of bandwidth. The attacker might choose popular e-commerce sites, software vendors, or open source software repositories. The attacker then configures the DDoS zombie to send SYN packets to these servers, spoofing the source address to appear to come from the intended flood victim. When these servers receive the incoming SYN packet, they’ll respond with a SYN-ACK directed to the flood victim. When the victims look at where the torrent of SYN-ACK packets is coming from, they’ll think the high-bandwidth bounce sites are attacking them. However, they are merely responding to spoofed incoming SYN packets. No attack software is installed on the bounce sites, but the attackers now have an extra layer of protection obscuring their true location.

Figure 9.7 Reflected DDoS attacks bouncing off of high-bandwidth sites.

Of course, the attackers must choose big sites with lots of load-balanced servers as a reflection point to make sure that their SYN packets don’t exhaust the connection queues of the bounce servers. The RESET packets sent from the flood victim certainly help alleviate the problem of connection queue exhaustion on the bounce machines. However, if the bounce servers do get exhausted by a SYN flood tying up their connection queues, the attacker’s desired SYN-ACKs won’t be sent to the ultimate target. Therefore, bigger is definitely better as far as bounce servers for reflected DDoS attacks are concerned.

Pulsing Zombies: What a Headache

When investigators analyze a DDoS attack, they often try to trace back from the victim machines to one or more zombies. After all, the zombies are one step closer to the attacker, and locating these machines sure helps in getting their zombies shut off. But remember, most zombies shoot out packets with a spoofed source IP address. To discover where the packet is really coming from, investigators must first contact the victim machine’s ISP. Of course, that ISP is just looking at spoofed packets entering its network, so it will have to look, router by router, to find the ingress point of the packets from another upstream ISP. Then, the investigative team can contact the upstream ISP, trace it through their network, and so on. This iterative process takes time. However, tracing back zombies is far easier if they are actively sending traffic, because an ISP can quickly identify the flow of traffic through their network in real time, rather than having to consult (perhaps nonexistent) logs. DDoS tool developers realized investigators were tracing active attacks, so they introduced another twist, called pulsing zombies, a name that sounds like it might better apply to a punk rock-and-roll band (or a horror flick).

A pulsing zombie floods the target with traffic for a brief period of time, bursting on for an interval like ten minutes. Then, it goes dormant for another period of time (perhaps another 30 minutes or so). After dormancy, it awakens and starts the flooding again for another interval. All of the attacker’s zombies pulse on and off asynchronously, so the average amount of traffic load is still significant, flooding the victim. This pulsing action confounds investigators, who cannot rely on the fact that the traffic is actively being sent as they investigate. As the investigators work with the ISP, they’ll track the packets router by router when suddenly the trail goes silent. Then, they’ll try tracing back to another zombie for a few minutes, when, suddenly it goes silent. Again and again, each trail goes silent, only to resume firing later. If the attacker has 10,000 zombies launching the flood, and each pulses on about 25 percent of the time, the attacker can still generate traffic from effectively 2,500 machines, while giving the investigators trying to trace the attack severe headaches.

From SYN Floods to HTTP Floods

Although SYN floods are still the most common form of DDoS attack, we’re starting to see some attackers and their tools opting for HTTP floods instead of the traditional SYN attack. Because HTTP is a TCP-based service and thus relies on SYN packets for session initiation, you might wonder what the difference is between plain old SYN floods and HTTP floods. SYN floods never complete the three-way handshake, and are therefore fairly easy to detect by targets and their ISPs. A barrage of SYNs with no follow-up packets is a highly unusual traffic pattern. When it detects a SYN flood, the upstream ISP might start filtering these packets when they arrive at the ISP’s own network.

To dodge this type of defense, some attackers use HTTP floods, which send a legitimate HTTP request from the zombies to a target Web server. These requests involve completing the three-way handshake with the target server, followed by retrieval of various Web pages on the target. Therefore, the traffic pattern associated with an HTTP flood looks like typical users accessing the Web site. Filtering out bogus requests is much harder than with a SYN flood.

To perform an HTTP flood, most zombies do not spoof the source IP address. As we discussed in Chapter 8, completing the three-way handshake using a spoofed source address involves predicting the ISN_B of the target machine’s SYN-ACK response, a process that could be quite difficult for large numbers of packets. Therefore, most HTTP-flooding zombies simply make the HTTP connection without any spoofing whatsoever. As you might expect, this makes tracing such attacks from the target back to the zombie simpler, because an investigator knows the real IP address of the zombie. However, some attackers are willing to trade off difficult tracing if they can get harder-to-differentiate flood traffic.

DDoS: A Look at the Future?

Attackers trying to launch a DoS attack certainly benefit from the massive scale afforded by DDoS flooding zombies, but things get really interesting when we apply similar distributed attack concepts beyond DoS attacks. By harnessing the distributed power of the Internet, an attacker can increase the amount of damage a single type of attack can accomplish, at the same time making locating the attacker even more difficult. Currently, a great deal of work is being done in the computer underground to extend the concept of distributed attacks beyond DoS. Indeed, many of the attacks discussed in this book can be mapped into a distributed model.

For example, an attacker can set up a group of zombies or bots to conduct a more stealthy port scan or network mapping exercise. Each zombie would send only a few innocuous-looking packets, so detecting the attack would be more difficult. The attacker still gets the same result—a list of open ports—but it is received from a bunch of zombies. Similarly, an attacker could distribute the work of password cracking among a number of machines, thereby exploiting more processing capacity to crack passwords more quickly on a virtual supercomputer made up of zombie-infected machines. Be on the lookout for many more tools using a distributed model in the near future. We’ll look at such capabilities in the bot section in the next chapter.

Distributed Denial-of-Service Defenses

There are two areas of defense against DDoS attacks: keeping zombies off of your systems and defending against the packet flood itself. First of all, you definitely don’t want your systems to be a friendly home for zombies! Because attackers deploy most zombies using standard exploits against unpatched systems or tricking users into installing a bot via spoofed e-mail, you must keep your systems patched and exercise safe Internet usage. As we’ve discussed throughout this book, vigorously apply patches in a timely manner after testing them carefully. Also, don’t run untrusted e-mail attachments, and educate your users to avoid them as well. User education, along with solid antivirus and attachment filtering at mail servers can help stem a lot of these e-mail-borne zombies and bots.

However, because some attacker might still break into your systems and install a zombie, you must employ egress antispoof filters on your external router or firewall. Such filters drop all outgoing traffic from your network that does not have a source IP address found on your network. Such packets are indicative of a misconfigured host or a spoofing attack. Because DDoS attacks almost always involve spoofed packets, egress antispoof filters go a long way in protecting the outside world from a DDoS zombie running on one of your machines.

Additionally, if you suspect one of your systems has been compromised and is running a zombie, most antivirus tools have signatures to detect, quarantine, and uninstall the flooding agent. Make sure you have up-to-date antivirus signatures because the bad guys release several new zombie and bot variants every day!

You work very hard to keep zombies off of your own system so that your machines cannot be used to attack others, yet a few hundred thousand fools halfway around the planet haven’t patched their systems. An attacker compromises their machines, setting up scads of zombies to launch an attack against you. How can you defend yourself against the resulting DDoS flood? As with other flooding techniques we’ve discussed in this chapter, adequate bandwidth, redundant paths through multiple ISPs, and traffic shaping tools are a must for your critical Internet connections. Still, even with all of the bandwidth that your organization can likely afford, a large enough grouping of zombies can overwhelm any network. Think about it: Amazon.com was briefly taken offline in February 2000 in a DDoS flood. Can you afford more bandwidth than Amazon.com surely has? Most organizations simply cannot. You can’t win this arms race by just buying bigger pipes. You must have adequate bandwidth to prevent a simple script kiddie flood, but trying to buy up enough bandwidth to handle a massive DDoS attack will bankrupt most organizations.

The best defense against a massive DDoS attack involves rapid detection and the ability to muster the incident response forces of your ISP. You need to employ IDS tools that can quickly alert you when a DDoS attack starts. Based on this warning, if you have critical systems on the Internet (like e-commerce servers that your organization’s livelihood depends on or critical health care systems), you should be able to pick up the phone and speak with a member of the incident response team at your ISP. Your ISP should be able to rapidly deploy filters upstream to block the flood traffic at the points where it enters their network. Although this is a very reactive defensive strategy, it really is the best way to prepare for a massive DDoS onslaught and quickly stop one when it comes.

In fact, your ISP can really help improve this kind of defense using a variety of DDoS detection and throttling tools on their own network. These tools, which include Arbor Networks’ Peakflow, Mazu Networks’ Enforcer, and Cisco Guard DDoS Mitigation Tool, involve deploying sensors on very large-scale networks, such as an ISP or a big enterprise WAN. When these sensors discover huge bursts of traffic with patterns that match a DDoS attack, they can start throttling it by reconfiguring routers before the DDoS victim even notices the attack. Check with your ISP to see if they are employing such solutions, and if they aren’t, ask them why not. Emphasize to your ISP the importance of solid DDoS defenses. Gradually, with many people asking for them, we’ll likely see more widespread detection and throttling capabilities at the majority of ISPs to help control the DDoS menace.

Conclusion

In this chapter, we have discussed a variety of the most common DoS attacks in use today. Attackers’ motivations for using these tools vary, including petty revenge, overly zealous competition, or extortion. Regardless of their reasons, attackers want to bring a target system to its knees and will use a variety of attacks, ranging from locally stopping services through full-blown DDoS floods. Given the damage that can be inflicted through a DoS attack by a determined attacker, you must defend your critical system against such attacks.

At this stage of the siege, the attacker has completed Phase 3, having gained (or denied) access to the target systems. With access to the targets, the attacker now moves on to Phase 4, maintaining access, employing a variety of fascinating tools and techniques for keeping control of the target machines.

Summary

DoS attacks do not let an attacker gain access to a system; they let an attacker prevent legitimate users from accessing the system. Although they often aren’t technically elegant, DoS attacks can severely impact an organization, making defenses quite important. These attacks fall into two main categories: stopping a service and resource exhaustion. Each of these categories of attack can be launched locally or across the network.

Stopping services locally prevents users from accessing them. An attacker could kill a process that provides the service, reconfigure the system to stop the service, or even cause the service to crash. A logic bomb is a particularly nasty method for launching a local DoS attack. To defend against local DoS attacks, you must keep your systems patched in a timely manner and be careful when allocating super-user privileges.

Another DoS technique involves locally exhausting resources. Attacks in this realm include filling up the process table, consuming the entire file system, or exhausting communications links. To defend against such attacks, make sure users have the minimum level of privilege required for their job function. Also, you must equip systems with adequate memory, disk storage, and communications capacity.

An attacker could launch a DoS attack by remotely stopping services. A common technique for accomplishing this is to send a malformed packet that exploits a bug in the target operating system or application, causing it to crash. A large number of malformed packet attack tools are available. To defend against such attacks, you must keep your system patches up to date and apply antispoof filters.

The final category of DoS attacks is the most popular: remotely exhausting resources. Within this realm, packet-flooding tools dominate. To defend against most of these techniques, you must make sure you have adequate bandwidth and redundant communications paths.

SYN flooding involves initiating a large number of connections to a target without finishing the TCP three-way handshake. SYN cookies can help to defend against such attacks.

Smurf attacks are based on sending packets to the broadcast address of a network. If the destination network supports directed broadcasts, all machines on the network will send a response. By spoofing the address of the original packet, an attacker can flood a victim, using the network supporting directed broadcasts as an amplifier. To defend against Smurf attacks, make sure you do not allow directed broadcast messages from the Internet.

DDoS attacks are particularly damaging. An attacker takes over a large number of systems on the Internet, installs zombie or bot software on each of them, and uses them in a coordinated attack to flood a victim. DDoS attacks allow an attacker to consume enormous amounts of bandwidth. The more zombies an attacker has, the more bandwidth the attacker can consume. Attackers launch reflected DDoS attacks to obscure their zombies’ location, and utilize pulsing zombies to make tracing attacks even harder. HTTP floods look more like normal traffic than SYN floods, letting the attacker fool some detection systems. To defend against DDoS attacks, you should utilize IDSs to provide an early warning, and be prepared to activate the incident response team of your ISP.