CHAPTER 18

DENIAL-OF-SERVICE ATTACKS

Gary C. Kessler and Diane E. Levine

18.1 INTRODUCTION

18.2 DENIAL-OF-SERVICE ATTACKS

18.2.1 History of Denial-of-Service Attacks

18.2.2 Costs of Denial-of-Service Attacks

18.2.3 Types of Denial-of-Service Attacks

18.2.4 Specific Denial-of-Service Attacks

18.2.5 Preventing and Responding to Denial-of-Service Attacks

18.3 DISTRIBUTED DENIAL-OF-SERVICE ATTACKS

18.3.1 Short History of Distributed Denial of Service

18.3.2 Distributed Denial-of-Service Terminology and Overview

18.3.3 Distributed Denial-of-Service Tool Descriptions

18.3.4 Defenses against Distributed Denials of Service

18.4 MANAGEMENT ISSUES

18.5 FURTHER READING

18.6 NOTE

18.1 INTRODUCTION.

This chapter discusses denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks. These attacks seek to render target systems and networks unusable or inaccessible by saturating resources or causing catastrophic errors that halt processes or entire systems. Furthermore, they are increasingly easy for even script kiddies (persons who follow explicit attack instructions or execute attack programs) to launch. Successful defense against these attacks will come only when there is widespread cooperation among all Internet service providers (ISPs) and other Internet-connected systems worldwide.

Working in a variety of ways, the DoS attacker selects an intended target system and launches a concentrated attack against it. Although initially deemed to be primarily a “nuisance,” DoS attacks can incapacitate an entire network, especially those with hosts that rely on Transmission Control Protocol/Internet Protocol (TCP/IP). DoS attacks on corporate networks and ISPs have resulted in significant damage to productivity and revenues. DoS attacks can be launched against any hardware or operating system platform because they generally aim at the heart of Internet Protocol (IP) implementations. Because IP is the typical target, the DoS attack tools that run under one operating system (Linux is a common choice) can be aimed at any operating system running IP. Additionally, because IP implementations are similar for different platforms, one DoS attack may target several operating systems and work on each. Once written for one platform and released, new DoS attacks appear to evolve (via the examination and participation of hackers and crackers) so that in a short period of time (approximately two weeks) mutations of the DoS attack appear that work on virtually all platforms.

Because of the critical impact that DoS attacks can have, they cannot be taken lightly. DoS attacks have been around in one form or another since the 1980s; in 1999, they evolved into distributed DoS attacks, primarily due to the heavy use of internal networks and the Internet. DDoS tools launch coordinated DoS attacks from many sources against one or more targets simultaneously.

This chapter describes first DoS and then DDoS attacks. This arrangement is primarily due to the fact that DoS attacks historically predate DDoS attacks. In addition, some DDoS attacks make use of DoS techniques. However, the attacks themselves, the terminology, and the defenses are sufficiently different that they warrant separate discussion.

18.2 DENIAL-OF-SERVICE ATTACKS.

Historically, any act that prevented use of a system could be called a denial of service. For example, in some mainframe and minicomputer systems, typing a malformed command could cause a system failure; pressing the RETURN key on the system console could monopolize the device-recognition process of the operating system and use up all the central processing unit (CPU) cycles, thus preventing any further activity on the system. Typing one or more characters on the system console without pressing the RETURN key could block all further system messages on the console, causing system buffers to fill up with unprinted messages; when the system buffers were exhausted, no system action requiring notification to the console could take place (e.g., logons, logoffs, special-form requests, or tape-mount requests). However, such events were usually the result of bugs in the operating system, inadequate numbers of buffers for critical data, or accident.

18.2.1 History of Denial-of-Service Attacks.

One of the first major DoS incidents that made headlines and ripples far and wide was probably accidental. It took place in December 1987, when an employee of IBM in Europe sent out a holiday greeting e-mail message. The e-mail message, however, contained a program that drew a nice Christmas tree on the recipient's terminal—and read the recipient's NAMES and NETLOG files listing the user's address book as well as the e-mail addresses of individuals that this user had recently sent mail to or received mail from. The Christmas Tree program then triggered the automatic transmission of copies of itself to all e-mail addresses found in NAMES and NETLOG. The result overloaded the IBM corporate network worldwide and brought it crashing down both in Europe and the United States. In addition, messages “escaped” from IBM's corporate network and wreaked havoc on the BITNET/EARN education and research networks in North America and Europe. Although the cause of the outage was originally thought to be a computer virus, and the incident has been referred to as a virus, a worm, and a prank, the result was a true denial of service.

Perhaps the most famous Internet DoS resulted from the Morris Worm, also referred to as the Internet Worm, which occurred in November 1988. Cornell graduate student Robert T. Morris cowrote an article about some vulnerabilities in Sendmail and fingerd on UNIX systems. Most of the TCP/IP community dismissed the vulnerabilities as theoretical; apparently Morris wanted to demonstrate that the vulnerabilities actually could be practically exploited. To demonstrate the problem, his program had to invade another system, guess some passwords, and then replicate itself. Morris said after the incident that he wanted the program to replicate just a few times to demonstrate that it was real; unfortunately, a programming error led the worm to replicate often and quickly in addition to superinfecting already-infected systems. The worm clogged the Internet with hundreds of thousands of messages and effectively brought the entire network down; most sites that did not actually crash were disconnected from the network by their system administrators to avoid being infected and to allow disinfection. Regardless of intent, the Morris Worm inadvertently caused a DoS.

On Friday, September 6, 1996, PANIX, a public access Internet provider in Manhattan, was struck by a DoS attack that consisted of many messages flooding the server with massive amounts of data. The attacks were made against mail, news, name, and Web servers as well as user shell account machines. The attackers successfully eluded tracking, and the attacks went on for several days. About a week after the attacks began, PANIX went public with the story, and dozens of other online service providers acknowledged that they too were the victims of similar attacks.

In 1997, a disgruntled former employee of Forbes, Inc., used a former colleague's password to remotely access the firm's computer systems. Deliberately tampering with the system, he deleted budgets and salary information and caused five of the eight network servers to crash. When Federal Bureau of Investigation (FBI) agents caught the perpetrator, his home was filled with hacking tools, proprietary information from Forbes, Inc., and other incriminating material.

In February 1998, hackers from Israel and Northern California attacked the U.S. Department of Defense (DoD). In a carefully organized attack that exploited buffer overflow, these hackers systematically perpetrated a DoS attack that lasted over a week on 11 DoD sites.

In March 1988, all across the United States, system administrators found their Windows NT servers under apparently automated attack. Systems crashed repeatedly until they were updated to the latest patches from Microsoft. There appeared to be no file damage from the attacks, which lasted more than a day. Sites affected included several NASA and other military sites, as well as several University of California and other college campuses.

Yet another mailstorm erupted in May 1998 when an Australian official set autoreply on his e-mail package while he was away. Unfortunately, he inadvertently set his destination for these largely useless messages to be all 2,000 users on his network—and requested auto confirmation of delivery of each autoreply, which generated yet another autoreply, and so on ad infinitum. Within four hours, his endless positive-feedback loop generated 150,000 messages before his autoreply was shut down. The ripples lasted for days, with the perpetrator saddled with 48,000 messages in his in basket and a stream of 1,500 a day pouring in. This was another case of an inadvertent DoS attack.

In January 1999, someone launched a sustained denial-of-service attack on Ozemail, an important Australian Internet service provider. E-mail service was disrupted for users in Sydney.

In March 1999, the Melissa e-mail-enabled virus/worm swept the world in a few days as it sent copies of itself to the first 50 addresses in victims' e-mail address books. Because of this high replication rate, the virus spread faster than any previous virus in history. On many corporate systems, the rapid rate of internal replication saturated e-mail servers with outbound automated junk e-mail. Initial estimates were in the range of 100,000 downed systems. Antivirus companies rallied immediately, and updates for all the standard products were available within hours of the first notices from the CERT Coordination Center (CERT/CC). The Melissa macro virus was quickly followed by the PAPA MS-Excel macro virus with similar properties but that, in addition, launched DoS attacks on two specific IP addresses.

More recent attacks are discussed in the sections describing modern DoS tools.

18.2.2 Costs of Denial-of-Service Attacks.

What are the effects of these DoS attacks in terms of productivity and actual financial costs? It is difficult to place an exact monetary figure on DoS attacks. DoS attacks can interrupt critical processes in an organization, and such interruption can be costly. When a company's computer network is inaccessible to legitimate users and they cannot conduct their normal business, productivity is lowered. The negative effect is bound to carry over to the financial aspects of the business. However, putting exact figures to these effects is uncertain at best, and the estimates are widely disputed, even among security and business experts. In addition, many companies do not comment on the exact losses they suffer because they fear that the negative publicity will decrease their market share. This latter point is significant: In an early 1990s study of Wall Street firms, some of the companies suggested that if they were to be without their network for two to three days, they might never reopen their doors.

In the case of the Christmas Tree worm, it took IBM several days to clean up its network and resulted in the loss of millions of dollars, both for cleansing the system and in lost business because of lost connectivity and related productivity. Additionally, there was the embarrassment suffered by IBM, a noted technology company. The individual who launched the worm was identified and denied access to any computer account, while IBM had to write a letter of apology to the European Academic and Research Network (EARN) administrators.

In 1988, at the time of the Morris Worm, the Internet consisted of 5,000 to 10,000 hosts, primarily at research and academic institutions. As a result, although the Morris Worm succeeded in bringing many sites to a halt and gained worldwide notoriety, the financial and productivity impact on the commercial world was minimal. A similar incident today would wreak havoc and cost millions of dollars in losses.

By 1996, however, commercial reliance on the Internet was already becoming a matter of course. Working around the clock, the management at PANIX and at Cisco, the ISP's router vendor, kept the service provider up and running, but the network received 210 fraudulent requests per minute. Although the systems did not crash, thousands of subscribers were unable to receive their e-mail messages. Other sites were attacked in the same time frame as PANIX, including Voters Telecommunication Watch. No one took the blame for these attacks, and it has been widely assumed that they were triggered by articles on SYN DoS attacks (see the description below) that had recently appeared in 2600 Magazine and Phrack, journals that cater to hackers.

According to Forbes, Inc., the losses suffered by the firm because of the DoS attack perpetrated by the disgruntled former employee exceeded $100,000. Could it have been prevented? According to the firm, it is highly unlikely, since Forbes had no reason to suspect the individual was maintaining either the firm's confidential and sensitive material at home or that he was thinking of hacking into the computer system and deliberately doing damage. Although the firm had security on its systems, the perpetrator used the password of a legitimate, authorized user.

The DoS attack launched against the Department of Defense computers in 1998 proved that attackers could deny access to vital military information. In this particular instance, the attack was directed at unclassified machines that had only administrative and accounting records, but it was a blow to the confidence of the Department of Defense. Tying up the computers for over a week presumably reduced productivity, but the government would not comment on the actual cost from loss of machine time and personnel productivity.

These cases show that a DoS attack on a computer or network can be devastating to an organization. Important equipment and networks and even an entire organization can be disabled by such attacks.

Early DoS incidents often were described as annoying, frustrating, or a nuisance. However, with increasing sophistication and dependency on networking, it has become difficult to keep a sense of humor about such incidents. Especially in corporations, where the mission is to make a profit for the shareholder, company managers find it increasingly difficult to excuse being incapacitated because of a DoS or DDoS attack.

As these forms of attack become more sophisticated, so must the tools and methods for detecting and fighting them. Current products scan equipment and networks for vulnerabilities, trigger alerts when an abnormality is found, and frequently assist in eliminating the discovered problem.

18.2.3 Types of Denial-of-Service Attacks.

DoS attacks, whether accidental or deliberate, result in loss of service; either a host or a server system is rendered inoperable or a network is rendered inaccessible. DoS attacks are launched deliberately by an intruder (the preferred term for attacker in this context). Systems and networks that are compromised are referred to as the victims. And while DoS attacks can be launched from the intruder's system, they often are launched by an automated process that allows the intruder to start the attack remotely with a few keystrokes. These programs are known as daemons, and they are often placed on another system that the hacker has already compromised.

There are three basic types or categories of DoS attack:

1. Saturation. This type of attack seeks to deprive computers and networks of scarce, limited, or nonrenewable resources that are essential in order for the computers or networks to operate. Resources of this type include CPU time, disk space, memory, data structures, network bandwidth, access to other networks and computers, and environmental resources such as cool air and power.
2. Misconfiguration. This type of attack destroys or alters configuration information. Because poor or improperly configured computers may fail to operate or operate inadequately, this type of attack can be very severe.
3. 3. Destruction. This type of attack results in network components being physically destroyed or altered. To guard against this type of attack, it is necessary to have good physical security to safeguard the computers and other network components. This chapter does not deal with physical damage.

18.2.4 Specific Denial-of-Service Attacks.

This discussion of some specific DoS attacks covers the main methods extant at the time of writing; however, new types of attacks are anticipated.

18.2.4.1 Destructive Devices.

Destructive devices are programs that accomplish either harassment or destruction of data. There are mixed opinions regarding how severe destructive devices are, but if they threaten a computer's or network's ability to function properly and efficiently, then they may be the instruments of DoS attacks. Viruses, e-mail bombs, and denial-of-service tools all can be considered destructive devices. In fact, viruses and e-mail bombs are known to cause DoS attacks. More about viruses and other malicious software and their actions can be found in Chapter 16 of this Handbook; DDoS tools and e-mail bombs are discussed in the next sections.

18.2.4.2 E-mail (and E-mail Subscription) Bombing.

E-mail and e-mail subscription bombings were among the first documented DoS attacks. An e-mail bomb consists of large numbers of e-mail messages that are used to fill up a victim's electronic mailbox. A huge number of messages can tie up an online connection, slow down mail delivery, and even overload the e-mail server system until the system crashes. Most e-mail bombings are thought to be deliberate attacks by disgruntled people; specific targets may be victims of someone with a particular grudge. For example, a San Francisco stockbroker received 25,000 messages on September 23, 1996, consisting of the word “Idiot” from a consultant with whom he had had a disagreement. The flood of messages prevented him from using his computer, so in December the victim sued the perpetrator's employer for $25,000 of damages. On occasions in the past, such as with the Christmas Tree worm and the Internet Worm, the DoS is thought to have been accidental.

E-mail bomb packages automate the process of launching and carrying out an e-mail bombing DoS attack. With names like Up Yours, Kaboom, Avalanche, Gatemail, and the Unabomber, these packages can be placed on a network server during a DoS attack and used to attack other systems. Administrators who are aware of these names and others should regularly scan their drives for associated filenames and eliminate them.

To safeguard computers and/or servers, mail filters and exclusionary schemes can automatically filter and reject mail sent from a source address using e-mail bomb packages. Mail filters are available for UNIX, Windows, Macintosh, and Linux systems. Most computer operating systems and most ISPs now offer filtering tools for eliminating unsolicited commercial e-mail and other e-mail. Although perpetrators often disguise their identity and location by using a false address, most filters can be set to screen and eliminate these addresses.

With e-mail subscription bombing, also known as list linking, a user is subscribed to dozens of mailing lists by the attacker without the user's knowledge. For example, one of the earliest subscription-bombing incidents was perpetrated by someone calling himself “johnny xchaotic.” In August 1996, he claimed the blame for a massive mail-bombing run based on fraudulently subscribing dozens of victims to hundreds of mailing lists. In a rambling and incoherent letter posted on the Net, this person made rude remarks about famous and not-so-famous people whose capacity to receive meaningful e-mail was obliterated by up to thousands of unwanted messages a day. Today, filtering packages have point-and-click mechanisms that provide automatic list linking. A user conceivably could start to receive hundreds or thousands of mail messages per day if linked to just 50 to 100 lists. Once linked to the various lists, the victim has to manually unsubscribe from each individual mailing list. If an attack takes place while the victim is away and without access to e-mail, a user could have a backlog of thousands of messages by the time he or she returns.

List server software should never accept subscriptions without sending a request for confirmation to the supposed subscriber; however, even this safety mechanism can generate a wave of many single e-mail messages if a mail bomber abuses the list servers.

Speaking of being away, vacation messages and return receipts are another way in which individuals can inadvertently start an e-mail storm. Many users set their e-mail clients to automatically request a return receipt of all messages sent. Then the users go on vacation and set up an auto-reply vacation message. When they get a message, the client sends back the vacation message and also requests a receipt. The returned receipts, in turn, generate more auto-reply vacation messages.

Another variant on this feedback loop occurs when an employee goes on vacation and forwards all e-mail to an external ISP that has a local access number in the locale of the vacation. If the employee decides not to check the mail while away, either due to a high local access fee or so as not to interfere with the vacation, the ISP mailbox will fill up with forwarded messages. If the mailbox fills up, the ISP will send a bounce message back to the corporate server—which then forwards the bounce message back to the ISP, which generates yet another bounce message. Eventually, even the corporate mail server will fill up with a single individual's messages, causing an e-mail DoS.

18.2.4.3 Buffer Overflow.

Buffer overflow attacks can be insidious and dam-aging. It is possible to send an input string to a target program that contains actual code and is long enough to overflow the memory space or input buffer. Sometimes this surreptitious code is placed on the process stack (the area in a computer's memory where the operating system keeps track of the program's input and related code used for processing the inputs), and the code then is processed. An overflow can occur when the input data overflows its buffer space and flows into the stack, where it overwrites the previous data and return address. If the program is written so that the stack address points to the malicious code located in the return buffer, the code executes with the original program's privileges. Buffer overflow is the result of poor programming, where the programmer does not check the size of the input compared to the input buffer; the Internet Worm attack was based, in part, on such poor programming. Although buffer overflows have been around for years and should have been eradicated by now, new buffer overflow attacks pop up monthly.

Not all buffer overflows allow the user to insert executable code. DoS attacks such as the Ping of Death merely attach a data block that is larger than allowed by the IP protocol (i.e., greater than the 65,536 bytes). Because the packets are broken into fragments for transmission, they manage to get through the network and, probably, the router and firewall. Once reassembled at the target, however, the packets cause the IP kernel's buffer to overflow and the systems crashes.

Another example is an old flaw in Microsoft's Internet Information Server (IIS) that could be exploited to allow the Web service to be halted. To do this, an attacker would request a document with a very long URL from an IIS-based Web site. Upon receipt of the request, an access violation occurred and the server would halt. Although Microsoft issued a patch for this “security hole,” successful attacks continue to take place today. (And how does one identify an IIS site? If a Web site use pages with the .htm or .asp extensions, it is a good guess that the site is running IIS.)

18.2.4.4 Bandwidth Consumption.

Bandwidth consumption involves generating a large number of packets directed to the network under attack. Such attacks can take place on a local network or can be perpetrated remotely. If the attacker has, or can access, greater bandwidth than the victim has available, the attacker can flood the victim's network connection. Such saturation can happen to both high-speed and low-speed network connections. Although any type of packet may be used, the most common are Internet Control Message Protocol (ICMP) Echo messages (generated by Pinging). By engaging multiple sites to flood the victim's network connection, attackers can amplify the DoS attack. To do this successfully, the attackers convince the amplifying system to send traffic to the victim's network. Tracing the intruder who perpetrates a bandwidth consumption attack can be difficult since attackers can spoof their source addresses.

EXHIBIT 18.1 SMURF DoS Attack

The most common bandwidth consumption attack is called a SMURF attack. This attack is particularly interesting (and clever) since it uses tools that reside on every IP system and employs a third-party site without actually having to take control of any system anywhere. As Exhibit 18.1 shows, the SMURF attack starts when the intruder (at attacker.com) sends a continuous string of very large Ping messages to the IP broadcast address (* in the exhibit) of the unsuspecting third party, stooge.com. The intruder spoofs the source IP address of the Ping message so that it appears that these messages come from, say, the router at the target network, router.victim.com. If the intruder sends a single 10,000-byte Ping message to the broadcast address of an intermediate site with 50 hosts, for example, the responses will consume 4 megabytes (Mb).¹ Even if victim.com has a T1 line (with a bandwidth of 1.544 Mb per second), the attacker can swamp a victim's line merely by sending a single large Ping per second to the right stooge site. The intermediate site is called, for obvious reasons, the amplifying network; note that the attacker does not need to compromise any systems there. The ratio of originally transmitted packets to the number of systems that respond is known as the amplification ratio.

A variant of the SMURF attack is called a Fraggle attack. In this variant, the attackers send spoofed User Datagram Protocol (UDP) packets instead of Echo messages to the broadcast address of the amplifying network. Each system on the amplifying network that has the specific broadcast address port enabled will create large amount of traffic by responding to the victim's host; if the port is not enabled, the system on the amplifying network will generate ICMP Host Unreachable messages to the victim's host. In either case, the victim's bandwidth is consumed.

Kernel panic attacks are not due to programming flaws per se. The Intel Pentium chip that could not correctly divide two particular legal inputs had a programming flaw. An IP kernel that fails when receiving a packet that should never occur in the first place is, indeed, a gap in the program's logic but not the same as failing to handle legal input.

A specific example of kernel panic occurs in Linux kernel v.2.2.0 when a program usually used for printing shared library dependencies is used instead to print some core files. Under certain circumstances, munmap(), a function call used to map and unmap devices into memory, overwrites critical areas of kernel memory and causes the system to panic and reboot.

And there are other examples of these kinds of attacks. A Land attack occurs when a spoofed packet is sent to a target host where the TCP source port and destination port are set to the same value, and the IP source address and destination address also are set to the same value. Since this is confusing to the host, it results in 100 percent CPU utilization and then a halt. Land attacks have been directed at just about all operating systems.

Teardrop attacks are also the result of behavior when receiving “impossible” packets. If an IP packet is too large for a particular network to handle, the packet will be fragmented into smaller pieces. Information in the IP packet header tells the destination host how to reassemble the packet. In a Teardrop attack, the attacker deliberately crafts IP packets that appear to overlap when reassembled. This, too, can cause the host to crash. Teardrop attacks have been targeted against Microsoft operating systems and all variants of UNIX.

18.2.4.5 Routing and Domain Name System Attacks.

Routing and Domain Name System (DNS) attacks are clever attacks that are achieved repeatedly. By tampering with the DNS, a site's domain name resolves to the IP address of some other site. In August 1999, Gary D. Hoke Jr., a disgruntled engineer for PairGain Technologies, provided a direct link to a bogus but authentic-looking Bloomberg News Service page he had created. Hoke, who owned PairGain shares, posted false information about PairGain's supposed acquisition by an Israeli company, pumping up the price of PairGain stock worldwide and creating havoc in the market through his pagejacking exploits. Although a nontraditional DoS attack, Hoke's antics did deny users access to the site that they desired, with serious consequences.

Another example occurred in July 1997, when Eugene Kashpureff filed fraudulent information with InterNIC for its DNS updates in July, forcing domain name servers around the globe to recognize temporary and unauthorized Internet addresses ending in .xxx, .mall, .nic, and .per. A few weeks later, he inserted false information that forced people trying to access the Web site of Network Solutions Inc. to end up at Kashpureff's Alternic site.

In another example of a routing and DNS attack, RSA Security, Inc., after announcing that it had developed a method to combat Web site hackers, found that users were unwittingly being rerouted to a counterfeit RSA Web site. The fraudulent site looked exactly like the original RSA Web site but made fun of the fact that the hacker had managed to achieve his DoS goal.

As far back as 1997, weaknesses were found in and documented about BIND implementations in versions preceding 4.9.5+P1. The earlier versions would cache bogus DNS information when DNS recursion was enabled. The vulnerability enabled attackers to exploit the process of mapping IP addresses to hostnames in what is known as PTR record spoofing. This type of spoofing provides the potential for a DNS DoS attack.

DNS attacks are still seen widely today. Phishing is a form of social engineering attack whereby users are directed to bogus, but authentic-looking, bank or credit card company Web sites and enticed to enter personal information used for identity theft. If users were to look closely at the URL of the site, however, they would observe a suspicious URL. Pharming is a variant of phishing that relies on some form of DNS poisoning so that a user going to the actual URL of a bank or credit card company will be redirected to the bogus site.

EXHIBIT 18.2 Normal TCP 3-Way Handshake

18.2.4.6 SYN Flooding.

SYN flooding is a DoS attack that fits into the consumption-of-scarce-resource category. This DoS attack exploits the three-way handshake used by TCP hosts to synchronize the logical connection prior to data exchange. In a normal TCP host-to-host connection, the two hosts exchange three TCP segments prior to exchanging data, as shown in Exhibit 18.2:

1. The client sends a segment to the server with its initial sequence number (ISN). The SYN (synchronization) flag is set in this segment.
2. The server responds by sending a segment containing its ISN and acknowledges the client's ISN. This segment will have both the SYN and ACK (acknowledgment) flags set. At this point, the server allocates resources for the about-to-be-established connection and waits for the third segment.
3. The client sends a segment acknowledging the server's ISN. This and all subsequent segments until the end of the session will have only the ACK flag set.

A SYN flood takes advantage of the three-way handshake and the fact that a server can have only a finite number of open TCP connections. The attack is launched when an attacker initiates connections for which there will never be a third segment (see Exhibit 18.3). After the server sends the segment in step 2, it waits for a response. Under normal circumstances, the client will respond within a few seconds. The server might wait, say, 10 seconds before timing out and releasing the resources. But suppose the attacker sends hundreds of connection messages per second on a sustained basis. When these bogus connection attempts flood the target faster than they can time-out, there will not be any resource left in which to establish a legitimate connection. This is the type of attack that was launched against PANIX in 1996.

EXHIBIT 18.3 TCP SYN DoS Attack

18.2.4.7 Resource Starvation.

Resource starvation is a catchall category for many other types of DoS attacks that are the result of some scarce resource—be it bandwidth, processing power, disk space—being consumed and exhausted. One example uses a novel UDP DoS attack, where an intruder forges UDP packets and uses them to connect the echo service of one machine (UDP port 7) to the character generator (chargen) service on another machine (UDP port 19). When this occurs, the two machines consume all available network bandwidth, and all machines on the same networks as the target machines can be affected and starved for resources.

But such attacks can happen locally, as well. Unfortunately, many authorized users carry out local DoS attacks that either consume system resources or deny users access. Numerous resource starvation attacks and programming flaws attack specific systems. For instance, by exceeding imposed quotas on disk space, multiuser systems can suffer from a resource starvation attack. Most operating systems limit the amount by which a user can exceed disk quota. Windows 2000 has a twist on this; although individual files can exceed their quota by only a small amount, if every file exceeds the quota, a user can consume a lot of extra disk space.

18.2.4.8 Java.

Java is another avenue for DoS attacks. One such DoS attack exploits the fact that whenever specific internal elements of the Netscape and HotJava browsers lock, additional host lookups via the browser are prevented. Another DoS occurs by forcing the overutilization of the CPU and random access memory (RAM), resulting in the browser halting or freezing. During both of these events, the origin of further attacks could be obscured.

It is also possible for the Java browser's proxies to be neutralized or knocked out with the victim's DNS queries being rerouted to an untrusted DNS server. Such an untrusted server would provide misinformation in regard to host names, and this would snowball into a root compromise.

Java also can force a reboot on Windows 9x systems. An applet that works for Netscape Communicator 4.x can kill a Windows box.

18.2.4.9 Router Attacks.

Router attacks have been developed for a wide variety of routers. Because routers are the backbone of the Internet and the gateway through which organizations connect to the Internet, killing a router denies network service for hundreds of machines. Productivity and financial repercussions from a hardware attack can be very severe. Popular targets for these kinds of attacks are routers from Ascend, Cisco, Livingston (now Lucent), and 3Com. Unfortunately, many network managers make the attacks easy by employing Telnet or HTTP for remote access and do not properly secure the network against remote access by anyone over the Internet.

18.2.4.10 Other Denial-of-Service Attacks.

Even this list of specific DoS attacks is not exhaustive. For example, Bonk and boink (aka bonk.c) are DoS attacks that cause a target Windows 9x/NT system to crash. Arnudp (arnudp100.c) forges UDP packets to implement a DoS against UDP ports 7 (echo), 13 (daytime), 19 (chargen), and 37 (time), services that frequently run on UNIX and Windows NT systems. And cbcb.c is a cancelbot that destroys existing Usenet news postings that fit certain criteria. (Some argue that cbcb.c does not actually carry out a DoS attack; however, once activated, the program denies access to postings for targeted Usenet users.)

The CERT/CC (www.cert.org) and SANS (www.sans.org) have the most comprehensive lists of various DoS attacks.

18.2.5 Preventing and Responding to Denial-of-Service Attacks.

DoS attacks are best prevented; handling them in real time is very difficult. And the most important way to protect a system is to harden the operating systems: Install them with security in mind, monitor sites to be aware of security vulnerabilities, maintain the latest versions of software where possible, and install all relevant security patches.

But a large measure of the prevention consists of packet filtering at network routers. Because attackers frequently hide the identity of the machines used to carry out the attacks by falsifying the source address of the network connection, techniques known as egress filtering and ingress filtering are commonly used as protective measures. As discussed later in this chapter, egress and ingress filtering are methods of preventing packets from leaving or entering the network, respectively, with an invalid source address. By blocking addresses that do not fit the criteria for legitimate source addresses and making certain that all packets leaving an organization's site contain legitimate addresses, many DoS attacks can be thwarted.

Other packet-filtering methods that will help prevent DoS are to block all broadcast messages and most ICMP messages. There is no reason that a site should accept messages being broadcast to all hosts on the site. Furthermore, there is probably no good reason to allow all hosts to respond to Ping or traceroute messages; in fact, most ICMP messages probably can be blocked.

In some instances, victims have set up response letters triggered to send and resend in large quantities so that they flood the attacker's address. Doing this is generally not a good idea. If these messages are sent to a legitimate address, the attacker may “get the message” and stop. But the attackers generally spoof the source IP address, so responding in kind is not a good defensive posture because it may harm innocent victims. The best defense will involve the ISP.

In instances where the attacker's service provider can be identified and contacted, the victim can request that the service provider intervene. In these instances, it is usual for the ISPs to take appropriate action to stop the attack and find the perpetrator. However, in instances where a DoS appears to emulate or mimic another form of attack or when it continues for an unusually long period of time, the victim may want to take more aggressive action by contacting CERT/CC, the Federal Bureau of Investigation, and other authorities that have experience with DoS attacks and some jurisdiction if the perpetrators are caught.

Real-time defenses are difficult but possible. Many routers and external intrusion detection systems (IDSs) can detect an attack in real time, such as too many connection requests per unit time from a given IP host or network address. A router might block the connection requests or an IDS might send a pager message to a security administrator.

However, attacks such as SMURFs can suck up all of the bandwidth even before the packets get to the target site. Cooperation by ISPs and end user sites is required to fully combat DoS attacks. This will be addressed further as part of the discussion of responding to DDoS.

18.3 DISTRIBUTED DENIAL-OF-SERVICE ATTACKS.

DDoS tools use amplification to augment the power of the attacker. By subverting poorly secured systems into sending coordinated waves of fraudulent traffic aimed at specific targets, intruders can overwhelm the bandwidth of any given victim.

In a DDoS attack, the attacking packets come from tens or hundreds of addresses rather than just one, as in a standard DoS attack. Any DoS defense that is based on monitoring the volume of packets coming from a single address or single network will fail since the attacks come from all over. Rather than receiving, for example, 1,000 gigantic Pings per second from an attacking site, the victim might receive one Ping per second from 1,000 attacking sites.

One of the other disconcerting things about DDoS attacks is that the handler can choose the location of the agents. So, for example, a handler could target several North Atlantic Treaty Organization (NATO) sites as victims and employ agents that are all in countries known to be hostile to NATO. The human attacker, of course, might be sitting in Canada.

Like DoS attacks, all of the DDoS attacks employ standard TCP/IP messages—but employ them in some nonstandard ways. Common DDoS attacks have such names as Tribe Flood Network (TFN), Trin00, Stacheldraht, and Trinity. The sections that follow present some details about these attacks.

18.3.1 Short History of Distributed Denial of Service.

Denial-of-service attacks under a number of guises have been around for decades. Distributed DoS attacks are much newer. In late June and early July 1999, groups of hackers installed and tested a DDoS tool called trinoo (see Section 18.3.3.1) to launch medium to large DDoS attacks. Their tests involved over 2,000 compromised systems and targets around the world.

Most of the literature suggests that the first documented large-scale DDoS attack occurred in August 1999, when Trinoo was deployed in at least 227 systems (114 of which were on Internet2) to flood a single University of Minnesota computer; this system was down for more than two days.

On December 28, 1999, CERT/CC issued its Advisory CA-1999-17 (www.cert.org/advisories/CA-1999-17.html) reviewing DDoS.

On February 7, 2000, Yahoo was the victim of a DDoS during which its Internet portal was inaccessible for three hours. On February 8, Amazon, Buy.com, CNN, and eBay were all hit by DDoS attacks that caused them either to stop functioning completely or to slow down significantly. And, on February 9, E*Trade and ZDNet both suffered DDoS attacks. Analysts estimated that during the three hours Yahoo was down, it suffered a loss of e-commerce and advertising revenue that amounted to about $500,000. According to book seller Amazon.com, its widely publicized attack resulted in a loss of $600,000 during the 10 hours it was down. During their DDoS attacks, Buy.com went from 100 percent availability to 9.4 percent, while CNN.com's users went down to below 5 percent of normal volume and Zdnet.com and E*Trade.com were virtually unreachable. Schwab.com, the online venue of the discount broker Charles Schwab, was also hit but refused to give out exact figures for losses. One can only assume that to a company that does $2 billion weekly in online trades, the downtime loss was huge. Another type of damage caused indirectly by the DDoS was the decline in stock values in the 10 days following the attacks: eBay suffered a 24 percent decline, Yahoo dropped 15 percent, and Buy.com dropped 44 percent.

These types of DDoS attacks have continued since the summer of 1999. One of the best-known incidents was a series of DDoS attacks again Steve Gibson's GRC.COM Web site in May 2001. The attacker was a 13-year-old using an Internet Relay Chat (IRC) bot, automated programs that exploit systems using IRC clients to become DDoS zombies.

The DDoS attack that had the highest potentially devastating impact, however, occurred on October 21, 2002, when all of the top-level DNS root servers were subjected to a sustained attack by thousands of zombies. Nine of the 13 DNS root servers were knocked off the Internet; the remaining 4 were able to keep operating during the attack. All of the major ISPs and many large private networks maintain their own DNS systems, although most servers ultimately rely on the root servers to find noncached DNS entries. The attack lasted for just an hour or two; had it continued for much longer, the remaining servers probably would have been overwhelmed, effectively blocking DNS host name/address translation.

A disturbing trend that is growing is the use of DDoS as an extortion tool. An increasing number of criminals are using DDoS tools as a way to threaten an attack rather than actually disrupting a target organization's network. Although several providers of network, security, and consulting services claim that they and many of their customers have received such extortion demands, few are public about naming the targets—many of whom are acceding to the threats and paying the blackmail. Most experts agree that the extortion demands should not be met; doing so only encourages the criminal behavior. If such a threat is received, the organization's ISP and law enforcement authorities should be contacted immediately.

18.3.2 Distributed Denial-of-Service Terminology and Overview.

To describe and understand DDoS attacks, it is important to understand the terminology that is used to describe the attacks and the tools. Although the industry has more or less settled on some common terms, that consensus did not come about until well after many DoS/DDoS attacks had already appeared in the hacker and mainstream literature. Early descriptions of DDoS tools used a jumble of terms to describe the various roles of the systems involved in the attack. At the CERT/CC Distributed System Intruder Tools Workshop held in November 1999, some standard terminology was introduced. Those terms are used in the paragraphs that follow (see www.cert.org/reports/dsit_workshop-final.html or www.cert.org/reports/dsiLworkshop.pdf). To align those terms and the terms used by the hacker literature as well as early descriptions, here are some synonyms:

Intruder—also called the attacker or client.

Master—also called the handler.

EXHIBIT 18.4 DDoS Phase 1

Daemon—also called an agent, bcast (broadcast) program, or zombie.

Victim—also called the target.

DoS/DDoS attacks actually have two victims, namely the ultimate target as well as the intermediate system(s) that were exploited and loaded with daemon software. In this chapter, the focus is on the end-of-the-line DoS/DDoS victim.

DDoS attacks always involve a number of systems. A typical DDoS attack scenario might follow roughly these three steps:

1. 1. The intruder finds one or more systems on the Internet that can be compromised and exploited (see Exhibit 18.4). This is generally accomplished using a stolen account on a system with a large number of users or inattentive administrators, preferably with a high-bandwidth connection to the Internet. (Many such systems can be found on college and university campuses.)
2. 2. The compromised system is loaded with any number of hacking and cracking tools, such as scanners, exploit tools, operating system detectors, rootkits, and DoS/DDoS programs. This system becomes the DDoS master. The master software allows it to find a number of other systems that can themselves be compromised and exploited. The attacker scans large ranges of IP network address blocks to find systems running services known to have security vulnerabilities. This initial mass-intrusion phase employs automated tools to remotely compromise several hundred to several thousand hosts, and installs DDoS agents on those systems. The automated tools to perform this compromise are not part of the DDoS toolkit but are exchanged within groups of criminal hackers. These compromised systems are the initial victims of the DDoS attack. These subsequently exploited systems will be loaded with the DDoS daemons that carry out the actual attack (see Exhibit 18.5).

   

   EXHIBIT 18.5 DDoS Phase 2

3. The intruder maintains a list of owned systems, the compromised systems with the DDoS daemon. The actual denial-of-service attack phase occurs when the attacker runs a program at the master system that communicates with the DDoS daemons to launch the attack. Here is where the intended DDoS victim comes into the scenario (see Exhibit 18.6).

Communication between the master and daemons can be obscured so that it becomes difficult to locate the master computer. Although some evidence may exist on one or more machines in the DDoS network regarding the location of the master, the daemons normally are automated so that it is not necessary for an ongoing dialog to take place between the master and the rest of the DDoS network. In fact, typically techniques are employed to deliberately camouflage the identity and location of the master within the DDoS network. These techniques make it difficult to analyze an attack in progress and difficult to block attacking traffic and trace it back to its source.

In most cases, the system administrators of the infected systems do not even know that the daemons have been put in place. Even if they do find and eradicate the DDoS software, they cannot help anyone determine where else the software may have been placed. Popular systems to exploit are a site's Web, e-mail, name, or other servers since these systems are likely to have a large number of open ports, a large amount of traffic, and are unlikely to be quickly pulled off-line even if an attack can be traced to them.

18.3.3 Distributed Denial-of-Service Tool Descriptions.

This section provides some details on how some of the major DDoS tools work.

EXHIBIT 18.6 DDoS Phase 3

18.3.3.1 Trinoo (Trin00).

Trinoo, also called trin00, was the first known DDoS tool, appearing in June or July 1999. The typical installation of trinoo is similar to the scenario painted above where an attacker plants handler software on a system and the handler, in turn, loads the attack software on the agents. Trinoo is a distributed SYN DoS attack.

Trinoo uses a number of TCP and UDP ports:

• Masters listen on TCP port 27665 for attacker-to-master communication.
• Daemons listen on UDP port 27444 for master-to-daemon communication.
• Masters listen on UDP port 31335 for daemon-to-master communication.

These are default port numbers, of course, and future implementations could use other ports. The human attacker can control a trinoo master (the handler) remotely via a connection to TCP port 27665. After connecting, the attacker gives the expected password, betaalmostdone.

The trinoo master program is typically named master.c and the daemon is ns.c. Communication between the trinoo master (handler) and daemons (agents) is via UDP. Master-to-daemon communications use UDP datagrams on port 27444. All commands contain a password, the default being l44adsl. All valid commands contain the substring l44.

Communication from the trinoo daemons to the master use UDP datagrams on port 31335. When the daemon starts, it sends a message to the master containing the string *HELLO*. The trinoo keep alive function is accomplished by an exchange between the master and daemon: The master sends a trinoo mping command, which sends the string png to a daemon; the daemon responds by sending the string PONG to the master.

The passwords are here to prevent system administrators from being able to take control of the masters and daemons that form the trinoo network. Other default passwords in the initial attacks were gOrave to start the trinoo master server and killme to control the master's mdie command to kill the trinoo processes. Like the port numbers, the passwords can be changed easily.

Intrusion detection software or system management routine analysis can look for a number of things that might indicate the presence of trinoo:

• A system listening on UDP port 27444 could be a trinoo daemon.
  • Trinoo daemon communication will contain the string l44.
  • The SYN flood mechanism picks the destination port using a random number generator function.
  • A trinoo daemon will send the string PONG if it receives a png command.
• A system listening on TCP port 27665 could be a trinoo master.
• A system listening on UDP port 27444 could be a trinoo master.
  • UDP packets will contain the string l44adsl.

A detailed analysis of trinoo by Dave Dittrich can be found at staff.washington. edu/dittrich/misc/trinoo.analysis.

18.3.3.2 Tribe Flood Network.

The Tribe Flood Network (TFN) appeared after trinoo. TFN runs primarily on compromised UNIX systems exploited using buffer overrun bugs in the RPC services. TFN client and daemon programs implement a DDoS network capable of employing a number of attacks, such as ICMP flood, SYN flood, UDP flood, and SMURF-style attacks.

TFN is noticeably different from trinoo in that all communication between the client (attacker), handlers, and agents use ICMP ECHO and ECHO REPLY packets. Communication from the TFN client to daemons is accomplished via ICMP ECHO REPLY packets. The absence of TCP and UDP traffic sometimes makes these packets difficult to detect because many protocol monitoring tools are not configured to capture and display the ICMP traffic.

Remote control of the TFN network is accomplished by executing a program on the client system. The program also can be executed at the handler system by the client via some host-to-host connection method, such as connecting to an exploited TCP port or using a UDP- or ICMP-based remote shell. The program must be supplied:

• The IP address list of hosts that are ready to carry out the flood attack
• The type of attack to be launched
• The IP address list of target hosts
• The port number for SYN attack

No password protection is associated with TFN. Each command to the daemons is sent in the Identifier field of the ICMP packet; values 345, 890, and 901 start the SYN, UDP, and ICMP flood attacks, respectively. The Sequence Number field in the ECHO REPLY message is always set to 0x0000, which make it look like the response to the initial ECHO packet sent out by the ping command.

The TFN client program typically is named tribe.c and the daemon is td.c. A detailed analysis of TFN by Dave Dittrich can be found at staff.washington.edu/dittrich/misc/tfn.analysis.

18.3.3.3 Stacheldraht.

Stacheldraht (German for “barbed wire”) is a DDoS tool that appeared in August 1999 and combines features of trinoo and TFN. It also contains some advanced features, such as encrypted attacker-master communication and automated agent updates.

Stacheldraht uses a trinoo-like client/server architecture. The handler listens on TCP port 16660 for client (intruder) commands, and the agents listen on TCP port 65000 for commands from the handler. Agent responses to the handler employ ICMP ECHO REPLY messages. The possible attacks are similar to those of TFN; namely, ICMP flood, SYN flood, UDP flood, and SMURF attacks.

Trinoo and TFN exchange commands in plaintext. Trinoo, being TCP-based, is also subject to common TCP attacks, such as session hijacking. Stacheldraht addresses these deficiencies by employing an encrypting “telnet alike” client. (“Telnet alike” is a Stacheldraht term.) The client uses secret key cryptography.

The Stacheldraht network comprises a number of programs. The attacker uses an encrypting client called telnetc/client.c to control to one or more handlers. The handler program is called mserv.c, and each handler can control up to 1,000 agents. The agent software, leaf/td.c, coordinates the attack against one or more victims upon command from the handler.

Dave Dittrich's analysis of stacheldraht can be found at staff.washington.edu/dittrich/misc/stacheldraht.analysis.

18.3.3.4 TFN2K.

Tribe Flood Network 2K (TFN2K) was released in December 1999 and targets UNIX and Windows NT servers. TFN2K is a complex variant of the original TFN with features designed specifically to:

• Make TFN2K traffic difficult to recognize and filter
• Remotely execute commands
• Hide the true source of the attack using IP address spoofing
• Transport TFN2K traffic over multiple transport protocols including UDP, TCP, and ICMP
• Confuse attempts to locate other nodes in a TFN2K network by sending “decoy” packets

TFN2K, like TFN, can consume all of a system's bandwidth by flooding the victim machine with data. But TFN2K, unlike TFN, also includes attacks designed to crash or introduce instabilities in systems by sending malformed or invalid packets, such as those found in the Teardrop and Land attacks.

TFN2K uses a client-server architecture in which a single client issues commands simultaneously to a set of TFN2K agents. The agents then conduct the DoS attacks against the victim(s). The agent software is installed in a machine that already has been compromised by the attacker.

An early description of TFN2K from CERT/CC can be found at www.cert.org/advisories/CA-1999-17.html.

18.3.3.5 Other Types of Distributed Denials of Service.

Trinoo, TFN/TFN2K, and Stacheldraht are the best-known, and still most widely used, DDoS tools, but more tools are becoming available.

In November 1999, for example, the Shaft DDoS tool became available. A Shaft network looks conceptually similar to a trinoo network with client-managing handler programs (“shaftmaster”) that, in turn, manage agent programs (“shaftnode”). Like trinoo, handler-agent communication uses UDP, with the handler(s) listening on port 20433 and the agent(s) listening on port 18753. The client communicates with the handler by telnetting to TCP port 20432. The attack itself is a packet flooding attack, and the client controls the size of the flooding packets and duration of the attack. One signature of Shaft is that the sequence number for all TCP packets is always 0x28374839. Additional information about Shaft can be found at www.sans.org/y2k/shaft.htm.

In August 2000, a DDoS attack against Apache Web servers was first detected. The attack took advantage of a vulnerability whereby a URL sent to an Apache Web server containing thousands of forward slashes (“/”) would put the server into a state that would consume enormous CPU time. This particular attack was launched by over 500 compromised Windows computers and would, presumably, succeed against Apache Web servers prior to version 1.2.5.

During the following month, a new DDoS tool called Trinity was reported. Trinity is capable of launching several types of flooding attacks on a victim site, including UDP, fragment, SYN, RST, ACK, and other floods. Trinity agent software must be placed on Linux systems compromised by a buffer overflow vulnerability. The agent binary code typically is found in /usr/lib/idle.so. Communication from the handler or intruder to the agent, however, is accomplished via Internet Relay Chat (IRC) or America Online's ICQ instant messaging software. Whereas the attacker has to keep track of the IP addresses of compromised systems with Trinoo and TFN, all of the Trinity agents report back to the attacker by appearing in the same chat room. The original reports were that the Trinity agent communicated over an IRC channel called #b3eblebr0x; other IRC channels presumably are being used for DDoS, as well. IRC uses TCP ports 6665 to −6669, and Trinity appears to use port 6667. In addition, a binary called /var/spool/uucp/uucico is a backdoor program that listens on TCP port 33270 for connections; an attacker connecting on that port and providing the password !@# will achieve rootshell on the affected system.

Zombie software is not always distributed by an attacker exploiting a vulnerability of an exposed system. Indeed, very often the user is the culprit. Trojan horses are often the mechanism for distributing the zombie code. The SubSeven Defcon8 software, for example, is abackdoor virus that is rapidly spreading. SubSeven gets on auser's system because it is distributed within programs available via Usenet and other Internet sites, such as some game or pornography programs (e.g., SexxxyMovie.mpeg). Potential attackers frequently scan computer systems today, particularly residential systems connected to the Internet via DSL or cable modem, for the presence of SubSeven, which provides a potential backdoor into users' systems; system administrators also are learning to scan for this dangerous program on their own systems.

18.3.3.6 Denial of Service Using Exploitable Software.

The tools just discussed employ the common DoS approach: An attacker exploits a vulnerability of a potential victim and uses that system to launch attacks on the intended victim. The latest round of DDoS attacks, however, use code that is commonly available and that has known vulnerabilities.

In May 2001, a buffer overflow exploit was discovered in the Microsoft Internet Information Service (IIS) Indexing Service. In mid-June, Microsoft released a security bulletin warning that administrative scripts (.ida files) and Internet data queries (.idq files) did not do proper bounds checking. As it happens, what seems like the vast majority of IIS servers did not get the patch, and, in essence, every unpatched IIS server became a DDoS zombie.

In July, eEye Digital Security and several other security organizations around the Internet saw an alarming number of TCP port 80 scans on the Internet. What they eventually discovered was what became known as the Code Red Worm.

Code Red has three distinct phases. The propagation phase occurs during the first 19 days of the month. During this phase, the attacking system scans target systems on TCP port 80 and sends a specially crafted HTTP GET request that exploits the IIS buffer overflow (even if the Index Service is not running). A common log entry might appear as:

211.5.255.44 - - [16/Aug/2001:11:30:49 -0400] “GET
/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u685
8%ucbd3%u7801u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u
9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00
=a HTTP/1.0” 400 357

If the exploit is successful, the worm runs in RAM of the infected server and spawns 99 new threads to attack a quasi-random set of IP addresses. If the exploited server's native language is English, the server's Web page is defaced with a message that says “Welcome to http://www.worm.com! Hacked by Chinese!” This message would stay up for 10 hours and then disappear.

The flood phase occurs on days 20 to 27 of the month. This is when the attack really happens; every day between 8:00 and 11:59 P.M. UTC, the compromised servers send 100 KB packets to the IP address 198.137.240.91, which formerly was assigned to www.whitehouse.gov.

Days 28 to 31 of the month are the termination phase, when the worm becomes dormant. Code Red was relatively innocuous to what it could have been; once asleep, the worm stayed asleep although it could be reawakened. Removing the worm program from RAM only required a reboot, and the patch from Microsoft would prevent further infection.

As an aside, although only IIS servers could be exploited, many other devices that listen on port 80 were also affected. Cisco 600 DSL routers and HP JetDirect devices, for example, listen on port 80 and would crash when they received the buffer overflow packet.

Three different variants of Code Red existed on the Internet, all acting as described. In August, a couple of new variants appeared that have been called Code Red II. Unlike Code Red, Code Red II did not deface Web pages nor did it launch a DDoS attack on any given site. Instead, this worm was destructive, installing backdoors on infected servers, changing many registry settings, installed a Trojan horse version of explorer.exe (Windows Explorer), and disabling the System File Checker (SFC) utility. The worm also spread very quickly, employing up to 300 threads at a time looking for other systems to infect.

The next evolution appeared in September 2001, and was called NIMDA. NIMDA (a play on the term admin) was truly unique because it exploited multiple vulnerabilities in Microsoft code, namely IIS, Internet Explorer (IE), and the Message Application Program Interface (MAPI). As a result, NIMDA had four distinct propagation vectors (see Exhibit 18.7):

EXHIBIT 18.7 NIMDA Propagation Vectors

1. IIS. When a Web server is found, the attacker attempts to exploit various IIS vulnerabilities, including IIS sadmind, a Code Red II root.exe or other backdoor program, or IIS Directory Traversal. If successful, the attacker uses tftp from cmd.exe to send the worm code (admin.dll) to the victim.
2. Web browser. The worm on an infected server creates a copy of itself in a file called readme.eml. The worm also alters every Web-content file at the infected site with a small JavaScript code that points to this file. When some user browses to the infected Web server, the infected page's JS code is activated, and readme.eml is downloaded. Vulnerable versions of Internet Explorer will auto-execute the file while most other browsers won't.
3. E-mail. NIMDA sends itself to all of the e-mail addresses found in the InBox and Address Book of an infected server in a MIME-encoded, 56KB attached file named readme.exe. The file contains an “audio/x-wav” section that contains the worm. E-mail clients using IE 5.1 or earlier to display HTML will automatically execute the attachment if the message is opened or previewed.
4. Network shares. When on an infected system, the worm copies itself to all local directories on victim host and to all open, writeable network shares. The worm also sets up shares on the victim host.

In addition, the GUEST account on the infected system is activated and made a member of Administrator group.

18.3.4 Defenses against Distributed Denials of Service.

As with DoS attacks, a site cannot in isolation defend itself from DDoS attacks. Members of the Internet community must work together to protect every site against becoming the source of attacks or forwarding the attacks. This section discusses some ways to help prevent the spread of DDoS attacks by limiting the distribution of the tools and by limiting the propagation of the offending attack packets.

Although not discussed in detail here, another point needs to be made about DDoS attack responses. As discussed in Chapter 38 in this Handbook, victims of such an attack should maintain detailed logs of all actions they take and events they detect. These logs may prove invaluable in understanding the attack, in preventing other attacks at the initial target and others, and in aiding law enforcement efforts to track down the perpetrators.

18.3.4.1 User and System Administrator Actions.

The next seven steps should be taken to minimize the potential that an individual system will be compromised and attacked or used as a stepping-stone to attack others:

1. Keep abreast of the security vulnerabilities for all of the site's hardware, operating systems, and application and other software. This sounds like a Herculean task, but it is essential to safeguarding the network. Apply patches and updates as soon as possible. Standardize on certain hardware, operating systems, and software where feasible to help manage the problem.
2. Use personal firewall software on workstations to detect an attack.
3. Monitor systems periodically to test for known operating system vulnerabilities. Also periodically check to see what TCP/UDP ports are using the “netstat –a” command; every open port should be associated with a known application. Turn off all unused applications.
4. Regularly monitor system logs and look for suspicious activity.
5. Use available tools to periodically audit systems, particularly servers, to ensure that there have been no unauthorized/unknown changes to the file system, registry, user account database, and so on.
6. Do not download software from unknown, untrusted sites. If possible, know the author of the code. Even better, download source code, review it, and compile it on a trustworthy system rather than downloading binaries or executables.
7. Keep up with and follow recommendations from the CERT/CC, SANS Institute, Internet Engineering Task Force (IETF) Requests for Comments (RFCs), and other best practices.

18.3.4.2 Local Network Actions.

Even if users lock down their systems so that no vulnerability has gone unpatched and no exposure unprotected, the local network itself still can be at risk. Local network managers and network administrators can take four steps to protect all of their own users as well as the rest of the Internet community:

1. Every network connected to the Internet should perform egress address filtering at the router. Egress filtering means that the router should examine the IP Source Address field of every outgoing packet to the Internet to be sure that the NETJD matches the NET_ID of the network. Historically users' firewalls have been used to protect users from attacks from the outside world. But those attacks come from somewhere, so sites should also use the firewall to protect the outside world.
2. Networks should block incoming packets addressed to the broadcast address (the all-ones HOST_ID). There is no legitimate reason that an external network device should be sending a broadcast message to every host on a network.
3. To prevent a site from being used as a broadcast amplification point, turn off the Directed Broadcast capability at the router unless it is absolutely essential. If it is essential, reexamine the network to see if there is not a better way. Even where Directed Broadcasts are useful, typically they are needed only within the enterprise and are not required for hosts on the outside.
4. RFC 1918 defines three blocks within the IP address space that are reserved for private IP networks; these addresses are not to be routed on the Internet.

In addition, there are a number of reserved IP addresses that are never assigned to “public” networks or hosts, including:

Attackers commonly use IP address spoofing, generally by using one of the RFC 1918 private addresses or one of the other reserved addresses. Firewalls should immediately discard any packet that contains any RFC 1918 or reserved IP address in the IP Source Address or Destination Address field; such packets should never be sent to the Internet.

1. Block all unused application ports at the firewall, particularly such ports as IRC (6665–6669/tcp) and those known to be associated with DDoS tools.
2. Use some form of intrusion detection system to protect the network. For example, one can install personal firewall software on every workstation to help detect an attack on individual systems; this strategy is particularly useful at sites (e.g., colleges) that have a large number of systems in front of a firewall. It is no coincidence that so many daemons reside on college and university computers that have been taken owned (i.e., taken over by hackers).
3. Regularly monitor network activity so that aberrations in traffic flow can be detected quickly.
4. Educate users about things to watch for on their systems and how to report any irregularity that might indicate that someone or something has tampered with their system. Educate the help desk and technical support to assist those users who make such reports. Have an intelligence-gathering system within the organization so that such reports can be coordinated centrally to spot trends and to devise responses.
5. Follow CERT/CC, SANS, US-CERT, and other best practices procedures.

18.3.4.3 Internet Service Provider Actions.

Internet service providers offer the last hope in defeating the spread of a DDoS attack. Although the ISP cannot take responsibility for locking down every customer's host systems, ISPs have—and should accept—the responsibility to ensure that their network does not carry packets that contain obviously “bad” packets. Some of the steps that ISPs can take include:

• As mentioned, attackers commonly employ IP address spoofing using an RFC 1918 private address or other reserved address. Amazingly, many ISPs will route these packets. Indeed, there is no entry in their routing table telling them where to send the packets; they merely forward them to a default upstream ISP. Any packet that contains any RFC 1918 or reserved IP address in the IP Source Address or Destination Address field should be discarded immediately.
• Perform ingress (and egress) address filtering. Ingress filtering means that ISPs should examine every incoming packet to their network from a customer's site and examine the IP Source Address field to be sure that the NET_ID matches the NET_ID assigned to that customer. Doing this will require additional configuration at the router and may even result in slight performance degradation, but the tradeoff is certainly well worth the effort. The ISPs also should perform egress filtering to check their outbound packets to upstream and peer ISPs.
• Disable IP directed broadcasts.
• Pay careful attention to high-profile systems (servers) and customers.
• Educate customers about security and work with them to help protect themselves.

Most of the ISP community takes at least some of these steps. Users should insist that their ISPs provide at least these protections and should not do business with those that do not. The ICSA Labs ISP Security (ISPSec) community (www.icsa.net/html/communities/ispsec) is a good source of information for ISPs.

18.3.4.4 Code Red/NIMDA Defensive Actions.

There are a number of defensive steps that can be taken to avoid or mitigate problems due to NIMDA, although several of these are controversial.

• If you are using IIS, consider using alternate Web server software. If you must use IIS, the only way to clean up after NIMDA is to reinstall IIS on a new, clean installation of the underlying operating system. Keep IIS and the operating system up to the latest patch revision. Microsoft's IIS Cumulative Patch does not clean a system of Code Red II backdoors or NIMDA.
• If you use Internet Explorer, consider using alternate browser software. If you must use IE, secure it against MIME auto-execution. IE 5.01 requires a patch whereas IE 5.5 SP2 and IE 6.0 are already immune.
• Disable any and all unused accounts on your system. In particular, enable the Guest account or anonymous access only if necessary.
• Disable JavaScript, Java, and ActiveX on your browser and turn those features on only if they are needed while you are on a safe site.
• Do not execute readme.exe or any e-mail attachment unless expected, known, and verified.
• Use most up-to-date antivirus signature files.
• Unbind file and print sharing from TCP/IP. In some cases, this will require in-stalling NetBEUI for file and print sharing.

18.3.4.5 Other Tools under Development or Consideration.

Responses to DDoS attacks are not limited to the defensive steps just listed. Indeed, proactive responses to the prevention and detection of DDoS attacks are an active area of research.

One method that is being discussed is to examine the network at the ISP level and build a type of intelligent, distributed network traffic monitor; in some sense, this would be like an IDS for the Internet. ISPs, peering points, and/or major host servers would have traffic monitor hardware using IP and the Internet for communications, much like today's routing protocols. Each node would examine packets and their contents, doing a statistical analysis of traffic to learn the normal patterns. These devices would have enough intelligence to be able to detect changes in traffic level and determine whether those changes reflected a normal condition or not. As an example, suppose that such hardware at Amazon.com were to identify a DoS attack launched from an ISP in Gondwanaland; the traffic-monitoring network would shut off traffic to Amazon coming from that ISP as close to the ISP as possible. In this way, the distributed network of monitors could shut traffic off at the source.

The hardware would need to be informed about traffic-level changes due to normal events, such as a new Super Bowl commercial being posted at the Ad Critic Web site or a new fashion show at Victoria Secret's Web site. The hardware also would need to prevent the attacker community from operating under the cover of these normal events.

RSA Laboratories has proposed another potential defense to DDoS attacks against Web servers that employs cryptographic methods. The approach uses a client puzzle protocol designed to allow servers to accept connection requests from legitimate clients and block those from attackers. A client puzzle is a cryptographic problem that is generated in such a way as to be dependent on time and information unique to the server and client request.

Under normal conditions, a server accepts any connection request from any client. If an attack is detected, the server selectively accepts connection requests by responding to each request with a puzzle. The server allocates the resources necessary to support a connection only to those clients that respond correctly to the puzzle within some regular TCP time-out period. A bona fide client will experience only a modest delay getting a connection during an attack, while the attacker will require an incredible amount of processing power to sustain the number of requests necessary for a noticeable interruption in service, quickly blocking the attack (in effect, a reverse DoS). This scheme might be effective against a DDoS attack from a relatively small number of hosts each sending a high volume of packets but would appear to have limited effectiveness against a low-volume attack from a large number of systems.

A third mechanism that is the subject of considerable research is IP Traceback. The problem with DoS/DDoS attacks is that packets come from a large number of sources, and IP address spoofing masks those sources. Traceback marking, in concept, is a relatively straightforward idea. Every packet on the Internet goes through some number of ISP routers. The processing power, memory, and storage are available for routers to mark packets with partial path information as they arrive. Since DoS/DDoS attacks generally comprise a large number of packets, the traceback mechanism does not need to mark every packet, but only a sample size that statistically is likely to include attack packets (e.g., 1 packet out of every 20,000). The feature allows the victim to locate the approximate source of the attack without the aid of outside agencies and even after the attack has ended. Another traceback proposal would define an ICMP Traceback message that would be sent to the victim site containing partial route information about the sampled packet. There are many issues related to traceback that need to be resolved, such as the minimum number of marked packets required to reconstruct the path back to the attacker, the actual processing overhead, and the ability to perform traceback while an attack is under way. In addition, any traceback solution will require a change to tens of thousands of routers in the Internet; how effective can traceback be during a period of gradual implementation? The upside, of course, is that the solution is backward compatible and results in no negative effects on users.

A fourth proposal is to modify IP to be less prone to address spoofing by making the protocol less dependent on the address field for anything more than routing. The Host Identity Payload (HIP), for example, defines a protocol for the exchange of a cryptographic Host Identity between two communicating systems. This feature relegates the IP address for use solely as a mechanism for packet forwarding rather than as an identifier of the sender. Sender identification, instead, is accomplished by the Host Identity value, and all of the higher layer protocols are bound to the Host Identity. HIP is not yet widely deployed but is available in some TCP/IP implementations.

These proposals are merely samples of some ways for dealing with DDoS attacks; the first adds new hardware to the Internet, the second requires changing Web server and client software, and the latter two require incrementally changing software in all of the Internet's routers and hosts, respectively. Upgrading Web browsers is probably the most practical strategy even though there are millions of copies in distribution; the vast majority come from two vendors, and users tend to upgrade frequently anyway.

18.4 MANAGEMENT ISSUES.

One of the greatest shortcomings in many organizations is that the highest levels of management do not truly understand the critical role that computers, networks, information, and the Internet play in the life of the organization. It is difficult to explain that there is an intruder community that is actively working on new tools all the time; and history has shown that as the tools mature and become more sophisticated, the technical knowledge required of the potential attacker goes down and the number of attacks overall goes up. Too many companies insist that “no one would bother us” without realizing that any site can become a target just by being there.

DoS attacks come in a variety of forms and aim at a variety of services, causing increased complexity and difficulty for system defense. DoS attacks should be taken seriously because of the potential threat they present, and attempts should be made to educate operational staff before such attacks occur, to document DoS attacks if they do occur, and to review the documentation and actions taken after the incident is over. Discussion of what steps were taken, what actions went into effect, and what the overall result was will help in determining whether the procedures carried out and techniques utilized were those best suited to the situation. A frank review and discussion will help achieve the best, most rapid, and most effective deployment of resources.

If anything proves the intertwined nature of the Internet, it is the defense against DDoS attacks. DDoS attacks require the subversion and coordination of hundreds or thousands of computers to attack a few victims. Defense against DDoS attacks requires the cooperation of thousands of ISPs and customer networks. Fighting DDoS requires continued diligence in locking down all of the hosts connected to the Internet as well as fundamental changes in the nature of TCP/IP connection protocols. As these changes are not likely to happen quickly, it is equally unlikely that DDoS attacks will disappear immediately.

18.5 FURTHER READING

Several books and articles describe the early history of DoS attacks.

Anonymous. Maximum Security, 4th ed. Indianapolis: SAMS, 2003.

Denning, D. E. Information Warfare and Security. Reading, MA: Addison-Wesley, 1999.

Ferguson, P., and D. Senie. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing” (RFC 2827/BCP 38). The Internet Society, 2000. Available from www.ietf.org/rfc/rfc2827.txt.

Gao, Z., and N. Ansari. “Tracing Cyber Attacks from the Practical Perspective.” IEEE Communications Magazine (May 2005): 123–131.

McClure, S., J. Scambray, and G. Kurtz, G. Hacking Exposed, Network Security Secrets & Solutions, 5th ed. Berkeley, CA: Osborne/McGraw-Hill, 2005.

Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear. “Address Allocation for Private Internets” (RFC 1918/BCP 5). Available from www.ietf.org/rfc/rfc1918.txt.

Skoudis, E. Counter Hack. Upper Saddle River, NJ: Prentice-Hall, 2002.

Spafford, E. H. “The Internet Worm: An Analysis.” Computer Communication Review (January 1989).

Most of the best current references, however, are on the Web. Some of the sites that readers should monitor for DoS/DDoS information are:

Attrition.org's “Denial of Service (DoS) Database” page: www.attrition.org/security/denial.

CERT/CC: www.cert.org.

Dave Dittrich's DDoS page: http://staff.washington.edu/dittrich/misc/ddos/.

Denialinfo.com's “Denial of Service (DoS) Attack Resources” page: www.denialinfo.com.

Distributed Intrusion Detection System: www.dshield.org.

Steve Gibson's “The Strange Tale of the Denial of Service Attacks Against GRC.COM”: http://grc.com/dos/grcdos.htm.

PacketStorm's “Distributed Attack Tools” page: http://packetstorm.securify.com/distributed.

SANS Internet Storm Center: http://isc.sans.org.

US-CERT: www.us-cert.gov/.

18.6 NOTE