This paper was submitted as the practical exercise in partial fulfillment for the SANS/GIAC Security Essentials Certification (GSEC). A much expanded version will be published as Chapter 11, "Denial of Service Attacks" (by Diane E. Levine and GCK) in the upcoming 4th edition of the Computer Security Handbook, edited by M.E. Kabay and S. Bosworth (John Wiley & Sons, in preparation).
This short paper discusses defenses against Distributed Denial of Service (DDoS) attacks. DoS attacks are of particular interest and concern to the Internet community because they seek to render target systems inoperable and/or target networks inaccessible. "Traditional" DoS attacks, however, typically generate a large amount of traffic from a given host or subnet and it is possible for a site to detect such an attack in progress and defend themselves. Distributed DoS attacks are a much more nefarious extension of DoS attacks because they are designed as a coordinated attack from many sources simultaneously against one or more targets.
This paper will focus on DDoS attacks only and assumes some basic familiarity with different DoS attacks. Rather than describe specific DDoS attacks in detail, this paper will define generic DDoS terms and ways in which service providers and user sites can defend themselves against these attacks.
A Short History of DDoS
Denial-of-service attacks under a number of guises have been around for decades. Distributed DoS attacks are much newer, first being seen in late June and early July of 1999. The first well-documented DDoS attack appears to have occurred in August 1999, when a DDoS tool called Trinoo (described below) was deployed in at least 227 systems, of which at least 114 were on Internet2, to flood a single University of Minnesota computer; this system was knocked off the air for more than two days.
The first well-publicized DDoS attack in the public press was in February 2000. On February 7, 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 to either stop functioning completely or slowed them 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% availability to 9.4%, while CNN.com's users went down to below 5% 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 dollars weekly in online trades, the downtime loss was huge.
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 upon monitoring the volume of packets coming from a single address or single network will then fail since the attacks come from all over. Rather than receiving, for example, a thousand gigantic Pings per second from an attacking site, the victim might receive one Ping per second from 1000 attacking sites.
One of the other disconcerting things about DDoS attacks are that the handler can choose the location of the agents. So, for example, a handler could target several NATO sites as victims and employ agents that are all in countries know to be hostile in 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 is some non-standard ways. Common DDoS attacks have such names as Tribe Flood Network (TFN), Trin00, Stacheldraht, and Trinity. Some details about these will be presented in the following sections.
DDoS 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. While the industry has more or less settled upon 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.
DDoS attacks always involve a number of systems. A typical DDoS attack scenario might follow roughly the following steps:
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 are normally automated so that it isn't necessary for an ongoing dialogue to take place between the master and the rest of the DDoS network. In fact, techniques are typically employed to deliberately camouflage the identity and location of the master within the DDoS network. These techniques make it difficult to analyze an attack while in progress and also to block attacking traffic and trace it back to its source.
In most cases, the system administrators of the infected systems don't even know that the daemons have been put in place. Even if they do find and eradicate the DDoS software, they can't 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.
A final word on terminology is necessary. 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 Distributed System Intruder Tools workshop held in November 1999, some standard terminology was introduced and those terms are used in the paragraphs above. To align those terms and the terms used by the hacker literature as well as early descriptions, we find the following synonyms:
It should not go without saying that 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. Although we tend to refer to the site that is eventually brought down as the victim, the intermediate systems from where the attack is launched have also been victimized. In this chapter, we will focus on the end-of-the line DoS/DDoS victim.
Some of the DDoS Tools
While this paper focuses on defensive measures against DDoS, it is important to know the names of the major tools to see their commonality -- and how they have already evolved!! By design, this section will be very brief; the reference section will provide a resources for additional information.
In rough chronological order, the DDoS tools commonly seen today include:
|TFN||ICMP Echo/Echo Reply||ICMP Echo Reply||ICMP Echo/Echo Reply|
|Stacheldraht||16660/tcp||65000/tcp||ICMP Echo Reply|
|Trinity||6667/tcp||6667/tcp (also 33270/tcp)|
The tools listed here are the best known, and most widely sued, but they are not the only ones and more tools are becoming available. In addition, the distribution of zombie software is not always due to an attacker exploiting a vulnerability of an exposed system. Indeed, the user is very often the "culprit" and Trojan horses are often the mechanism for distributing the zombie code. The SubSeven Defcon8 software, for example, is a backdoor virus that is rapidly spreading. SubSeven gets on a user'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). Computer systems today are frequently scanned for the presence of SubSeven and provides a potential door into users' systems.
The earlier part of this paper has been the preamble to discussing how sites can protect themselves from these kinds of attacks. The truth is that a site cannot defend itself from DDoS attacks alone. DDoS attacks depend upon the "community" of the Internet and defenses, therefore, depend upon the Internet community acting like a community with a common interest. And defending against attack includes ensuring that our own sites are not the source of attacks and our own networks do not forward attacks. This section will discuss some methods that will help prevent the spread of DDoS attacks, by limiting the distribution of the tools and/or limiting the propagation of the offending "attack" packets.
Although not discussed in detail here, another point needs to be made about DDoS attack responses. If you are the victim of such an attack, maintain detailed logs of all actions you take and events you detect. These logs may prove invaluable in subsequently understanding the attack that occurred, preventing other attacks at your site and others, and aiding law enforcement efforts to track down the perpetrators.
User and System Administrator Actions
Despite the best intentions and even the best distributed system management tools, the fact is that most computers today are largely managed by the local user. That means, in essence, that the local system has no security protections. But whether the local host computer is a secretary's desktop system or the Web server for a company, there are steps that can and should be taken to minimize the potential that an individual system will be compromised and itself attacked or used as a stepping-stone to attack others:
Local Network Actions
Even if a user locks down their system so that no vulnerability has gone unpatched and no exposure unprotected, the network itself -- including the user community -- can still be at risk. There are a number of steps that local network managers and network administrators can take to protect all of their own users as well as the rest of the Internet community:
|One Class A address|
16 Class B addresses
256 Class C addresses
Historical broadcast address|
Class D Multicast address range
Class E Experimental address range
The Internet Service Providers (ISPs) offer the last hope in defeating the spread of a DDoS attack. While the ISP cannot take responsibility for locking down every customers' host systems, the 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:
Most of the ISP community take at least some of these steps. Users should insist that their ISPs provide at least these protections and should not do business with those who don't. The TruSecure (formerly ICSA) ISP Security (ISPSec) community is a good source of information for ISPs.
Other Tools Under Development or Consideration
Responses to DDoS attacks are not limited to the defensive steps listed above. Indeed, proactive responses to the prevention and detection of DDoS attacks is 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. The idea is that ISPs, peering points, and/or major host servers would have traffic monitor hardware watching over it. The monitor hardware would itself, naturally, use IP and the Internet for communications, much like today's routing protocols. each box would examine packets and their contents, doing some type of multilayer statistical analysis of traffic to learn the ordinary patterns. These devices would have enough intelligence, presumably, to be able to detect changes in traffic level and determine whether those changes reflected a normal condition or not. The hardware is defensive in nature at the receiving side. As an example, suppose that such hardware at Amazon.com thinks that there is a DoS attack being launched from an ISP in Gondwanaland. The traffic monitoring network would communicate and shut off traffic to Amazon coming from that ISP, as close to the ISP as possible. In this way, the distributed network of monitors can shut traffic off at the source.
The hardware, of course, needs to somehow be informed about traffic level changes that are 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. And the hardware also needs to prevent the attacker community from operating under the cover of these normal events.
RSA Laboratories, one of the leading vendors of cryptography in the world, has proposed another potential defense to DDoS attacks against Web servers that employs cryptographic methods. Their 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 upon time and information unique to the server and client request.
The scheme, simply, works roughly like this. Under normal conditions, the 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 timeout period. The idea is that a bona fide client will only experience 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).
A third tool that is under consideration is that of 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, in concept, is a relatively straight-forward idea. Every packet on the Internet goes through some number of ISP routers. The processing power, memory, and storage are sufficiently available that routers could mark packets with partial path information as they arrive. Since DoS/DDoS attacks generally comprise a large number of packets, the traceback mechanism doesn't need to mark every packet, but only a sample size that statistically likely to include attack packets (e.g., one 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 similar, yet different, traceback proposal would define an ICMP Traceback message that would be sent to the victim site containing partial route information about the sampled packet. While both of these proposals requires a change to tens of thousands of routers in the Internet, it is a solution that can be gradually implemented, is backward compatible, and results in no negative affect to users.
These three proposals are merely samples of some of the R&D for dealing with DDoS attacks; the first adds new hardware to the Internet, the second requires changing Web server and client software (actually, upgrading Web browsers is probably the easiest part to fix even though there are millions of copies in distribution; the vast majority come from two vendors and users tend to eventually upgrade), and the third requires incrementally changing software in all of the Internet's routers. And there are even more proposals -- such as ICSA's Host Identity Payload (HIP) protocol -- under way.
One of the greatest short-comings 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 very life of the organization. Without using outright scare tactics, it is difficult to explain that there is an intruder community and that they are actively working on new tools all the time; and history has shown that as the tools mature and become more sophisticated, the technical knowledge necessary of the potential attacker goes down and the number of attacks overall goes up. Too many companies hide their heads in the sand and insist that "no one would bother us" without realizing that any site can become a target just by being there.
If anything proves the intertwingled nature of the Internet, it is the defense against DDoS attacks (even more than the Web!). DDoS attacks require the (unintended) collusion of hundreds or thousands of computers to attack a few victims and defense against DDoS attacks requires the (intended) cooperation of tens of thousands of ISPs and customer networks. DDoS attacks will be with us for some time but there are ways today to minimize them -- but they require continued diligence at locking down all of the hosts connected to the Internet. As that is not likely to happen anytime soon, the disappearance of DDoS attacks is equally unlikely.