· 7 years ago · Oct 05, 2018, 06:36 PM
1 Internet Denial of Service: Attack and Defense Mechanisms
2By Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher
3...............................................
4
5Pages: 400
6
7
8
9Table of Contents | Index
10
11--------------------------------------------------------------------------------
12
13 Copyright
14 The Radia Perlman Series in Computer Networking and Security Radia Perlman, Series Editor
15 Foreword
16 Acknowledgments
17 About the Authors
18 Chapter 1. Introduction
19 Section 1.1. DoS and DDoS
20 Section 1.2. Why Should We Care?
21 Section 1.3. What Is This Book?
22 Section 1.4. Who Is This Book For?
23 Section 1.5. What Can This Book Help You Do?
24 Section 1.6. Outline of the Remaining Chapters
25 Chapter 2. Understanding Denial of Service
26 Section 2.1. The Ulterior Motive
27 Section 2.2. Meet the Attackers
28 Section 2.3. Behind the Scenes
29 Section 2.4. Distribution Effects
30 Section 2.5. DDoS: Hype or Reality?
31 Section 2.6. How Vulnerable Are You to DDoS?
32 Chapter 3. History of DoS and DDoS
33 Section 3.1. Motivation
34 Section 3.2. Design Principles of the Internet
35 Section 3.3. DoS and DDoS Evolution
36 Chapter 4. How Attacks Are Waged
37 Section 4.1. Recruitment of the Agent Network
38 Section 4.2. Controlling the DDoS Agent Network
39 Section 4.3. Semantic Levels of DDoS Attacks
40 Section 4.4. Attack Toolkits
41 Section 4.5. What Is IP Spoofing?
42 Section 4.6. DDoS Attack Trends
43 Chapter 5. An Overview of DDoS Defenses
44 Section 5.1. Why DDoS Is a Hard Problem
45 Section 5.2. DDoS Defense Challenges
46 Section 5.3. Prevention versus Protection and Reaction
47 Section 5.4. DDoS Defense Goals
48 Section 5.5. DDoS Defense Locations
49 Section 5.6. Defense Approaches
50 Chapter 6. Detailed Defense Approaches
51 Section 6.1. Thinking about Defenses
52 Section 6.2. General Strategy for DDoS Defense
53 Section 6.3. Preparing to Handle a DDoS Attack
54 Section 6.4. Handling an Ongoing DDoS Attack as a Target
55 Section 6.5. Handling an Ongoing DDoS Attack as a Source
56 Section 6.6. Agreements/Understandings with Your ISP
57 Section 6.7. Analyzing DDoS tools
58 Chapter 7. Survey of Research Defense Approaches
59 Section 7.1. Pushback
60 Section 7.2. Traceback
61 Section 7.3. D-WARD
62 Section 7.4. NetBouncer
63 Section 7.5. Secure Overlay Services (SOS)
64 Section 7.6. Proof of Work
65 Section 7.7. DefCOM
66 Section 7.8. COSSACK
67 Section 7.9. Pi
68 Section 7.10. SIFF: An End-Host Capability Mechanism to Mitigate DDoS Flooding Attacks
69 Section 7.11. Hop-Count Filtering (HCF)
70 Section 7.12. Locality and Entropy Principles
71 Section 7.13. An Empirical Analysis of Target-Resident DoS Filters
72 Section 7.14. Research Prognosis
73 Chapter 8. Legal Issues
74 Section 8.1. Basics of the U.S. Legal System
75 Section 8.2. Laws That May Apply to DDoS Attacks
76 Section 8.3. Who Are the Victims of DDoS?
77 Section 8.4. How Often Is Legal Assistance Sought in DDoS Cases?
78 Section 8.5. Initiating Legal Proceedings as a Victim of DDoS
79 Section 8.6. Evidence Collection and Incident Response Procedures
80 Section 8.7. Estimating Damages
81 Section 8.8. Jurisdictional Issues
82 Section 8.9. Domestic Legal Issues
83 Section 8.10. International Legal Issues
84 Section 8.11. Self-Help Options
85 Section 8.12. A Few Words on Ethics
86 Section 8.13. Current Trends in International Cyber Law
87 Chapter 9. Conclusions
88 Section 9.1. Prognosis for DDoS
89 Section 9.2. Social, Moral, and Legal Issues
90 Section 9.3. Resources for Learning More
91 Section 9.4. Conclusion
92 Appendix A. Glossary
93 Appendix B. Survey of Commercial Defense Approaches
94 Section B.1. Mazu Enforcer by Mazu Networks
95 Section B.2. Peakflow by Arbor Networks
96 Section B.3. WS Series Appliances by Webscreen Technologies
97 Section B.4. Captus IPS by Captus Networks
98 Section B.5. MANAnet Shield by CS3
99 Section B.6. Cisco Traffic Anomaly Detector XT and Cisco Guard XT
100 Section B.7. StealthWatch by Lancope
101 Section B.8. Summary
102 Appendix C. DDoS Data
103 Section C.1. 2004 CSI/FBI Computer Crime and Security Survey
104 Section C.2. Inferring Internet Denial-of-Service Activity
105 Section C.3. A Framework for Classifying Denial-of-Service Attacks
106 Section C.4. Observations and Experiences Tracking Denial-of-Service Attacks across a Regional ISP
107 Section C.5. Report on the DDoS Attack on the DNS Root Servers
108 Section C.6. Conclusion
109
110
111
112
113
114
115Foreword
116Society is getting to be more and more dependent on the reliability of the Internet. Businesses are relying on the Internet as their link to their customers. Customers are being encouraged to do most of their business in the Internet.
117
118It is not enough to protect your communication from eavesdroppers, or to protect your own system from being infected with viruses. Traditionally, the security community has focused its attention on unauthorized disclosure or modification of information, and perhaps theft of services. Denial of service was largely ignored as being unlikely to occur because the attacker would not gain anything from such an attack.
119
120Clearly this is not the case today. Denial of service can be a devastating attack. It can put merchants out of business and can cause major and very visible disruption to our world. It can be (and is) used against specific companies for which the attacker has a grudge or has been paid to attack; or it can be used by terrorists to cause major disruption to critical infrastructure.
121
122As widely publicized denial-of-service attacks occur, the subject is finally getting needed attention. Not so long ago, it was assumed that the amount of damage any attacker could do was limited by the speed of that attacker's Internet connection. If that were true, it wouldn't be too hard to find the attacker's machine, filter out its packets, disconnect it from the Internet, and prosecute the machine's owner (presumably the attacker). Unfortunately, attacks grew more sophisticated. Instead of attacking directly from the attacker's own machine, an attacker breaks into a lot of machines, and causes them to attack. The attacks are now coming from many machines owned by innocent, if careless, owners.
123
124Why is it so easy to break into machines? Unfortunately, there is little incentive for vendors to provide secure software, and little incentive for owners of machines to keep up with patches and turn security on in their machine. Vendors are in business to make money. Time to market, fancy features (which are likely to introduce vulnerabilities), and price are more important differentiators than security. A vendor that provides a low-frills product that goes to market later due to stringent testing will lose in the marketplace. If manufacturers were routinely sued for security bugs in their products, perhaps security would feature more prominently in the economic equation.
125
126It is tempting to blame the users. Why don't they install patches promptly? Why don't they turn off dangerous features such as cookies? However, it is completely unfair to blame the users. Users are getting less and less sophisticated. When computers were used primarily by university computer science students, it was reasonable to make them arcanely difficult to manage. Today just about everyone is using computers, and is expected to manage their own systems. And when there are features that can be exploited by attackers (such as ActiveX), users can't simply turn these features off, because many Web sites wind up using these features. Not because they need to, but because the features are there. If users say no to anything, they get strange error messages and all sorts of things stop working.
127
128Fighting denial of service is going to be a constant spy vs. spy game. The good guys (the defenders) will try to defend against all the known attacks, and the bad guys (the attackers) will try to disguise their attacks to stay under the radar. It is good that the good guys have been awakened to the need to be ever vigilant, and to get ahead of the game through research.
129
130This book is timely and written by an ideal author team. It is crucial to understand the world as currently deployed, and it is also crucial to look to the future. This author team provides expertise along the whole range. David Dittrich, of the University of Washington's Information School and the Center for Information Assurance and Cybersecurity, is one of the foremost frontline DDoS fighters today, and indeed, an "I'm feeling lucky" Google search for DDoS brings up the DDoS page that he maintains.
131
132Jelena Mirkovic did her Ph.D. work at UCLA, with advisor Peter Reiher, on innovative approaches to DDoS defense. Their work produced the first source-end DDoS defense system, which helps network administrators ensure that poorly secured machines in their network cannot be misused to attack others. They also worked on developing taxonomies of DDoS attacks and defenses, and defining methods for measuring the success of defenses. Jelena continues her fight against DDoS as an assistant professor at the University of Delaware.
133
134Sven Dietrich is a researcher at the CERT Coordination Center. He is part of the research group that investigates the survivability of networked systems. The CERT Coordination Center is the first organization of its kind, and has helped to start similar organizations around the world. It is likely to be the first place to hear about attacks, and to marshal the resources necessary to provide defenses. Sven also works closely with Carnegie Mellon CyLab—a cybersecurity research and education center. Following their meeting at the CERT DSIT Workshop, Sven teamed up with David Dittrich and others in producing analyses of several early DDoS tools.
135
136Radia Perlman
137
138
139Previous Section < Day Day Up > Next Section
140
141Acknowledgments
142The authors wish to thank Radia Perlman from Sun Microsystem Laboratories, and Mary Franz and her colleagues at Prentice Hall for their support and assistance in producing this book. Radia and Mary were instrumental in encouraging us to write the book and getting Prentice Hall to commit to its publication.
143
144The authors also wish to thank distinguished researchers and practitioners in the network security community who reviewed this book: Steven M. Bellovin from AT&T Labs, Angelos D. Keromytis from Columbia University, Giovanni Vigna from the University of California at Santa Barbara, Cat Okita from Earthworks, Kevin Fu from MIT, Warwick Ford from Wyltan, Inc., Harlan Carvey, and Howard Lipson from the CERT Coordination Center. Their reviews have been instrumental to us in improving the technical content and the readability of this book.
145
146The authors would like to thank the CERT Coordination Center, for permitting us to reproduce some of their copyrighted figures and other material in this book. We also thank the companies that have granted us the permission to use their products' copyrighted material in preparation of Appendix B. These are: Mazu Networks, Arbor Networks, WebScreen Technologies, Captus Networks, CS3, Riverhead Networks (now part of Cisco Systems), and Lancope.
147
148David Dittrich
149
150I wish to thank the following people: my parents, Carol and William Dittrich (I wish he were still here to read this), for raising me to consider how I can best contribute to the good of society; my cousin Dan and uncle Richard Kegel, for being early inspirations to me to explore computing; my extended family and friends (especially Ali Ritter) for putting up with me working through two plus years' holidays analyzing DDoS malware; my coworkers at the University of Washington who have assisted or inspired me to find better ways to deal with an ever-growing number of compromised computers (e.g., Corey Satten; Aaron Racine; my former assistant director Oren Sreebny and his wonderful Client Services group; Sandy Moy, Mike Hornung, Eliot Lim, Alexander Howard, and Daniel Schwalbe, who continue to deal with compromised hosts on campus; Terry Gray and his Network Engineering and Network Operations crews; and the many others in C&C and MCIS who deal with computer security incident response); Lance Spitzner and all of the members of the Honeynet Project and Research Alliance for sharing my curiosity about how computer attack tools function and how to detect and counter them; Kirk Bailey and members of the Agora, who form connections with others in government and industry to deal with issues like DDoS, incident response, forensics, identity theft, and online privacy; Ivan Orton, John Christiansen, Alisha Ritter, James Vasquez, Jennifer Granick, Richard Salgado, Dario Forte, Steve Schroeder, Ken Himma, Marc Lampson, and the many participants at the 3rd Agora Active Defense Workshop for their guidance through the varied and complex landscape of the Law; Dean Michael Eisenberg, David Notkin, Harry Bruce, Alpha Delap, Ed Lazowska, and all in the Information School and Center for Information Assurance and Cybersecurity for supporting and encouraging me to publish, develop research, teach, and consult in this fascinating field; the staff of the CERT Coordination Center and attendees at the Distributed Intruder Tools Workshop with whom I have maintained contact and worked over the years; to the many former and current members of the federal government, military, and intelligence community, who share a desire to protect our critical cyberinfrastructure from attack, and who have involved me in this effort over the years in ways that make me and my family proud.
151
152Sven Dietrich
153
154Sven Dietrich would like to thank the following for their dedication, integrity, and support: Aghadi Shraim, Karen Petraska, Frank Ottens, Bill Farrell, Andy Schain, and Neil Long. Without their help the early DDoS analysis work could not have been completed.
155
156Sven would also like to thank Howard Lipson, Eric Hayes, Sheila Rosenthal, Tom Longstaff, John McHugh, Nancy Mead, Carrie Gates, Mike Collins, Sarah Strauss, Mindi McDowell, David Biber, Jason Rafail, Chad Dougherty, Art Manion, Allen Householder, and many others from the CERT Coordination Center and the Software Engineering Institute for their support, scrutiny, and contributions. Sven is grateful for the environment at CERT Research that allowed him to continue and extend his DDoS research, both in the context of the Survivable Systems Engineering Team and the Carnegie Mellon CyLab, and to eventually write this book.
157
158Finally, Sven would like to thank his friends and family for their patience and support during the writing of this book.
159
160Jelena Mirkovic
161
162Jelena Mirkovic and Peter Reiher are very grateful to the Defense Advanced Research Project Agency (DARPA) for supporting their research in DDoS defense, through the Fault Tolerant Networking (FTN) program led by Dr. Douglas Maughan, program manager. The FTN program funded a large number of cybersecurity research projects, with an aim of improving Internet robustness in face of attacks. Many of these projects were focused on DDoS defenses, and they greatly affected the DDoS research community by both advancing the knowledge of the threat and by proposing innovative defense measures (some of which evolved into full-fledged commercial products). Dr. Maughan stepped outside the conventional funding paradigm, which fosters individual projects developed in isolation and with no relation to one another, by encouraging partnerships between projects. This enabled both combinations of defense approaches and their independent evaluation, and resulted in a higher quality of research.
163
164Jelena is very grateful to the Computer and Information Sciences Department at the University of Delaware, for supporting her DDoS research and her book-writing efforts. Friendly and supporting colleagues, bright students, and helpful and capable staff make this department an enjoyable and inspiring place to work.
165
166Jelena would like to extend profound thanks to the faculty, students, and staff associated with the University of Utah Emulab testbed, a shared testbed resource that enables researchers to acquire multiple machines, load them with their code, and test to their hearts' content. The people at Emulab did a superb job creating and maintaining this facility; they were very forthcoming in meeting the special needs of various projects she has worked on, and they heroically coped with occassional mishaps in these projects (such as escaped scans, overloaded disks, and excessive traffic that brought down the NFS server) without revoking her account. Testing DDoS defenses in a (as much as possible) realistic setting requires multiple machines—usually many more than an average university lab can acquire. Those machines must further be recombined into various topologies, and doing this in an ordinary lab environment is painful and includes a lot of cable reconnecting, manual reconfiguration, and anguish when packets just don't flow. In Emulab, the act of acquiring a hundred machines, organizing them in a desired topology and installing the code one needs to run takes about 10 minutes. Imagine how this advances research! Jelena has used Emulab resources and found them invaluable both in her Ph.D. work, her current research at the University of Delaware, and in teaching network security classes.
167
168Jelena is especially grateful to her husband, Nikola, and numerous friends and family members, who lent her their patience, advice, and energy in the challenging process of writing this book.
169
170Peter Reiher
171
172Peter Reiher would like to thank several students who have worked on research projects related to distributed denial of service problems with him. These students have been instrumental in helping him develop a better understanding of the problems caused by DDoS attacks and the advantages and disadvantages of various possible solutions to those problems. These students include (in addition to Jelena Mirkovic) Gregory Prier, Max Robinson, Matthew Schnaider, B. Scott Michel, and Jun Li. Peter would also like to thank Dr. Gerald Popek and Dr. Geoff Kuenning for their contributions to his research group's work on distributed denial of service attacks.
173
174Peter would also like to thank Raj Yavatkar and the Intel Corporation for support they've provided to allow him to pursue the use of programmable routers for combating DDoS attacks. This support helped develop ideas and approaches to DDoS defense discussed in this book.
175
176Peter would also like to thank his wife, Cathleen, for her understanding, support, and patience through the long process of producing this book.
177
178Previous Section < Day Day Up > Next Section
179
180About the Authors
181Jelena Mirkovic received her B.Sc. in Electrical and Computer Engineering from the University of Belgrade, Serbia, and Montenegro in 1998, and her M.S. and Ph.D. from UCLA in 2000 and 2003. She is currently an assistant professor in the Computer and Information Sciences Department, University of Delaware.
182
183Jelena developed an interest in networking and security research during her graduate studies, and became involved in projects working on new defenses against IP spoofing and distributed denial of service attacks. Her Ph.D. work led to the first source-end DDoS defense system, called D-WARD, that prevents participation of poorly managed networks in DDoS attacks. She further worked to improve the understanding of the DDoS threat and the solution space by developing a taxonomy of DDoS attacks and of DDoS defense mechanisms. She is currently working on developing benchmarks and common evaluation methodology for testing DDoS defenses.
184
185Since her graduation, Jelena's research interests have grown to include other network security problems such as Internet worms, intrusions, and routing attacks, but DDoS remains her "first research love" and the main focus of her investigations.
186
187Sven Dietrich is a member of the technical staff for the CERT Coordination Center, part of the Software Engineering Institute at Carnegie Mellon University in Pittsburgh, Pennsylvania. He also has an appointment at the Carnegie Mellon CyLab, a universitywide cybersecurity research and education initiative. Prior to joining Carnegie Mellon University, Sven worked as a Senior Security Architect at the NASA Goddard Space Flight Center from 1997 to 2001, where he observed and analyzed the first distributed denial-of-service attacks against the University of Minnesota in 1999. He taught Mathematics and Computer Science as an adjunct faculty member at Adelphi University, his alma mater, from 1991 to 1997.
188
189His research interests include survivability, computer and network security, anonymity, cryptographic protocols, and cryptography. His previous work has included a formal analysis of the secure sockets layer protocol (SSL), intrusion detection, analysis of distributed denial-of-service tools, and the security of IP communications in space. For his work on the latter he received a National Resource Group Achievement Award from the NASA Goddard Space Flight Center in 2000. His publications include Analyzing Distributed Denial of Service Tools: The Shaft Case (with N. Long and D. Dittrich) and The "mstream" Distributed Denial of Service Tool (with D. Dittrich, G. Weaver, and N. Long), as well as articles on Active Network Defense, DDoS tool analysis, and survivability. He has given invited talks and presentations on DDoS at conference venues such as USENIX, ACSAC, the IEEE Symposium on Security and Privacy, and HAL 2001, and at NASA-wide briefings, and has participated in DDoS panels at HAL 2001 and SANS Network Security 2002. He also teaches computer and network security at both the national and international level, including giving tutorials and guest lectures on DDoS.
190
191He received a D.A. in Mathematics in 1997, a M.S. in Mathematics in 1991, and a B.S. in Computer Science and Mathematics in 1989, all from Adelphi University in Garden City, New York, and an International Baccalaureate from the International School of Geneva, Switzerland, in 1985. He is a member and former president of the New York Xi chapter of Pi Mu Epsilon, the National Mathematics Honor Society.
192
193Sven discovered his interest in computers working on Apple ][+/e computers and a Commodore 64 in the early 1980s, in networks during his dealings with X.25 packet-switched networks, such as TELENET and TYMNET, and networked PC and Unix-based bulletin board systems in the mid- to late-1980s. His curiosity about denial of service was piqued in the early 1990s on Internet Relay Chat networks, and by witnessing an intruder flood his alma mater's Internet connection in the mid-1990s. Early on he was fascinated by the book Hackers for Moscow (Rowohlt Verlag, 1989) describing the hackers' view of Clifford Stoll's Cuckoo's Egg (a book he has not read to this day). His passion remains the beauty of mathematics.
194
195David Dittrich began his computing career in 1979 with a "family owned" (read "his personal") Apple ][+, which he used to maintain a local credit union's membership mailing list. He wrote his own terminal emulator (in assembly, dove-tailed using jump instructions into the slack space between subroutines in the published Apple DOS assembly listing so as not to take up any added space on the only disk drive, a 720KB floppy disk!). This allowed him to be the primary user of one of the two modems owned by Western Washington University to do his Computer Science homework from at home while drinking beer and listening to the likes of Pink Floyd, Led Zeppelin, and Steely Dan (while the other students had to sit in straightback chairs at VT100 terminals in the main terminal room). Dave's background in programming and system administration on several platforms and operating systems was honed first at WWU, then the Boeing Company, and finally when he moved in 1990 to the University of Washington. His role as the main Unix workstation support contact for the entire UW campus led him to become an expert in dealing with Unix computer intrusions and malware of all types. Dave has been a prolific selfpublisher of white papers, FAQs, and malware tool analyses, all intended to make his (and everyone else's) life easier in dealing with computer intrusions. Dave is most widely known for his research into Distributed Denial of Service attack tools, starting with an invited talk at the November 1999 CERT Distributed System Intruder Tools Workshop and leading to invited talks and panels on DDoS at SANS, the USENIX Security Symposium, JASON summer workshop, DDoS BoF sessions at RSA 2000 and NANOG, and HAL 2001 in the Netherlands. Dave received one of SANS' Security Technology Leadership Awards in 2000 for his work in understanding DDoS tools.
196
197Besides DDoS, Dave is also active in other areas of host and network forensics, honeynets, and information assurance. He has taught Unix Forensic Analysis at the Black Hat Briefings and both taught in and cochaired SANS' first forensic track at SANS FIRE '01. As one of the founding members of the Honeynet Project, he led the "Forensic Challenge" (the first ever forensic analysis challenge based on a published "in the wild" compromised Linux system), and now leads the development of the nextgeneration distributed Honeywall CD-ROM.
198
199Dave has contributed to the books Know Your Enemy, by the Honeynet Project (Addison-Wesley, 2001), The Hacker's Challenge, edited by Mike Schiffman (McGraw Hill, 2001), and two articles in the Handbook of Information Security, edited by Hossein Bidgoli (John Wiley & Sons, 2005). His Web page and papers are referenced in dozens of popular Linux, system administration, and computer security books. He has also spoken around the world at conferences such as the Black Hat Briefings, CanSecWest, SANS, Korea's OlymFair, and Austalia's AusCERT; and at several workshops, classes, professional organizations, and government agencies. He has been interviewed in print, radio, and television from the campus level to international media outlets.
200
201His home page can be found at http://staff.washington.edu/dittrich/
202
203Peter Reiher received his B.S. in Electrical Engineering from the University of Notre Dame in 1979. He received an M.S. and a Ph.D. in Computer Science from UCLA in 1983 and 1987, respectively.
204
205Dr. Reiher spent five years working at JPL, where he served as the principal designer for the Time Warp Operating System. He then returned to UCLA, where he is now an adjunct associate professor in the Computer Science Department. He has worked on a variety of research topics, including distributed operating systems, parallel discrete event simulation, optimistically replicated file systems and databases, mobile computing, active networks, and various issues in file system design. In recent years, much of his research has centered around network security topics, particularly combatting IP spoofing and defending against distributed denial of service attacks. The SAVE system to combat IP spoofing, the D-WARDDDoS defense system, and the DefCOMDDoS defense system all originated in his research group at UCLA.
206
207Previous Section < Day Day Up > Next Section
208
209Chapter 1. Introduction
210It is Monday night and you are still in the office, when you suddenly become aware of the whirring of the disks and network lights blinking on the Web server. It seems like your company's Web site is quite well visited tonight, which is good because you are in e-business, selling products over the Internet, and more visits mean more earnings. You decide to check it out too, but the Web page will not load. Something is wrong.
211
212A few minutes later, network operations confirm your worst fears. Your company's Web site is under a denial-of-service attack. It is receiving so many requests for a Web page that it cannot serve them all—50 times your regular load. Just like you cannot access the Web site, none of your customers can. Your business has come to a halt.
213
214You all work hard through the night trying to devise filtering rules to weed out bogus Web page requests from the real ones. Unfortunately, the traffic you are receiving is very diverse and you cannot find a common feature that would make the attack packets stand out. You next try to identify the sources that send you a lot of traffic and blacklist them in your firewall. But there seem to be hundreds of thousands of them and they keep changing. You spend the next day bringing up backup servers and watching them overload as your earnings settle around zero. You contact the FBI and they explain that they are willing to help you, but it will take them a few days to get started. They also inform you that many perpetrators of denial-of-service attacks are never caught, since they do not leave enough traces behind them.
215
216All you are left with are questions: Why are you being attacked? Is it for competitive advantage? Is an ex-employee trying to get back at you? Is this a very upset customer? How long can your business be offline and remain viable? How did you get into this situation, and how will you get out of it? Or is this just a bug in your own Web applications, swamping your servers accidentally?
217
218This is a book about Denial-of-Service attacks, or DoS for short. These attacks aim at crippling applications, servers, and whole networks, disrupting legitimate users' communication. They are performed intentionally, easy to perpetrate, and very, very hard to handle. The popular form of these attacks, Distributed Denial-of-Service (DDoS) attacks, employs dozens, hundreds, or even well over 100,000 compromised computers, to perform a coordinated and widely distributed attack. It is immensely hard to defend yourself against a coordinated action by so many machines.
219
220This book describes DoS and DDoS attacks and helps you understand this new threat. It also teaches you how to prepare for these attacks, preventing them when possible, dealing with them when they do occur, and learning how to live with them, how to quickly recover and how to take legal action against the attackers.
221
222 Previous Section < Day Day Up > Next Section
223
2241.1. DoS and DDoS
225The goal of a DoS attack is to disrupt some legitimate activity, such as browsing Web pages, listening to an online radio, transferring money from your bank account, or even docking ships communicating with a naval port. This denial-of-service effect is achieved by sending messages to the target that interfere with its operation, and make it hang, crash, reboot, or do useless work.
226
227One way to interfere with a legitimate operation is to exploit a vulnerability present on the target machine or inside the target application. The attacker sends a few messages crafted in a specific manner that take advantage of the given vulnerability. Another way is to send a vast number of messages that consume some key resource at the target such as bandwidth, CPU time, memory, etc. The target application, machine, or network spends all of its critical resources on handling the attack traffic and cannot attend to its legitimate clients.
228
229Of course, to generate such a vast number of messages the attacker must control a very powerful machine—with a sufficiently fast processor and a lot of available network bandwidth. For the attack to be successful, it has to overload the target's resources. This means that an attacker's machine must be able to generate more traffic than a target, or its network infrastructure, can handle.
230
231Now let us assume that an attacker would like to launch a DoS attack on example.com by bombarding it with numerous messages. Also assuming that example.com has abundant resources, it is then difficult for the attacker to generate a sufficient number of messages from a single machine to overload those resources. However, suppose he gains control over 100,000 machines and engages them in generating messages to example.com simultaneously. Each of the attacking machines now may be only moderately provisioned (e.g., have a slow processor and be on a modem link) but together they form a formidable attack network and, with proper use, will be able to overload a well-provisioned victim. This is a distributed denial-of-service—DDoS.
232
233Both DoS and DDoS are a huge threat to the operation of Internet sites, but the DDoS problem is more complex and harder to solve. First, it uses a very large number of machines. This yields a powerful weapon. Any target, regardless of how wellprovisioned it is, can be taken offline. Gathering and engaging a large army of machines has become trivially simple, because many automated tools for DDoS can be found on hacker Web pages and in chat rooms. Such tools do not require sophistication to be used and can inflict very effective damage. A large number of machines gives another advantage to an attacker. Even if the target were able to identify attacking machines (and there are effective ways of hiding this information), what action can be taken against a network of 100,000 hosts? The second characteristic of some DDoS attacks that increases their complexity is the use of seemingly legitimate traffic. Resources are consumed by a large number of legitimate-looking messages; when comparing the attack message with a legitimate one, there are frequently no telltale features to distinguish them. Since the attack misuses a legitimate activity, it is extremely hard to respond to the attack without also disturbing this legitimate activity.
234
235Take a tangible example from the real world. (While not a perfect analogy to Internet DDoS, it does share some important characteristics that might help you understand why DDoS attacks are hard to handle.) Imagine that you are an important politician and that a group of people that oppose your views recruit all their friends and relatives around the world to send you hate letters. Soon you will be getting so many letters each day that your mailbox will overflow and some letters will be dropped in the street and blown away. If your supporters send you donations through the mail, their letters will either be lost or stuffed in the mailbox among the copious hate mail. To find these donations, you will have to open and sort all the mail received, wasting lots of time. If the mail you receive daily is greater than what you can process during one day, some letters will be lost or ignored. Presumably, hate letters are much more numerous than those carrying donations, so unless you can quickly and surely tell which envelopes contain donations and which contain hate mail, you stand a good chance of losing most of the donations. Your opponents have just performed a real-world distributed denial of service attack on you, depriving you of support that may be crucial to your campaign.
236
237What could you do to defend yourself? Well, you could buy a bigger mailbox, but your opponents can simply increase the number of letters they send, or recruit more helpers. You must still identify the donations in the even larger pool of letters. You could hire more people to go through letters—a costly solution since you have to pay them from diminishing donations. If your opponents can recruit more helpers for free, they can make your processing costs as high as they like. You could also try to make the job of processing mail easier by asking your supporters to use specially colored envelopes. Your processing staff can then simply discard all envelopes that are not of the specified color, without opening them. Of course, as soon as your opponents learn of this tactic they will purchase the same colored envelopes and you are back where you started. You could try to contact post offices around the country asking them to keep an eye on people sending loads of letters to you. This will only work if your opponents are not widely spread and must therefore send many letters each day from the same post office. Further, it depends on cooperation that post offices may be unwilling or unable to provide. Their job is delivering letters, not monitoring or filtering out letters people do not want to get. If many of those sending hate mail (and some sending donations) are in different countries, your chances of getting post office cooperation are even smaller. You could also try to use the postmark on the letters to track where they were sent from, then pay special attention to post offices that your supporters use or to post offices that handle suspiciously large amounts of your mail. This means that you will have to keep a list of all postmarks you have seen and classify each letter according to its postmark, to look for anomalous amounts of mail carrying a certain postmark. If your opponents are numerous and well spread all over the world this tactic will fail. Further, postmarks are fairly nonspecific locators, so you are likely to lose some donations while discarding the hate letters coming to you from a specific postmark.
238
239As stated before, the analogy is not perfect, but there are important similarities. In particular, solutions similar to those above, as well as numerous other approaches specific to the Internet world, have been proposed to deal with DDoS. Like the solutions listed above that try to solve the postal problem, the Internet DDoS solutions often have limitations or do not work well in the real world. This book will survey those approaches, presenting their good and bad sides, and provide pointers for further reference. It will also talk about ways to secure and strengthen your network so it cannot be easily taken offline, steps to take once you are under attack (or an unwitting source of the attack), and what law enforcement can do to help you with a DDoS problem.
240
241
242
2431.2. Why Should We Care?
244Why does it matter if someone can take a Web server or a router offline? It matters because the Internet is now becoming a critical resource whose disruption has financial implications, or even dire consequences on human safety. An increasing number of critical services are using the Internet for daily operation. A DDoS attack may not just mean missing out on the latest sports scores or weather. It may mean losing a bid on an item you want to buy or losing your customers for a day or two while you are under attack. It may mean, as it did for the port of Houston, Texas, that the Web server providing the weather and scheduling information is unavailable and no ships can dock [MK03]. Lately, a disturbing extortion trend has appeared—online businesses are threatened by DDoS if they do not pay for "protection." Such a threat is frequently backed up by a small demonstration that denies the business service for a few hours [Sha].
245
246How likely are you to be a DDoS target? A study evaluated Internet DDoS activity in 2001, looking at a small sample of traffic observable from its network [MVS01]. The authors were able to detect approximately 4,000 attacks per week (for a three-week period), against a variety of targets ranging from large companies such as Amazon and Hotmail to small Internet Service Providers (ISPs) and dial-up connections. The method they used was not able to notice all attacks that happened during that period, so 4,000 is an underestimate. Further, since DDoS activity has increased and evolved since then, today's figure is likely to be much bigger. In the 2004 FBI report on cybercrime, nearly a fifth of the respondents who suffered financial loss from an attack had experienced a DoS attack. The total reported costs of DoS attacks were over $26 million. Denial of service was the top source of financial loss due to cybercrime in 2004. It is safe to conclude that the likelihood of being a DDoS target is not negligible.
247
248But DDoS affects not only the target of the attack traffic. Legitimate users of the target's services are affected, too. In January 2001, a DDoS attack on Microsoft prevented about 98% of legitimate users from getting to any of Microsoft's servers. In October 2002, there was an attack on all 13 root Domain Name System (DNS) servers. DNS service is crucial for Web browsers and for many other applications, and those 13 servers keep important data for the whole Internet. Since DNS information is heavily cached and the attack lasted only an hour, there was no large disruption of Internet activity. However, 9 of these 13 servers were seriously affected. Had the attack lasted longer, the Internet could conceivably have experienced severe disruption. The aforementioned attack that disabled the port of Houston, Texas, was actually directed at a South African chat room user, with the port's computers being misused for the attack [Reg]. DDoS affects all of us directly or indirectly and is a threat that should be taken seriously.
249
250
251
2521.3. What Is This Book?
253This is the first book that is written exclusively about the DoS problem. There have been a number of important shorter treatments of the DDoS problem and solution approaches ([CER99, HMP+01]), but this book greatly expands on and updates these seminal works. It is intended to speak to both technical and nontechnical audiences, informing them about this problem and presenting and discussing potential solutions. Whether you are a CTO of a company, a network administrator, or a computer science student, we are sure you will find the information in this book informative and helpful and will want to learn more about DoS and DDoS. We have provided references to further reading, conferences, and journals that publish papers from this field and organizations that deal with the DoS problem specifically for this purpose. Since the DDoS field is very dynamic both in new threats and new defenses, we will gather and publish current information to accompany the book on a Web page: http://staff.washington.edu/dittrich/misc/ddos/book/. Following is an overview of all the useful things you will find inside this book.
254
255A thorough explanation of DoS and DDoS—why these attacks occur, how frequently they are conducted and in what manner, and how they affect the victim.
256
257Examples of some DoS and DDoS attack types that have been seen to date and a discussion of trends, in an effort to give the reader a good overview of the field.
258
259An extensive overview of the defensive methods and tools that exist now or are in research and development stages.
260
261Examples of the true fragility of services that depend on the current Internet infrastructure that will provide decision makers (or those who advise them) with a better context for making risk assessments and judgments about what services to place in the Internet, how to protect them, and what the consequences might be if they are attacked.
262
263Descriptions of how DDoS attack tools function, how to respond to DDoS attacks, and how to collect and analyze evidence in ways that support both DDoS defense and the needs of law enforcement, should you choose to pursue criminal prosecution or civil litigation.
264
265
266
2671.4. Who Is This Book For?
268The book is meant for readers with a good background in general computer networking and some knowledge of general network security issues, but little specialized knowledge of DDoS attacks.
269
270It is primarily aimed at computer system (end host) and network administrators, those who are responsible for keeping computers and networks functioning in the face of failure (whether natural or human-induced). There should be sufficient depth and detail for technical readers, with many citations to provide the added detail this audience demands.
271
272It is also aimed at those in management and policy positions who need to understand how to manage businesses and other organizations that rely on the Internet functioning in an operational sense. There should be enough general and easy-to-digest information to bring the picture of DDoS into view for those who have never encountered this subject before, allowing them to see how they may be affected by this problem in the future or how to deal with it now if they are affected.
273
274This book will be useful to those with political and legal responsibilities, helping them understand how the technical and legal worlds intersect in the Internet. The concepts of cybercrime and cyberwarfare involve the potential use of denial of service as a weapon to disrupt or degrade critical infrastructures. Many services, such as computers designed for medical imaging, were not designed to be used in a hostile network environment. They use Common Off-The-Shelf (COTS) commercial operating systems as delivered by the vendor, and often without securing them or updating the software. These computers are vulnerable to potential denial of service or complete compromise. As more and more critical applications migrate to the Internet, the risk of potential loss of income or even loss of life grows. This book will provide political and legal representatives with the background necessary to make sound decisions on public policy and law enforcement. Understanding the risks and making appropriate investments in protective measures or new security research can help prevent this risky future.
275
276Finally, the book is meant for anyone who has heard rumors about DDoS and would like to understand more about the phenomenon (e.g., students, teachers, corporate employees, home business owners, journalists). These people will gain detailed knowledge of the problem and of the current defense approaches. Some of them may be intrigued enough to join the search for solutions!
277
278
2791.5. What Can This Book Help You Do?
280This book will help you understand the problem of DDoS. It will help you in evaluating current defenses and in choosing the right ones for you. It will help you protect your network, minimizing damages and quickly recovering if you do get attacked.
281
282We wrote this book because—surprisingly, considering DDoS has existed as a problem since 1999—there are currently no books that focus exclusively on DDoS. Existing network security books either ignore the topic or devote at most a chapter to it. These works provide enough information for computer practitioners who merely need to be familiar with the concept, but not nearly enough for a network administrator or CTO who needs to protect her network from such attacks and must be prepared to recover from them. There are many academic papers on the subject, but their view is limited to their particular research topic. There are also white papers from companies offering products to ameliorate DDoS attacks, but they are primarily interested in demonstrating the effectiveness and other advantages of their particular product.
283
284
285
2861.6. Outline of the Remaining Chapters
287Since the book is intended for a variety of readers, we divided its content into chapters with different difficulty levels (denoted in italics next to chapter names in the overview below). Chapters marked nontechnical are intended for readers who do not have extensive knowledge of networking and security and who are seeking a gradual introduction to DDoS. These readers may wish to read only the nontechnical chapters. Chapters marked technical are for those readers who are familiar with networking operations, such as system administrators, and who are looking for a quick reference to specific DDoS issues or for a fast technical overview of the problems and potential solutions. These readers may wish to read only the technical chapters. There is also a chapter that bears a nontechnical/technical mark. This chapter has a blend of material that contains both technical and nontechnical items. Both of the above groups should read this chapter. Finally, readers who are specifically seeking to learn about DDoS in order to work in this field in the future, such as students and teachers, will find it useful to read the book from cover to cover, as nontechnical chapters set the stage for technical ones.
288
289Chapter 2: Understanding Denial of Service. (Nontechnical/technical level) This chapter explains the DDoS phenomenon and illustrates the scope and seriousness of the problem.
290
291Chapter 3: History of DoS and DDoS. (Nontechnical level) This chapter recounts how and when DoS attacks came about, how they evolved into DDoS attacks, what is behind the DDoS problem, and what aspects of Internet design and management are especially related to this problem.
292
293Chapter 4: How Attacks Are Waged. (Technical level) This chapter gives a detailed description of the "modus operandi" of a DDoS attack and discusses different DDoS variants.
294
295Chapter 5: An Overview of DDoS Defenses. (Nontechnical level) This chapter discusses the challenges that DDoS defense is facing. It also discusses different approaches to design a DoS or DDoS defense, and presents some key ideas, found both in research and commercial solutions. These ideas are building blocks of current defenses.
296
297Chapter 6: Detailed Defense Approaches. (Technical level) This chapter explains practical approaches to strengthen your network and make it resist and recover from DDoS attacks. It discusses how to analyze DDoS incidents and gather detailed information that will help respond to the attack and, later, take legal action against perpetrators.
298
299Chapter 7: Survey of Research Defense Approaches. (Technical level) This chapter gives an overview of many research approaches to DoS and DDoS defense.
300
301Chapter 8: Legal Issues. (Nontechnical level) This chapter speaks about laws that are applicable to DoS and DDoS, and steps you can take to bring legal action against attackers.
302
303Chapter 9: Conclusions. (Nontechnical level) This chapter offers a prognosis for DDoS defense and conclusions, along with useful pointers to Web pages, mailing lists, conferences, and journals that publish DDoS-related information.
304
305Appendix A: Glossary. (Technical level) This appendix contains a glossary of technical terms used throughout the book, with detailed explanation and organized as an easy reference.
306
307Appendix B: Survey of Commercial Defense Approaches. (Technical level) This appendix offers a survey of several commercial DDoS solutions to inform the reader of design decisions implemented in these solutions, and functionalities that can be found in the market.
308
309Appendix C: DDoS Data. (Technical level) This appendix offers a survey of available quantitative studies of the DDoS phenomenon, detailing the frequency and type of observed attacks, how they are performed, and the damages incurred.
310
311
312Chapter 2. Understanding Denial of Service
313A denial-of-service attack is different in goal, form, and effect than most of the attacks that are launched at networks and computers. Most attackers involved in cybercrime seek to break into a system, extract its secrets, or fool it into providing a service that they should not be allowed to use. Attackers commonly try to steal credit card numbers or proprietary information, gain control of machines to install their software or save their data, deface Web pages, or alter important content on victim machines. Frequently, compromised machines are valued by attackers as resources that can be turned to whatever purpose they currently deem important.
314
315In DDoS attacks, breaking into a large number of computers and gaining malicious control of them is just the first step. The attacker then moves on to the DoS attack itself, which has a different goal—to prevent victim machines or networks from offering service to their legitimate users. No data is stolen, nothing is altered on the victim machines, and no unauthorized access occurs. The victim simply stops offering service to normal clients because it is preoccupied with handling the attack traffic. While no unauthorized access to the victim of the DDoS flood occurs, a large number of other hosts have previously been compromised and controlled by the attacker, who uses them as attack weapons. In most cases, this is unauthorized access, by the legal definition of that term.
316
317While the denial-of-service effect on the victim may sound relatively benign, especially when one considers that it usually lasts only as long as the attack is active, for many network users it can be devastating. Use of Internet services has become an important part of our daily lives. The Internet is increasingly being used to conduct business and even to provide some critical services. Following are some examples of the damaging effects of DoS attacks.
318
319Sites that offer services to users through online orders make money only when users can access those services. For example, a large book-selling site cannot sell books to its customers if they cannot browse the site's Web pages and order products online. A DoS attack on such sites means a severe loss of revenue for as long as the attack lasts. Prolonged or frequent attacks also inflict long-lasting damage to a site's reputation—customers who were unable to access the desired service are likely to take their business to the competition. Sites whose reputations were damaged may have trouble attracting new customers or investor funding in the future.
320
321Large news sites and search engines are paid by marketers to present their advertisements to the public. The revenue depends on the number of users that view the site's Web page. A DoS attack on such a site means a direct loss of revenue from the marketers, and may have the long-lasting effect of driving the customers to more easily accessible sites. Loss of popularity translates to a direct loss of advertisers' business.
322
323Some sites offer a critical free service to Internet users. For example, the Internet's Domain Name System (DNS) provides the necessary information to translate human-readable Web addresses (such as www.example.com) into Internet Protocol (IP) addresses (such as 192.0.34.166). All Web browsers and numerous other applications depend on DNS to be able to fetch information requested by the users. If DNS servers are under a DoS attack and cannot respond due to overload, many sites may become unreachable because their addresses cannot be resolved, even though those sites are online and fully capable of handling traffic. This makes DNS a part of the critical infrastructure, and other equally important pieces of the Internet's infrastructure are also vulnerable.
324
325Numerous businesses have come to depend on the Internet for critical daily activities. A DoS attack may interrupt an important videoconference meeting or a large customer order. It may prevent a company from sending out an important document for a rapidly approaching deadline or interfere with its bid for a large contract.
326
327The Internet is increasingly being used to facilitate management of public services, such as water, power, and sewage, and to deliver critical information for important activities, such as weather and traffic reports for docking ships. A DoS attack that disrupts these critical services will directly affect even people whose activities are not related to computers or the Internet. It may even endanger human lives.
328
329A vast number of people use the Internet on a daily basis for entertainment or for communicating with friends and family. While a DoS attack that disrupts these activities may not cause them any serious damage, it is certainly an unpleasant experience that they wish to avoid. If such disruptions occur frequently, people are likely to stop using the Internet for these purposes, in favor of more reliable technologies.
330
331
3322.1. The Ulterior Motive
333Why do attackers seek to deny service? This act, very disruptive in nature, is not always an end in and of itself. What could be the ultimate goal then?
334
335Some of the early DoS attacks were largely proofs of concept or simple pranks played by hackers. The ultimate goal was to prove that something could be done, such as taking a large, popular Web site offline. Such a major achievement brings an attacker recognition in the underground community.
336
337Frequently, attackers would also fight each other for supremacy via denial of service. Internet chat channels were and still are a sought-after resource by the attackers. They are used to coordinate multiple attacking machines and to trade code and illegal information with other attackers. The user who created the channel controls the access to it, and is called a moderator, operator, or owner. The easy way to take over the channel (and along with it all the attack machines that are controlled via this channel) and to dominate all the communications is to perform a DoS attack on its current moderator. When a moderator's machine goes offline, another user can take over the channel. Besides supremacy, attackers also sought revenge through denial of service. A hacker whose machines were knocked offline by DoS would "return the favor" by attacking the perpetrator. People who dared to speak ill of hackers in public have also felt DoS revenge.
338
339Another frequent motive of DoS attacks is self-described as being political. Individuals or groups who disagree with views or actions of a certain organization (an online media site, a corporation, or a government) have been known to launch DoS attacks against computers and networks owned by this organization.
340
341If the target of the attack is a company, a conceivable motive can be a competitor's wish to gain an edge in the market. So far, no attacks have been proved to have this motive. However, there is a major lack of data on perpetrators and motives of DoS attacks. The vast majority of attacks are not reported, let alone investigated. Of those that do undergo detailed investigation, only a few contain enough evidence to establish the motive. It is thus quite possible that some companies may resort to such illegal means of driving the competition out of the market.
342
343Recently, a number of attacks have appeared as part of extortion attempts [ZDn04]. The attackers threaten an online business with a denial of service, and a payment is requested for "protection." Sites that refuse the payment are being "persuaded" by small-scale attacks.
344
345
3462.2. Meet the Attackers
347Who are the likely perpetrators of DDoS attacks? We have evidence from studies that thousands of attacks occur on a regular basis, yet very few attackers have been caught and prosecuted. This is partly due to the inability of victims to meet the minimum damage limits necessary to prosecute, or because the victim doesn't feel prosecution is worthwhile or fears negative publicity. Another factor is the ease of performing a DoS attack without leaving many traces for investigators to follow. It is impossible to judge the profile of perpetrators from such a small sample of provable crimes. Still, from the lack of sophistication in many attacks, it is safe to assume that a very large percentage seem to be perpetrated by inexperienced hackers, so-called script kiddies. These hackers download crude attack tools from the Internet and use them unaltered. While such attacks can still severely cripple the victim, sufficient traces sometimes exist for investigators to be able to understand much about the attacker. Such crude attacks also frequently generate an easily recognizable traffic pattern that can be controlled by simple filters.
348
349Another type of a DoS perpetrator is a sophisticated hacker who uses several means to obscure her identity and create subtle variations in traffic patterns to bypass defenses. While these attacks are less common than the simple ones, they are particularly vicious and hard to handle. Sophisticated hackers may act on their own accord (when attacking for supremacy in their peer circle or for revenge) or may be hired by an underground movement or a criminal organization.
350
351The most dangerous potential attacker is the nation-state actor that has significant resources and skill available to write his own tools, using sophisticated command and control techniques, and taking advantage of intelligence resources that are hard to come by. Such an attacker could create very subtle effects that are difficult to even notice using common methods or tools. Besides, the monitoring tools may potentially have vulnerabilities themselves that can be exploited to hide the presence of the attack. To date, no DDoS attacks can be confidently ascribed to such nation-state actors, but they are inherently better at covering their tracks. If no such attacks have occurred yet, they may well occur in the future.
352
353Previous Section < Day Day Up > Next Section
354
355Previous Section < Day Day Up > Next Section
356
3572.3. Behind the Scenes
358How do DoS attacks work? As mentioned in Chapter 1, there are two main approaches to denying a service: exploiting a vulnerability present on the target or sending a vast number of seemingly legitimate messages. The first kind of an attack is usually called a vulnerability attack, while the second is called a flooding attack.
359
360Vulnerability attacks work by sending a few specifically crafted messages to the target application that possesses a vulnerability. This vulnerability is usually a software bug in the implementation or a bug in a default configuration of a given service. Malicious messages by the attacker represent an unexpected input that the application programmer did not foresee. The messages cause the target application to go into an infinite loop; to severely slow down, crash, freeze, or reboot a machine; or to consume a vast amount of memory and deny service to legitimate users. This process is called exploiting a vulnerability, and the malicious messages are called the exploit. In some cases, vulnerabilities of this kind can be exploited in the operating system, a common piece of middleware, or in a network protocol, as well as in application programs.[1] While it is impossible to detect all vulnerabilities, it can also be quite hard to find new exploits. This means that each vulnerability that is detected and patched is a large gain and a sure step ahead for the defenders.
361
362[1] For example, some implementations of the 802.11 wireless access protocol have a vulnerability that allows an attack to deny service selectively to one user in the wireless network or promiscuously to all of them. In effect, the attacker can send a packet to the wireless access point that claims to be from another user and that indicates that the user is finished and essentially wants to "hang up" [BS03]. The wireless access point then no longer recognizes communications from the targeted user. That user can reestablish communications with the access point, but the attacker can shut it down again in the same way.
363
364Flooding attacks work by sending a vast number of messages whose processing consumes some key resource at the target. For instance, complex messages may require lengthy processing that takes up CPU cycles, large messages take up bandwidth, and messages that initiate communication with new clients take up memory. Once the key resource is tied up by the attack, legitimate users cannot receive service. The crucial feature of flooding attacks is that their strength lies in the volume, rather than in content. This has two major implications:
365
366The attackers can send a variety of packets. The attack traffic can be made arbitrarily similar to the legitimate traffic, which greatly hinders defense.
367
368The flow of traffic must be so large as to consume the target's resources. The attacker usually has to engage more than one machine to send out the attack traffic. Flooding attacks are therefore commonly DDoS attacks.
369
370The simplest form of a DDoS attack is merely to send a very large quantity of messages, divided into packets, to a service on the victim machine. Unless something between the attacking machines and the victim drops those request packets, the victim will spend resources attempting to receive and properly handle them. If there are enough of these packets, all of the machine's resources will be spent trying to handle packets that have no value.
371
372Another DDoS option is to attack the victim's network interface. If the network card in the victim's machine can handle only 10 Mbps of traffic, then an attacker needs to merely generate 10 or more Mbps of any deliverable IP packets and send them to the victim. Again assuming that no other entity drops those packets before they reach the victim's interface, they will easily exhaust its network resources and also create a sizable congestion on the path to the victim. If there are a few legitimate packets in addition to the large flood of attack packets, they are unlikely to receive service.
373
374The attacker can also target the local network that attaches the victim to the Internet. If the attacker knows that the victim is attached to a 1-Gbps network segment, then she can send enough packets to the victim or other nodes on the segment to overwhelm it. Most networks become unusable as the traffic offered to them approaches their rated capacity, so little or no legitimate traffic will get through to the victim. In this form of DDoS attack, all of the other nodes on the network segment will similarly suffer. This example illustrates a curious property of DDoS: The damage is inflicted not only on the victim, but also on its legitimate users (who cannot get the service) and anyone else who shares the critical resource. For instance, the attacker may target a network that has the same ISP as you. If the amount of attack traffic is sufficiently high, your services may also be denied.
375
376The above attacks are all based on large volumes of traffic. The attacker can sometimes perpetrate an effective flooding attack with much smaller volumes. If the victim has some service running that requires more time to process a remote request than it takes to generate that request, or that ties up a scarce resource on the server, the attacker can make use of this asymmetry. Even short or infrequent bursts of malicious traffic will effectively tie up the critical resource. A common example is the TCP SYN flood attack, described in detail in Chapter 4. The attacker floods the victim with TCP SYN packets, which are usually used to initiate new communication. The victim reserves some memory in a limited-size buffer for each new communication request, while the attacker can send out those requests without any memory cost. This asymmetry helps the attacker disable any new communication during the attack, while sending very few TCP SYN packets.
377
378This discussion illustrates the fact that the line between vulnerability and flooding attacks is thin, and many attacks may well fall into both the vulnerability and flooding categories.
379
3802.3.1. Recruiting and Controlling Attacking Machines
381DDoS attacks require engagement of multiple machines, which will be sending the attack traffic to the victim. Those machines do not belong to the attacker. They are usually poorly secured systems at universities, companies, and homes—even at government institutions. The attacker breaks into them, takes full control, and misuses them for the attack. Therefore, the attacking machines are frequently called zombies, daemons, slaves, or agents. In this book we use the term agents.
382
383How does the attacker gain control over machines that belong to others? The agents are usually poorly secured machines—they do not have recent patches and software updates, they are not protected by a firewall or other security devices, or their users have easily guessed passwords. The attacker takes advantage of these well-known holes to break in. Un patched and old software has well-known vulnerabilities with already-written exploits. These belong to a specific kind of vulnerabilities—once exploited, they allow the attacker unlimited access to the system, as if he had an administrator's account. Accounts with easily guessed passwords, such as combinations of users' names or dictionary words, allow another easy way into the machine. There are several password-guessing tools that will quickly reveal if any of the accounts on a system have weak passwords. For example, Phatbot will attempt to connect and log in to Windows hosts using a set of several dozen very commonly chosen passwords. Even if these programs find accounts that do not have administrator privileges, this access can still be misused for a DDoS attack or, by exploiting other vulnerabilities, can elevate privileges to the administrator level.
384
385[2] A weak password is one that is easily guessed, by either a human guesser or an automated program that tries many possible passwords, such as all very short passwords, all the words in the dictionary, or the most commonly used men's and women's names.
386
387Once the attacker has gained control of the host, she installs the DDoS attack agent and makes sure that all traces of the intrusion are well hidden and that the code runs even after the machine is rebooted.
388
389DDoS attacks frequently involve hundreds or thousands of agents. It would be tedious and time consuming if the attacker had to manually break into each of them. Instead, there are automated tools that discover potential agent machines, break into them, and install the attack code upon a single command from an attacker, and report success back to her. Such tools can easily be downloaded from the Web or acquired from Internet chat channels. In addition to recruiting the collection of agents, automated tools also facilitate the control of this network by keeping track of the agents and providing easy ways of delivering commands to all of them at once. The attacker needs only to issue a single command and have all agents start the flood to the given victim.
390
3912.3.2. Hiding
392The attacker further hides her identity by deploying several layers of indirection between her machine and the agents. She uses one or several machines that deliver her commands to the agents. These machines are called handlers or masters. In this book we use the term handlers.
393
394Another layer of indirection consists of the attacker's logging on to several machines in sequence, before accessing the handlers. These intermediary machines between the attacker's machine and the handlers are called the stepping stones,
395
396Both handlers and stepping stones are used to hinder investigation attempts. If authorities located and examined an agent machine, all its communication would point to one of the handlers. Further examination of the handler would point to a stepping stone, and from there to another stepping stone. If stepping stones are selected from different countries and continents (and they usually are), it becomes very difficult to follow the trail back to the attacker's machine and unveil her identity.
397
398Another means of obscuring the attack is through the use of IP spoofing. Each packet in the Internet carries some control information preceding the data—an IP header. One field in the IP header specifies the address of the sender—the source IP field. This information is filled in by the machine that sends the packet (an action similar to putting a return address on a letter), and is used by the destination, or the routers on the path to the destination, to send replies back to the source. Attackers commonly forge this field to achieve impunity for the attacks and hinder the discovery of agent machines. IP spoofing also greatly complicates some DDoS defense approaches that rely on a source address for differentiation between legitimate clients and attackers. With IP spoofing, an attacker easily assumes the identity of a legitimate client or even several of them.
399
4002.3.3. Misusing Legitimate Services
401IP spoofing creates an opportunity for fooling noncompromised and otherwise perfectly secure machines into participating in a DDoS attack. The attacker chooses a publicly available service or protocol, such as the Domain Name System (DNS), Web, or ping, and sends service requests to many such servers, forging the source address of the victim. Servers then reply back to the victim, and this flood of replies creates denial of service. This type of attack is called a reflection attack, and the servers participating in it are called reflectors. Of special interest to the attacker are services that can generate lengthy or numerous replies for a few short requests. This is called amplification, and it enables the attacker to create a DoS effect with a few small packets.
402
403
404
4052.4. Distribution Effects
406Denial of service is possible without using distributed techniques, but it poses a challenge for an attacker. For example, imagine that a DoS attack based on pure flooding originates at a single machine with a 10-Mbps link and is directed toward a victim machine that has a 100-Mbps link. In an attempt to overwhelm the victim's link, the attacker will flood his own network and deny service to himself. To successfully disrupt the victim's communication, the attacker must compromise an agent machine that has more network resources than the victim. Locating and breaking into such a machine may prove difficult, especially if the target of the attack is a well-provisioned site.
407
408However, consider what happens if the same attack is performed in a distributed manner, say, by a hundred machines. Each machine now sends 1 Mbps toward the victim. Assuming all hundred machines have 10-Mbps links, none of them generates enough traffic to cause serious harm to its own local network. But the Internet delivers all attack traffic to the victim, overwhelming its link. Thus, the victim's service is denied, while the attackers are still fully operational.
409
410Distribution brings a number of benefits to the attacker:
411
412A typical server machine has more computing, memory, and bandwidth resources than a typical client machine. An attacker with control of only one client machine would thus have difficulty overwhelming the server's resources without first overwhelming his own. By using distributed techniques, the attacker can multiply the resources on the attacking end, allowing him to deny service to more powerful machines at the target end.
413
414To stop a simple DoS attack from a single agent, a defender needs to identify that agent and take some action that prevents it from sending such a large volume of traffic. In many cases, the attack from a machine can be stopped only if the machine's human administrator, or network operator, takes action. If there are 10, 100, or 1,000 agents participating in the attack, however, stopping any single one of them may provide little benefit to the victim. Only by stopping most or all of them can the DoS effect be alleviated. Getting thousands of people to take some action to stop an attack from their machine is an overwhelming challenge.[3]
415
416[3] Alternatively, defenders might attempt to locate a handler machine and command agents to stop flooding. This is a challenging task, too, since the attacker may have multiple handlers or use a legitimate service (e.g., IRC) instead of a handler, and the agent commands may be encrypted or password-protected.
417
418If the attacker chooses agents that are spread widely throughout the Internet, attempts to stop the attack are more difficult, since the only point at which all of the attack traffic merges is close to the victim. This point is called the aggregation point. Other nodes in the network might experience no telltale signs of the attack and might have difficulty distinguishing the attack traffic from legitimate traffic. Thus, they cannot help defend against the attack.
419
420In a DoS attack executed from a single agent, the victim might be able to recover by obtaining more resources. For example, an overwhelmed Web server might be able to recruit other local servers to help handle the extra load. Regardless of how powerful a single agent might be, the defender can add more capacity until he outstrips the attacker's ability to generate load. This approach is less effective in defending against DDoS attacks. If the defender doubles his resources to handle twice as many requests, the attacker merely needs to double the number of agents—often an easy task.
421
422Another aspect makes both DoS and DDoS attacks hard to handle: Defenses that work well against many other kinds of attacks are not necessarily effective against denial of service. For years, system administrators have been advised to install a firewall and keep its configuration up to date, to close unnecessary ports on all machines, to stay current with patches of operating systems and other important software, and to run intrusion detection systems to discover any attacks that have managed to penetrate the outer bastions of defense. Unfortunately, these security measures often will not help against denial of service. The attack can consist of traffic that the firewall finds acceptable, probably because it bears a close resemblance to legitimate traffic. Since the DoS attack merely needs to exhaust resources, it can work on any port left open, including those that must be open for a node to do its normal business. Attackers can perform DoS attacks on machines that have no vulnerabilities (by the standard definition of that term), so patches to close vulnerabilities may not help. Also, intrusion detection systems are of limited value in dealing with DoS, since, unlike break-ins and thefts, DoS attacks rarely hide themselves. After all, their whole purpose is to interrupt normal business, an event that will usually be noticed.
423 Previous Section < Day Day Up > Next Section
424
4252.5. DDoS: Hype or Reality?
426The issues described in the previous section make DDoS attacks a frightening possibility. Yet researchers in computer and network security are aware of many frightening possibilities that never come to pass. Are security researchers merely alarming the public with claims of the dangers of DDoS?
427
428Unfortunately, DDoS attacks are not speculation or fiction. They occur on a daily basis, directed against a wide range of sites. Chapter 3 details, in timeline fashion, a large number of representative attacks. The details of these attacks will be left to that chapter, while some specifics will be mentioned in this chapter. In addition to several well-known occurrences of DDoS attacks that were widely reported in the press, there are scientific studies of the frequency of these attacks that demonstrate the reality of the problem (see Appendix C for a summary of these studies).
429
4302.5.1. How Common Are DDoS Attacks?
431There are some forms of cyberattacks that receive a lot of publicity because they generate a few high-profile incidents, even though these types of attacks do not actually occur that often. Unless these incidents are particularly disastrous, the overall impact of the attacks is more related to publicity than large amounts of damage done to many businesses or individuals.
432
433DDoS attacks do not fit that category. A number of recent studies have demonstrated that DDoS attacks are extremely common in today's networks. Given that they are usually quite effective and perpetrators are rarely caught, there is reason to believe they will become even more popular in the future.
434
435Measuring the frequency of any form of attack in the Internet is difficult. Victims do not always realize that they are under attack. Even if they do, they often fail to report the attack to any authority. A number of organizations use survey techniques to gain some insight into the prevalence of different kinds of cyberattacks and the amount of damage they do. One example is the FBI's annual report on cybercrime, based on information provided by nearly 500 organizations. In the 2004 report, nearly a fifth of the respondents who suffered financial loss from an attack had experienced a DoS attack. The total reported costs of DoS attacks to these companies was over $26 million. Denial of service was the top source of financial loss due to cybercrime! These surveys are often criticized because their methodology is unavoidably subject to certain limitations, but relatively little better data exists.
436
437The methods used in these surveys do not differentiate between distributed and nondistributed DoS attacks, since the technology for making the distinction is in its infancy. In the meantime, researchers have used a variety of techniques to estimate data on the frequency of DDoS attacks and their other characteristics.
438
439For example, Farnam Jahanian of the University of Michigan has been able to observe network activities in the MichNet ISP. This network provider offers ISP service to government and nonprofit organizations in the state of Michigan, including most educational institutions in that state. Over the course of time, Jahanian's team has gathered data suggesting that DDoS attacks are quite common and are increasingly sophisticated. Jahanian's full results have not yet been published; however, a presentation covering some of his results can be found at http://www.arbor.net/downloads/nanogSlides4.pdf.
440
441A number of researchers have investigated various technical means to deduce information about the prevalence and character of DDoS attacks in the Internet [DLD00]. CAIDA (the Cooperative Association for Internet Data Analysis), for example, used a technique called backscatter. Full details of this technique and CAIDA's results can be found in Appendix C. Their results suggest that during a three-week observation period in 2001 there were around 4,000 DDoS attacks per week on Internet nodes.
442
443For reasons covered in Appendix C, CAIDA's numbers are certainly an underestimate. Jahanian's results can be interpreted to suggest that the CAIDA figure of 4,000 attacks per week would be more realistically set at 12,000 attacks per week, even leaving aside some classes of DDoS attacks. Further, other data suggests that DDoS attacks have become more common since 2001.
444
445If DDoS attacks are so common, why do we not hear more about them? Evidence gathered by CAIDA and Jahanian suggests that most DDoS attacks are launched against fairly small targets (home machines, for example) for short durations. Some have speculated that many of the incidents represent hackers attacking each other, though too little evidence exists to come to any strong conclusion on this point. Short durations can cause a DDoS attack to appear to be no more than another network glitch. When a user clicks on a link and receives no response for a minute or two, he is more likely to conclude that the server is busy or that there are general network congestion problems, rather than that he (or, more likely, the server) is suffering a DDoS attack. Thus, in many cases DDoS attacks may pass unnoticed.
446
447If many DDoS attacks are not even noticed, how seriously should we regard the problem? First, there is a significant and growing number of high-profile incidents of serious, persistent, powerful DDoS attacks clearly meant to deny service to important sites. Second, remember that the small, short attacks are typically small and short because that was what the attacker wanted to do, rather than what he could do. A DDoS agent network can continue its attack for hours, or perhaps even indefinitely. And attackers can easily gather huge agent armies. The techniques are already well known and of proven effectiveness. All that remains is a sufficient motive for them to be widely used for destructive purposes.
448
4492.5.2. The Magnitude of DDoS Attacks
450Another potentially measurable dimension of a DDoS attack is its size. The size of an attack can be measured in the traffic it generates or in the number of sites participating in the attack. It can also be measured in its duration, a characteristic that some DDoS studies have addressed.
451
452The built-in statistics capabilities of the Shaft attack tool [DLD00] allowed researchers to estimate the magnitude of a given attack in late 1999, at 4.5 Mbps emanating from a single DDoS agent in a network of about 100 agents (see also Figure 4.11 in Chapter 4). Also, MultiRouter Traffic Grapher (MRTG) measurements [Oet] from an actual attack in May 2001 collected close to the target location provide a lower estimate for the inbound attack traffic volume of about 25 Mbps (see Figure 4.13 in Chapter 4). The lower estimate is due to the measurement equipment collapsing intermittently under the heavy load.
453
454DDoS attacks that have taken out large network links in the past, such as an attack on Australian Uecomm, have involved volumes of up to 600,000 pps [Gra]. In attacks on the DNS root servers in 2002, each server received 100,000 to 200,000 pps [Nar]. In some cases, such as the Al-Jazeera attack in 2003, the attackers added attack volume as the defenders added capacity to handle traffic. This shows that attackers can easily increase the attack strength when necessary, so the measured attack magnitudes have more to do with what the attacker feels is required than with the maximum amount that he can generate. In fact, many attacks may have specifically used a set of moderate-sized discrete attack networks so as to not expose all of them at one time. More recent attackers have learned that it is wasteful to use all of their resources at one time and instead ramp up an attack slowly to maximize how long the attack can be maintained in the face of attrition of the agents.
455
456The backscatter approach used by CAIDA can also estimate the volume of attacks. (Again, for details on how this can be done, see Appendix C.) Taking into account certain limitations of the approach that might lead to underestimates, half of the attacks they observed caused volumes of 350 pps or more. Depending on the target's capabilities, the type of packet, and the target's defenses, this volume is often enough to deny service. The largest volumes CAIDA deduced were hundreds of thousands of packets per second. For example, in the TCP SYN flood attacks against SCO in December 2003, CAIDA estimated that SCO's servers received as many as 50,000 pps at one point and dealt with a total of over 700 million attack packets over a 32-hour period. They estimated this peak rate of 50,000 pps yielded "approximately 20 Mbits/second of Internet traffic in each direction, comparable to half the capacity of a DS3 line (roughly 45 MBits/second.)" [MVS01].
457
458In terms of the number of machines involved in an attack, statistics are harder to come by. It is clear from evidence gathered by the University of Minnesota, which suffered one of the first DDoS attacks in 1999, that DDoS attack networks could be assembled from well over 2,200 systems using only partially automated agent recruitment methods. This minimum number is known because that attack did not use IP spoofing. In attacks in which some form of IP spoofing is used, merely counting the number of IP addresses observed during a particular DDoS attack will grossly overestimate the number of nodes involved.
459
460Another approach is to deduce the number of machines from the observed volume. The largest attack rate observed by CAIDA was estimated to be 679,000 pps. How many packets a machine can generate per second depends on several factors, including its CPU speed and network connectivity. For machines with 10-Mbps links to the Internet, generating 20,000 pps is probably near their maximum capability. So if we assume the largest attack observed by CAIDA was performed by a group of such machines, there had to be at least 30 or 40 of them. For the DNS server attack mentioned above, there had to be at least 90 of them. Many machines have substantially lower speed Internet connections, and if these machines are used as agents, many more of them would be required to achieve these rates. For example, if all agents used 56 Kbps links to connect to the Internet, CAIDA's largest observed attack would have involved at least 5,800 agents. The actual number of agents used in this attack is probably between these ballpark figures. Reflected attacks, where attacking hosts send out forged attack packets that are reflected off a very large number of legitimate servers around the world, greatly amplify the attack. One such attack against futuresite.register.com involved a very small number of attacking hosts, but was still able to generate 60 to 90 million bits per second flooding the victim.
461
462One might wonder where the DDoS agents come from. Most experts believe that very few attackers use their own machines to launch DDoS attacks, since doing so would increase their risk of being caught. Instead, they compromise other machines remotely and use them to launch the attack. If compromising a remote machine were a difficult process requiring extensive human intelligence and attention, this factor would limit the seriousness of the DDoS threat. However, experience has shown that automated techniques are highly effective at compromising remote sites, which can then be used to launch DDoS attacks.
463
464Just to give an idea of how easy it is to compromise a large number of hosts, here are some figures:
465
466Microsoft announced that their MSBlast cleanup tool was downloaded and used to successfully clean up 9.5 million hosts from August 2003 to April 2004, an average of approximately 1 million compromised computers per month (see http://zdnet.com.com/2100-1105-5201807.html?tag=nl).
467
468Microsoft announced in May 2004 that they had cleaned up 2 million Sasser infected hosts (see http://www.securityfocus.com/news/8573).
469
470The same news story reports Symantec had identified a bot network of 400,000 hosts.
471
472A network administrator in the Netherlands has identified between 1 million and 2 million unique IP addresses associated with Phatbot infections. Phatbot has features to harvest MyDoom- and Bagel-infected hosts, among other infection vectors (see http://www.ladlass.com/archives/001938.html).
473
474Probably the most common method of recruiting agents is to run an automated program that scans a large IP address range attempting to find machines that are susceptible to well-known methods of compromise. These programs, called automated infection toolkits, or auto-rooters (after the name of the system administrator account on Unix systems, root, also the hacker verb meaning "to compromise or gain elevated privileges on"), are generally quite successful in finding large numbers of vulnerable machines, particularly if they are updated to include newly discovered vulnerabilities that are less likely to have been patched.
475
476The ultimate in automation is an Internet worm—a program that looks for vulnerable machines and infects them with a copy of its code. Worms propagate extremely rapidly. Some worms have used their armies of infected machines specifically to perform DDoS attacks. The worm can even carry the code to perpetrate the DDoS attack. For example, Code Red was designed to perform a DDoS attack from all the nodes it compromised on a particular IP address. Code Red succeeded in infecting over 250,000 machines, by some estimates. Code Red II infected as many as 500,000 machines. Estimates for the number of machines infected by the W32/Blaster and W32/Sobig.F worms run from the tens of thousands to a few hundreds of thousands, and some reports refer to these numbers as "small." Sasser infected at least 2 million hosts, judging by Microsoft's report (http://www.securityfocus.com/news/8573). Thus, it is quite realistic to envision DDoS attacks originating from hundreds of thousands, even millions of points in the Internet.
477
478
4792.6. How Vulnerable Are You to DDoS?
480If you accept that DDoS attacks are a real threat to some Internet sites, the next question likely to come to mind is: How vulnerable is my site? The simple answer is that if your site is connected to the Internet, you are a potential target of a DDoS attack. A DDoS attack can target any IP address and, if the attack is strong enough, it is likely to be successful. Large and small businesses, ISPs, government organizations that rely on networking, and even private individuals are among those who may be damaged by a DDoS attack. The more use you have for the Internet in your enterprise, the greater the damage you will suffer if a DDoS attack takes it offline for an extended period.
481
482Even if your machine sits behind a NAT box,[4] a firewall, or some other form of protection that prevents arbitrary traffic from being directly routed to it, you may still be vulnerable to the more sophisticated DDoS attacks. A sophisticated attacker can replay or spoof traffic that should go to your node or indirectly subject you to denial of service by overloading the NAT box, firewall, router, or network link.
483
484[4] A Network Address Translation (NAT) box is a firewall-like host acting as a gateway to a network. All packets leaving the network pass through the NAT box and have their source addresses replaced by the address of this box. A reverse transformation is applied to destination addresses of incoming packets—the address of the NAT box is replaced with the appropriate address of a machine inside the network. The NAT technique enables a network to hide its internal structure—the only address that external users ever see is that of the NAT box.
485
486Further, as we previously discussed, careful system and network administration will not necessarily save you from an attack. While some fixes will prevent vulnerability attacks, your site will still be susceptible to large flooding attacks.
487
488Heavy provisioning, in the form of ample server and network capacity, can protect you from many flooding DDoS attacks, but cannot guarantee your immunity. Any realistic amount of capacity you provide can be overcome if an attacker recruits enough machines to press his attack against you. Reflect on how heavily you would have to provision yourself to withstand a DDoS attack by the million-plus Phatbot network reported earlier.
489
490Nonetheless, there are things you can do to decrease your vulnerability to DDoS attacks and make you a less attractive target. Heavy provisioning helps, since it rules out casual attacks by hackers who have only one or two dozen agent machines at their disposal. Closing vulnerabilities also helps, since it fends off vulnerability attacks. If keeping a low profile on the network is an option for your organization, doing so requires the attacker to find some obscure information before he can launch his attack. There are practical steps to take to strengthen your network and also efficient attack responses that alleviate the DoS effect. We will discuss these in more detail in Chapter 6. Chapter 7 looks at research approaches that may lead to new DDoS defense tools in the future. A number of commercial products have successfully defended against many forms of DDoS attack; we will discuss some of them in Appendix B.
491
492Generally, the evidence suggests that practically all DDoS attacks that occur are not nearly as bad as catastrophic worst-case-scenario thinking suggests they could be. Even some of the high-profile attacks on major Internet sites were not that difficult to handle once the defenders were aware of the nature of the attack and had a little time to respond to it. If you depend on continual Internet availability of your resources, you are almost certainly in danger from DDoS attacks; but with a little knowledge, forethought, and vigilance you can prevent DDoS attacks on your site from becoming disasters.
493
494Even if you are not particularly dismayed by the prospect of being a DDoS victim, another element of DDoS attacks might cause you trouble. To perpetrate a strong DDoS attack, the attacker typically compromises a large number of machines. If your machine is among them, at best you are unwillingly sharing your resources with a criminal who definitely doesn't have your best interests at heart. At worst, you may find yourself partially liable for some of the damages done by his attack, or your vital data may be stolen or damaged by the attacker who has taken over your machine. The value attackers obtain by performing DDoS attacks on others has made such criminals more motivated to compromise ever larger armies of agent machines, meaning that your machine has become more likely to be taken over by an outside party.
495
496
497Chapter 3. History of DoS and DDoS
498In this chapter we will discuss the origins of Internet denial of service, based on the historical aspects of the Internet and its design principles, as well as the events that led to major DDoS attacks on Internet sites and beyond, up to today. We describe the motivations of both the Internet designers and the attackers.
499Previous Section < Day Day Up > Next Section
500
5013.1. Motivation
502It is human nature that when groups of people get together, there is bound to be disagreement and conflict. This conflict can take many forms: glaring at someone who is crowding you in line to get them to back off, cutting someone off in traffic, using the favorite national hand gesture that shows the utmost contempt possible for them. Or even worse acts: slashing someone's tires, pouring sugar in their gas tank to make their car fail, or throwing a bundle of money into a public square or street causing a riot and obstructing passage. As it happens, all of these are examples of physical-world forms of DoS, denial of transportation, in these last examples.
503
504As the Internet gained popularity as a virtual meeting place, it also became a place of conflict. Usenet newsgroups that bring together people with like interests degrade into flame-filled series of tirade after tirade among arguing members. Or someone who feels wronged goes "trolling" [Wik]—making inflammatory statements, calling someone names, asking a blatantly off-topic question—anything to purposely cause flame wars and degrade conversation in a newsgroup or e-mail list. Someone who trolls can cause dozens, even hundreds, of useless e-mail messages saying, "Stop this!," "You're just an idiot and should leave this group," "Can't someone ban this jerk from our newsgroup?", etc. In some cases, it gets so bad that people unsubscribe and leave the group permanently. The degradation of discourse is another form of DoS—some kind of interference that prevents a computer user from doing something that he or she would otherwise have been able to do had there been no interference, but one that often cannot be maintained very long.
505
506Articles like Suler and Phillips' "The Bad Boys of Cyberspace" [SP98] and a study titled "The Experience of Bad Behavior in Online Social Spaces: A Survey of Online Users," by Davis [JPD] show that people can sometimes behave quite differently, often in very antisocial ways, when interacting in the Internet as opposed to when they interact with people face to face. They may misinterpret things because they lack nonverbal cues or because they lack detail or context. They may be quicker to anger than if speaking to someone face to face, and because they cannot see the person they are speaking to, they may react more strongly. Anonymity may give them a sense of invisibility, and they may consider the icons that represent other users as being unreal and disassociated from another person.
507
508This point is important. Some people consider online chat rooms to be just like real rooms, and they can form a picture in their mind that gives these other participants identity. Other people in the same chat room will only see the words on the screen, and they will themselves feel invisible and invincible because they sit in the comfort of their own room and can turn off the computer whenever they want. The other world (and everyone in it) then ceases to exist, just like the TV world vanishes when the set is turned off. Unlike the physical world, where two people having a conflict are often standing toe to toe, in the Internet the conflict takes place with an intermediary network that is effectively a black box to the parties involved. There is only a keyboard and monitor in front of each person, and their respective moral and ethical frameworks to guide them in how they act. This disassociation and lack of physical proximity encourages people to participate in illegal activities in the Internet, such as hacking, denial of service, or collecting copyrighted material. They do not feel that in reality they are doing any serious harm.
509
510Typical end users do not care about the intrinsics of network communications in the Internet. Instead, they are merely interested in the benefits the Internet provides them with, such as e-commerce or Internet banking. However, those who have that detailed knowledge of network specifics and can abuse it to exclude and effectively deny the services to others feel greatly empowered. That is the point at which DoS programs enter the scene.
511
512Over the years, DoS attacks in the Internet have predominantly been associated with communication mechanisms such as newsgroups, chat rooms, online games, etc. These are asynchronous communication mechanisms, meaning that there is no direct and immediate acknowledgment of receipt, and no real-time dialogue. E-mail gets delivered when it gets delivered, and messages can come in out of order and get mixed in with all the rest. Asynchronous communication mechanisms in the Internet, such as Usenet newsgroups or e-mail lists, can be attacked by trolling or by flooding with bogus messages, but these attack mechanisms do not have a direct effect and can fairly easily be dealt with by filtering. Since these communication mechanisms are asynchronous, there is a delay and thus the attacker does not get instant gratification.
513
514DoS attacks that cause servers to crash or fill networks with useless traffic, on the other hand, do provide immediate satisfaction. They directly affect a system and, if combined with a threat immediately beforehand, increase the potency and satisfaction for the attacker. They work best on synchronous means of communication, like realtime chat or Web activity that involves a sustained series of interactions between a browser and a Web server.
515
516For example, if Jane wants to hurt NotARealSiteForPuppies.com, to really scare them, she might first send them a threatening e-mail that states, "You people are scum! I am going to take your site down for three hours, and then I'm going after your little dog, too!" She waits until she gets a reply saying this is being reported to the ISP of the account that sent the message (most likely a stolen account), and then she immediately begins the promised attack. She then checks to see if the Web page comes up, and sees that the browser reports, "Timeout connecting to server." Mission accomplished!
517
518Synchronous communication mechanisms like online games [Gam] and Internet Relay Chat (IRC [vLL]), as opposed to Usenet newsgroups and mailing lists, are more often subjected to DoS attacks because of this direct effect. Not only can you directly affect an individual user, causing them to get knocked off of IRC channels, but you can also disrupt an entire IRC network. It is important to understand these attacks (even if you don't use or have anything to do with IRC) because the tools and techniques are just as effective against a Web server, or a corporation's external Domain Name System (DNS) or mail servers.
519
520Early attacks on the IRC network were known to a few security experts, such as coauthor Sven Dietrich, in the early 1990s. DoS attacks, which in one instance took the form of a TCP RST flood, caused IRC servers to "split" (i.e., to lose track of who owns a channel). A remote user, being the only one left in that channel, would then "own" one or more chat channels, since the legitimate owner was split from the local network. When the networks would join again, legitimate and illegitimate owners would have a face-off, which could lead to further retribution. Larger-scale attacks were also used to remove unwelcome users from chat channels, as an effective method of kicking them off forcefully. These problems were known to some IRC operators at Boston University at the time.
521
522Over the years, IRC has been one of the main motivators for development and use of DoS and DDoS tools, as well as being its major target. This relationship between IRC and DDoS attacks shares some similarities to the development of the HIV/AIDS crisis in the 1980s.[1] When HIV/AIDS was first discovered, many considered it a problem for only gays or Haitians or intravenous drug users. As long as you were not in that group, why should you worry about HIV/AIDS? Research into treatments and cures did not start early enough, and as a result HIV/AIDS spread across the world, to the point where today, the world's largest country, China, has cases in all levels of society throughout the entire country.
523
524[1] We are certainly not trying to say that DDoS has caused even a minute fraction of the harm that HIV/AIDS has. That is ridiculous. What is common are the lack of recognition of the problem by the general populace and media, the lack of response by some because it was believed to be "somebody else's problem," and a slow increase to the point where the problem becomes well entrenched and widespread. It was Machiavelli who said, "When trouble is sensed well in advance it can easily be remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. . . . Political disorders can be quickly healed if they are seen well in advance (and only a prudent ruler has such foresight); when, for lack of a diagnosis, they are allowed to grow in such a way that everyone can recognize them, remedies are too late."
525
526Similarly, DoS and DDoS were originally seen as an IRC-related problem, affecting only IRC servers and IRC users. Some sites even banned IRC servers on their campus, or moved IRC servers outside of the main network to a DMZ (DeMilitarized Zone) "free fire zone" that wouldn't impact the main network, all with the belief that this would "solve" the problem of DoS. (In fact, it just pushed it away, allowing it to continue to develop and outpace defense capabilities.) The same issue involved in DDoS—a large flood of packets—in 2003 began to occur as a result of worms, taking down many of the largest networks in the world, which had nearly five years to understand the problem and prepare for it but chose not to.
527
528In this same time, the attack tools themselves have grown in power, capabilities, ability to spread, and sophistication to the point where they are today being used in sophisticated attacks with financial motivations by organized criminal gangs. How did all this happen?
529
530We begin our quest for answers by examining the assumptions and principles on which the Internet was built.
531
532 Previous Section < Day Day Up > Next Section
533
5343.2. Design Principles of the Internet
535The predecessor to today's Internet, called ARPANET (Advanced Research Project Agency Network), was born in the late 1960s when computers were not present in every home and office.[2] Rather, they existed in universities and research institutions, and were used by experienced and knowledgeable staff for scientific calculations. Computer security was viewed as purely host security, not network security, as most hosts were not networked yet. As those calculations became more advanced and computers started gaining a significant presence in research activities, people realized that interconnecting research networks and enabling them to talk to each other in a common language would advance scientific progress. As it turned out, the Internet advanced more than the field of science—it transformed and revolutionized all aspects of human life, and introduced a few new problems along the way.
536
537[2] For a historical overview of the ARPANET, see the University of Texas timeline at http://www.cs.utexas.edu/users/chris/think/ARPANET/Timeline/
538
5393.2.1. Packet-Switched Networks
540The key idea in the design of the Internet was the idea of the packet-switched network [Kle61, Bar64]. The birth of the Internet happened in the middle of the Cold War, when the threat of global war was hanging over the world. Network communications were already crucial for many critical operations in the national defense, and were performed over dedicated lines through a circuit-switched network. This was an expensive and vulnerable design. Government agencies had to pay to set up the network infrastructure everywhere they had critical nodes, then set up communication channels for every pair of nodes that wanted to talk to each other. During this communication, the route from the sender to the receiver was fixed. The intermediate network reserved resources for the communication that could not be shared by information from other source-destination pairs. These resources could only be freed once the communication ended. Thus, if the sender and the receiver talked infrequently but in high-volume bursts, they would tie down a considerable amount of resources that would lie unutilized most of the time.
541
542The bigger problem was the vulnerability of the communication to intermediate node failures. The dedicated communication line was as reliable as the weakest of the intermediate nodes comprising it. Single node or link failure led to the tear-down of the whole communication line. If another line was available, a new channel between the sender and the receiver had to be set up from the start. Nodes in circuit-switched networks had only a few lines available, which were high-quality leased lines dedicated to point-to-point connectivity between computers. These were not only very expensive, but made the network topology extremely vulnerable to physical node and link failures and consequently could not provide reliable communications in case of targeted physical attack. A report [Bar64] not only discussed this in detail, but also offered simulation results that showed that adding more nodes and links to a circuit-switched network only marginally improves the situation.
543
544The packet-switched network emerged as a new paradigm of network design. This network consists of numerous low-cost, unreliable nodes and links that connect senders and receivers. The low cost of network resources facilitates building a much larger and more tightly connected network than in the circuit-switched case, providing redundancy of paths. The reliability of communication over the unreliable fabric is achieved through link and node redundancy and robust transport protocols. Instead of having dedicated channels between the sender and the receiver, network resources are shared among many communication pairs. The senders and receivers communicate through packets, with each packet carrying the origin and the destination address, and some control information in its header. Intermediate nodes queue and interleave packets from many communications and send them out as fast as possible on the best available path to their destination. If the current path becomes unavailable due to node or link failure, a new route is quickly discovered by the intermediate nodes and subsequent packets are sent on this new route. To use the communication resource more efficiently, links may have variable data rates. To compensate for the occasional discrepancy in the incoming and outgoing link rates, and to accommodate traffic bursts, intermediate nodes use store-and-forward switching—they store packets in a buffer until the link leading to the destination becomes available. Experiments have shown that store-and-forward switching can achieve a significant advantage with very little storage at the intermediate nodes [Bar64].
545
546The packet-switched network paradigm revolutionized communication. All of its design principles greatly improved transmission speed and reliability and decreased communication cost, leading to the Internet we know today—cheap, fast, and extremely reliable. However, they also created a fertile ground for misuse by malicious participants. Let's take a closer look at the design principles of the packet-switched network.
547
548There are no dedicated resources between the sender and the receiver. This idea allowed a manifold increase in network throughput by multiplexing packets from many different communications. Instead of providing a dedicated channel with the peak bandwidth for each communication, packet-switched links can support numerous communications by taking advantage of the fact that peaks do not occur in all of them at once. A downside of this design is that there is no resource guarantee, and this is exactly why aggressive DDoS attack traffic can take over resources from legitimate users. Much research has been done in fair resource sharing and resource reservation at the intermediate nodes, to offer service guarantees to legitimate traffic in the presence of malicious users. While resource reservation and fair sharing ensure balanced use among legitimate users, they do not solve the DDoS problem. Resource reservation protocols are sparsely deployed and thus cannot make a large impact on DDoS traffic. Resource-sharing approaches assign a fair share of a resource to each user (e.g., bandwidth, CPU time, disk space). In the Internet context, the problem of establishing user identity is escalated due to IP spoofing. An attacker can thus fake as many identities as he wants and monopolize resources in spite of the fair sharing mechanism. Even if these problems were solved, an attacker could effectively slow service to legitimate users to an unacceptable rate by compromising enough machines and using their "fair shares" of the resources.
549
550Packets can travel on any route between the sender and the receiver. Packet-switched network design facilitates the development of dynamic routing algorithms that quickly discover an alternative route if the primary one fails. This greatly enhances communication robustness as packets in flight can take a different route to the receiver from the one that was valid when they were sent. The route change and selection process are performed by the intermediate nodes directly affected by the route failure, and are transparent to the other participants, including the sender and the receiver. This facilitates fast packet forwarding and low routing message overhead, but has a side effect that no single network node knows the complete route between the packet origin and its destination.
551
552To illustrate this, let us observe the network in Figure 3.1. Assume that the path from A to B leads over one node, C, and that a node D is somewhere on the other side of the Internet. If D ever sees a packet from A to B, it cannot infer if the source address (A) is fake, or if C somehow failed and the packet is trying to follow an alternative path. Therefore, D will happily forward the packet to B. This example illustrates why it is difficult to detect and filter spoofed packets.[3] IP spoofing is one of the centerpieces of the DDoS problem. It is not necessary for many DDoS attacks, but it significantly aggravates the problem and challenges many DDoS defense approaches.
553
554[3] Packets that have a fake source IP address
555
556
557Figure 3.1. Routing in a packet-switched network
558
559
560
561
562
563Different links have different data rates. This is a logical design principle, as some links will naturally be more heavily used than others. The Internet's usage patterns caused it to evolve a specific topology, resembling a spider with many legs. Nodes in the Internet core (the body of the spider) are heavily interconnected, while edge nodes (on the spider's legs) usually have one or two paths connecting them to the core. Core links provide sufficient bandwidth to accommodate heavy traffic from many different sources to many destinations, while the links closer to the edges need only support the end network traffic and need less bandwidth. A side effect of this design is that the traffic from the high-bandwidth core link can overwhelm the low-bandwidth edge link if many sources attempt to talk to the same destination simultaneously, which is exactly what happens during DDoS attacks.
564
5653.2.2. Best-Effort Service Model and End-to-End Paradigm
566The main purpose of the Internet is to move packets from source to destination quickly and at a low cost. In this endeavor, all packets are treated as equal and no service guarantees are given. This is the best-effort service model, one of the key principles of the Internet design. Since routers need only focus on traffic forwarding, their design is simple and highly specialized for this function.
567
568It was understood early on that the Internet would likely be used for a variety of services, some of which were unpredictable. In order to keep the interconnection network scalable and to support all the services a user may need now and in the future, the Internet creators decided to make it simple. The end-to-end paradigm states that application-specific requirements, such as reliable delivery (i.e., assurance that no packet loss occurred), packet reorder detection, error detection and correction, quality-of-service requirements, encryption, and similar services, should not be supported by the interconnection network but by the higher-level transport protocols deployed at the end hosts—the sender and the receiver. Thus, when a new application emerges, only the interested end hosts need to deploy the necessary services, while the interconnection network remains simple and invariant. The Internet Protocol (IP) manages basic packet manipulation, and is supported by all routers and end hosts in the Internet. End hosts additionally deploy a myriad of other higher-level protocols to get specific service guarantees: Transport Control Protocol (TCP) for reliable packet delivery; User Datagram Protocol (UDP) for simple traffic streaming; Real Time Protocol (RTP), Real Time Control Protocol (RTCP), and Real Time Streaming Protocol (RTSP) for streaming media traffic; and Internet Control Message Protocol (ICMP) for control messages. Even higher-level services are built on these, such as file transfer, Web browsing, instant messaging, e-mail, and videoconferencing.
569
570The end-to-end argument is frequently understood as justification not to add new functionalities to the interconnection network. Following this reasoning, DDoS defenses located in the interconnection network would not be acceptable. However, the end-to-end argument, as originally stated, did not claim that the interior of the network should never again be augmented with any functionality, nor that all future changes in network behavior had to be implemented only on the ends. The crux of this argument was that only services that were required for all or most traffic belonged in the center of the network. Services that were specific to particular kinds of traffic were better placed at the edge of the network.
571
572Another component of the end-to-end argument was that security functions (which include access control and response functions to mitigate attacks) were the responsibility of the edge devices (i.e., end hosts) and not something the network should do. This argument assumes that owners of end hosts:
573
574Have the resources, including time, skills, and tools, to ensure the security of every end host
575
576Will be able to notice malicious activity themselves and take response actions quickly
577
578It also assumes that compromised hosts will themselves not become a threat to the availability of the network to other hosts.
579
580These assumptions have increasingly proven to be incorrect, and network stability became a serious problem in 2003 and 2004 due to rampant worms and bot networks. (The mstream DDoS program, for example, caused routers to crash as a result of the way it spoofed source addresses, as did the Slammer worm.)
581
582Taking that into account, there is a good case for putting DDoS defense mechanisms in the core of the network, since DDoS attacks can leverage any sort of packet whatsoever, and pure flooding attacks cannot be handled at an edge once they achieve a volume greater than the edge connection's bandwidth. DDoS defense mechanisms that add general defenses against attacks using any kind of traffic are not out of bounds by the definitions of the end-to-end argument, and should be considered, provided they can be demonstrated to be safe, effective, and cheap—the latter especially—for ordinary traffic when no attack is going on. It is not clear that any of the currently proposed DDoS defense mechanisms requiring core deployment meet those requirements yet, and obviously any serious candidate for such deployment must do so before it should even be considered for actual insertion into the routers making up the core of the Internet. However, both proponents and critics of core DDoS defenses should remember that the authors of the original end-to-end argument put it forward as a useful design principle, not absolute truth.
583
584Critiques of DDoS defense solutions based solely on violation of the end-to-end argument miss the point. On the other hand, critiques of particular components of DDoS defense solutions on the basis that they could be performed as well or better on the edges are proper uses of the end-to-end argument.
585
586These two above-mentioned ideas, the best-effort service model and the end-to-end paradigm, essentially define the same design principle: The core network should be kept simple; all the complexity should be pushed to the edge nodes. Thanks to this simplicity and division of functionalities between the core and the edges, the Internet easily met challenges of scale, the introduction of new applications and protocols, and a manifold increase in traffic while remaining a robust and cheap medium with ever-increasing bandwidth and speed. A downside of this simple design becomes evident when one of the parties in the end-to-end model is malicious and acts to damage the other party. Since the interconnection network is simple, intermediate nodes do not have the functionality necessary to step in and police the violator's traffic.
587
588This is exactly what happens in DDoS attacks, IP spoofing, and congestion incidents. The problem first became evident in October 1986 when the Internet suffered a series of congestion collapses [Nag84]. End hosts were simply sending more traffic than could be supported by the interconnection network. The problem was quickly addressed by the design and deployment of several TCP congestion control mechanisms [Flo00]. These mechanisms augment end-host TCP implementations to detect packet drops as a sign of congestion and respond to them by rapidly reducing the sending rate. However, it soon became clear that end-to-end flow management cannot ensure a fair allocation of resources in the presence of aggressive flows. In other words, those users who would not deploy congestion control were able to easily steal bandwidth from well-behaved congestion-responsive flows. As congestion builds up and congestion-responsive flows reduce their sending rate, more bandwidth becomes available for the aggressive flows that keep on pounding.
589
590This problem was finally handled by violating the end-to-end paradigm and enlisting the help of intermediate routers to monitor and police bandwidth allocation among flows to ensure fairness. There are two major mechanisms deployed in today's routers for congestion avoidance purposes—active queue management and fair scheduling algorithms [BCC+98]. A similar approach may be needed to completely address the DDoS problem. We discuss this further in Section 5.5.3.
591
5923.2.3. Internet Evolution
593The Internet has experienced immense growth in size and popularity since its creation. The number of Internet hosts has been growing exponentially and currently (in 2004) there are over 170 million computers online. Thanks to its cheap and fast message delivery, the Internet has become extremely popular and its use has spread from scientific institutions into companies, government, public works, schools, homes, banks, and many other places.
594
595This immense growth has also brought on several issues that affect Internet security.
596
597Scale. In the early days of the ARPANET, there was a maximum of 64 hosts allowed in the network, and if a new host needed to be added to the network, another had to leave. In 1971, there were 23 hosts and 15 connection hosts (nowadays called routers). In August 1981, when these restrictions no longer applied (NCP, with 6-bit address fields allowing only 64 hosts, was being phased out—it was being replaced by TCP, which was specified in 1974 and initially deployed in 1975), there were only 213 hosts online. By 1983, there were more than 1,000, by 1987 more than 10,000, and by 1989 (when the ARPANET was shut down) more than 100,000 hosts. In January 2003, there were more than 170 million Internet hosts. It is quite feasible to manage several hundred hosts, but it is impossible to manage 170 million of them. Poorly managed machines tend to be easy to compromise. Consequently, in spite of continuing efforts to secure online machines, the pool of vulnerable (easily compromised) hosts does not get any smaller. This means that attackers can easily enlist hundreds or thousands of agents for DDoS attacks, and will be able to obtain even more in the future.
598
599User profile. A common ARPANET user in the 1970s was a scientist who had a fair knowledge of computers and accessed a small, fairly constant set of machines at remote sites that typically ran a well-known and static set of software. A large number of today's Internet users are home users who need Internet access for Web browsing, game downloads, e-mail, and chat. Those users usually lack knowledge to properly secure and administer their machines. Moreover, they commonly download binary files (e.g., games) from unknown Internet sites or receive them in e-mail. A very effective way for the attacker to spread his malicious code is to disguise it to look like a useful application (a Trojan horse), and post it online or send it in an e-mail. The unwitting user executes the code and his machine gets compromised and recruited into the agent army. An ever-growing percentage of the Internet users are home users whose machines are constantly online and poorly secured, representing an easy recruiting pool for an attacker assembling a DDoS agent army.
600
601Popularity. Today, Internet use is no longer limited to universities and research institutions, but permeates many aspects of everyday life. Since connectivity plays an important role in many businesses and infrastructure functions, it is an attractive target for the attackers. Internet attacks inflict great financial damage and affect many daily activities.
602
603The evolution of the Internet from a wide-area research network into the global communication backbone exposed security flaws inherent in the Internet design and made the task of correcting them both pressing and extremely challenging.
604
6053.2.4. Internet Management
606The way the Internet is managed creates additional challenges for DDoS defense. The Internet is not a hierarchy but a community of numerous networks, interconnected to provide global access to their customers. As early as the days of NSFnet,[4] there existed little islands of self-managed networks as part of the noncommercial network. Each of the Internet networks is managed locally and run according to policies defined by its owners. There is no central authority. Thanks to this management approach, the Internet has remained a free medium where any opinion can be heard. On the other hand, there is no way to enforce global deployment of any particular security mechanism or policy. Many promising DDoS defense solutions need to be deployed at numerous points in the Internet to be effective, as illustrated in Chapter 5. IP spoofing is another problem that will likely need a distributed solution. The distributed nature of these threats will make it very difficult for single-node solutions to counteract them. However, the impossibility of enforcing global deployment makes highly distributed solutions unattractive. See Chapter 5 for a detailed discussion of defense solutions and their deployment patterns.
607
608[4] NSFnet, founded in 1986, was the National Science Foundation offspring from the ARPANET, meant to connect educational and research institutions.
609
610Due to privacy and business concerns, network service providers typically do not wish to provide information on cross-network traffic behavior and may be reluctant to cooperate in tracing attacks (see [Lip02] for further discussion of Internet tracing challenges and possible solutions, as well as the legal issues in Chapter 8). Furthermore, there is no automated support for tracing attacks across several networks. Each request needs to be authorized and put into effect by a human at each network. This introduces large delays. Since many DDoS attacks are shorter than a few hours, they will likely end before agent machines can be located.
611
612Previous Section < Day Day Up > Next Section
613
6143.3. DoS and DDoS Evolution
615There are many security problems in today's Internet. E-mail viruses lurk to infect machines and spread further, computer worms—sometimes silently—swarm the Internet, competitors and your neighbor's kids attempt to break into company machines and networks and steal industrial secrets, DDoS attacks knock down online services. The list goes on and on. None of these problems have been completely solved so far, but many have been significantly lessened through practical technological solutions. Firewalls have greatly helped reduce the danger from the intrusions by blocking all but necessary incoming traffic. Antivirus programs prevent the execution of known worms and viruses on the protected machine, thus defeating infection and stopping the spread. Applications and operating systems check for software updates and patch themselves automatically, greatly reducing the number of vulnerabilities that can be exploited to compromise a host machine.
616
617However, the DoS problem remains largely unhandled, in spite of great academic and commercial efforts to solve it. Sophisticated firewalls, the latest antivirus software, automatic updates, and a myriad of other security solutions improve the situation only slightly, defending the victim from only the crudest attacks. It is, however, strikingly easy to generate a successful DDoS attack that bypasses these defenses and takes the victim down for as long as the attacker wants. And there is often nothing a victim can do about it.
618
619How did these tools develop, and how are they being used? We will now look at a combined history of the development of network-based DoS and DDoS attack tools, in relation to the attacks waged with them.
620
6213.3.1. History of Network-Based Denial of Service
622The developmental progression of DoS and DDoS tools and associated attacks can give great insight into likely trends for the future, as well as allowing an organization to gauge the kinds of defenses they need to consider based on what is realistic to expect from various attackers, from less skilled up to advanced attackers.
623
624These are only some representative tools and attacks, not necessarily all of the significant attacks. For more stories, see http://staff.washington.edu/dittrich/misc/ddos/.
625
626The Late 1980s
627The CERT Coordination Center (CERT/CC, which was originally founded by DARPA as the Computer Emergency Response Team) at Carnegie Mellon University's Software Engineering Institute was established in 1988 in response to the so-called Morris worm, which brought the Internet to its knees.[5] The CERT Coordination Center has a long-established expertise in handling and responding to incidents in the Internet, analyzing and reporting vulnerabilities within systems, as well as research in computer and network security, and networked system survivability. Figure 3.2 presents a CERT Coordination Center–created summary of the trends in attacker tools over the last few years.
628
629[5] A Network sniffer is a program that can observe communication on a shared network looking for interesting information (e.g., user passwords). Ethernet is one example of a shared network. A sniffer installed on one computer connected to an Ethernet can observe communication of all other computers connected to this same Ethernet.
630
631
632Figure 3.2. Over time, attacks on networked computer systems have become more sophisticated, but the knowledge attackers need has decreased. Intruder tools have become more sophisticated and easy to use. Thus, more people can become "successful intruders" even though they have less technical knowledge. (Reprinted with permission of the CERT Coordination Center.)
633
634
635
636
637
638The Early 1990s
639After the story of the Morris worm incident died out, the Internet continued to grow through the early 1990s into a fun place, with lots of free information and services. More and more sites were added, and Robert Metcalf stated his now famous law: The usefulness, or utility, of a network equals the square of the number of users. But as we saw earlier in Section 3.1, some percentage of these new users will not be nice, friendly users.
640
641In the mid-1990s, remote DoS attack programs appeared and started to cause problems. In order to use these programs, one needed an account on a big computer, on a fast network, to have maximum impact. This led to rampant account theft at universities in order for attackers to have use of stolen accounts to run DoS programs—as they were easy to identify and shut down, they were often considered "throwaway" accounts—which drove a market for installing sniffers.[6] These accounts would be traded for pirated software, access to hard-to-reach networks, stolen computers, credit card numbers, cash, etc. At the time, flat thick-wire and thin-wire Ethernet networks were popular, as was the use of telnet and ftp (both of which suffered from a clear-text password problem). The result of this architectural model, combined with vulnerable network services, were networks that were easy prey to attackers running network sniffers.
642
643[6] The Morris worm, written by and named after Robert Morris, Jr., was a self-propagating program that spread from computer system to computer system via its network connections [Spa86].
644
6451996
646In 1996, a vulnerability in the TCP/IP stack was discovered that allowed a flood of packets with only the SYN bit set (known as a SYN flood; see Chapter 4 for detailed description). This became a popular and effective tool to use to make servers unavailable, even with moderate bandwidth available to an attacker (which was a good thing for attackers, as modems at this time were very slow). Small groups used these tools at first, and they circulated in closed groups for a time.
647
6481997
649Large DoS attacks on IRC networks began to occur in late 1996 and early 1997. In one attack, vulnerabilities in Windows systems were exploited by an attacker who took out large numbers of IRC users directly by crashing their systems [Val]. DoS programs with names like teardrop, boink, and bonk allowed an attacker to crash unpatched Windows systems at will. In another attack, a Romanian hacker took out portions of IRC network Undernet's server network with a SYN flood [KC]. SYN flood attacks on IRCg networks are still prevalent today. A noteworthy event in 1997 was the complete shutdown of the Internet due to (nonmalicious) false route advertisement by a single router [Bon97]
650
651For the most part, these DoS vulnerabilities are simple bugs that were fixed in subsequent releases of the affected operating systems. For example, there were a series of bugs in the way the Microsoft Windows TCP/IP stack handled fragmented packets. One bug in Windows' TCP/IP stack didn't handle fragmented packets whose offset and length did not match properly, such that they overlapped. The TCP/IP stack code authors expected packets to be properly fragmented and didn't properly check start/end/offset conditions. Specially crafted overlapping packets would cause the stack to allocate a huge amount of memory and hang or crash the system.[7] As these bugs were fixed, attackers had to develop new means of performing DoS attacks to up the ante and increase the disruption capability past the point where it can be stopped by simple patches.
652
653[7] Most of these simple attacks no longer affect consumer PC operating systems although they are still an issue for new memory-constrained "Internet-ready" cell phones and Personal Digital Assistants (PDAs) that have more primitive TCP/IP stacks similar to those in Windows PCs of the early 1990s. Proof-of-concept malware [Lab04] has been written for Symbian-based cell phones.
654
655Another effective technique that appeared around 1997 was a form of reflected, amplified DoS attack, called a Smurf attack. Smurf attacks allowed for amplification from a single source. By bouncing packets off a misconfigured network, attackers could amplify the number of packets destined for a victim by a factor of up to 200 or so for a so-called Class C or /24 network, or by a factor of several thousands for a moderately populated Class B or /16 network. The attacker would simply craft packets with the return address of the intended victim, and send those packets to the broadcast address of a network. These packets would effectively reach all available and responsive hosts on that particular network and elicit a response from them, Since the return address of the requests was forged, or spoofed, the response would be sent to the victim.[8]
656
657[8] The defense against the Smurf attack is to simply turn off the directed incoming broadcast capability in routers, which was allowed by default at the time. Still, many networks did not take this step, for whatever reasons, and thus remain potential sources of Smurf attacks.
658
659Attackers next decided to explore another avenue for crashing machines. Instead of exploiting a vulnerability, they just sent a lot of packets to the target. If the target was on a relatively slow dial-up connection (say, 14.4Kbps), but the attacker was using a stolen university computer on a 1Mbps connection, she could trivially overwhelm the dial-up connection and the computer would be lagged, or slowed down to the point of being useless (each keystroke typed could take 10 seconds or more to be received and echoed).
660
6611998
662As the bandwidth between attacker and target became more equal, and more network operators learned to deal with simple Smurf attacks, the ability to send enough traffic at the target to lag it became harder and harder to achieve. The next step was to add the ability to control a large number of remotely located computers—someone else's computers—and to direct them all to send massive amounts of useless traffic across the network and flood the victim (or victims). Attackers began organizing themselves into coordinated groups, performing an attack in concert on a victim. The added packets, whether in sheer numbers or by overlapping attack types, obtained the desired effect.
663
664Prototypes of DDoS tools (most notably fapi, see [CER99]) were developed in mid-1998, serving as examples of how to create client/server DDoS networks. Rather than relying on a single source, attackers could now take advantage of all the hosts they can compromise to attack with. These early programs had many limitations and didn't see widespread use, but did prove that coordination of computers in an attack was possible.
665
666Vulnerability-based attacks did not simply go away, and in fact continued to be possible due to a constant stream of newly discovered bugs. Successful DoS attacks using the relatively simple fragmented packet vulnerability targeting tens to hundreds of thousands of vulnerable hosts have been waged in the past. For example, the attacks in 1998, took advantage of fragmented packet vulnerabilities but added scripts to prepare the list of vulnerable hosts in advance and then rapidly fired exploit packets at those systems. This attacker prepared the list by probing potential victims for the correct operating system (by a technique called OS fingerprinting, which can be defeated by packet normalization [SMJ00]) and for the existence of the vulnerability, and creating a list of those that "pass the test." The University of Washington network was one of the victims of the attack. In computer labs across campus, some with hundreds of PCs being busily used by students doing their homework, the sound of keystrokes turned to dead silence as every screen in the lab went blue, only to be replaced seconds later with the chatter of "Hey, did your computer just crash too?" A large civilian U.S.-based space agency was a similar victim of these attacks during the same time period. Users at many locations were subjected to immediate patching, since subsequent controlled tests clearly turned unpatched systems' screens (and their respective users) blue.
667
668The next step to counter the patching issue, which made it harder for an attacker to predict which DoS attack would be effective, was to combine multiple DoS exploits into one tool, using Unix shell scripts. This increased the speed at which an effective DoS attack could be waged. One such tool, named rape, (according to the code, written in 1998) integrates the following DoS attacks into a single shell script:
669
670
671echo "Editted for use with www.ttol.base.org"
672
673echo "rapeing $IP. using weapons:"
674
675echo "latierra "
676
677echo -n "teardrop v2 "
678
679echo -n "newtear "
680
681echo -n "boink "
682
683echo -n "bonk "
684
685echo -n "frag "
686
687echo -n "fucked "
688
689echo -n "troll icmp "
690
691echo -n "troll udp "
692
693echo -n "nestea2 "
694
695echo -n "fusion2 "
696
697echo -n "peace keeper "
698
699echo -n "arnudp "
700
701echo -n "nos "
702
703echo -n "nuclear "
704
705echo -n "ssping "
706
707echo -n "pingodeth "
708
709echo -n "smurf "
710
711echo -n "smurf4 "
712
713echo -n "land "
714
715echo -n "jolt "
716
717echo -n "pepsi "
718
719
720
721
722A tool like this has the advantage of allowing an attacker to give a single IP address and have multiple attacks be launched (increasing the probability of a successful attack), but it also means having to have a complete set of precompiled versions of each individual exploit packaged up in a Unix "tar" format archive for convenient transfer to a stolen account from which to launch the attack.
723
724To still allow multiple DoS exploits to be used, but with a single precompiled program that is easier to store, transfer, and use quickly, programs like targa.c by Mixter were developed (this same strategy was used again in 2003 by Agobot/Phatbot). Targa combines all of the following exploits in a single C source program:
725
726
727/* targa.c - copyright by Mixter <mixter@gmx.net>
728
729 version 1.0 - released 6/24/98 - interface to 8
730
731 multi-platform remote denial of service exploits
732
733 */
734
735.
736
737.
738
739.
740
741/* bonk by route|daemon9 & klepto
742
743 * jolt by Jeff W. Roberson (modified by Mixter for overdrop effect)
744
745 * land by m3lt
746
747 * nestea by humble & ttol
748
749 * newtear by route|daemon9
750
751 * syndrop by PineKoan
752
753 * teardrop by route|daemon9
754
755 * winnuke by _eci */
756
757
758
759
760Even combined DoS tools like targa still only allowed one attacker to DoS one IP address at a time, and they required the use of stolen accounts on systems with maximum bandwidth (predominantly university systems). To increase the effectiveness of these attacks, groups of attackers, using IRC channels or telephone "voice bridges" for communication, could coordinate attacks, each person attacking a different system using a different stolen account. This same coordination was being seen in probing for vulnerabilities, and in system compromise and control using multiple backdoors and "root kits."
761
762The years 1998 and 1999 saw a significant increase in the ability to attack computer systems, which came as a direct result of programming and engineering efforts, the same ones that were bringing the Internet to the world: automation, increases in network bandwidth, client/server communications, and global chat networks.
763
7641999
765In 1999, two major developments grew slowly out of the computer underground and began to take shape as everyday attack methods: distributed computing (in the forms of distributed sniffing, distributed scanning, and distributed denial of service), and a rebirth of the worm (the worm simply being the integration and automation of all aspects of intrusion: reconnaissance scanning, target identification, compromise, embedding, and attacker control). In fact, many worms today (e.g., Nimda, Code Red, Deloder, Lion, and Blaster) either implement a DDoS attack or bundle in DDoS tools.
766
767The summer of 1999 saw the first large-scale use of new DoS tools: trinoo [Ditf], Tribe Flood Network (TFN) [Dith], and Stacheldraht [Ditg]. These were all simple client/server style programs—handlers and agents, as mentioned earlier—that performed only DDoS-related functions of command and control, various types of DoS attacks, and automatic update in some cases. They required other programs to propagate them and build attack networks, and the most successful groups using these tools also used automation for scanning, target identification, exploitation, and installation of the DDoS payload. The targets of nearly all the attacks in 1999 were IRC clients and IRC servers.
768
769One prominent attack against the IRC server at the University of Minnesota and a dozen or more IRC clients scattered around the globe was large enough to keep the University's network unusable for almost three full days. This attack used the trinoo DDoS tool, which generated a flood of UDP packets with a 2-byte payload and did not use IP spoofing. The University of Minnesota counted 2,500 attacking hosts, but the logs were not able to keep up with the flood, so that count was an underestimate.[9] These hosts were used in several DDoS networks of 100 to 400 hosts each, in rolling attacks that activated and deactivated groups of hosts. This made locating the agents, identification, and cleanup take several hours to a couple of days. The latency in cleanup contributed to the attack's duration.
770
771[9] Again, e-mail correspondence sent privately to two DDoS researchers from individuals claiming involvement in these attacks stated the real number was more likely 4,000 to 5,000 hosts total.
772
773The change to using distributed tools was inevitable. The growth of network bandwidth that came about through the development of Internet2 [Con] (officially launched in 2000) made simple point-to-point tools less effective against well-provisioned networks, and attacks that used single hosts for flooding were easy to filter out and easy to track back to their source and stop. Scripting of vulnerability scans (which are also made faster because of the same bandwidth increase) and scripting of attacks made it much easier to compromise hundreds, thousands, even tens of thousands of hosts in just a few hours. If you control thousands of computers, why not program them to work in a coordinated manner for leverage? It wasn't a large leap to automate the installation of attack tools, back doors, sniffers—whatever the attackers wanted to add.
774
775Private communications with some of the authors of the early DDoS tools[10] indicated the motivation for this automation was for a smaller group of attackers to counter attacks wielded at it by a large group (using the classic DoS tools described above, and manual coordination). The smaller group could not wield the same number of manual tools and thus resorted to automation. In almost all cases, these were first coding efforts, and even with bugs they were quite effective at waging large-scale attacks. The counterattacks were strikingly effective, and the smaller group was able to retake all their channels and strike back at the larger group.
776
777[10] This information was relayed to David Dittrich in 2000, after the initial DDoS analyses of trinoo, TFN, and Stacheldraht were published.
778
779Similar attacks, although on a slightly smaller scale, continued through the late fall of 1999, this time using newer tools that spoofed source addresses, making identification of attackers even harder. Nearly all of these attacks were directed at IRC networks and clients, and there was very little news coverage of them. Tribe Flood Network (or TFN), Stacheldraht, and then Tribe Flood Network 2000 (TFN2K) saw popular use, while Shaft showed up in more limited attacks.
780
781In November of 1999, CERT Coordination Center sponsored (for the first time ever) a workshop to discuss and develop a response to a situation they saw as a significant problem of the day, in this case Distributed System Intruder Tools (including distributed scanners, distributed sniffers, and distributed denial of service tools.) The product of the workshop was a report [CER99], which covered the issue from multiple perspectives (those of managers, system administrators, Internet service providers, and incident response teams). This report is still one of the best places to start in understanding DDoS, and what to do about it in the immediate time frame (< 30 days), medium term (30–180 days) and long term (> 180 days). Ironically, only days after this workshop, a new tool was discovered that was from a different strain of evolution, yet obeyed the same attack principles as trinoo, TFN, and Stacheldraht [Ditf, Dith, Ditg]. The Shaft [DLD00] tool, as discussed in Chapter 4, was wreaking havoc with only small numbers of agents across Europe, the United States, and the Pacific Rim, and caught the attention of some analysts.
782
783This next generation of tools included features such as encryption of communications (to harden the DDoS tools against counterattack and detection), multiplicity of attack methods, integrated chat functions, and reporting of packet flood rates. This latter function is used by the attacker to make it easier to determine the yield of the DDoS attack network, and hence when it is large enough to obtain the desired goal and when (due to attrition) it needs to be reinforced. (The attackers, at this point, knew more about how much bandwidth they were using than many network operators knew was being consumed. Refer to the discussion of Shaft in Chapter 4 for more on this statistics feature, and the OODA Loop in Chapter 4 to understand how this affects the attacker/defender balance of power.) As more and more groups learned of the power of DDoS to engage in successful warfare against IRC sites, more DDoS tools were developed.
784
785As Y2K Eve approached, many security professionals feared that widespread DDoS attacks would disrupt the telecommunications infrastructure, making it look like Y2K failures were occurring and panicking the public [SSSW]. Thankfully, these attacks never happened. That did not mean that attack incidence slowed down, however.
786
7872000
788On January 18, 2000, a local ISP in Seattle, Washington, named Oz.net was attacked [Ric]. This appeared to be a Smurf attack (or possibly an ICMP Echo reply flood with a program like Stacheldraht). The unique element of this attack was that it was directed against not only the servers at Oz.net, but also at their routers, the routers of their upstream provider Semaphore, and the routers of the upstream's provider, UUNet. It was estimated that the slowdown in network traffic affected some 70% of the region surrounding Seattle.
789
790Within weeks of this attack, in February 2000, a number of DDoS attacks were successfully perpetrated against several well-provisioned and carefully run sites—many of the major "brand names" of the Internet. They included the online auction company eBay (with 10 million customers), the Internet portal Yahoo (36 million visitors in December 1999), online brokerage E*Trade, online retailer Buy.com (1.3 million customers), online bookselling pioneer Amazon.com, Web portal Excite.com, and the widely consulted news site CNN [Har]. Many of these sites were used to high, fluctuating traffic volume, so they were heavily provisioned to provide for those fluctuations. They were also frequent targets of other types of cyberattacks, so they kept their security software up to date and maintained a staff of network administration professionals to deal with any problems that arose. If anyone in the Internet should have been immune to DDoS problems, these were the sites. (A detailed timeline of some of the lesser known events surrounding the first public awareness of DDoS, leading up to the first major DDoS attacks on e-commerce sites, is provided in the side bar at the end of this chapter.)
791
792However, the attacks against all of them were quite successful, despite being rather unsophisticated. For example, the attack against Yahoo in February 2000 prevented users from having steady connectivity to that site for three hours. As a result, Yahoo, which relies on advertising for much of its revenue, lost potentially an estimated $500,000 because its users were unable to access Yahoo's Web pages and the advertisements they carried [Kes]. The attack method used was not sophisticated, and thus Yahoo was eventually able to filter out the attack traffic from its legitimate traffic, but a significant amount of money was lost in the process. Even the FBI's own Web site was taken out of service for three hours in February of 2000 by a DDoS attack [CNN].
793
7942001
795In January 2001, a reflection DDoS attack (described in Section 2.3.3) [Pax01] on futuresite.register.com [el] used false DNS requests sent to many DNS servers throughout the world to generate its traffic. The attacker sent many requests under the identity of the victim for a particularly large DNS record to a large number of DNS servers. These servers obediently sent the actually undesired information to the victim. The amount of traffic inbound to the victim's IP address was reported to be 60 to 90 Mbps, with one site reporting seeing approximately 220 DNS requests per minute per DNS server.
796
797This attack lasted about a week, and could not be filtered easily at the victim network because simple methods of doing so would have disabled all DNS lookup for the victim's customers. Because the attack was reflected off many DNS servers, it was hard to characterize which ones were producing only attack traffic that should be filtered out.
798
799Arguably, the DNS servers responding to this query really shouldn't have done so, since it would not ordinarily be their business to answer DNS queries on random records from sites not even in their domain. That they did so could be considered a bug in the way DNS functions, a misconfiguration of DNS servers, or perhaps both, but it certainly underscores the complexity of Internet protocols and protocol implementations and inherent design issues that can lead to DoS vulnerabilities.
800
801The number and scope of DDoS attacks continued to increase, but most people (at least those who didn't use IRC) were not aware of them. In 2001 David Moore, Geoffrey Voelker, and Stephan Savage published a paper titled, "Inferring Internet Denial-of-Service Activity" [MVS01]. This work investigates Internet-wide DDoS activity and is described in detail in Appendix C. The technique for measuring DDoS activity underestimates the attack frequency, because it cannot detect all occurring attacks. But even with these limitations, the authors were able to detect approximately 4,000 attacks per week for the three-week period they analyzed. Similar techniques for attack detection and evaluation were already in use among network operators and network security analysts in 1999 and 2000. What many operators flagged as "RST scans" were known to insiders as "echoes" of DDoS attacks [DLD00].
802
803Microsoft's prominent position in the industry has made it a frequent target of attacks, including DDoS attacks. Some DDoS attacks on Microsoft have failed, in part because Microsoft heavily provisions its networks to deal with the immense load generated when they release an important new product or when an upgrade becomes available. But some of the attacks succeeded, often by cleverly finding some resource other than pure bandwidth for the attack to exhaust. For example, in January 2001 someone launched a DDoS attack on one of Microsoft's routers, preventing it from routing normal traffic at the required speeds [Del]. This attack would have had relatively little overall effect on Microsoft's Internet presence were it not for the fact that all of the DNS servers for Microsoft's online properties were located behind the router under attack. While practically all of Microsoft's network was up and available for use, many users could not get to it because their requests to translate Microsoft Web site names into IP addresses were dropped by the overloaded router. This attack was so successful that the fraction of Web requests that Microsoft was able to handle dropped to 2%.
804
8052002
806Perhaps inspired by this success, in October 2002 an attacker went a step further and tried to perform a DDoS attack on the complete set of the Internet's DNS root servers. DNS is a critical service for many Internet users and many measures have been taken to make it robust and highly available. DNS data is replicated at 13 root servers, that are themselves well provisioned and maintained, and it is heavily cached in nonroot servers throughout the Internet. An attacker attempted to deny service to all 13 of these root servers using a very simple form of DDoS attack. At various points during the attack, 9 of the 13 root servers were unable to respond to DNS requests, and only 4 remained fully operational throughout the attack. The attack lasted only one hour, after which the agents stopped. Thanks to the robust design of the DNS and the attack's short duration, there was no serious impact in the Internet as a whole. A longer, stronger attack, however, might have been extremely harmful.
807
8082003
809It wasn't until 2003 that a major shift in attack motivations and methodologies began to show up. This shift coincided with several rapid and widespread worm events, which have now become intertwined with DDoS.
810
811First, spammers began to use distributed networks in the same ways as DDoS attackers to set up distributed spam networks [KP]. As antispam sites tried to counter these "spambots," the spammers' hired guns retaliated by attacking several antispam sites [AJ]. Using standard DDoS tools, and even worms like W32/Sobig [JL], they waged constant attacks against those who they perceived were threatening their very lucrative business.
812
813Second, other financial crimes began to involve the use of DDoS. In some cases, online retailers with daily gross sales on the order of tens of thousands of dollars a day (as opposed to larger sites like the ones attacked in February 2000) were also attacked, using a form of DDoS involving seemingly normal Web requests. These attacks were just large enough to bring the Web server to a crawl, yet not large enough to disrupt the networks of the upstream providers. Similarly to the reflected DNS attacks described earlier, it was difficult (if not impossible) to filter out the malicious Web requests, as they appeared to be legitimate. Similar attacks were waged against online gambling sites and pornography sites. Again, in some cases extortion attempts were made for sums in the tens of thousands of dollars to stop the attacks (a new form of protection racketeering) [CN].
814
815DDoS had finally become a component of widespread financial crimes and high dollar e-commerce, and the trend is likely to only increase in the near future. DDoS continued to also be used as in prior years, including for political reasons.
816
817During the Iraq War in 2003, a DDoS attack was launched on the Qatar-based Al-Jazeera news organization, which broadcast pictures of captured American soldiers. Al-Jazeera attempted to outprovision the attackers by purchasing more bandwidth, but they merely ratcheted up the attack. The Web site was largely unreachable for two days, following which someone hijacked their DNS name, redirecting requests to another Web site that promoted the American cause.
818
819In May 2003, then several more times in December, SCO's Web site experienced DDoS attacks that took it offline for prolonged periods of time. Statements by SCO management indicated the belief that the attacks were in response to SCO's legal battle over Linux source code and statements criticizing the Open Source community's role in these lawsuits [Lem].
820
821In mid-2003, Clickbank (an electronic banking service) and Spamcop (a company that filters e-mail to remove spam) were subjected to powerful DDoS attacks [Zor. The attacks seemingly involved thousands of attack machines. After some days, the companies were able to install sophisticated filtering software that dropped the DDoS attack traffic before it reached a bottleneck point.
822
8232004
824Financially motivated attacks continue, along with speculation that worm attacks in 2004 were used to install Trojan software on hundreds of thousands of hosts, creating massive bot networks. Two popular programs—Agobot, and its successor Phatbot [LTIG]—have been implicated in distributed spam delivery and DDoS; in some cases networks of these bots are even being sold on the black market [Leya]. Phatbot is described in more detail in Chapter 4.
825
826Agobot and Phatbot both share many of the features that were predicted in 2000 by Michal Zalewski [Zal] in his write-up on features of a "super-worm." This paper was written in response to the hype surrounding the "I Love You" virus. Zalewski lists such features as portability (Phatbot runs on both Windows and Linux), polymorphism, selfupdate, anti-debugging, and usability ( Phatbot comes with usage documentation and online help commands). Since Phatbot preys on previously infected hosts, other parts of Zalewski's predictions are also possible (via programming how Phatbot executes) and thus Phatbot is one of the most advanced forms of automation seen to date in the category of DDoS (or blended threat, actually) tools.
827
828Like all histories, this history of DDoS attacks does not represent a final state, but is merely the prelude to the future. In the next chapter, we will provide more details on exactly how today's attacks are perpetrated, which will then set the stage for discussing what you must do to counter them. Remember, however, that the history we've just covered suggests, more than anything else, continued and rapid change for the future. Early analyses of DDoS attack tools like trinoo, Tribe Flood Network, Stacheldraht, and Shaft all made predictions about future development trends based on past history, but attackers proved more nimble in integrating new attack methods into existing tools than those predictions suggested. We should expect both the number and sophistication of attack tools to grow steadily, and perhaps more rapidly than anyone predicts. Therefore, the tools attackers will use in upcoming years and the methods used to defend against them will progress from the current states we describe in the upcoming chapters, requiring defenders to keep up to date on new trends and defense methods.
829
830Early DDoS Attack Tool Time Line
831There was a flurry of media attention paid to the potential for DoS attacks to be used around the time of Y2K Eve. These attacks were expected to mimic anticipated Y2K bug failures and potentially attract much public attention and invoke panic. This potential generated, rightly from a protective role, a lot of attention from within the government and organizations that support the government. Many stories covering the possibility of a DoS attack were published in the media. The media attention continued at a low level after Y2K, then picked up sharply after the first majorDDoS attacks against e-commerce sites in February 2000. Many of the authors of then-published stories could not benefit from behind-the-scenes activity or information that was unpublished at the time. This created an impression that DDoS is a phenomenon that was largely neglected by incident responders. Later, some articles took very critical positions against federal government agencies, mostly due to the reporters not knowing all of the events leading up to February 2000. Those articles can be obtained following links at http://security.royans.net/info/articles/feb_attack.shtml and http://staff.washington.edu/dittrich/misc/ddos/.
832
833The time line below follows a talk given at the Usenix Security Symposium in 2000 on DDoS attacks (see http://www.computerworld.com/news/2000/story/0,11280,48796,00.html and http://staff.washington.edu/dittrich/talks/sec2000/) and provides more information about early DoS/DDoS incidents.
834
835May/June, 1998. First primitive DDoS tools developed in the underground—small networks, only mildly worse than coordinated point-to-point DoS attacks. These tools did not see widespread use at the time, but classic point-to-point DoS attacks continued to cause problems, as well as increasing "Smurf" amplification attacks (see Section 2.3.3).
836
837July 22, 1999. The CERT Coordination Center released Incident Note 99-04 mentioning widespread intrusions on Solaris RPC services. (See http://www.cert.org/incident_notes/IN-99-04.html.)
838
839August 5, 1999. First evidence seen at sites around the Internet of programs being installed on Solaris systems in what appeared to be "mass" intrusions using massive autorooters and using multiple attack vectors. (This was a precursor to some of today's worms and blended threats, such as Phatbot.) It was not clear at first how these incidents were related.
840
841August 17, 1999. Attack on the University of Minnesota reported to University of Washington (among many others) network operations and security teams. The University of Minnesota reported as many source networks as it could identify (but netflow records were overwhelming their storage capacity, so some records were dropped).
842
843September 2, 1999. Contents of a stolen account used to cache files were recovered. Over the next month, a detailed analysis of the files was performed. An initial draft analysis of trinoo was circulated privately at first.
844
845October 21, 1999. Final drafts of trinoo and TFN analyses were finished. (See http://packetstormsecurity.nl/distributed/trinoo.analysis and http://packetstormsecurity.nl/distributed/tfn.analysis.)
846
847November 2–4, 1999. The Distributed Systems Intruder Tools (DSIT) workshop, organized by the CERT Coordination Center, was held near the Carnegie Mellon University campus in Pittsburgh. It was agreed by attendees that it was important not to panic people, but instead provide meaningful steps to deal with this new threat. All attendees agreed to keep information about DDoS programs private until the attendees finished a report on how to respond, and not to release other information provided to them without permission of the sources.
848
849November 18, 1999. The CERT Coordination Center released Incident Note 99-07 "Distributed Denial of Service Tools," mentioning DDoS tools. (See http://www.cert.org/incident_notes/IN-99-07.html.)
850
851November 29, 1999. SANS NewsBytes, Vol. 1, Num. 35, mentioned trinoo / TFN in the context of widespread Solaris intrusion reports they were getting that were consistent with the CERT Coordination Center IN-99-07 and involving ICMP Echo Reply packets.
852
853Late November/Early December, 1999. Evidence of another DDoS agent (Shaft) was found in Europe. (An analysis by Sven Dietrich, Neil Long, and David Dittrich wasn't published until March 13, 2000.
854
855See http://www.adelphi.edu/~spock/shaft_analysis.txt.)
856
857December 4, 1999. Massive attack using Shaft is detected. (Data acquired during this attack was analyzed in early 2000 and presented by Sven Dietrich in a paper at the USENIX LISA 2000 conference.
858
859See http://www.adelphi.edu/~spock/lisa2000-shaft.pdf.)
860
861December 7, 1999. ISS released an advisory on trinoo / TFN after first nontechnical mention of DDoS tools in a USA Today article. The CERT Coordination Center released final report of the DSIT workshop. David Dittrich sent his analyses of trinoo and TFN to the BUGTRAQ e-mail list.
862
863(See http://www.usatoday.com/life/cyber/tech/review/crg681.htm,
864
865http://www.cert.org/reports/dsit_workshop-final.html,
866
867http://packetstormsecurity.nl/distributed/trinoo.analysis, and
868
869http://packetstormsecurity.nl/distributed/tfn.analysis.)
870
871Remainder of December 1999 and into January 2000. Many conference calls were held within a group of government, academic, and private industry participants who worked cooperatively and constructively in helping develop responses to the DDoS threat. Fears of Y2K-related attacks helped drive the urgency. (See http://news.com.com/2100-1001-234678.html and http://staff.washington.edu/dittrich/misc/corrections/cnet.html.)
872
873December 8, 1999. According to a USA Today article, NIPC sent a note briefing FBI director Louis Freeh on DDoS tools.
874
875(See http://www.usatoday.com/life/cyber/tech/cth523.htm.)
876
877December 17, 1999. According to a USA Today article, NIPC director Michael Vatis briefed Attorney General Janet Reno as part of an overview of preparations being made for Y2K.
878
879(See http://www.usatoday.com/life/cyber/tech/cth523.htm.)
880
881December 27, 1999. As final work on the analysis of Stacheldraht was being performed by David Dittrich, with help from Sven Dietrich, Neil Long, and others, Dittrich scanned the University of Washington network with gag (the scanner included in the Stacheldraht analysis). Three active agents were found and traced to a handler in the southern United States. The ISP and its upstream provider were able to use the Stacheldraht analysis to identify over 100 agents in this network and take it down.
882
883December 28, 1999. The CERT Coordination Center releases Advisory CA-1999-17 "Denial-of-Service Tools" (covers TFN2K and MacOS 9 DoS exploit).
884
885(See http://www.cert.org/advisories/CA-1999-17.html.)
886
887December 30, 1999. Analysis of Stacheldraht posted to the BUGTRAQ e-mail list. NIPC issued a press release on DDoS programs and released "Distributed Denial of Service Attack Information (trinoo/Tribe Flood Network)," including a tool for scanning local file systems/memory for DDoS programs. (See http://packetstormsecurity.nl/distributed/stacheldraht.analysis, http://www.fbi.gov/pressrm/pressrel/pressrel99/prtrinoo.htm, and http://www.fbi.gov/nipc/trinoo.htm.)
888
889January 3, 2000. The CERT Coordination Center and FedCIRC jointly published Advisory 2000–01 "Denial-of-Service Developments," discussing Stacheldraht and NIPC scanning tool. (See http://www.cert.org/advisories/CA-2000-01.html.)
890
891January 4, 2000. SANS asked its membership to use published DDoS detection tools to determine how widely DDoS attack tools are being used. Reports of successful searches started coming in within hours. Several DDoS networks were discovered and taken down.
892
893January 5, 2000. Sun released bulletin #00193, "Distributed Denial-of-Service Tools."
894
895(See http://packetstorm.securify.com/advisories/sms/sms.193.ddos.)
896
897January 14, 2000. Attack on OZ.net in Seattle affected Semaphore and UUNET customers (affecting as much as 70% of Puget Sound Internet users, and possibly other sites in the United States—no national press attention until January 18). This attack targeted the network infrastructure, as well as end servers.
898
899January 17, 2000. ICSA.net organized Birds of a Feather (BoF) session on DDoS attacks at the RSA 2000 conference in San Jose.
900
901February 7, 2000. A talk was given by Steve Bellovin on DDoS attacks, and another ICSA.net DDoS BoF was organized at a NANOG [Ope] meeting in San Jose. Coincidentally (although not necessarily related), the first attacks on e-commerce sites began.
902
903February 10, 2000. Jason Barlow and Woody Thrower of AXENT Security Team published analysis of TFN2K.
904
905February 8–12, 2000. Attacks on e-commerce sites continued. Popular media began to widely publish reports on these DDoS attacks. To this day, most stories incorrectly refer to this as the beginning of DDoS.
906
907While the government was criticized heavily in some early media reports, the following points are considered important in understanding these stories.
908
909Technical details of the developing DDoS tools did not start circulating, even privately, until October 1999.
910
911The CERT Coordination Center released IN-99-07 mentioning DDoS tools on November 18, 1999, and published CA-1999-17 on December 28, 1999. Any sites paying attention to the CERT Coordination Center Incident Notes and Advisories learned of trinoo, TFN, and TFN2K in November and December 1999.
912
913Anyone reading BUGTRAQ learned of trinoo and TFN on December 7, 1999, and Stacheldraht on December 30, 1999.
914
915NIPC's advisory and tool came out just after the technical analyses were published, but because all three commonly used DDoS tools were discussed publicly by lateDecember 1999, it seems overly critical to say the government "failed to warn" e-commerce sites before February 7, 2000. The e-commerce sites could have learned about the possible attacks from the CERT Coordination Center Incident Note, the DSIT Workshop Report, SANS publications, and postings to BUGTRAQ in November and December 1999.
916
917Several news stories mentioned all of these information sources in December 1999 through February 2000.
918
919Various agencies widely spread the analyses of DDoS tools as necessary, so the problem was known and being handled privately long before any media stories were published.
920
921
922Chapter 4. How Attacks Are Waged
923A DDoS attack has to be carefully prepared by the attacker. She first recruits the agent army. This is done by looking for vulnerable machines, then breaking into them, and installing her attack code. The attacker next establishes communication channels between machines, so that they can be controlled and engaged in a coordinated manner. This is done using either a handler/agent architecture or an IRC-based command and control channel. Once the DDoS network is built, it can be used to attack as many times as desired against various targets.
924
925Previous Section < Day Day Up > Next Section
926
9274.1. Recruitment of the Agent Network
928Depending on the type of denial of service planned, the attacker needs to find a sufficiently large number of vulnerable machines to use for attacking. This can be done manually, semi-automatically, or in a completely automated manner. In the cases of two well-known DDoS tools, trinoo [Ditf] and Shaft [DLD00], only the installation process was automated, while discovery and compromise of vulnerable machines were performed manually. Nowadays, attackers use scripts that automate the entire process, or even use scanning to identify already compromised machines to take over (e.g., Slammer-, MyDoom-, or Bagle-infected hosts). It has been speculated that some worms may be used explicitly to create a fertile harvesting ground for building bot networks that are later used for various malicious purposes, including DDoS attacks. If the owners didn't notice the worm infection, they will likely not notice the bot that harvests them!
929
9304.1.1. Finding Vulnerable Machines
931The attacker needs to find machines that she can compromise. To maximize the yield, she will want to recruit machines that have good connectivity and ample resources and are poorly maintained. Unfortunately, many of these exist within the pool of millions of Internet hosts.
932
933In the early days of DDoS, hosts with high-availability connections were found only in universities and scientific and government institutions. They further tended to have fairly lax security and no firewalls, so they were easily compromised by an attacker. The recent popularity of cable modem and digital subscriber line (DSL) highspeed Internet for business and home use has brought high-availability connections into almost every home and office. This has vastly enlarged the pool of lightly administered and well-provisioned hosts that are frequently continuously connected and running—ideal targets for DDoS recruitment. The change in the structure of potential DDoS agents was followed by a change in DDoS tools. The early tools ran mostly on Unix-based hosts, whereas recent DDoS code mostly runs on Windows-based systems. In some cases, such as the Kaiten and Knight bots, the same original Unix source code was simply recompiled using the Cygwin portable library.
934
935The process of looking for vulnerable machines is called scanning. Figure 4.1 depicts the simple scanning process. The attacker sends a few packets to the chosen target to see whether it is alive and vulnerable. If so, the attacker will attempt to break into the machine.
936
937
938Figure 4.1. Recruitment of agent army
939
940
941
942
943
944Scanning was initially a manual process performed by the attacker using crude tools. Over time, scanning tools improved and scanning functions were integrated and made automatic. Two examples of this are "blended threats" and worms.
945
946Blended threats are individual programs or groups of programs that provide many services, in this case command and control using an IRC bot and vulnerability scanning.
947
948A bot (derived from "robot") is a client program that runs in the background on a compromised host, and watches for certain strings to show up in an IRC channel. These strings represent encoded commands that the bot program executes, such as inviting someone into an IRC channel, giving the user channel operator permissions, scanning a block of addresses (netblock), or performing a DoS attack. Netblock scans are initiated in certain bots, such as Power [Dita], by specifying the first few octets of the network address (e.g., 192.168 may mean to scan everything from 192.168.0.0 to 192.168.255.255). Once bots get a list of vulnerable hosts, they inform the attacker using the botnet (a network of bots that all synchronize through communication in an IRC channel). The attacker retrieves the file and adds it to her list of vulnerable hosts. Some programs automatically add these vulnerable hosts to the vulnerable host list, thereby constantly reconstituting the attack network. Network blocks for scanning are sometimes chosen randomly by attackers. Other times they are chosen explicitly for a reason (e.g., netblocks owned by DSL providers and universities are far more "target-rich environments" than those owned by large businesses and are less risky than a military site).
949
950The scanning can be performed with separate programs that are simply "plugged in" to the blended threat kit, or (as is the case with Phatbot), built into the program as a module. An IRC bot scanning is depicted in Figure 4.2.
951
952
953Figure 4.2. Sophisticated scanning for recruitment
954
955
956
957
958
959Another program that employs scanning to identify vulnerable hosts is an Internet worm. Internet worms are automated programs that propagate from one vulnerable host to another, in a manner similar to biological viruses (e.g., the flu). A worm has three distinct primary functions: (1) scanning, to look for vulnerable machines; (2) exploitation, which compromises machines and establishes remote control; and (3) a payload (code they execute upon compromise to achieve some attack function). Since the worm is designed to propagate, once it infects a machine, the scan/infect cycle repeats on both the infected and infecting machines. The payload can be simply a copy of the worm (in memory or written to the file system), or it may be a complete set of programs loaded into the file system. Internet worms are an increasingly popular method of recruiting DDoS agents, so the worm payload frequently includes DDoS attack code. Figure 4.3 illustrates worm propagation.
960
961
962Figure 4.3. Worm scanning for recruitment
963
964
965
966
967
968Worms choose the addresses to scan using several methods.
969
970Completely randomly. Randomly choose all 32 bits of the IP address (if using IPv4) for targets, effectively scanning the entire Internet indiscriminately.
971
972Within a randomly selected address range. Randomly choose only the first 8 or 16 bits of the IP address, then iterate from .0.0 through .255.255 in that address range. This tends to scan single networks, or groups of networks, at a time.
973
974Using a hitlist. Take a small list of network blocks that are "target rich" and preferentially scan them, while ignoring any address range that appears to be empty or highly secured. This speeds things up tremendously, as well as minimizing time wasted scanning large unused address ranges.
975
976Using information found on the infected machine. Upon infecting a machine, the worm examines the machine's log files that detail communication activity, looking for addresses to scan. For instance, a Web browser log contains addresses of recently visited Web sites, and a file known_hosts contains addresses of destinations contacted through the SSH (Secure Shell) protocol.
977
978Worms spread extremely fast because of their parallel propagation pattern. Assume that a single copy successfully infects five machines in one second. In the next second, all six copies (the original one and five new copies) will try to propagate further. As the worm spreads, the number of infected machines and number of worm copies swarming over the Internet grow exponentially. Frequently, this huge amount of scanning/attacking traffic clogs edge networks and creates a DoS effect for many users. Some worms carry DDoS payloads as well, allowing the attacker who controls the compromised machines to carry out more intentional and targeted attacks after the worm has finished spreading. Since history suggests that worms are often not completely cleaned up (for example, Code Red–infected hosts still exist in the Internet, years after Code Red first appeared), some infected machines might continue serving as DDoS agents indefinitely.
979
9804.1.2. Breaking into Vulnerable Machines
981The attacker needs to exploit a vulnerability in the machines that she is intending to recruit in order to gain access to them. You will find this referred to as "owning" the machine. The vast majority of vulnerabilities provide an attacker with administrative access to the system, and she can add/delete/change files or system settings at will.
982
983Exploits typically follow a vulnerability exploitation cycle.
984
9851. A new vulnerability has been discovered in attacker circles and is being exploited in a limited fashion.
986
987
9882. The vulnerability makes it outside of this circle and gets exploited at a wider scale.
989
990
9913. Automated tools appear, and nonexperts (script kiddies) are running the tools.
992
993
9944. A patch for the vulnerability appears and gets applied.
995
996
9975. Exploits for a given vulnerability decline.
998
999
1000
1001Once one or more vulnerabilities have been identified, the attacker incorporates the exploits for those vulnerabilities into his DDoS toolkit. Some DDoS tools actually take advantage of several vulnerabilities to propagate their code to as many machines as possible. These are often referred to as propagation vectors.
1002
1003Frequently, the attackers patch the vulnerability they exploited to break into the machine. This is done to prevent other attackers from gaining access in the same manner and seizing control of the agent machine. To facilitate his future access to the compromised machine, the attacker will start a program that listens for incoming connection attempts on a specific port. This program is called a backdoor. Access through the backdoor is sometimes protected by a strong password, and in other cases is wide open and will respond to any connection request.
1004
1005One vulnerability that is not mitigated by patching, which some blended threats take advantage of, is weak passwords. Some exploits contain a list of common passwords. They try these passwords in a brute-force or iterative manner, one after another. This sometimes exceeds system limits for failed logins and causes a lockout condition (a safe fallback for the system, but disruptive to legitimate users who cannot get in to the system). All too many times, these exploits succeed in finding a weak login/password combination and gain unauthorized access to the system. Users often think that leaving no password on the Administrator account is reasonable, or that "password" or some other simple word is sufficient to protect the account. They are mistaken.
1006
10074.1.3. Malware Propagation Methods
1008The attacker needs to decide on a propagation model for installing his malware. A simple model is the central repository, or cache, approach: The attacker places the malware in a file repository (e.g., an FTP server) or a Web site, and each compromised host downloads the code from this repository. One advantage of the caching model for the defender is that such central repositories can be easily identified and removed. Attackers installing trinoo [Ditf] and Shaft [DLD00] agents used such centralized approaches in the early days. In 2001, W32/Leaves [CER01c] used a variant of reconfigurable sites for its cache, as did the W32 / SoBig mass-mailing worm in 2003. Figure 4.4 illustrates propagation with central repository.
1009
1010
1011Figure 4.4. Propagation with central repository. (Reprinted from [HWLT01] with permission of the CERT Coordination Center.)
1012
1013
1014
1015
1016
1017Another model is the back-chaining, or pull, approach, wherein the attacker carries his tools from an initially compromised host to subsequent machines that this host compromises. Figure 4.5 illustrates propagation with back-chaining.
1018
1019
1020Figure 4.5. Propagation with back chaining. (Reprinted from [HWLT01] with permission of the CERT Coordination Center.)
1021
1022
1023
1024
1025
1026Finally, the autonomous, push, or forward propagation approach combines propagation and exploit into one process. The difference between this approach and back chaining is that the exploit itself contains the malware to be propagated to the new site, rather than performing a copy of that malware after compromising the site. The worm carries a DDoS tool as a payload, and plants it on each infected machine. Recent worms have incorporated exploit and attack code, protected by a weak encryption using linear feedback shift registers. The encryption is used to defeat the detection of well-known exploit code sequences (e.g., the buffer overflow "sled," a long series of NOOP commands [Sko02]) by antivirus or personal firewall software. Once on the machine, the code self-decrypts and resumes its propagation. Figure 4.6 illustrates autonomous propagation.
1027
1028
1029Figure 4.6. Autonomous propagation. (Reprinted from [HWLT01] with permission of the CERT Coordination Center.)
1030
1031
1032
1033
1034
1035All of the preceding propagation methods are described in more detail in [HWLT01].
1036
1037Other complexities of attack tools and toolkits include such features as antiforensics and encryption. Methods of analyzing DDoS tools are described in Chapter 6.
1038Previous Section < Day Day Up > Next Section
1039
10404.2. Controlling the DDoS Agent Network
1041When the agent army has been recruited in sufficiently large numbers, the attacker communicates with the agents using special "many-to-many" communication tools. The purpose of this communication is twofold.
1042
1043The attacker commands the beginning/end and specifics of the attack.
1044
1045The attacker gathers statistics on agent behavior.
1046
1047Note here that "sufficiently large" depends on the frame of reference: Early tools like trinoo, Tribe Flood Network (TFN), and Shaft dealt with hundreds and low thousands of agents, but nowadays it is not uncommon to see sets of agents (or botnets) of tens of thousands being traded on IRC. Phatbot networks as large as 400,000 hosts have reportedly been witnessed (http://www.securityfocus.com/news/8573).
1048
10494.2.1. Direct Commands
1050Some DDoS tools like trinoo [Dith] build a handler/agent network, where the attacker controls the network by issuing commands to the handler, which in turn relays commands (sometimes using a different command set) to the agents. Commands may consist of unencrypted (clear) text, obfuscated or encrypted text, or numeric (binary) byte sequences. Analysis of the command and control traffic between handlers and agents can give insight into the capabilities of the tools without having access to the malware executable or its source code, as demonstrated with Shaft [DLD00].
1051
1052In order for some handlers and agents, such as trinoo, Stacheldraht, and Shaft to function, the handler must learn the addresses of the agents and "remember" this across reboots or program restarts. The early DDoS tools have hardcoded the IP address of a handler, and agents would report to this handler upon recruitment. Usually the agent list is kept in a file that the handler maintains in order to keep state information about the DDoS network. In some cases, there is no authentication of the handler (in fact any computer can send commands to some DDoS agents, and they will respond). The early analyses of trinoo, TFN, Stacheldraht, Shaft, and mstream all showed ways in which handlers and agents could be detected or controlled. Early DDoS attacks were waged between underground groups fighting for supremacy and ownership of IRC channels. Attackers would sometimes act to take over another's DDoS network if access to it was not somehow protected.[1] For instance, an attacker who captures a plaintext message sent to another's agent can control this same agent by modifying the necessary message fields and resending it. Or the defender can issue a command that stops the attack. Some DDoS tools that used a handler/agent architecture protected remote access to the handler using passwords, and some tried to protect the handler/agent communication through passwords or encryption using shared secrets. The first handlers even encrypted (using RC4 and Blowfish ciphers; see [MvOV96] for an excellent reference on applied cryptography) their list of agents to avoid disclosure of the identity of the agents, if the handler was examined by investigators. By replaying the commands the list of agents could be exposed, or the file could sometimes be decrypted using keys obtained from forensic analysis or reverse engineering of the handler. Other tools like Stacheldraht [Ditg] allowed encryption of the command channel between the attacker and the handler, but not between handlers and agents. Over time, these handlers became traceable and were, in most cases, removable.
1053
1054[1] The analyses of trinoo [Ditf], TFN [Dith], and Stacheldraht [Ditg] all showed weaknesses that could be used to take over a DDoS network. IRC-based botnets can also be taken over with the right information.
1055
1056Figures 4.7 and 4.8 illustrate the control and attack traffic visible from the site hosting an agent and from the site hosting a handler, respectively.
1057
1058
1059Figure 4.7. Illustration of control traffic seen from site hosting agents
1060
1061
1062
1063
1064
1065
1066Figure 4.8. Illustration of control traffic seen from site hosting a handler
1067
1068
1069
1070
1071
10724.2.2. Indirect Commands
1073Direct communication had a few downsides for the attackers. Because the handlers needed to store agents' identities and, frequently, an agent machine would store the identity of the handler, once investigators captured one machine the whole DDoS network could be identified. Further, direct communication patterns were generating anomalous events on network monitors (imagine a Web server that suddenly initiates communication with a foreign machine on an obscure port), which network operators were quick to spot. Investigating captured messages, they could identify the foreign peer's address. Operators were able to detect agent or handler processes even when no messages were actively flowing, by monitoring open ports on their machines. For direct communication, both agents and handlers had to be "ready" to receive messages all the time. This readiness was manifested by the attack process' opening a port and listening on it. Operators were able to spot this by looking at the list of currently open ports; unidentified listening processes were promptly investigated. Finally, the attacker needed to write his own code for command and control.
1074
1075A drawback to the original handler/agent design that caused a limitation in the size of DDoS networks was the number of open file handles required for TCP connections between the handler and agents. Many versions of Unix have limits to the number of open file descriptors each process can have, as well as limits for the kernel itself. Even if these limits could be increased, some DDoS tools would simply stop being able to add new agents after reaching 1024, a typical limit on the number of open file handles for many operating systems.
1076
1077Since many of the authors of DDoS tools were developing them to fight battles on IRC, and since they were already programming bots for other purposes, they began to extend existing code for IRC bots to implement DDoS functions and scanning. An early example of this was the Kaiten bot, programmed originally for Unix systems. Another example coded for the Windows operating environment is the Power bot. Rather than running a separate program that listens for incoming connections on an attacker-specified port, both the DDoS agents (the bots) and the attacker connect to an IRC server like any other IRC client. Since most sites would allow IRC as a communications channel for users, the DDoS communication does not create anomalous events. The role of the handler is played by a simple channel on an IRC server, often protected with a password. There is typically a default channel hard-coded into the bot, where it connects initially to learn where the current control channel is really located. The bot then jumps to the control channel. Channel hopping, even across IRC networks, can be implemented this way. Once in the current control channel, the bots are ready to respond to attacker commands to scan, DDoS someone, update themselves, shut down, etc.
1078
1079The advantage to the attacker of communicating via IRC is manifold. The server is already there and is being maintained by others. The channel is not easily discovered within thousands of other chat channels (although it might be unusual for a channel full of real humans to suddenly have 10,000 "people" in it in a few minutes). Even when discovered, the channel can be removed only through cooperation of the server's administrators. This cooperation may be difficult to obtain in the case of foreign servers. Due to the distributed nature of IRC, not all clients have to access the same IRC server to get to the "handler channel," but merely have to access a server within the same IRC network or alliance. Most tools appearing after Trinity (discussed in [DLD00]) take advantage of this alternate communication mechanism.
1080
1081As a means of hardening IRC-based communications, attackers regularly compromise hosts and turn them into rogue IRC servers, often using nonstandard ports (instead of the typical 6667/tcp that regular IRC servers use.) Another mechanism, made trivial by Phatbot, is to turn some of the bots into TCP proxies on nonstandard ports, which in turn connect to the real IRC servers on standard ports. Either way, another form of stepping stone in the command and control channel easily defeats many incident responders trying to identify and disable botnets.
1082
1083The attacker's communication with agents via IRC is illustrated in Figure 4.9.
1084
1085
1086Figure 4.9. IRC-based DDoS network
1087
1088
1089
1090
1091
10924.2.3. Malware Update
1093Like everyone else, attackers need to update the code for their tools. DDoS attackers essentially wanted a software update mechanism analogous to the software update function available in many common desktop operating systems, though without the actual machine owner's controlling the update process, of course. Using the same mechanism to perform updates as was used for initial recruitment—scanning for machines with attack code and planting new code—is noisy and not always effective, since some attack tools patch the vulnerability they used to gain entrance to ensure that no one else can take over their agents. The attacker then cannot break in the same way as before. Many existing tools and bots distribute updates by sending a command to their agents that tells each agent to download a newer version of the code from some source, such as a Web server.
1094
1095With the increased use of peer-to-peer networks, attackers are already looking at using peer-to-peer mechanisms for malicious activity. The Linux Slapper worm, for example, used a peer-to-peer mechanism that it claimed could handle millions of peers. More recently, Phatbot has adopted peer-to-peer communication using the "WASTE" protocol, linking to other peers by using Gnutella caching servers to appear to be a Gnutella client (see http://www.lurhq.com/phatbot.html). Using this mechanism, attackers can organize their agents into peer-to-peer networks to propagate new code versions or even to control the attack. Robustness and reliability of peer-to-peer communication can make such DDoS networks even more threatening and harder to dismantle than today.
1096
10974.2.4. Unwitting Agent Scenario
1098There is also a class of DDoS attacks that engage computers with vulnerabilities whose exploitation does not necessarily require installing any malicious software on the machine but, instead, allows the attacker to control these hosts to make them generate the attack traffic. The attacker assembles a list of vulnerable systems and, at the time of the attack, has agents iterate through this list sending exploit commands to initiate the traffic flow. The generated traffic appears to be legitimate. For example, the attacker can misuse a vulnerability present in a Web server to cause it to run the PING.EXE program.[2] Some researchers have called these unwitting agents.
1099
1100[2] Ping was designed to allow a user to determine if a remote computer is available, and its primary purpose is for troubleshooting connectivity problems. Firewalls may, however, prevent the ICMP packets that ping relies on from getting to the remote system. Sending a ping request corresponds to saying, "Are you there?" and waiting for the reply, "I am here."
1101
1102The distinction between an "unwitting agent" and other DDoS attack scenarios is subtle. Rather than a remotely executable vulnerability being used to install malicious software, the vulnerability is used to execute legitimate software already on the system. A more complete description can be found in a talk by David Dittrich (see http://staff.washington.edu/dittrich/talks/first/).
1103
1104Although attacks generated by unwitting agents, like the Web server vulnerability used to run PING.EXE, are similar in some respects to reflection attacks, they are not identical. In most reflection attacks, the attacker misuses a perfectly legitimate service, generating legitimate requests with a fake source address. In unwitting agent attacks, the misused service possesses a remotely exploitable vulnerability that enables the attacker to initiate attack traffic. Patching this vulnerability will immunize unwitting agents from misuse, while defense against reflection attacks is far more complex and difficult.
1105
1106Unwitting agents cannot be identified by remote port-scanning tools (e.g., RID [Bru] or Zombie Zapper [Tea]), nor can they be found by running file system scanners such as NIPC's find_ddos or antivirus software. This is because there is no malicious software or obscure open ports, just a remotely exploitable vulnerability. The vulnerable machines may be identified by monitoring network traffic, looking for DDoS attack traffic. They can also be discovered by doing typical vulnerability scans with programs such as Nessus (http://www.nessus.org).
1107
1108An example of an unwitting agent attack is the ICMP Echo Request (ping) flood leveled on www.whitehouse.gov on May 4, 2001. The attack misused a Microsoft IIS server vulnerability to trigger a ping application on unwitting agents and start the flood. It was reported that hundreds of systems worldwide were flooding. The systems were identified to be running Windows 2000 and NT, and some administrators found PING.EXE running on their systems, targeting the IP address of www.whitehouse.gov. Since ping is a legitimate application, antivirus software cannot help in detecting or disabling this attack. A message to the UNISOG mailing list shown in the sidebar provides some more technical information about the attack.
1109
1110The Power bot used the identical mechanism to do some of its flooding. The recruited bots would use scanning techniques described earlier to identify unwitting agents. When an attack was initiated the bots would send exploit code to the agent's vulnerable Web server to start the flood. The exploit details are given in the sidebar on page 76.
1111
11124.2.5. Attack Phase
1113Some attacks are prescheduled—hard-coded in the propagated code. However, most attacks occur when an attacker disseminates a command from his handlers to the agents. During the attack, the control traffic has mostly subsided. Depending on the type of attack tool used, the attacker may or may not be able to stop the ongoing attack. The duration of the attack is either specified in the attacker's command or controlled by default variable settings (e.g., 10 minutes of flooding). It could very well be that the attacker has moved on by the time the flooding has started. However, it is likely that the attacker is observing the ongoing attack, looking for its effects on test targets. Some tools, like Shaft [DLD00], have the ability to provide feedback on flood statistics. Figure 4.10 shows the initial compromise and test runs of the Shaft tool. The attacker is testing several attack types, such as ICMP, TCP SYN, and UDP floods, which we will discuss in section 4.3, prior to the real full-fledged attack aimed at multiple targets shown in Figure 4.11.
1114
1115
1116Figure 4.10. Illustration of test runs of the Shaft tool
1117
1118
1119
1120
1121
1122
1123Figure 4.11. Illustration of full-scale attack with the Shaft tool
1124
1125
1126
1127
1128
1129UNISOG E-mail Message
1130Date: Fri, 04 May 2001 14:26:29 -0700
1131
1132From: Computer Security Officer <security@stanford.edu>
1133
1134To: unisog@sans.org
1135
1136Subject: [unisog] DDoS against www.whitehouse.gov
1137
1138The attack exploited vulnerable IIS5 servers on Win2K and WinNT systems.
1139
1140Immediately prior to the attack we see an incoming port 80 connection from IP address 202.102.14.137 (CHINANET Jiangsu province network) to each of the systems that subsequently began pinging 198.137.240.92. The argus log looks in part like this.
1141
1142
1143
1144Fri 05/04 05:18:21 tcp 202.102.14.137.41406 <-> 128.12.177.11
1145
1146.80 EST
1147
1148Fri 05/04 05:18:21 tcp 202.102.14.137.41495 <-> 128.12.157.89
1149
1150.80 EST
1151
1152Fri 05/04 05:18:22 F icmp 128.12.157.89 -> 198.137.240.92 ECO
1153
1154Fri 05/04 05:18:22 F icmp 128.12.177.11 -> 198.137.240.92 ECO
1155
1156
1157
1158
1159Each of the systems reviewed so far had two ping processes running. One of the hosts had the following in its IIS log file.
1160
1161
1162
116312:21:36 202.102.14.137 GET /scripts/../../winnt/system32/ping
1164
1165.exe 200
1166
116712:29:29 202.102.14.137 GET /scripts/../../winnt/system32/ping
1168
1169.exe 200
1170
1171
1172
1173
1174While I am surprised that such a simple exploit could work, it looks like it may be exactly what happened.
1175
1176The attack was targeted at less than 2% of the total residence network population so it was probably mapped out earlier. ZDNet has a story running that indicated that we were not the only one used in this way.
1177
1178We are issuing an alert to our dorm network users to update their systems with the relevant security patches. We've been working so hard at cleaning up the Linux boxes that we've tended to ignore the Windows boxes. Not any more.
1179
1180Stephen
1181
1182Excerpt from "Power Bot" Analysis
1183
1184The HTTP GET request exploiting the Web server vulnerability (as seen by the ngrep utility from http://www.packetfactory.net/Projects/Ngrep/) and the corresponding flood traffic generated by the request:
1185
1186
1187
1188T 2001/06/08 02:20:09.406262 10.0.90.35:2585 -> 192.168.64.225:80
1189
1190 [AP]
1191
1192 GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+ping
1193
1194.exe+"-v"+igmp+"
1195
1196 -t"+"-l"+30000+10.2.88.84+"-n"+9999+"-w"+10..
1197
1198
1199
1200I 2001/06/08 02:20:09.430676 192.168.64.225 -> 10.2.88.84 8:0
1201
1202 7303@0:1480
1203
1204 ...c...
1205
1206.abcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnop
1207
1208
1209
1210 qrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopq
1211
1212
1213
1214
1215
1216 rstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqr
1217
1218
1219
1220
1221
1222 stuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrs
1223
1224
1225
1226
1227
1228 tuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrst
1229
1230
1231
1232
1233
1234 uvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstu
1235
1236
1237
1238
1239
1240 vwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuv
1241
1242
1243
1244
1245
1246 wabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvw
1247
1248
1249
1250
1251
1252 abcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwa
1253
1254
1255
1256
1257
1258 bcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwabcdefghijklmnopqrstuvwab
1259
1260
1261
1262 ..........
1263
1264
1265
1266
1267The exploit is contained in the embedded Unicode characters %c1%9c, which trick the server into performing a directory traversal and executing a command shell /winnt/system32/cmd.exe.
1268
1269
1270
1271
1272
1273During the attack phase, levels of network activity can be above normal, depending on the type of attack. In a flooding attack, the majority of it is felt at the aggregation point, that is, the target. This is illustrated in Figure 4.12.
1274
1275
1276Figure 4.12. Floods from the perspective of the victim
1277
1278
1279
1280
1281
1282In another example, you can observe unusual levels of traffic in Figure 4.13, as seen from the victim's perspective. The quick fluctuations between 12:00 and 18:00 represent a full-scale attack, whereas the somewhat tamed flood between 00:00 and 12:00 reflects a repeated attack, only this time mitigated by a defense mechanism. The aforementioned fluctuations are not due to variations in the attack, but solely to the measuring equipment collapsing under the load.
1283
1284
1285Figure 4.13. Illustration of a full-scale attack as seen by a victim. Average bits out denote the traffic received by the victim.
1286
1287
1288
1289
1290
1291From a different perspective, the same attack viewed from an upstream provider a few hops into the Internet in Figure 4.14 barely shows an impact of traffic levels. (The box on the right side of Figure 4.14 indicates the attack timeframe shown in Figure 4.13.) It is important to realize that what affects the target or victim can have little impact on an upstream provider, thus not creating any anomalous observations.
1292
1293
1294Figure 4.14. Illustration of a full-scale attack seen further upstream. Average bits in denote the traffic sent to the victim.
1295
1296Previous Section < Day Day Up > Next Section
1297
12984.3. Semantic Levels of DDoS Attacks
1299There are several methods of causing a denial of service. Creating a DoS effect is all about breaking things or making them fail. There are many ways to make something fail, and often multiple vulnerabilities will exist in a system and an attacker will try to exploit (or target) several of them until she gets the desired result: The target goes offline.
1300
13014.3.1. Exploiting a Vulnerability
1302As mentioned in Chapter 2, vulnerability attacks involve sending a few well-crafted packets that take advantage of an existing vulnerability in the target machine. For example, there is a bug in Windows 95 and NT, and some Linux kernels, in handling improperly fragmented packets. Generally, when a packet is too large for a given network, it is divided into two (or more) smaller packets, and each of them is marked as fragmented. The mark indicates the order of the first and the last byte in the packet, with regard to the original. At the receiver, chunks are reassembled into the original packet before processing. The fragment marks must fit properly to facilitate reassembly. The vulnerability in the above kernels causes the machine to become unstable when improperly fragmented packets are received, causing it to hang, crash, or reboot. This vulnerability can be exploited by sending two malformed UDP packets to the victim. There were several variations of this exploit—fragments that indicate a small overlap, a negative offset that overlaps the second packet before the start of the header in the first packet, and so on. These were known as the bonk, boink, teardrop, and newtear exploits [CER98b].
1303
1304Vulnerability attacks are particularly bad because they can crash or hang a machine with just one or two carefully chosen packets. However, once the vulnerability is patched, the original attack becomes completely ineffective.
1305
13064.3.2. Attacking a Protocol
1307An ideal example of protocol attacks is a TCP SYN flood attack. We first explain this attack and then indicate general features of protocol attacks.
1308
1309A TCP session starts with negotiation of session parameters between a client and a server. The client sends a TCP SYN packet to the server, requesting some service. In the SYN packet header, the client provides his initial sequence number, a uniqueper-connection number that will be used to keep count of data sent to the server (so the server can recognize and handle missing, misordered, or repeated data). Upon SYN packet receipt, the server allocates a transmission control block (TCB), storing information about the client. It then replies with a SYN-ACK, informing the client that its service request will be granted, acknowledging the client's sequence number and sending information about the server's initial sequence number. The client, upon receipt of the SYN-ACK packet, allocates a transmission control block. The client then replies with an ACK to the server, which completes the opening of the connection. This message exchange is called a three-way handshake and is depicted in Figure 4.15.
1310
1311
1312Figure 4.15. Opening of TCP connection: three-way handshake
1313
1314
1315
1316
1317
1318The potential for abuse lies in the early allocation of the server's resources. When the server allocates his TCB and replies with a SYN-ACK, the connection is said to be half-open. The server's allocated resources will be tied up until the client sends an ACK packet, closes the connection (by sending an RST packet) or until a timeout expires and the server closes the connection, releasing the buffer space. During a TCP SYN flooding attack, the attacker generates a multitude of half-open connections by using IP source spoofing. These requests quickly exhaust the server's TCB memory, and the server can accept no more incoming connection requests. Established TCP connections usually experience no degradation in service, though, as they naturally complete and are closed, the TCB records spaces they were using will be exhausted by the attack, not replaced by other legitimate connections. In rare cases, the server machine crashes, exhausts its memory, or is otherwise rendered inoperative. In order to keep buffer space occupied for the desired time, the attacker needs to generate a steady stream of SYN packets toward the victim (to reserve again those resources that have been freed by timeouts or completion of normal TCP sessions).
1319
1320The TCP SYN flooding attack is described in detail in [CER96, SKK+97]. This is an especially vicious attack, as servers expect to see large numbers of legitimate SYN packets and cannot easily distinguish the legitimate from the attack traffic. No simple filtering rule can handle the TCP SYN flooding attack because legitimate traffic will suffer collateral damage. Several solutions for TCP SYN flooding have been proposed, and their detailed description is given in [SKK+97].
1321
1322In order to perform a successful TCP SYN flooding attack, the attacker needs to locate an open TCP port at the victim. Then he generates a relatively small volume packet stream—as few as ten packets per minute [SKK+97] can effectively tie up the victim's resources. Another version of the TCP SYN flooding attack, random port TCP SYN flooding, is much less common. In it, the attacker generates a large volume of TCP SYN packets targeting random ports at the victim, with the goal of overwhelming the victim's network resources, rather than filling his buffer space.
1323
1324Protocol attacks are often difficult to fix—if the fix requires changing the protocol, both the sender and receiver must use the new version of the protocol. Changing commonly used Internet protocols for any reason has proven difficult. In a few cases, clever use of the existing protocol can solve the problem. For example, TCP SYN cookies (described in Chapters 5 and 6) deal with the SYN flood attack without changing the protocol specification, only how the server's stack processes the connections.
1325
1326Simple Nomad of the RAZOR team at BindView came up with an attack that targets the same resource as a SYN flood, connection state record, but in a novel manner. Instead of creating lots of half-open connections, the attacker actually completes the three-way handshake and creates many established connection state records in the kernel's TCB table. The trick that enables the attacker to quickly set up a lot of established connections without using up the agent's TCB memory lies in the attack programming using custom packets rather than the TCP API [Wright]. The agent machine never allocates a TCB. Instead, it listens promiscuously on the Ethernet card and responds to TCP packets based on header flags alone. The agent infers from the victim's replies the TCP header information that the victim expects to see in future packets. For instance, if the victim has sent a SYN-ACK packet with SEQ number 1232 and ACK number 540, the agent infers that it should next send an ACK packet with SEQ 540 and ACK 1233. While the server uses TCBs, the attacker does not. This attack can even forge the source address to make it look like packets are coming from a nonexistent host on the local network. Since the attacker is listening to communications on the local network in promiscuous mode, he will be able to hear and reply to the victim's packets, even though they are sent to the spoofed address.
1327
1328The attacker leaves established TCP connections idle but responds to keep-alive packets so that the connections do not time out and free up kernel resources. He can even rate limit the connection establishment to avoid SYN flooding protections within the stack [CER00]. This attack is called the Naptha attack [Bin00], and TCP SYN cookies are an ineffective defense against it.
1329
1330To generalize, protocol attacks target an asymmetry inherent in certain protocols. This asymmetry enables the attacker to create a large amount of work and consume substantial resources at the server, while sparing its own resources. Generally, the only fix that works against protocol attacks is creating a protocol patch that balances the asymmetry in the server's favor.
1331
13324.3.3. Attacking Middleware
1333Attacks can be made on algorithms, such as hash functions that would normally perform its operations in linear time for each subsequent entry. By injecting values that force worst-case conditions to exist [CW03], such as all values hashing into the same bucket, the attacker can cause the application to perform their functions in exponential time for each subsequent entry [MvOV96].
1334
1335As long as the attacker can freely send data that is processed using the vulnerable hash function, she can cause the CPU utilization of the server to exceed capacity and degrade what would normally be a subsecond operation into one that takes several minutes to complete. It does not take a very large number of requests to overwhelm some applications this way and render them unusable by legitimate users.
1336
1337The victim can immunize the host from this kind of attacks by changing (or even removing) the middleware to remove the vulnerability. Doing so may not always be easy, and if the attacker has truly found a previously unknown vulnerability, even detecting what he has done to cause the slowdown may be a challenge. Also, the middleware may not be changeable by the victim himself, who may need to wait for an update from the author or manufacturer of the middleware. Further, if the middleware is vital to the victim's proper operation, disabling or removing it may prove to be as damaging as the attack itself.
1338
1339Note that a node under a successful middleware attack might not appear to be in any trouble at all, except that those of its services that rely on the middleware are slow. The number of packets it receives might be unexceptional, other unrelated services on the node might be behaving properly, and there might be few telltale signs of an ongoing DoS attack, beyond services not working. Further, many DDoS defense mechanisms that aim to defend against flooding might be unable to help with this kind of attack.
1340
13414.3.4. Attacking an Application
1342The attacker may target a specific application and send packets to reach the limit of service requests this application can handle. For example, Web servers take a certain amount of time to serve normal Web page requests, and thus there will exist some finite number of maximum requests per second that they can sustain. If we assume that the Web server can process 1,000 requests per second to retrieve the files that make up a company's home page, then at most 1,000 customers' requests can be processed concurrently. For the sake of argument, let's say the normal load a Web server sees daily is 100 requests per second (one tenth of capacity).
1343
1344But what if an attacker controls 10,000 hosts, and can force each one of them to make one request every 10 seconds to the Web server? That is an average of 1,000 requests per second, and added to the normal traffic results in 110% of the server's capacity. Now a large portion of the legitimate requests will not make it through because the server is saturated.
1345
1346As with middleware attacks, an application attack might not cripple the entire host or appear as a vast quantity of packets. So, again, many defenses are not able to help defend against this kind of attack.
1347
13484.3.5. Attacking a Resource
1349The attacker may target a specific resource such as CPU cycles or router switching capacity. In January 2001, Microsoft suffered an outage that was reported to have been caused by a network configuration error, as described in Chapter 3. This outage disrupted a large number of Microsoft properties. When news of this attack came out, it was discovered that all of Microsoft's DNS servers were on the same network segment, served by the same router. Attackers then targeted the routing infrastructure in front of these servers and brought down all of Microsoft's online services.
1350
1351Microsoft quickly moved to disperse its name servers geographically and to provide redundant routing paths to the servers to make it more difficult for someone to take them all out of service at once. Removing bottlenecks and increasing capacity can address resource attacks, though, again, an attacker may respond with a stronger attack. For companies with fewer resources than Microsoft, overprovisioning and geographically dispersing services may not be a financially viable option.
1352
1353Attacking Infrastructure Resources
1354Infrastructure resources are particularly attractive targets because attacks on them can have effects on large segments of the Internet population. Routing is a key Internet infrastructure service that could be (and, indeed, sometimes has been) targeted by DoS attacks. Briefly, this infrastructure maintains the information required to deliver packets to their destinations, and thus is critical for Internet operation. At a high level, the service operates by exchanging information about paths through the Internet among routers, which build tables that help decide where to send packets. As a packet enters a router, the table is consulted to determine where to send the packet next.
1355
1356This infrastructure can be attacked in many ways to cause denial of service [Gre02] [ZPW+02] [MV02] [Jou00]. In addition to flooding routers, the protocols used to exchange information have various potential vulnerabilities that could be exploited to deny service. These are not only bugs in the implementations of the protocols, but also characteristics of how the protocols were designed that could be misused by an attacker. For example, there are various methods by which an attacker could try to fill up a router's tables with unimportant entries, perhaps leaving no room for critical entries or making the router run much slower. A router could be instructed by an attacker to send packets to the wrong place, preventing their delivery.[3] Or the routing infrastructure could be made unstable by forcing extremely frequent changes in its routing information. There are a number of fairly effective approaches to countering these attacks [Tho] [Ope], and research is ongoing into even better methods of protecting this critical infrastructure [KLS00].
1357
1358[3] One cannot exclude that a router can be compromised either through an existing vulnerability or through a weak or default password.
1359
13604.3.6. Pure Flooding
1361Given a sufficiently large number of agents, it is possible to simply send any type of packets as fast as possible from each machine and consume all available network bandwidth at the victim. This is a bandwidth consumption attack. The victim cannot defend against this attack on her own, since the legitimate packets get dropped on the upstream link, between the ISP and the victim network. Thus, frequently the victim requests help from its ISP to filter out offending traffic.
1362
1363It is not unusual that the victim's ISP is also affected by the attack (at least on the "customer attach router" connecting the victim to the ISP's network) and may have to filter on their upstream routers and even get their upstream provider or peers to also filter traffic coming into their network. In some cases, the attack traffic is very easy to identify and filter out (e.g., large-packet UDP traffic to unused ports, packets with an IP protocol value of 255). In other cases, it may be very difficult to identify specific packet header fields that could be used for filtering (e.g., reflected DNS queries, which could look like responses to a legitimate DNS query from clients within your network, or a flood of widely dispersed legitimate-looking HTTP requests). If this happens, filtering will simply save both the victim's and the ISP's resources, but the victim's customer traffic will be brought down to zero, achieving a DoS effect.
1364
1365Previous Section < Day Day Up > Next Section
1366
13674.4. Attack Toolkits
1368While some attackers are sophisticated enough to create their own attack code, far more commonly they use code written by others. Such code is typically built into a general, easily used package called an attack toolkit. It is very common today for attackers to bundle a large number of programs into a single archive file, often with scripts that automate its installation. This is a blended threat, as discussed in Section 4.4.2.
1369
13704.4.1. Some Popular DDoS Programs
1371While there are numerous scripts that are used for scanning, compromise and infection of vulnerable machines, there are only a handful of DDoS attack tools that have been used to carry out the actual attacks. A detailed overview of these tools, along with a timeline of their appearance, is given in [HWLT01]. DDoS attack tools mostly differ in the communication mechanism deployed between handlers and agents, and in the customizations they provide for attack traffic generation. The following paragraphs provide a brief overview of these popular tools. The reader should bear in mind that features discussed in this overview are those that have been observed in instances of attack code detected on some infected machines. Many variations may (and will) exist that have not yet been discovered and analyzed.
1372
1373Trinoo[Ditf] uses a handler/agent architecture, wherein an attacker sends commands to the handler via TCP and handlers and agents communicate via UDP. Both handler and agents are password protected to try to prevent them from being taken over by another attacker. Trinoo generates UDP packets of a given size to random ports on one or multiple target addresses, during a specified attack interval.
1374
1375Tribe Flood Network (TFN) [Dith] uses a different type of handler/agent architecture. Commands are sent from the handler to all of the agents from the command line. The attacker does not "log in" to the handler as with trinoo or Stacheldraht. Agents can wage a UDP flood, TCP SYN flood, ICMP Echo flood, and Smurf attacks at specified or random victim ports. The attacker runs commands from the handler using any of a number of connection methods (e.g., remote shell bound to a TCP port, UDP-based client/server remote shells, ICMP-based client/server shells such as LOKI [rou97], SSH terminal sessions, or normal telnet TCP terminal sessions). Remote control of TFN agents is accomplished via ICMP Echo Reply packets. All commands sent from handler to agents through ICMP packets are coded, not cleartext, which hinders detection.
1376
1377Stacheldraht [Ditg] (German for "barbed wire") combines features of trinoo and TFN tools and adds encrypted communication between the attacker and the handlers. Stacheldraht uses TCP for encrypted communication between the attacker and the handlers, and TCP or ICMP for communication between handler and agents. Another added feature is the ability to perform automatic updates of agent code. Available attacks are UDP flood, TCP SYN flood, ICMP Echo flood, and Smurf attacks.
1378
1379Shaft [DLD00] is a DDoS tool that shares a combination of features similar to those in trinoo, TFN, and Stacheldraht. Added features are the ability to switch handler and agent ports on the fly (thus hindering detection of the tool by intrusion detection systems), a "ticket" mechanism to link transactions, and a particular interest in packet statistics. Shaft uses UDP for communication between handlers and agents. Remote control is achieved via a simple telnet connection from the attacker to the handler. Shaft uses "tickets" for keeping track of its individual agents. Each command sent to the agent contains a password and a ticket. Both passwords and ticket numbers have to match for the agent to execute the request. Simple letter shifting (a Caesar cipher) is used to obscure passwords in sent commands. Agents can generate a UDP flood, TCP SYN flood, ICMP flood, or all three attack types. The flooding occurs in bursts of 100 packets per host (this number is hard-coded), with the source port and source address randomized. Handlers can issue a special command to agents to obtain statistics on malicious traffic generated by each agent. It is suspected that this is used to calculate the yield of a DDoS network.
1380
1381Tribe Flood Network 2000 (TFN2K) [CERb] is an improved version of the TFN attack tool. It includes several features designed specifically to make TFN2K traffic difficult to recognize and filter; to remotely execute commands; to obfuscate the true source of the traffic, to transport TFN2K traffic over multiple transport protocols including UDP, TCP, and ICMP, and to send "decoy" packets to confuse attempts to locate other nodes in a TFN2K network. TFN2K obfuscates the true traffic source by spoofing source addresses. Attackers can choose between random spoofing and spoofing within a specified range of addresses. In addition to flooding, TFN2K can also perform some vulnerability attacks by sending malformed or invalid packets, as described in [CER98a, CERa].
1382
1383Mstream [CER01b, DWDL] generates a flood of TCP packets with the ACK bit set. Handlers can be controlled remotely by one or more attackers using a password-protected interactive login. The communications between attacker and handlers, and a handler and agents, are configurable at compile time and have varied significantly from incident to incident. Source addresses in attack packets are spoofed at random. The TCP ACK attack exhausts network resources and will likely cause a TCP RST to be sent to the spoofed source address (potentially also creating outgoing bandwidth consumption at the victim).
1384
1385Trinity is the first DDoS tool that is controlled via IRC. Upon compromise and infection by Trinity, each machine joins a specified IRC channel and waits for commands. Use of a legitimate IRC service for communication between attacker and agents replaces the classic independent handler and elevates the level of the threat, as explained in Section 4.2.2. Trinity is capable of launching several types of flooding attacks on a victim site, including UDP, IP fragment, TCP SYN, TCP RST, TCP ACK, and other floods.
1386
1387From late 1999 through 2001, the Stacheldraht and TFN2K attack tools were the most popular. The Stacheldraht agent was bundled into versions of the t0rnkit rootkit and a variant of the 2001 Ramen worm. The 1i0n worm included the TFN2K agent code.
1388
1389On the Windows side, a large number of blended threat rootkit bundles include the knight.c or kaiten.c DDoS bots. TFN2K was coded specifically to compile on Windows NT, and versions of the trinoo agent have also been seen on Windows systems. In fact, knight.c was originally coded for Unix systems, but can be compiled with the Cygwin development libraries. Using this method, nearly any Unix DDoS program could reasonably be ported to Windows, and in fact some Windows blended threat bundles are delivered in Unix tar-formatted archives that are unpacked with the Cygwin-compiled version of GNU tar [Dev].
1390
1391Agobot and its descendant Phatbot saw very widespread use in 2003 and 2004. This blended threat is packed into a single program that some have called a "Swiss army knife" of attack tools. Phatbot implements two types of SYN floods, a UDP flood, an ICMP flood, the Targa flood (random IP protocol, fragmentation and fragment offset values, and spoofed source address), the wonk flood (one SYN packet, followed by 1,023 ACK packets) floods, and a recursive HTTP GET flood or a single HTTP GET flood with a built-in delay in hours (either set by the user or randomly chosen). The latter, when distributed across a network of tens or hundreds of thousands of hosts, would look like a normal pattern of HTTP traffic that would be very difficult to detect and block by some defense mechanisms.
1392
13934.4.2. Blended Threat Toolkits
1394Blended threats typically include some or all of the following components, which can vary due to operating system, degree of automation (for example, worms), author, etc.
1395
1396A Windows network service program. A tool commonly found in Windows blended threats is a program called Firedaemon. Firedaemon is responsible for registering programs to be run as servers, so they can listen on network sockets for incoming connections. Firedaemon would typically control the FTP server, IRC bounce program, and/or backdoor shell.
1397
1398Scanners. Various network scanners are included to help the attacker reconnoiter the local network and find other hosts to attack. These may be simple SYN scanners like synscan, TCP banner grabbers like mscan, or more full-featured scanners like nmap (http://www.nmap.org).
1399
1400Single-threaded DoS programs. While these programs may seem old-fashioned, a simple UDP or SYN flooder such as synk4 can still be effective against some systems. The attacker must log in to the host and run these commands from the command line, or use an IRC bot that is capable of running external commands, such as the Power bot.
1401
1402An FTP server. Installing an FTP server, such as Serv-U FTP daemon, allows an attacker (or software/media pirate who doubles as DDoS attacker) to upload files to the compromised host. These files are then served up by the next category of programs, the Warez bot.
1403
1404An IRC file service (Warez) bot. Pirated media files (music and video) and software programs are known as Warez. Bots that serve Warez are known as—you guessed it—Warez bots. Bots and IRC clients are able to transfer files using a feature of IRC called the Direct Client-to-Client (DCC) protocol.
1405
1406One of the most popular Warez bots is called the iroffer bot. Large bot networks using the iroffer form XDCC Warez bot nets (a peer-to-peer DCC network) and rely on Serv-U FTP daemons for uploading gigabytes of pirated movies.[4]
1407
1408[4] For a description of this activity, see http://www.cs.rochester.edu/~bukys/host/tonikgin/EduHacking.html.
1409
1410An IRC DDoS bot or DDoS agent. As mentioned earlier, standard DDoS tools like Stacheldraht or TFN, or IRC bots like GTbot or knight, are typically found in blended threats. These programs may be managed by Firedaemon on Windows hosts, or inetd or cron on Unix hosts.
1411
1412Local exploit programs. Since these kits are used for convenience, they often include some method of performing privilege escalation on the system, in the event they are loaded into a normal user account that was compromised through password sniffing. This allows the attacker to gain full administrative rights, at which point all the programs can then be installed completely on the compromised host.
1413
1414Remote exploit programs. Going along with the scanner program will often be a set of remote exploits that can be used to extend the attacker's reach into your network, or use your host as a stepping stone to go attack another site. Scripts that automate the scanning and remote exploitation are often used, making the process as simple as running a single command and giving just the first one, two, or three octets of a network address.
1415
1416System log cleaners. Once the intruder has gained access to the system, she often wants to wipe out any evidence that she ever connected to the host. There are log cleaners for standard text log files (e.g., Unix syslog or Apache log files), or for binary log files (e.g., Windows Event Logs or Unix wtmp and lastlog files).
1417
1418Trojan Horse operating system program replacements. To provide backdoors to regain access to the system, or to make the system "lie" about the presence of the attackers running programs, network connections, and files/directories, attackers often replace some of the operating system's external commands. On Unix systems, the candidate programs for replacement would typically be ls and find (replaced to hide files), ps and top (replaced to hide processes), netstat (replaced to hide network connections), and ifconfig (replaced to hide the fact the network interface is in promiscuous mode for sniffing).
1419
1420Sniffers. Installing a sniffer allows the attacker to steal more login account names and passwords, extending his reach into your network. Most sniffers look for commonly used protocols that put passwords in cleartext form on the network, such as telnet, ftp, and the IMAP and POP e-mail protocols. Some sniffers allow logging of the sniffed data to an "unlinked" (or removed) file that will not show up in directory listings, possibly encrypted, or even located on a remote host (Phantom sniffer).
1421
1422As described earlier, Phatbot implements a large percentage of these functions in a single program, including its own propagation.
1423
14244.4.3. Implications
1425Security sites such as PacketStormSecurity.org have assembled large numbers of malicious programs. Some of the tools are clearly written for reuse and allow easy adaptation for a specific purpose, and others are clearly crippled so that script kiddies cannot easily apply them.
1426
1427Hacker Web sites offer readily downloadable DDoS toolkits. This code can frequently be used without modification or real understanding, just by specifying a command to start recruiting agents and then, at the time of the attack, specifying another command with the target address and type of the attack. As a result, those who wish to use existing tools, or craft their own, have a ready supply of code with which to work. They must still learn how to recruit an attack network, to keep it from being stolen by others, how to target their victims, and how to get around any defenses. With dedication and time, or money to buy these skills, this is not a significant obstacle.
1428
1429Previous Section < Day Day Up > Next Section
1430
14314.5. What Is IP Spoofing?
1432One tactic used in malicious attacks, particularly in DDoS, is IP spoofing. In normal IP communications, the header field contains the source IP address and the destination address as set by the default network socket operations. IP spoofing occurs when a malicious program creates its own packets and does not set the true source IP address in the packet's header. It is easy to craft individual packets with full control over the IP header and send them out over the network if one has sufficient privileges within the operating system. This is referred to as raw socket access.
1433
1434A natural question to ask is why does this capability exist in the TCP/IP stack? There are perfectly legitimate reasons to craft packets by hand and transmit them on the network, rather than only use functions provided by a given TCP/IP stack's API; for example, in mobile IP environments, where a roaming host must use a "home" IP address in a foreign network [Per02], virtual private networks that set the host IP to an address local to the organization's network, etc. Regardless of the advisability of allowing use of raw sockets in the TCP/IP API, current operating systems lacking mandatory access control [Bell] and other advanced security features will have ways of getting around such limitations. Removal of raw sockets from the Windows API was proposed in 2001, and researchers showed many examples of programmers getting around the lack of raw sockets in earlier versions of Windows (e.g., the l0pht implemented a workaround for a lack of raw sockets in Windows 9x in l0phtcrack 3; PCAUSA provides a raw sockets implementation for Windows 9x—see http://www.pcausa.com/; WinPcap implements a means of sending raw packets—see http://netgroup-serv.polito.it/winpcap/). With the release of Windows XP Service Pack 2 in August 2004, Microsoft removed the raw sockets API, which broke applications like the public domain nmap port scanner. In just a few days, a workaround was produced restoring the ability of nmap to craft custom packets. See http://seclists.org/lists/nmap-hackers/2004/Jul-Sep/0003.html. We must also live with the fact that even if the ability to spoof addresses did not exist in the first place, DDoS would still not only be possible, but be just as damaging. There are simply too many ways to perform viable denial of service attacks.
1435
1436There are several levels of spoofing.
1437
1438Fully random IP addresses. The host generates IP addresses that are taken at random from the entire IPv4 space, 0.0.0.0–255.255.255.255. This strategy will sometimes generate invalid IPv4 addresses, such as addresses from 192.168.0.0 range, that are reserved for private networks, and may also generate nonroutable IP addresses, multicast addresses, broadcast addresses, and invalid addresses (e.g.,0.2.45.6). Some of these exotic addresses cause significant problems in their own right for routing hardware, which must process spoofed packets, and in some cases they crash or lock up the router. However, most randomly generated addresses will be valid and routable. If the attacker cares little about whether a particular packet is delivered, she can send large numbers of randomly spoofed packets and expect that most of them will be delivered.
1439
1440A frequently proposed defense against random spoofing is to use a form of ingress and egress filtering [FS00]. (See Sidebar "Ingress/Egress Filtering" for a complete description of these sometime confusing terms and how they apply to the problem of IP spoofing.) This technique compares the packet's source address with the range of IP addresses assigned to its source or destination network, depending on the location of the filtering router, and drops nonmatching ones that appear to be randomly spoofed.
1441
1442While ingress/egress filtering has the potential to greatly limit the ability of attackers to generate spoofed packets, it has to be widely deployed to really impact the DDoS threat. An edge network performing ingress/egress filtering is mostly scrutinizing its own traffic to protect others, but itself gains little benefit. This may be the reason why this type of filtering is still not widely deployed.
1443
1444Subnet spoofing. If a host resides in, say, the 192.168.1.0/24 network, then it is relatively easy to spoof a neighbor from the same network. For example, 192.168.1.2 can easily spoof 192.168.1.45 or any other address in 192.168.1.0/24 range unless the network administrators have put in protective measures that prevent an assigned Ethernet hardware address (MAC address) being associated with any but the administratively assigned IP address. This is an expensive fix from an administration point of view.
1445
1446If the host is part of a larger network (for example, a /16 network that contains 65,536 addresses), then it could spoof addresses from the larger domain, assuming the protective measures outlined in the previous point have not been implemented.
1447
1448Packets spoofed at the subnet level can be filtered by ingress/egress filtering only at the subnet level, since their source address is, by definition, from an assigned address range for a given network. Even with such filtering at the subnet level, spoofing can still make it difficult to identify the flooding host.
1449
1450Ingress/Egress Filtering
1451The terms ingress and egress mean, respectively, the acts of entering and exiting. In an interconnected network of networks, such as the Internet, what leaves (egresses) one network will enter (ingress) another. It is extremely important to clearly define the location where the filtering is done with respect to the network whose traffic is being filtered, to avoid confusion.
1452
1453If there was one "Big I" Internet, and we all connected our hosts directly to "The Internet," life would be simple and we could just say "ingress means entering the Internet" and "egress means leaving the Internet," and everything would be clear. There would be only one perspective. But there is no "Internet" to which we all connect, and to make matters worse there are tier 1 and tier 2 network providers, as well as leaf networks (e.g., university and enterprise networks).
1454
1455To see how a confusion can occur, take the example given in RFC 2827 [FS00]. It discusses ingress filtering in terms of an attacker's packets coming in to an edge router of ISP D. This is illustrated by the following figure.
1456
1457Ingress/egress filtering example from RFC 2827
1458
1459
1460
1461The authors of the RFC describe an attacker residing within the 204.69.207. 0/24 address space, which is provided Internet connectivity by ISP D. (This is shown in the above figure.) They describe an input traffic filter being applied on the ingress (input) link of Router 2, which provides connectivity to the attacker's network. This restricts traffic to allow only packets originating from source addresses within the 204.69.207.0/24 prefix, prohibiting the attacker from spoofing addresses of any other network besides 204.69.207.0/24.
1462
1463The authors of this RFC only discuss ISP D doing filtering of traffic coming in to their edge router from their customer, shown in the figure on page 94 as Router 2. So in their example, ISP D does ingress filtering to avoid an attacker using "invalid" source addresses that appear to come from networks other than the customer's address range.
1464
1465This RFC does not consider this same filtering also being done by the customer through the router the customer owns, Router 1. (This customer is known as an edge network, an end customer of a network service provider, or simply a leaf network.) If outbound packets are filtered on Router 1 to prevent source addresses from networks other than 204.69.207.0/24 leaving this leaf network, the customer would be doing egress filtering.
1466
1467It would be very confusing to always say "ingress means packets going to the ISP" and explain that customer 204.69.207.0/24 does ingress filtering to block packets leaving its network, especially if the description is taken across more than one network (e.g., moving to the left in the figure on page 94.)
1468
1469Another possible source of confusion in the use of these terms is that the filtering to be performed could be on any criteria, not just on source addresses. While discussion of these terms often focuses on the issue of mitigating IP spoofing, the filtering could be on protocol type, port number, or any other criteria of importance.
1470
1471Within the context of handling IP spoofing, there are two important reasons for making the ingress/egress distinction, and they have to do with filtering being done for the same reason at two locations (perhaps simultaneously), the customer network's egress router and the ingress router of an ISP that connects to the customer's network.
1472
1473It can be argued that egress filtering of traffic leaving a leaf network is less expensive, CPU-wise, than the equivalent ingress filtering for that same traffic coming into a tier 2 network provider (and it is even worse if you go up one level to tier 1, or backbone providers, which is not the place to do ingress filtering to stop spoofed packets coming in from their peers.) [*] Given this argument, egress filtering on leaf networks to stop attackers from spoofing off-network hosts is more desirable.
1474
1475Spoofing can happen in either direction. Attackers outside your network can send packets inbound to your network pretending to be hosts on your network, and attackers inside your network can send packets outbound from your network pretending to be from hosts outside your network. This means that leaf networks should do both ingress and egress filtering to protect their network as well as other networks. Even if your ISP says it will filter packets coming into your network to prevent spoofing, you may want to do redundant filtering of those same packets to make sure that spoofing cannot take place. After all, don't things fail sometimes?
1476
1477In this book, we will be careful to use ingress filtering to mean filtering the traffic coming into your network and egress filtering to mean filtering the traffic leaving your network. We will be explicit when talking about filtering being done by an ISP or tier 1 provider versus filtering being done by a leaf network. Where the filters are applied and why really does matter.
1478
1479
1480
1481
1482
1483[*] see http://www.netsys.com/firewalls/firewalls-2001-06/msg00385.html
1484
1485Spoofing the victim's addresses. This is the reflection attack scenario. The host forges the source address in service request packets (for example, a SYN packet for a TCP connection) to invoke a flood of service replies to be sent to the victim. If there is no filtering of packets as they leave the source network or at the entry point to the upstream ISP's router, these forged packets allow a reflection DoS attack.
1486
14874.5.1. Why Is IP Spoofing Defense Challenging?
1488There is nothing to prevent someone from spoofing IP addresses, since all that is required is privileged access to the network socket. One must put up filters and restrictions at the edge of every network to allow only packets with source addresses from that network to leave. For example, a network 192.168.1.0/24 (a /24 network containing 254 host addresses) should allow only address packets carrying a source from the range 192.168.1.1–192.168.1.254 to leave the network. Note the clear omission of the broadcast addresses 192.168.1.0 and 192.168.1.255 which are used in conjunction with spoofing in a Smurf attack. If any network does not put this form of filtering in place on its router, machines in that network can spoof any IP address.
1489
1490There are sometimes good reasons not to turn this form of filtering on in your network. It requires a little extra network administration, and may temporarily shut off your Internet access if you make configuration mistakes. If you do turn anti-spoofing egress filtering on, it may break mobile IP support. It may be worth considering for other security implications, but you must realize that you are contributing to other networks' security, not your own. You would need expensive solutions to prevent spoofed traffic from reaching you. Some ideas are discussed in Chapter 7.
1491
1492There are research results suggesting that it may be possible to detect many spoofed packets in the core of the Internet [PL01, LMW+01, FS00]. However, these approaches are immature, they require deployment in core Internet routers, and there is no reason to believe any of them will be adopted in the foreseeable future.
1493
14944.5.2. Why DDoS Attacks Use IP Spoofing
1495IP spoofing is not necessary for a successful DDoS attack, since the attacker can exhaust the victim's resources with a sufficiently large packet flood, regardless of the validity of source addresses. However, some DDoS attacks do use IP spoofing for several reasons.
1496
1497Hiding the location of agent machines. In single-point DoS attacks, spoofing was used to hide the location of the attacking host. In such attacks, network operators find it hard to block the source of the attack and/or remove the offending host from the network, or even clean it. In DDoS attacks, the agents are the path to the handler, which provides an additional layer of indirection to the attacker. Hiding agents means hiding a quick path to the attacker.
1498
1499Reflector attacks. Reflector attacks require spoofing to be accomplished. The agents must be able to spoof the victim's addresses in service requests directed at legitimate servers, to invoke replies that flood the victim.
1500
1501Bypassing DDoS defenses. Some DDoS defenses build a list of legitimate clients that are accessing the network. During the attack, these clients are given preferential treatment. Other defenses attempt to share resources fairly among all current clients, each source IP address being assigned its fair share. In both of these scenarios, IP spoofing defeats the separation of clients based on their IP addresses, and enables the attack packets to assume the IP addresses of legitimate clients. Of course this only applies to UDP-based attacks, as one cannot typically spoof source addresses on TCP connection–based services in order to bypass DDoS mitigation defenses.
1502
15034.5.3. Spoofing Is Irrelevant at 10,000+ Hosts
1504Looking at the history of DDoS attacks, one quickly realizes that given the sheer number of agents in a DDoS network, spoofing is not really necessary in a flooding attack, as described in Section 4.3.6. Agent networks of 10,000 hosts or more are not uncommon and are easily traded on IRC networks, where some malicious attackers use them as "currency." As shown in Section 2.5.2, botnets of 400,000 hosts are not impossible to obtain. At this size, preventing all spoofing could somewhat help certain DDoS defense approaches deal with certain forms of DDoS attacks. This alone would not eliminate the problem of DDoS.
1505
1506
15074.6. DDoS Attack Trends
1508There is a constant arms race between the attackers and the defenders. As soon as there are effective defenses against a certain type of attack, the attackers change tactics finding a way to bypass these defenses. Due to improved security practices such as ingress/egress filtering, attackers have improved their tools, adding the option of specifying the spoofing level or spoofing netmask. A large number of attacks nowadays use subnet spoofing, as discussed in Section 4.5, bypassing anti-spoofing ingress/egress filters.
1509
1510The defenses that detect command and control traffic based on network signatures of known DDoS tools have led the attackers to start encrypting this traffic. As an added benefit, this encryption prevents the DDoS networks from being easily taken over by competing attacker groups, as well as from being easily discovered and dismantled.
1511
1512New techniques in anti-analysis and anti-forensics make discovery of the mission of the tool difficult. Obfuscation of the running code by encryption exists in both the Windows and Unix worlds. Code obfuscators like burneye, Shiva, and burneye2 are under scrutiny by security analysts.
1513
1514The trend of making DDoS tools and attack strategies more advanced in response to advanced defenses will likely continue. This was predicted in the original trinoo analysis [Ditf], and the trend has continued unabated. There are a variety of potential DDoS scenarios that would be very difficult for defense mechanisms to handle, yet painfully simple for attackers to perpetrate. Some of these were detailed in a CERT Coordination Center publication on DDoS attack trends [HWLT01].
1515
1516To prevail, the defenders must always keep in mind that they have intelligent and agile adversaries. They themselves need to be intelligent and agile in response. While it is unlikely that we will ever design a perfect defense which handles all possible DDoS attacks, making determined progress in handling simple scenarios will discourage all but the most sophisticated attackers, and dramatically reduce the incidence of attacks.
1517
1518In defending against an advanced attacker, one needs to get into the mindset of the attacker and pay close attention to DDoS attack tool capabilities and features. Attackers often must test their attack method in advance, or probe your network for weaknesses. They may also need to test to see if their attack has succeeded. Evidence of this can be found in logs, or collected during an attack as you adjust your defenses. This is known as "network situational awareness."
1519
1520When facing an advanced DDoS attack, one would be wise to study Boyd's OODA Loop (which stands for Observe, Orient, Decide, and Act) [Boy]. While a complex concept, the essential aspects are employing methods of observing what is happening on your network and hosts, using a body of knowledge of DDoS attack tools and behavior such as what is provided in this book, knowing the available set of actions that can be taken to counter an attack (and the results you expect to obtain by taking those actions), and finally acting to counter the attack. Once action is taken, you immediately go back to observation to determine if you obtained the expected results, and if not, go through the process again to choose another course of action.
1521
1522Boyd goes on to suggest taking two actions, one conventional and the other nonconventional, to attempt to confuse your attacker and either slow them down, or force them to expose themselves through their actions. (For example, DDoS attackers may expose themselves as they test your Web site again and again to see if it has gone down and stayed down. If you increase logging prior to making a defensive move, and do additional analysis during and after, you may be able to detect these probes and gain information on your attacker.) In other words, a simple defense may only stop simple attacks; a sophisticated attack may call for a sophisticated defense.
1523
1524Chapter 5. An Overview of DDoS Defenses
1525How can we defend against the difficult problems raised by distributed denial-of-service attacks? As discussed in Chapter 4, there are two classes of victims of DDoS attacks: the owners of machines that have been compromised to serve as DDoS agents and the final targets of DDoS attacks. Defending against the former attack is the same as defending against any other attempt to compromise your machine. We will concentrate in this chapter on the issue of defending the final target of the DDoS attack—the machine or network that the attacker wishes to deny service to.
1526
1527We will begin by discussing the aspects of DDoS attacks that make defending against them difficult. We will then discuss the types of challenges a DDoS defense solution must overcome, and then cover basic concepts of defense: prevention versus detection and reaction, the basic goals to be achieved by a defense system, and where to locate the defenses in the network.
1528
1529In spite of several years of intense research, these attacks still inflict a large amount of damage to Internet users. Why are these attacks possible? Can we identify some feature in the Internet design or in its core protocols, such as TCP and IP, that facilitates DoS attacks? Can we then remove or modify this feature to resolve the problem? Like all histories, the history of DDoS attacks discussed in Chapter 3 does not represent a final state, but is merely the prelude to the future. We have presented publically known details on exactly how today's attacks are perpetrated, which has set the stage for discussing what you must do to counter them. Remember, however, that the current DDoS attack trends suggest, more than anything else, continued and rapid change for the future. Early analyses of DDoS attack tools like trinoo, TFN, Stacheldraht, and Shaft all made predictions about future development trends based on past history. Attackers continued in the directions identified, as well as going in new directions (e.g., using IRC for command and control, and integration of several other malicious functions). We should expect both the number and sophistication of attack tools to grow steadily. Therefore, the tools attackers will use in upcoming years and the methods used to defend against them will progress from the current states we describe in this book, requiring defenders to keep up to date on new trends and defense methods.
1530
1531Another big problem in the arms race between the attackers and the defenders is the imbalance of the effort needed to take another step. Developing DDoS solutions is costly and they usually work for a small range of attacks. The attacker needs only to change a few lines of code, or gather more agents (hardly any effort at all) to bypass or overwhelm the existing defenses. The defenders, on the other hand, spend an immense amount of time and resources to augment their systems for handling new attacks. It seems like an unfair competition. But does it have to be so, or is there something we have overlooked that could restore the balance?
1532
1533Previous Section < Day Day Up > Next Section
1534
15355.1. Why DDoS Is a Hard Problem
1536The victim of a vulnerability attack (see Chapter 2) usually crashes, deadlocks, or has some key resource tied up. Vulnerability attacks need only a few packets to be effective, and therefore can be launched from one or very few agents. In a flooding attack, the resource is tied up as long as the attack packets keep coming in, and is reclaimed when the attack is aborted. Flooding attacks thus need a constant flow of the attack packets into the victim network to be effective.
1537
1538Vulnerability attacks target protocol or implementation bugs in the victim's systems. They base their success on much the same premise as intrusion attempts and worms do, relying on the presence of protocol and implementation bugs in the victim's software that can be exploited for the attacker's purpose. While intruders and worm writers simply want to break into the machine, the aim of the vulnerability attack is to crash it or otherwise cripple it. Future security mechanisms for defending against intrusions and worms and better software writing standards are likely to help address DDoS vulnerability attacks. In the meantime, patching and updating server machines and filtering malformed packets offer a significant immunity to known vulnerability attacks. A resourceful attacker could still bypass these defenses by detecting new vulnerabilities in the latest software releases and crafting new types of packets to exploit them. This is a subtle attack that requires a lot of skill and effort on the part of the attacker, and is not very common. There are much easier ways to deny service.
1539
1540Flooding attacks target a specific resource and simply generate a lot of packets that consume it. Naturally, if the attack packets stood out in any way (e.g., they had a specific value in one of the header fields), defense mechanisms could easily filter them out. Since a flooding attack does not need any specific packets, attackers create a varied mixture of traffic that blends with the legitimate users' traffic. They also use IP spoofing to create a greater variety of packet sources and hide agent identities. The victim perceives the flooding attack as a sudden flood of requests for service from numerous (potentially legitimate) users, and attempts to serve all of them, ultimately exhausting its resources and dropping any surplus traffic it cannot handle. As there are many more attack packets than the legitimate ones, legitimate traffic stands a very low chance of obtaining a share of the resource, and a good portion of it gets dropped. But the legitimate traffic does not lose only because of the high attack volume. It is usually congestion-responsive traffic—it perceives packet drops as a sign of congestion and reduces its sending rate. This decreases the chance of obtaining resources even further, resulting in more legitimate drops. The following characteristics of DDoS flooding attacks make these attacks very effective for the attacker's purpose and extremely challenging for the defense:
1541
1542Simplicity. There are many DDoS tools that can be easily downloaded or otherwise obtained and set into action. They make agent recruitment and activation automatic, and can be used by inexperienced users. These tools are exceedingly simple, and some of them have been around for years. Still, they generate effective attacks with little or no tweaking.
1543
1544Traffic variety. The similarity of the attack traffic to legitimate traffic makes separation and filtering extremely hard. Unlike other security threats that need specially crafted packets (e.g., intrusions, worms, viruses), flooding attacks need only a high traffic volume and can vary packet contents and header values at will.
1545
1546IP spoofing. IP spoofing makes the attack traffic appear as if it comes from numerous legitimate clients. This defeats many resource-sharing approaches that identify a client by his IP address. If IP spoofing were eliminated, agents could potentially be distinguished from the legitimate clients by their aggressive sending patterns, and their traffic could be filtered. In the presence of IP spoofing, the victim sees a lot of service initiation requests from numerous seemingly legitimate users. While the victim could easily tell those packets apart from ongoing communications with the legitimate users, it cannot discern new legitimate requests for service from the attack ones. Thus, the victim cannot serve any new users during the attack. If the attack is long, the damage to victim's business is obvious.
1547
1548High-volume traffic. The high volume of the attack traffic at the victim not only overwhelms the targeted resource, but makes traffic profiling hard. At such high packet rates, the defense mechanism can do only simple per-packet processing. The main challenge of DDoS defense is to discern the legitimate from the attack traffic, at high packet speeds.
1549
1550Numerous agent machines. The strength of a DDoS attack lies in the numerous agent machines distributed all over the Internet. With so many agents, the attacker can take on even the largest networks, and she can vary her attack by deploying subsets of agents at a time or sending very few packets from each agent machine. Varying attack strategies defeat many defense mechanisms that attempt to trace back the attack to its source. Even in the cases when the attacker does not vary the attacking machines, the mere number of agents involved makes traceback an unattractive solution. What if we knew the identities of 10,000 machines that are attacking our network? This would hardly get us any closer to stopping the attack. The situation would clearly be simplified if the attacker were not able to recruit so many agents. As mentioned above, the general increase of Internet hosts and, more recently, the high percentage of novice Internet users suggest that the pool of potential agents will only increase in the future. Furthermore, the distributed Internet management model makes it unlikely that any security mechanism will be widely deployed. Thus, even if we found ways to secure machines permanently and make them impervious to the attacker's intrusion attempts, it would take many years until these mechanisms would be sufficiently deployed to impact the DDoS threat.[1]
1551
1552[1] One could contemplate a self-spreading patching or updating mechanism, as done before by some independent party [Hex01] in response to the CodeRed worm threat [CER01a], but that is legally and ethically questionable and more challenging than it might at first appear.
1553
1554
1555Weak spots in the Internet topology. The current Internet hub-and-spoke topology has a handful of highly connected and very well provisioned spots that relay traffic for the rest of the Internet. These hubs are highly provisioned to handle heavy traffic in the first place, but if these few spots were taken down by an attacker or heavily congested, the Internet would grind to a halt. Amassing a large number of agent machines and generating heavy traffic passing through those hot spots would have a devastating effect on global connectivity. For further discussion of this threat, see [GOM03] or [AJB00, Bar02].
1556
1557Let's face it: A flooding DDoS attack seems like a perfect crime in the Internet realm. Means (attack tools) and accomplices (agent machines) are abundant and easily obtainable. A sufficient attack volume is likely to bring the strongest victim to its knees and the right mixture of the attack traffic, along with IP spoofing, will defeat attack filtering attempts. Since numerous businesses rely heavily on online access, taking that away is sure to inflict considerable damage to the victim. Finally, IP spoofing, numerous agent machines and lack of automated tracing mechanisms across the networks guarantee little to no risk to perpetrators of being caught.
1558
1559The seriousness of the DDoS problem and the increased frequency, sophistication and strength of attacks have led to the advent of numerous defense mechanisms. Yet, although a great effort has been invested in research and development, the problem is hardly dented, let alone solved. Why is this so?
1560
1561Previous Section < Day Day Up > Next Section
1562
1563
1564Previous Section < Day Day Up > Next Section
1565
15665.2. DDoS Defense Challenges
1567The challenges in designing DDoS defense systems fall roughly into two categories: technical challenges and social challenges. Technical challenges encompass problems associated with the current Internet protocols and characteristics of the DDoS threat. Social challenges, on the other hand, largely pertain to the manner in which a successful technical solution will be introduced to Internet users, and accepted and widely deployed by these users.
1568
1569The main problem that permeates both technical and social issues is the problem of large scale. DDoS is a distributed threat that requires a myriad of overlapping "solutions" to various aspects of the DDoS problem, which must be spread across the Internet because attacking machines may be spread all over the Internet. Clearly, attack streams can only be controlled if there is a point of defense between the agents and the victims. One approach is to place one defense system close to the victim so that it monitors and controls all of the incoming traffic. This approach has many deficiencies, the main one being that the system must be able to efficiently handle and process huge traffic volumes. The other approach is to divide this workload by deploying distributed defenses. Defense systems must then be deployed in a widespread manner to ensure effective action for any combination of agent and victim machines. As widespread deployment cannot be guaranteed, the technical challenge lies in designing effective defenses that can provide reasonable performance even if they are sparsely deployed. The social challenge lies in designing an economic model of a defense system in a manner that motivates large-scale deployment in the Internet.
1570
15715.2.1. Technical Challenges
1572The distributed nature of DDoS attacks, similarity of the attack packets to the legitimate ones, and the use of IP spoofing represent the main technical challenges to designing effective DDoS defense systems, as discussed in Section 5.1. In addition to that, the advance of DDoS defense research has historically been hindered by the lack of attack information and absence of standardized evaluation and testing approaches. The following list summarizes and discusses technical challenges for DDoS defense.
1573
1574Need for a distributed response at many points in the Internet. There are many possible DDoS attacks, very few of which can be handled only by the victim. Thus, it is necessary to have a distributed, possibly coordinated, response system. It is also crucial that the response be deployed at many points in the Internet to cover diverse choices of agents and victims. Since the Internet is administered in a distributed manner, wide deployment of any defense system (or even various systems that could cooperate) cannot be enforced or guaranteed. This discourages many researchers from even considering distributed solutions.
1575
1576Lack of detailed attack information. It is widely believed that reporting occurrences of attacks damages the business reputation of the victim network. Therefore, very limited information exists about various attacks, and incidents are reported only to government organizations under obligation to keep them secret. It is difficult to design imaginative solutions to the problem if one cannot become familiar with it. Note that the attack information should not be confused with attack tool information, which is publicly available at many Internet sites. Attack information would include the attack type, time and duration of the attack, number of agents involved (if this information is known), attempted response and its effectiveness, and damages suffered. Appendix C summarizes the limited amount of publicly available attack information.
1577
1578Lack of defense system benchmarks. Many vendors make bold claims that their solution completely handles the DDoS problem. There is currently no standardized approach for testing DDoS defense systems that would enable their comparison and characterization. This has two detrimental influences on DDoS research: (1) Since there is no attack benchmark, defense designers are allowed to present those tests that are most advantageous to their system; and (2) researchers cannot compare actual performance of their solutions to existing defenses; instead, they can only comment on design issues.
1579
1580Difficulty of large-scale testing. DDoS defenses need to be tested in a realistic environment. This is currently impossible due to the lack of large-scale test beds, safe ways to perform live distributed experiments across the Internet, or detailed and realistic simulation tools that can support several thousand nodes. Claims about defense system performance are thus made based on small-scale experiments or simulations and are not credible.
1581
1582This situation, however, is likely to change soon. The National Science Foundation and the Department of Homeland Security are currently funding a development of a large-scale test bed and have sponsored research efforts to design benchmarking suites and measurement methodology for security systems evaluation [USC]. We expect that this will greatly improve quality of research in DDoS defense field. Some test beds are in use right now by DDoS researchers (e.g. PlanetLab [BBC+04] and Emulab/Netbed [WLS+02]).
1583
15845.2.2. Social Challenges
1585Many DDoS defense systems require certain deployment patterns to be effective. Those patterns fall into several categories.
1586
1587Complete deployment. A given system is deployed at each host, router, or network in the Internet.
1588
1589Contiguous deployment. A given system is deployed at hosts (or routers) that are directly connected.
1590
1591Large-scale, widespread deployment. The majority of hosts (or routers) in the Internet deploy a given system.
1592
1593Complete deployment at specified points in the Internet. There is a set of carefully selected deployment points. All points must deploy the proposed defense to achieve the desired security.
1594
1595Modification of widely deployed Internet protocols, such as TCP, IP or HTTP.
1596
1597All (legitimate) clients of the protected target deploy defenses.
1598
1599None of the preceding deployment patterns are practical in the general case of protecting a generic end network from DDoS attacks (although some may work well to protect an important server or application that communicates with a selected set of clients). The Internet is extremely large and is managed in a distributed manner. No solution, no matter how effective, can be deployed simultaneously in hundreds of millions of disparate places. However, there have been quite a few cases of an Internet product (a protocol, an application, or a system) that has become so popular after release that it was very widely deployed within a short time. Examples include Kazaa, the SSH (Secure Shell) protocol, Internet Explorer, and Windows OS. The following factors determine a product's chances for wide deployment:
1600
1601Good performance. A product must meet the needs of customers. The performance requirement is not stringent, and any product that improves the current state is good enough.
1602
1603Good economic model. Each customer must gain direct economic benefit, or at least reduce the risk of economic loss, by deploying the product. Alternately, the customer must be able to charge others for improved services resulting from deployment.
1604
1605Incremental benefit. As the degree of deployment increases, customers might experience increased benefits. However, a product must offer considerable benefit to its customers even under sparse partial deployment.
1606
1607Development of better patch management solutions, better end-host integrity and configuration management solutions, and better host-based incident response and forensic analysis solutions will help solve the first phase of DDoS problems—the ability to recruit a large agent network. Building a DDoS defense system that is itself distributed, with good performance at sparse deployment, with a solid economic model and an incremental benefit to its customers, is likely to ensure its wide deployment and make an impact on second-phase DDoS threat—defending the target from an ongoing attack.
1608
1609In the remainder of this chapter we discuss basic DDoS defense approaches at a high level. In Chapter 6, we get very detailed and describe what steps you should take today to make your computer, network, or company less vulnerable to DDoS attacks, and what to do if you are the target of such an attack. In Chapter 7, we provide deeper technical details of actual research implementations of various defense approaches. This chapter is intended to familiarize you with the basics and to outline the options at a high conceptual level.
1610
1611
1612Previous Section < Day Day Up > Next Section
1613
16145.3. Prevention versus Protection and Reaction
1615As with handling other computer security threats, there are two basic styles of protecting the target of a DDoS attack: We can try to prevent the attacks from happening at all, or we can try to detect and then react effectively when they do occur.
1616
16175.3.1. Preventive Measures
1618Prevention is clearly desirable, when it can be done. A simple and effective way to make it impossible to perform a DDoS attack on any Internet site would be the best solution, but it does not appear practical. However, there is still value in preventive measures that make some simple DDoS attacks impossible, or that make many DDoS attacks more difficult. Reasonably effective preventive defenses deter attackers: If their attack is unlikely to succeed, they may choose not to launch it, or at least choose a more vulnerable victim. (Remember, however, that if the attacker is highly motivated to hit you in particular, making the attack a bit more difficult might not deter her.)
1619
1620There are two ways to prevent DDoS attacks: (1) We can prevent attackers from launching an attack, and (2) we can improve our system's capacity, resiliency, and ability to adjust to increased load so that an ongoing attack fails to prevent our system from continuing to offer service to its legitimate clients.
1621
1622Measures intended to make DDoS attacks impossible include making it hard for attackers to compromise enough machines to launch effective DDoS attacks, charging for network usage (so that sending enough packets to perform an effective DDoS attack becomes economically infeasible), or limiting the number of packets forwarded from any source to any particular destination during a particular period of time. Such measures are not necessarily easy to implement, and some of them go against the original spirit of the Internet, but they do illustrate ways in which the basis of the DoS effect could be undermined, at least in principle.
1623
1624Hardening the typical node to make it less likely to become a DDoS agent is clearly worthwhile. Past experience and common sense suggest, however, that this approach can never be completely effective. Even if the typical user's or administrator's vigilance and care increase significantly, there will always be machines that are not running the most recently patched version of their software, or that have left open ports that permit attackers to compromise them. Nonetheless, any improvement in this area will provide definite benefits in defending against DDoS attacks, and many other security threats such as intrusions and worms. More effective ways to prevent the compromise of machines would be extremely valuable. Similarly, methods that might limit the degree of damage that an attacker can cause from a site after compromising it might help, provided that the damage limitation included preventing the compromised site from sending vast numbers of packets.
1625
1626Hardening a node or an entire installation to protect it from swelling the ranks of a DDoS army is no different from hardening them to protect from other network threats. Essentially, this is a question of computer and network hygiene. Entire books are written on this subject, and many of the necessary steps depend very much on the particular operating system and other software the user is running. If the reader does not already have access to such a book, many good ones can be found on the shelves of a typical bookstore that stocks computer books. So other than reiterating the vital importance of making it hard for an attacker to take control of your node, for complete details we refer the reader to resources specific to the kinds of machines, operating systems, and applications deployed.
1627
1628While perfectly secure systems are a fantasy, not a feature of the next release of your favorite operating system, there are known things that can be done to improve the security of systems under development. More widespread use of these techniques will improve the security of our operating systems and applications, thus making our machines less likely to be compromised. Again, these are beyond the scope of this book and are subjects worthy of their own extended treatment. Possible avenues toward building more secure systems that might help us all avoid becoming unwilling draftees in a DDoS army in the future include the following:
1629
1630Better programmer education will lead to a generally higher level of application and operating system security. There are well-known methods to avoid common security bugs like buffer overflows, yet such problems are commonplace. A bettereducated programmer workforce might reduce the frequency of such problems.
1631
1632Improvements in software development and testing tools will make it easier for programmers to write code that does not have obvious security flaws, and for testers to find security problems early in the development process.
1633
1634Improvements in operating system security, both from a code quality point of view and from better designed security models for the system, will help. In addition to making systems harder to break into, these improvements might make it harder for an attacker to make complete use of a system shortly after she manages to run any piece of code on it, by compartmentalizing privileges or by having a higher awareness of proper and improper system operations.
1635
1636Automated tools for program verification will improve in their ability to find problems in code, allowing software developers to make stronger statements about the security of their code. This would allow consumers to choose to purchase more secure products, based on more than the word and reputation of the vendor. Similarly, development of better security metrics and benchmarks for security could give consumers more information about the risks they take when using a particular piece of software.
1637
1638Beyond hardening nodes against compromise, prevention measures may be difficult to bring to bear against the DDoS problem. Many other types of prevention measures have the unfortunate characteristic of fundamentally changing the model of the Internet's operation. Charging for packet sending or always throttling or metering packet flows might succeed in preventing many DDoS attacks, but they might also stifle innovative uses of the Internet. Anything based on charging for packets opens the Internet to new forms of attacks based on emptying people's bank accounts by falsely sending packets under their identities. From a practical point of view, these types of prevention measures are unrealistic because they would require wholesale changes in the existing base of installed user machines, routers, firewalls, proxies, and other Internet equipment. Unless they can provide significant benefit to some segments of the Internet with more realistic partial deployment, they are unlikely to see real use.
1639
1640Immunity to some forms of DDoS attack can potentially be achieved in a number of ways. For example, a server can be so heavily provisioned that it can withstand any amount of traffic that the backbone network could possibly deliver to it. Or the server and its router might accept packets from only a small number of trusted sites that will not participate in a DDoS attack. Of course, when designing a solution based on immunity, one must remember that the entire path to your installation must be made immune. It does little good to make it challenging to overload your server if it is trivial to flood your upstream ISP connection.
1641
1642Some sites have largely protected themselves from the DDoS threat by these kinds of immunity measures, so they are not merely theoretical. For example, during the DDoS attacks on the DNS root servers in October 2002, all of the DNS servers were able to keep up with the DNS requests that reached them, since they all were sufficiently provisioned with processing power and memory [Nar]. Some of them, however, did not have enough incoming bandwidth to carry both the attack traffic and the legitimate requests. Those servers thus did not see all of the DNS requests that were sent to them. Other root servers were able to keep up with both the DDoS traffic (which consisted of a randomized mixture of ICMP packets, TCP SYN requests, fragmented TCP packets, and UDP packets) and the legitimate requests because these sites had ample incoming bandwidth, had mirrored their content at multiple locations, or had hardware-switched load balancing that prevented individual links from being overloaded. A number of DDoS attacks on large sites have failed because they targeted companies' sites that have high-bandwidth provisions to handle the normal periodic business demand for download of new software products, patches, and upgrades.
1643
1644The major flaw to the immunity methods as an overall solution to the DDoS problem is that known immunity methods are either very expensive or greatly limit the functionality of a network node, often in ways that are incompatible with the node's mission. For example, limiting the nodes that can communicate with a small business's Web site limits its customer base and makes it impossible for new customers to browse through its wares. Further, many immunity mechanisms protect only against certain classes of attacks or against attacks up to a particular volume. An immunity mechanism that rejects all UDP packets does not protect against attacks based on floods of HTTP requests, for example, and investing in immunity by buying bandwidth equal to that of your ISP's own links will be a poor investment if the attacker generates more traffic than the ISP can accept. If attackers switch to a different type of DDoS attack or recruit vastly larger numbers of agents, the supposed immunity might suddenly vanish.
1645
16465.3.2. Reactive Measures
1647If one cannot prevent an attack, one must react to it. In many cases, reactive measures are better than preventive ones. While there are many DDoS attacks on an Internetwide basis, many nodes will never experience a DDoS attack, or will be attacked only rarely. If attacks are rare and the costs of preventing them are high, it may be better to invest less in prevention and more in reaction. A good reactive defense might incur little or no cost except in the rare cases where it is actually engaged.
1648
1649Reaction does not mean no preparation. Your reaction may require you to contact other parties to enlist their assistance or to refer the matter to legal authorities. If you know who to contact, what they can do for you, and what kind of information they will need to do it, your reaction will be faster and more effective. If your reaction includes locally deployed technical mechanisms that expect advice or confirmation from your system administrators, understanding how to interact with them and the likely implications of following (or not following) their recommendations will undoubtedly pay off when an attack hits. Certainly, with the current state of DDoS defense mechanisms, your preparation should include some ability to analyze what's going on in your network. As discussed in Chapter 6, many sites have assumed a DDoS attack when actually there was a different problem, and their responses have thus been slow, expensive, and ineffective. Being well prepared to detect and react to DDoS attacks will prove far more helpful than anything you can buy or install.
1650
1651Unlike preventive measures, reactive measures require attack detection. No reaction can take place until a problem is noticed and understood. Thus, the effectiveness of reactive measures to DDoS attacks depends not only on how well they reduce the DoS effect once they are deployed, but also on the accuracy of the system that determines which defenses are required to deal with a particular attack, when to invoke them, and where to deploy them. False positives, signals that DDoS attacks are occurring when actually they are not, may be an issue for the detection mechanism, especially if some undesirable costs or inconveniences are incurred when the reactive defense is deployed. At the extreme, if the detection mechanism falsely indicates that the reactive defense needs to be employed all the time, a supposedly reactive mechanism effectively becomes a preventive one, probably at a higher cost than having designed it to prevent attacks in the first place.
1652
1653Reactive defenses should take effect as quickly as possible once the detection mechanism requests them. Taking effect does not mean merely being turned on, but reaching the point where they effectively stop (or, at least, reduce) the DoS effect. Presuming that there is some cost to engaging the reactive defense, this defense should be turned off as soon as the DoS attack is over. On the other hand, the defense must not be turned off so quickly that an attacker can achieve the DoS effect by stopping his attack and resuming it after a brief while, repeating the cycle as necessary.
1654
1655Regardless of the form of defense chosen, the designers and users of the defenses must keep their real aim in mind. Any DoS attack, including distributed DoS attacks, aims to cripple the normal operation of its target. The attack's goal is not really to deliver vast numbers of attack packets to the target, but to prevent the target from servicing most or all of its legitimate traffic. Thus, defenses must not only stop the attack traffic, but must let legitimate traffic through. If one does not care about handling legitimate traffic, a wonderful preventive defense is to pull out the network cable from one's computer. Certainly, attackers will not be able to flood your computer with attack packets, but neither can your legitimate customers reach you. A defensive mechanism that, in effect, "pulls the network cable" for both good and bad traffic is usually no better than the attack itself. However, in cases in which restoring internal network operations is more important than allowing continued connectivity to the Internet, pulling the cable, either literally or figuratively, may be the lesser of two evils.
1656
1657
1658
16595.4. DDoS Defense Goals
1660Whether our DDoS defense strategy is preventive, reactive, or a combination of both, there are some basic goals we want it to achieve.
1661
1662Effectiveness. A good DDoS defense should actually defend. It should provide either effective prevention that really makes attacks impossible or effective reaction ensuring that the DoS effect goes away. In the case of reactive mechanisms, the response should be sufficiently quick to ensure that the target does not suffer seriously from the attack.
1663
1664Completeness. A good DDoS defense should handle all possible attacks. If that degree of perfection is impossible, it should at least handle a large number of them. A mechanism that is capable of handling an attack based on TCP SYN flooding, but cannot offer any assistance if a ping flood arrives, is clearly less valuable than a defense that can handle both styles of attack. Thus, a preventive measure like TCP SYN cookies helps but is not sufficient unless coupled with other defense mechanisms. Completeness is also required in detection and reaction. If our detection mechanism does not recognize a particular pattern of incoming packets as an attack, presumably it will not invoke any response and the attack will succeed.
1665
1666While completeness is an obvious goal, it is extremely hard to achieve, since attackers are likely to develop new types of attacks specifically designed to bypass existing defenses. Defensive mechanisms that target the fundamental basis of DoS attacks are somewhat more likely to achieve completeness than those targeted at characteristics of particular attacks, even if those are popular attacks. For example, a mechanism that validates which packets are legitimate with high accuracy and concentrates on delivering only as many such packets as the target can handle is more likely to be complete than a mechanism that filters out packets based on knowledge of how a particular popular DDoS toolkit chooses its spoofed source addresses. However, it is often easier to counter a particular attack than to close basic vulnerabilities in networks and operating systems. Virus detection programs have shown that fairly complete defenses can be built by combining a large number of very specific defenses. A similar approach might solve the practical DDoS problem, even if it did not theoretically handle all possible DDoS attacks.
1667
1668Provide service to all legitimate traffic. As mentioned earlier, the core goal of DDoS defense is not to stop DDoS attack packets, but to ensure that the legitimate users can continue to perform their normal activities despite the presence of a DDoS attack. Clearly, a good defense mechanism must achieve that goal.
1669
1670Some legitimate traffic may be flowing from sites that are also sending attack traffic. Other legitimate traffic is destined for nodes on the same network as the target node. There may be legitimate traffic that is neither coming from an attack machine nor being delivered to the target's network, but perhaps shares some portion of its path through the Internet with some of the attack traffic. And some legitimate traffic may share other characteristics with the attack traffic, such as application protocol or destination port, potentially making it difficult to distinguish between them. None of these legitimate traffic categories should be disturbed by the DDoS defense mechanism. Legitimate traffic dropped by a DDoS defense mechanism has suffered collateral damage. (Collateral damage is also used to refer to cases where a third party who is not actually the target of the attack suffers damage from the attack.) Since DDoS attackers often strive to conceal their attack traffic in the legitimate traffic stream, it is common for legitimate traffic to closely resemble the attack packets, so the problem of collateral damage is real and serious.
1671
1672Consider a DDoS defense mechanism that detects that a DDoS attack stream is coming from a local machine and then shuts down all outgoing traffic from that machine. Assuming high accuracy and sufficient deployment, such a mechanism would indeed stop the DDoS attack, but it would also stop much legitimate traffic. As mentioned early in this chapter, many machines that send DDoS attack streams are themselves victims of the true perpetrators of the attacks. It would be undesirable to shut down their perfectly legitimate activities simply because they have been taken over by a malicious adversary.[2]
1673
1674[2] Some might argue that those who do not maintain their machines well and thus allow them to be taken over by attackers deserve these consequences. However, a defense based on degrading the service of huge numbers of careless, but otherwise legitimate, users is unlikely to be embraced by the broader community. Clearly, a defense that harms such users' legitimate activities is less desirable than a defense that does not.
1675
1676If a DDoS defense mechanism develops some form of signature by which it distinguishes attack packets from nonattack packets, then unfortunate legitimate packets that happen to share that signature are likely to suffer at the hands of the DDoS defense mechanism. For example, a Web server might be flooded by HTTP request packets. If a DDoS defense mechanism decides that all HTTP request packets are attack packets, using that as the signature to determine which packets to drop, not only will the packets attacking the Web server be dropped, but so will all of the server's legitimate traffic.
1677
1678Many proposed DDoS defenses inflict significant collateral damage in some situations. While all collateral damage is bad, damage done to true third parties, who are neither at the sending nor receiving end of the attack, is probably the worst form of collateral damage. Any defense mechanism that deploys filtering, rate limiting, or other technologies that impede normal packet handling in the core of the network must be carefully designed to avoid all such third-party collateral damage.
1679
1680Low false-positive rates. Good DDoS defense mechanisms should target only true DDoS attacks. Preventive mechanisms should not have the effect of hurting other forms of network traffic. Reactive mechanisms should be activated only when a DDoS attack is actually under way. False positives may cause collateral damage in many cases, but there are other undesirable properties of high false-positive rates. For example, when a reactive system detects and responds to a DDoS attack, it might signal the system administrator of the targeted system that it is taking action. If most such signals prove to be false, the system administrator will start to ignore them, and might even choose to turn the defense mechanism off. Also, reactive mechanisms are likely to have costs of some sort. Perhaps they use some fraction of a system's processing power, perhaps they induce some delay on all packets, or, in the longer term, perhaps a sufficiently frequent occurrence of reactions demands investment in a more powerful piece of defensive equipment. If these costs are frequently paid when no attack is under way, then the costs of running the defense system may outweigh the benefits achieved in those rare cases when an attack actually occurs.
1681
1682Low deployment and operational costs. DDoS defenses are meant to allow systems to continue operations during DDoS attacks, which, despite being very harmful, occur relatively rarely. The costs associated with the defense system must be commensurate with the benefits provided by it. For commercial solutions, there is an obvious economic cost of buying the hardware and software required to run it. Usually, there are also significant system administration costs with setting up new security equipment or software. Depending on the character of the DDoS defense mechanism, it may require frequent ongoing administration. For example, a mechanism based on detecting signatures of particular attacks will need to receive updates as new attacks are characterized, requiring either manual or automated actions.
1683
1684Other operational costs relate to overheads imposed by the defense system. A system that performs stateful inspection of all incoming packets may delay each packet, for example. Or a system that throttles data streams from suspicious sources may slow down any legitimate interactions with those sources. Unless such costs are extremely low or extremely rarely paid, they must be balanced against the benefits of achieving some degree of protection against DDoS attacks.
1685
1686You must further remember that part of the cost you will need to pay to protect yourself against DDoS attacks will not be in delays or CPU cycles, nor even in money spent to purchase a piece of hardware or software. Nothing beats preparation, and preparation takes time. You need to spend time carefully analyzing your network, developing an emergency plan, training your employees to recognize and deal with a DDoS attack, contacting and negotiating with your ISP and other parties who may need to help you in the case of an attack, and taking many other steps to be ready. The cost of any proposed DDoS solution must take these elements into account.
1687
1688Previous Section < Day Day Up > Next Section
1689
16905.5. DDoS Defense Locations
1691The DDoS threat can be countered at different locations in the network. A DDoS attack consists of several streams of attack packets originating at different source networks. Each stream flows out of a machine; through a server or router into the Internet; across one or more core Internet routers; into the router, server, or firewall machine that controls access to the target machine's network; and finally to the target itself. Defense mechanisms can be placed at some or all of these locations. Each possible location has its strengths and weaknesses, which we discuss in this section.
1692
1693Figure 5.1 shows a highly simplified network with several user machines at different locations, border routers that attach local area networks to the overall network, and a few core routers. This figure will be used to illustrate various defensive locations. In this and later figures, the node at the right marked T is the target of the DDoS attack, and nodes A1, A2, and A3 are sources of attack streams.
1694
1695
1696Figure 5.1. A simplified network
1697
1698
1699
1700
1701
17025.5.1. Near the Target
1703The most obvious location for a DDoS defense system is near the target (the area surrounded by a dashed rectangle in Figure 5.2). Defenses could be located on the target's own machine, or at a router, firewall, gateway, proxy, or other machine that is very close to the target. Most existing defense mechanisms that protect against other network threats tend to be located near the target, for very good reasons. Many of those reasons are equally applicable to DDoS defense. Nodes near the target are in good positions to know when an attack is ongoing. They might be able to directly observe the attack, but even if they cannot, they are quite close to the target and often have a trust relationship with that target. The target can often tell them when it is under attack. Also, the target is the single node in the network that receives the most complete information about the characteristics of the attack, since all of the attack packets are observed there. Mechanisms located elsewhere will see only a partial picture and might need to take action based on incomplete knowledge.
1704
1705
1706Figure 5.2. Deployment near the attack's target
1707
1708
1709
1710
1711
1712Another advantage of locating a defense near the target is deployment motivation. Those who are particularly worried about the danger of DDoS attacks will pay the price of deploying such a defense mechanism, while those who are unaware or do not care about the threat need not pay. Further, the benefit of deploying the mechanism accrues directly to the entity that paid for it. Historically, mechanisms with these characteristics (such as firewalls and intrusion detection systems) have proved to be more widely accepted than mechanisms that require wide deployment for the common good (such as ingress/egress filtering of spoofed IP packets).
1713
1714A further advantage of deployment near the target is maximum control by the entity receiving protection. If the defense mechanism proves to be flawed, perhaps generating large numbers of false positives, the target machine that suffers from those flaws can turn off or adjust the defense mechanism fairly easily. Similarly, different users who choose different trade-offs between the price they pay for defense and the amount of protection they receive can independently implement those choices when the defense mechanisms are close to them and under their control. (Note that this advantage assumes a rather knowledgeable and careful user. It is far more common for users to install a piece of software or hardware using whatever defaults it specifies, and then never touch it again unless problems arise.)
1715
1716But there are also serious disadvantages to defense mechanisms located close to the target. A major disadvantage is that a DDoS attack, by definition, overwhelms the target with its volume. Unless the defense mechanism can handle this load more cheaply than the target, or is much better provisioned than the target, it is in danger of being similarly overloaded. Instead of spending a great deal of money to heavily provision a defense box whose only benefit is to help out during DDoS attacks, one might be better off spending the same money to increase the power of the target machine itself. In some cases where the defense mechanism is just a little bit upstream of the potential target, we may gain advantages by sharing the defense mechanism among many different potential targets, somewhat lessening this problem, since several entities can pool the resources they are willing to devote to DDoS defense on a more powerful mechanism.
1717
1718A less obvious problem with this location is that the target may be in a poor position to perform actions that require complex analysis and differentiation of legitimate and attack packets. The defense mechanism in this location is, as noted above, itself in danger of being overwhelmed. Unless it is very heavily provisioned, it will need to perform rather limited per-packet analysis to differentiate good packets from attack traffic. Such mechanisms are thus at risk of throwing away the good packets with the bad.
1719
1720A further potential disadvantage is that, unless the solution is totally automated and completely effective, some human being at the target will have to help in the analysis and defense deployment. If you do not have a person on your staff capable of doing that, you will have to enlist the assistance of others who are not at your site, which limits the advantages of the defense being purely local. Further, if the flood is large and the necessary countermeasures are not obvious, many of your local resources could well be overwhelmed, not least of which are the human resources you need to adjust your defenses to the attack. This problem may not be too serious for very large sites that maintain many highly trained system and network administrators, but it could be critical for a small site that has few or no trained computer professionals on its regular staff.
1721
1722A final disadvantage is that deployment near each potential target benefits only that target. Every edge network that needs protection must independently deploy its own defense, gaining little benefit from any defense deployed by other edge networks. The overall cost of protecting all nodes in the Internet using this pattern of deployment might prove higher than the costs of deploying mechanisms at other locations that provide protection to wider groups of nodes.
1723
17245.5.2. Near the Attacker
1725Figure 5.3 illustrates the option of deploying a defense mechanism near attack sources. Such a defense could be statically deployed at most or all locations from which attacks could possibly originate or could be dynamically created at locations close to where streams belonging to a particular ongoing attack actually are occurring. The multiple dotted rectangles in Figure 5.3 suggest one important characteristic of locating the defense near the attacker. An effective defense close to the attacker must actually be located close to all or most of the attackers. If the attack is coming from A1 and A2, but the defense is deployed only at A3, it will not be able to stop this attack. Even if it is deployed also at A2, the attack streams coming out of A1 will not be affected by the defense.
1726
1727
1728Figure 5.3. Deployment near attack sources
1729
1730
1731
1732
1733
1734One advantage of this deployment location is that DDoS attack streams are not highly aggregated close to the source, unlike close to the attack's target. They are of a much lower volume, allowing more processing to be devoted to detecting and characterizing them than is possible close to the target. This low volume and lack of aggregation may also prove helpful in separating the packets participating in an attack from those that are innocent traffic.
1735
1736There are also disadvantages. Typically, a host that originates a DDoS attack stream suffers little direct adverse effect from doing so.[3] Its attack stream is a tiny fraction of the huge flood that will swamp the target, and thus will rarely cause problems to its own network. A DDoS defense system located close to a source might have trouble determining that there is an attack going on. Even if it does know that an attack is being sent out of its network, the defense mechanism must determine which of its packets belong to attack streams. Existing research has shown that some legitimate traffic can be differentiated from attack traffic at this point, but it is not clear that all traffic can be confidently characterized as legitimate or harmful.
1737
1738[3] There are some notable exceptions. For example, the mstream DDoS tool forged its source addresses using full randomization of all 32 bits in the address, which meant invalid addresses, network addresses, multicast addresses, etc., would all go through the router. If the router had to process each of these packets due to egress-filtering Access Control Lists (ACLs), it could be overwhelmed or even crash. A single host running mstream could take out a multi-interface router.
1739
1740The second disadvantage is deployment motivation. A DDoS defense node close to a source will provide its benefits to other nodes and networks, not to the node where the attack originates or to its local network. Thus, there are few direct economic advantages to deploying a DDoS defense node of this kind, leading to a variant on the tragedy of the commons.[4] While everyone might be better off if all participants deployed an effective DDoS defense system at the exit point of their own network, nobody benefits much from his own deployment of such a system. The benefits derive from the overall deployment by everyone, with no incremental benefit accruing to the individual who must perform each deployment.
1741
1742[4] The tragedy of the commons is a phrase referring to a problem of shared resources. Increased use of the resource by any sharing member hurts all members equally. Yet the benefit to a member that uses more of the resource outweighs, to him, the damage from the overall increased use. As a result, all sharing members choose to maximize their use of the resource, resulting in its inevitable depletion [Har68].
1743
1744If there were advantages to deploying a source-end defense system, then this problem might be overcome. Proponents of these kinds of solutions have thus devoted some effort to finding such advantages. One possible advantage is that a target-end defense might form a trust relationship with the source-end network that polices its own traffic. During an attack, this trust relationship may bring privileged status to this source-end network, delivering its packets despite the DDoS attack. Another possible advantage is that one might avoid legal liability by preventing DDoS flows from originating in one's network, though it is unclear if existing law would impose any such liability. Finally, there is the advantage that accrues from being known as a good network citizen. However, these motivations have not been sufficient to ensure widespread deployment of other defense mechanisms with a similar character. For example, egress filtering at the exit router of the originator's local network can detect most packets with spoofed IP source addresses before they get outside that network (see Chapter 4 for details on ingress and egress filtering). However, despite the feature's being available on popular routing platforms and recommendations from knowledgeable sources to enable it, many installers do not turn it on.[5] DDoS defense mechanisms designed to operate close to potential sources would need to overcome similar reluctance.
1745
1746[5] The reasons that this filtering feature is not turned on more widely are not clear. Some possible reasons include potentially bad interactions with mobile IP, the extra maintenance costs of keeping the information up to date, possible lack of flexibility in handling network traffic, the need to act as a transit domain for some other network, and, perhaps, ignorance. Given that the feature provides little or no local benefit, it is no surprise that installers do not bother turning it on.
1747
1748The reluctance will be even greater if the defense mechanism does not have superb discrimination. If the defense's ability to separate attack traffic from good traffic is poor, it will harm many legitimate packets. Assuming that the mechanism either drops or delays packets that it classifies as part of the attack, anyone who chooses to deploy the mechanism will suddenly see some of her legitimate traffic being harmed. Perhaps the defense mechanism will even start dropping good packets when no attack stream is actually coming out of the local network. If so, it would be quickly turned off and discarded.
1749
1750A final disadvantage is the deployment scale required for this approach to be effective. If attack streams emanate from 10,000 sources to converge on one poor victim, this style of defense mechanism would need to be deployed close to a significant fraction of those 10,000 sources to do much good. A DDoS defense mechanism that is only applied to 5 to 10% of the attack packets will very likely do no good. The attacker would merely need to recruit 5 to 10% more machines to perform his attack, not a very challenging task. Unless the defense mechanism in question is located near a large fraction of all possible sites, it would not have enough coverage to be effective.
1751
17525.5.3. In the Middle
1753Deployments in the middle of the network generally refer to defenses living at core Internet routers (depicted in Figure 5.4). As a rule, such defenses are deployed at more than one core router, as the figure suggests. However, deployment "in the middle" might also refer to routers and other network nodes that are close to the target but not part of the target's network, such as an ISP. At some point, "middle" blends into "edges," and the deployment location is really near the target or near the attacker, having the characteristics of those locations. For true core deployments, there are obvious advantages and disadvantages.
1754
1755
1756Figure 5.4. Deployment in the middle of the Internet
1757
1758
1759
1760
1761
1762The vast bulk of the Internet's traffic goes through a relatively small number of core Autonomous Systems (ASs), each of which deploys a large, but not immense, number of routers to carry that traffic. Thus, any defense located at a reasonably large number of well-chosen ASs can get excellent coverage. To the degree that the defense is effective, it can provide its benefit to practically every node attached to the Internet. In Figure 5.4, if the defense is located at the two routers shown, all traffic coming from the three attack sources will pass through it. Further, even if there were a different victim (say T1, located in the same network as A3), the same two deployment points would offer protection to that victim against all attack traffic except that originating in its own network. (Core defenses inherently cannot protect against attacks that do not traverse the core; most attacks do, however.) If core defenses were effective, accurate, cheap, and easy to deploy, they could thus completely solve the problem of DDoS attacks.
1763
1764These caveats suggest the disadvantages of deploying DDoS defense in the middle of the network. First, routers at core ASs are very busy machines. They cannot devote any substantial resources to handling or analyzing individual packets. Thus, a core defense mechanism cannot perform any but the most cursory per-packet inspection, and cannot perform any serious packet-level analysis to determine the presence, characteristics, or origins of a DDoS attack, even assuming we had analysis methods that could do so.
1765
1766The basic problem in DDoS defense is, again, separating the huge volume of DDoS traffic from the relatively tiny volume of legitimate traffic. DDoS defenses at core routers cannot afford to devote many resources to making such differentiation decisions. They must have simple, cheap rules for dealing with the vast majority of the packets they see.
1767
1768A second problem arises because core routers could inflict massive collateral damage if they are not exceptionally accurate in discriminating DDoS traffic from legitimate traffic. If they make mistakes at a rate that might be acceptable for a victim-side deployment, they could easily drop a huge amount of legitimate traffic. Those running core routers consider dropping legitimate traffic as extremely undesirable. Combined with their lack of resources to perform careful examination of packets, we thus would require the core defense to provide high accuracy with little analysis, a very challenging task.
1769
1770Another problem with this deployment location is that core routers are unlikely to notice DDoS attacks. They themselves are unlikely to be overwhelmed, and they cannot afford to keep statistics on packets coming through on a per-destination basis. Perhaps they can afford to look for DDoS attacks by a statistical method that examines a tiny fraction of the total packets, looking for suspiciously high numbers of packets to a single destination, but one node's overwhelming DDoS attack is another node's ordinary daily business. There is ongoing research on using measurements of entropy in packet traffic to detect DDoS attacks in the core. However, proven methods applied at core routers are not likely to pinpoint all DDoS attacks without generating unacceptable levels of false positives.
1771
1772Deployment incentives are also problematic for core-located DDoS defense mechanisms. By and large, the routers comprising the Internet backbone are not likely targets of DDoS attacks. They are heavily provisioned, are designed to perform well under high load, and are not easy to send packets to directly. Attackers are likely to need to deduce which network paths pass through such a router if they want to target it, which is not always easy. Thus, the companies running these machines would probably not receive direct benefit from deploying DDoS defenses. They would receive indirect benefit, since they typically try to minimize the time a packet travels through their system (and quickly dropping a packet because it is part of a DDoS flow certainly minimizes that time), and because their business ultimately depends on the usability of the Internet as a whole. On the other hand, their equipment is expensive and must operate correctly even under conditions of heavy strain, so they are generally little inclined to install unproven hardware and software. A very compelling case for the need for a particular defense mechanism, its correctness, and the acceptability of its performance would be required before there would be any hope of deployment in the core.
1773
1774If a core router defense performs badly, many users would be affected. Yet, unlike defenses located in their own domains (whether source-side or victim-side), users would have no power to turn the defense mechanisms off or adjust them. Those running the Internet backbone cannot afford to field calls from every ISP or, worse, every user who is having her legitimate packets dropped by a core-deployed DDoS defense mechanism.
1775
1776A final point against this form of defensive deployment is based on the respected end-to-end argument, which states that network functionality should be deployed at the endpoints of a network connection, not at nodes in the middle, unless it cannot be achieved at the endpoints or is so ubiquitously required by all traffic that it clearly belongs in the middle. While the end-to-end argument should not be regarded as the final deciding word in any discussion of network functionality, its careful application is arguably an important factor in the success of the Internet. Core-deployed DDoS defense mechanisms tend to run counter to the end-to-end argument, unless one can make a strong case for the impossibility of achieving similar results at the endpoints.
1777
17785.5.4. Multiple Deployment Locations
1779Some researchers have argued that an inherently distributed problem like DDoS requires a distributed solution. In the most trivial sense, we must have distributed solutions, unless someone comes up with a scheme that protects all potential targets against all possible attacks by deploying something at only one machine in the Internet. Most commercial solutions are, in this trivial sense, distributed, since each network that wants protection deploys its own solution. There are actually nontrivial distributed system problems related to this kind of deployment for other cyberdefenses, as exemplified by the issue of updating virus protection databases. Similarly, updating all target-side deployments to inform them of a new DDoS toolkit's signatures would be such a distributed system problem even for this trivial form of distribution.
1780
1781Some source end solutions operate purely autonomously to control a single network's traffic, and these are distributed in the same trivial sense. All other types of defense schemes suggested to date are distributed in a less trivial sense. Some of those require defense deployment at the source and at the victim, with the defense systems communicating during an attack. Others require deployment at multiple core routers, which may also cooperate among themselves. Some require defense nodes scattered at the edge networks to cooperate. All these schemes will be discussed in more detail in Chapter 7.
1782
1783There's a simple argument for why distributed solutions are necessary. Source-side nondistributed deployments just will not happen at a high enough rate to solve the problem. Target-side deployments cannot handle high-volume flooding attacks. There is no single location in the network core where one can capture all attacks, since not all packets pass any single point in the Internet. What is left? A solution that is deployed in more than one place, or multiple cooperating solutions at different places. Hence, a distributed solution.
1784
1785Perhaps each instance of such a solution can work independently, rendering its distributed nature nearly trivial. However, this seems unlikely, since the common characteristic of the flooding attacks that force distributed solutions is that you cannot observe all the traffic except at a point where there is too much of it to do anything with. Unless each instance can independently, based on its own local information, reach a conclusion on the character of the attack that is generally the same as the conclusion reached by other instances, independent defense points might not engage their defenses against enough attack traffic. Most likely, some information exchange between instances will be required to reach a common agreement on the presence and character of attacks and the nature of the response, leading to true distributed characteristics.
1786
1787With a good design, a distributed defense could exploit the strong points of each defense location while minimizing its weaknesses. For example, locations at aggregation points near the target are in a good position to recognize attacks. Locations near the attackers are well positioned to differentiate between good and bad packets. Locations in the center of the network can achieve high defensive coverage with relatively few deployment points. One approach to solving the DDoS problem is stitching together a defensive network spanning these locations. One such distributed deployment is shown in Figure 5.5. This approach must avoid the pitfall of accumulating the weaknesses of the various defensive locations, in addition to their strengths. For example, if locations near potential attackers are reluctant to deploy defensive mechanisms because they see no direct benefit and core router owners hesitate because they are unwilling to take the risk of damaging many users' traffic, a defense mechanism requiring deployments in both locations might be even less likely to be installed than one requiring deployment in only one of these locations.
1788
1789
1790Figure 5.5. Distributed deployment
1791
1792
1793
1794
1795
1796Generally speaking, a defensive scheme that deploys cooperating mechanisms at multiple locations requires handling the many well-known difficulties of properly designing a distributed system. Distributed systems, while potentially powerful, are notorious for being bug-ridden and prone to unpredicted performance problems. Given that a distributed DDoS defense scheme is likely to be a tempting target for attackers, it must carefully resolve all distributed system problems that may create weak points in the defense system. These problems include standard distributed system issues (such as synchronization of various participants and behavior in the face of partial failures) and security concerns of distributed systems (such as handling misbehavior by some supposedly legitimate participants).
1797
1798
1799Previous Section < Day Day Up > Next Section
1800
18015.6. Defense Approaches
1802Given the basic dichotomy between prevention and reaction, the goals of DDoS defense, and the three types of locations where defenses can be located, we will now discuss the basic options on how to defend against DDoS attacks that have been investigated, to date. The discussion here is at a high level, with few examples of actual systems that have been built or actions that you can take, since the purpose of this material is to lay out for you the entire range of options. Doing so will then make it easier for you to understand and evaluate the more detailed defense information presented in subsequent chapters.
1803
1804Some DDoS defenses concentrate on protecting you against DDoS. They try to ensure that your network and system never suffer the DDoS effect. Other defenses concentrate on detecting attacks when they occur and responding to them to reduce the DDoS effect on your site. We will discuss each in turn.
1805
1806Most of these approaches are not mutually exclusive, and one can build a more effective overall defense by combining several of them. Using a layered approach that combines several types of defenses, at several different locations, can be more flexible and harder for an attacker to completely bypass. This layering includes host-level tuning and adequate resources, close-proximity network-level defenses, as well as border- or perimeter-level network defenses.
1807
18085.6.1. Protection
1809Some protection approaches focus on eliminating the possibility of the attack. These attack prevention approaches introduce changes into Internet protocols, applications and hosts, to strengthen them against DDoS attempts. They patch existing vulnerabilities, correct bad protocol design, manage resource usage, and reduce the incidence of intrusions and exploits. Some approaches also advocate limiting computer versatility and disallowing certain functions within the network stack (see, for example, [BR00, BR01]). These approaches aspire to make the machines that deploy them impervious to DDoS attempts. Attack prevention completely eliminates some vulnerability attacks, impedes the attacker's attempts to gain a large agent army, and generally pushes the bar for the attacker higher, making her work harder to achieve a DoS effect. However, while necessary for improving Internet security, prevention does not eliminate the DDoS threat.
1810
1811Other protection approaches focus on enduring the attack without creating the DoS effect. These endurance approaches increase and redistribute a victim's resources, enabling it to serve both legitimate and malicious requests during the attack, thus canceling the DoS effect. The increase is achieved either statically, by purchasing more resources, or dynamically, by acquiring resources at the sign of a possible attack from a set of distributed public servers and replicating the target service. Endurance approaches can significantly enhance a target's resistance to DDoS—the attacker must now work exceptionally hard to deny the service. However, the effectiveness of endurance approaches is limited to cases in which increased resources are greater than the attack volume. Since an attacker can potentially gather hundreds of thousands of agent machines, endurance is not likely to offer a complete solution to the DDoS problem, particularly for individuals and small businesses that cannot afford to purchase the quantities of network resources required to withstand a large attack.
1812
1813Hygiene Hygiene approaches try to close as many opportunities for DDoS attacks in your computers and networks as possible, on the generally sound theory that the best way to enhance security is to keep your network simple, well organized, and well maintained.
1814
1815Fixing Host Vulnerabilities Vulnerability DDoS attacks target a software bug or an error in protocol or application design to deny service. Thus, the first step in maintaining network hygiene is keeping software packages patched and up to date. In addition, applications can also be run in a contained environment (for instance, see Provos' Systrace [Pro03]), and closely observed to detect anomalous behavior or excess resource consumption.
1816
1817Even when all software patches are applied as soon as they are available, it is impossible to guarantee the absence of bugs in software. To protect critical applications from denial of service, they can be duplicated on several servers, each running a different operating system and/or application version akin to biodiversity. This, however, greatly increases administrative requirements.
1818
1819As described in Chapters 2 and 4, another major vulnerability that requires attention is more social than technical: weak or no passwords for remotely accessible services, such as Windows remote access for file services. Even a fully patched host behind a good firewall can be compromised if arbitrary IP addresses are allowed to connect to a system with a weak password on such a service. Malware, such as Phatbot, automates the identification and compromise of hosts that are vulnerable due to such password problems. Any good book on computer security or network administration should give you guidance on checking for and improving the quality of passwords on your system.
1820
1821Fixing Network Organization Well-organized networks have no bottlenecks or hot spots that can become an easy target for a DDoS attack. A good way to organize a network is to spread critical applications across several servers, located in different subnetworks. The attacker then has to overwhelm all the servers to achieve denial of service. Providing path redundancy among network points creates a robust topology that cannot be easily disconnected. Network organization should be as simple as possible to facilitate easy understanding and management. (Note, however, that path redundancy and simplicity are not necessarily compatible goals, since multiple paths are inherently more complex than single paths. One must make a trade-off on these issues.)
1822
1823A good network organization not only repels many attack attempts, it also increases robustness and minimizes the damage when attacks do occur. Since critical services are replicated throughout the network, machines affected by the attack can be quarantined and replaced by the healthy ones without service loss.
1824
1825Filtering Dangerous Packets Most vulnerability attacks send specifically crafted packets to exploit a vulnerability on the target. Defenses against such attacks at least require inspection of packet headers, and often even deeper into the data portion of packets, in order to recognize the malicious traffic. However, data inspection cannot be done with most firewalls and routers. At the same time, filtering requires the use of an inline device. When there are features of packets that can be recognized with these devices, there are often reasons against such use. For example, a lot of rapid changes to firewall rules and router ACLs is often frowned upon for stability reasons (e.g., what if an accident leaves your firewall wide open?) Some types of Intrusion Prevention Systems (IPS), which act like an IDS in recognition of packets by signature and then filter or alter them in transit, could be used, but may be problematic and/or costly on very high bandwidth networks.
1826
1827Source Validation
1828Source validation approaches verify the user's identity prior to granting his service request. In some cases, these approaches are intended merely to combat IP spoofing. While the attacker can still exhaust the server's resources by deploying a huge number of agents, this form of source validation prevents him from using IP spoofing, thus simplifying DDoS defense.
1829
1830More ambitious source validation approaches seek to ensure that a human user (rather than DDoS agent software) is at the other end of a network connection, typically by performing so-called Reverse Turing tests.[6] The most commonly used type of Reverse Turing test displays a slightly blurred or distorted picture and asks the user to type in the depicted symbols (see [vABHL03] for more details). This task is trivial for humans, yet very hard for computers. These approaches work well for Web-based queries, but could be hard to deploy for nongraphical terminals. Besides, imagine that you had to decipher some picture every time you needed to access an online service. Wouldn't that be annoying? Further, this approach cannot work when the communications in question are not supposed to be handled directly by a human. If your server responds directly to any kind of request that is not typically generated by a person, Reverse Turing tests do not solve your problem. Pings, e-mail transfers between mail servers, time synchronization protocols, routing protocol updates, and DNS lookups are a few examples of computer-to-computer interactions that could not be protected by Reverse Turing tests.
1831
1832[6] The original Turing test was passed when an artificial intelligence program could fool people into thinking it was human. The Reverse Turing test can only be passed by a human.
1833
1834Finally, some approaches verify the user's legitimacy. In basic systems, this verification can be no more than checking the user's IP address against a list of legitimate addresses. To achieve higher assurance, some systems require that the user present a certificate, issued by some well-known authority, that grants him access to the service, preferably for a limited time only. Since certificate verification is a cryptographic activity, it consumes a fair amount of the server's resources and opens the possibility for another type of DDoS attack. In this attack, the attacker generates many bogus certificates and forces the server to spend resources verifying them.
1835
1836Note that any agent machine that is capable of proving its legitimacy to the target will pass these tests. If nothing more is done by the target machine, once the test is passed an agent machine can perpetrate the DDoS attack at will. So an attacker who can recruit sufficient legitimate clients of his target as agents can defeat such systems. If you run an Internet business selling to the general public, you may have a huge number of clients who are able to prove their legitimacy, making the attacker's recruitment problem not very challenging.
1837
1838This difficulty can perhaps be addressed by requiring a bit more from machines that want to communicate with your site, using a technique called proof of work.
1839
1840Proof of Work
1841Some protocols are asymmetric—they consume more resources on the server side than on the side of the client. Those protocols can be misused for denial of service. The attacker generates many service requests and ties up the server's resources. If the protocol is such that the resources are released after a certain time, the attacker simply repeats the attack to keep the server's resources constantly occupied.
1842
1843One approach to protect against attacks on such asymmetric protocols is to redesign the protocols to delay commitment of the server's resources. The protocol is balanced by introducing another asymmetric step, this time in the server's favor, before committing the server's resources. The server requires a proof of work from the client.
1844
1845The asymmetric step should ensure that the client has spent sufficient resources for the communication before the server spends its own resources. A commonly used approach is to send a client some puzzle to solve (e.g., [JB99, CER96]). The puzzle is such that solving it takes a fair amount of time and resources, while verifying the correctness of the answer is fast and cheap. Such puzzles are called one-way functions or trapdoor functions [MvOV96]. For example, a server could easily generate a large number and ask the client to factor it. Factoring of large numbers is a hard problem and it takes a lot of time. Once the client provides the answer, it is easy to multiply all the factors and see that they produce the number from the puzzle. After verifying the answer, the server can send another puzzle or grant the service request. Of course, the client machine runs software that automatically performs the work requested of it, so the human user is never explicitly aware of the need to solve the puzzle.
1846
1847The use of proof-of-work techniques ensures that the client has to spend a lot more resources than the server before his request is granted. The amount of work required must not be sufficiently onerous for legitimate clients to mind or even usually notice, but it must be sufficient to slow down DDoS agents very heavily, making it difficult or perhaps impossible for them to send enough messages to the target to cause a DDoS effect.
1848
1849At best, proof-of-work techniques make attacks using spoofed source addresses against handshake protocols less effective from small- to moderate-sized attack networks. (The exact efficiency of these techniques is not clear.) DDoS attacks are still feasible if the attacker uses much larger attack networks. Beyond simple flooding, there are two possible ways to use spoofed packets to perform an attack against a proof-of-work system. One way is for the agents to generate a lot of requests, then let the server send out puzzles to many fake addresses, thus exhausting its resources. Since puzzle generation consumes very few resources, the attacker would have to amass many agents to make this attack effective. The other way is for agents to generate a lot of false solutions to puzzles with spoofed source addresses (with or without previously sending in spoofed requests). Since the server spends some resources to verify the reply, this could be a way to tie up the server's resources and deny service. However, puzzle verification is also cheap for the server, and the attacker needs a huge number of agents to make this attack effective. (Keep in mind that some of today's attackers do, indeed, already have a huge number of agents.) The only "economical" way to deny service is for agents to act like legitimate clients, sending valid service requests and providing correct solutions for puzzles, to lead the server to commit his resources. Spoofing cannot be used in this attack, since the agent machine must receive the puzzles from the target to solve them. If the requests are spoofed, the puzzle will be delivered to another machine and the agent will not be able to provide the desired answer.
1850
1851Elimination of IP spoofing facilitates use of other DDoS defenses that may help in the latter case. Thus, proof-of-work techniques would best be combined with other defensive techniques.
1852
1853There are several requirements to make the proof-of-work approach practical and effective. First, it would be good if the approach were transparent to the clients and deployed only by the server. Popular services have no way to ensure that their vast client population simultaneously upgrades the software. For these services, a proof-of-work solution will be practical only if it can be unilaterally deployed. For instance, imagine a protocol that goes as follows:
1854
18551. Client sends a request to the server.
1856
1857
18582. Server allocates some resources and sends a reply back to the client.
1859
1860
18613. Client allocates some resources and sends a reply back to the server.
1862
1863
18644. Server grants the request.
1865
1866
1867
1868This protocol can be balanced unilaterally by modifying steps 2 and 4. In step 2, the server does not allocate any resources. Instead, he embeds some information from the request in the reply he sends to the client. When the client replies, the server recreates the original request information in step 4 and allocates resources. The proof of work on the client side consists not in solving some puzzle, but in allocating resources, just like the original protocol prescribes. For this solution to work, the client must repeat the embedded information in his reply, so that the server can use it in step 4.
1869
1870Consider the TCP protocol as an example. TCP performs a three-way handshake at connection establishment. In its original form, this was an asymmetric protocol that required the server to commit resources early in the protocol. The server allocates resources (transmission control blocks from a fixed length table) upon receipt of a connection request (SYN packet). If the client never completes the connection, the server's resources remain allocated for a fairly long time. TCP SYN attacks, described in Chapter 4, allowed attackers to use this characteristic to perform a DoS attack with a relatively low volume of requests.
1871
1872The TCP SYN cookie approach [Ber] modifies this protocol behavior to require the client to commit his resources first. The server encodes the information that would normally be stored in the transmission control block in the server's initial sequence number value. The server then sends this value in the connection reply packet (SYN-ACK) to the client and does not preserve any state. If the client completes the connection (and allocates its own transmission control block locally), the server retrieves encoded information from client's connection-completion packet and only then allocates a transmission control block. If the client never completes the connection, the server never allocates resources for this connection.
1873
1874The second requirement for proof-of-work solutions is that the required work has to be equally hard for all clients, regardless of their hardware. Otherwise, an attacker who has compromised a powerful machine might be able to solve puzzles very quickly, thus generating enough requests to overwhelm the server despite solving all the puzzles. This requirement is hard to meet in the case of protocols that send out puzzles, because puzzle solving is computationally intensive and much easier for faster processors. Unless the amount of work is reasonable for even the least powerful legitimate client, a proof-of-work solution causes performance degradations even when no attack is ongoing. Some recent research [LC04] suggests that proofs hard enough to cause problems for attackers are so hard that many legitimate clients are hurt.
1875
1876The third requirement states that theft or replay of answers must be prevented. In other words, a client himself must do the work. He cannot save and reuse old answers, and he cannot steal somebody else's answer. Puzzle-generation techniques usually meet these requirements by generating time-dependent puzzles, and making them depend on the client identity.
1877
1878Ultimately, proof-of-work systems cannot themselves defend against attacks that purely flood network bandwidth. Until the server machine establishes that the incoming message has not provided the required proof of work for a particular source, messages use up network resources. Similarly, putative (but false) proofs of work use up resources until their deception is discovered. Lastly, these techniques only work on protocols involving session setup (not UDP services, for example).
1879
1880Resource Allocation
1881Denial of service is essentially based on one or more attack machines seizing an unfair share of the resources of the target. One class of DDoS protection approaches based on resource allocation (or fair resource sharing) approaches seeks to prevent DoS attacks by assigning a fair share of resources to each client. Since the attacker needs to steal resources from the legitimate users to deny service, resource allocation defeats this goal.
1882
1883A major challenge for resource allocation approaches is establishing the user's identity with confidence. If the attacker can fake his identity, he can exploit a resource allocation scheme to deny service. One attack method would be for the attacker to fake a legitimate user's identity, and take over this user's resources. Another attack method is to use IP spoofing to create a myriad of seemingly legitimate users. Since there are not enough resources to grant each user's request, some clients will have to be rejected. Because fake users are much more numerous than the legitimate ones, they are likely to grab more resource slots, denying the service.
1884
1885The common approach for establishing the user's identity is to couple resource allocation with source validation schemes. Another approach is to combine resource allocation with a proof of work. Once the client submits the correct proof of work, the server is assured not only of the client's identity but also of his commitment to this communication. Resource allocation can then make sure that no client can monopolize the service.
1886
1887Bear in mind that the attacker can still perform a successful attack, in spite of a strong resource allocation scheme. Just like with proof-of-work or source validation approaches, a large number of attack agents can overload the system if they behave like the legitimate users. However, resource allocation significantly raises the bar for the attacker. He needs a lot more agents than before that can only send with a limited rate, and they must abstain from IP spoofing to pass the identity test. This makes the game much more balanced for the defenders than before.
1888
1889However, unless resource allocation schemes are enforced throughout the entire Internet, the attacker can still attempt to flood the point at which resource allocations are first checked. Most such schemes are located near the target, often at its firewall or close to its connection to the Internet. At that point, the function that determines the owner of each message and performs accounting can reject incoming messages that go beyond their owners' allocations, protecting downstream entities from flooding. But it cannot prevent itself from being flooded. A resource allocation defense point that can only handle 100 Mbps of incoming traffic can be overwhelmed by an attacker who sends 101 Mbps of traffic to it, even if he has not been allocated any downstream resources at all.
1890
1891A further disadvantage of this approach is that it requires users to divulge their identities in verifiable ways, so that their resource usage can be properly accounted for. Many users are understandably reluctant to provide these kinds of identity assurances when not absolutely necessary. A DDoS solution that requires complete abandonment of all anonymous or pseudonymous interactions [DMS04] in the Internet has a serious downside. Some researchers are examining the use of temporary pseudonyms or other identity-obscuring techniques that might help solve this problem, but it is unclear if they would simultaneously prevent an attacker from obtaining as many of these pseudonyms as he needs to perpetrate his attack.
1892
1893Hiding
1894None of the above approaches protect the server from bandwidth overload attacks that clog incoming links with random packets, creating congestion and pushing out the legitimate traffic. Hiding addresses this problem. Hiding obscures the server's or the service's location. As the attacker does not know how to access the server, he cannot attack it anymore. The server is usually hidden behind an "outer wall of guards." Client requests first hit this wall, and then clients are challenged to prove their legitimacy. Any source validation or proof-of-work approach can be used to validate the client. The legitimacy test has to be sufficiently reliable to weed out attack agent machines. It also has to be distributed, so that the agents cannot crash the outer-wall guards by sending too many service requests. Legitimate clients' requests are then relayed to the server via an overlay network. In some approaches, a validated client may be able to send his requests more directly, without going through the legitimacy test for every message or connection. In the extreme, trusted and preferred clients are given a permanent "passkey" that allows them to take a fast path to the service without ever providing further proof of legitimacy. There are clear risks to that extreme. An example hiding approach is SOS [KMR02], discussed in more detail in Chapter 7.
1895
1896A poor man's hiding scheme actually prevented one DDoS attack. The Code Red worm carried, among its other cargo, code intended to perform a DDoS attack on the White House's Web site. However, the worm contained a hard-coded IP address for the victim's Web site. When the worm was captured and analyzed, this IP address was identified and the target was protected simply by changing its IP address. By sending out routing updates that caused packets sent to the old address to be dropped, the attack packets would not even be delivered to the White House's router. Had the worm instead used a DNS name to identify its victim, a DNS name resolution lookup would have occured. This would mean both worms and legitimate clients would be directed to any new IP address (thus making a change of the DNS host name to IP address mapping an ineffective solution.)[7] This approach is not generally going to help you against a reasonably intelligent DDoS attacker, but it illustrates the basic idea.
1897
1898[7] On the other hand, if DDoS agents do DNS lookups for a particular victim IP address, they can be discovered by watching for these queries on local name servers. They may then be individually blocked at the site's border using filtering methods.
1899
1900Hiding approaches show a definite promise, but incur high cost to set up the overlay network and distribute guard machines all over the Internet. Further, client software is likely to need modification for various legitimacy tests. All this extra cost makes hiding impractical for protection of public and widely accessed services, but well suited for protection of corporate or military servers. A major disadvantage of hiding schemes is that they rely on the secrecy of the protected server's IP address. If this secret is divulged, attackers can bypass the protection by sending packets directly to that address, and the scheme can become effective again only by changing the target's address.
1901
1902Some hiding solutions have been altered to provide defense benefits even when the protected target's address is not a secret. More details can be found in Chapter 7, but, briefly, the target's router is configured to allow messages to be delivered to the target only if they originate from certain hosts in a special overlay network. Legitimate users must prove themselves to the overlay network, while attackers trying to work through that network are filtered out. Whether this scheme can provide effective protection is uncertain at this time. At the least, flooding attacks on the router near the target will be effective if they can overcome that router's incoming bandwidth.
1903
1904Overprovisioning
1905Overprovisioning ensures that excess resources that can accommodate both the attack and the legitimate traffic are available, thus avoiding denial of service. Unlike previous approaches that deal with attack prevention, overprovisioning strengthens the victim to withstand the attack.
1906
1907The most common approach is purchasing abundant incoming bandwidth and deploying a pool of servers behind a load balancer. The servers may share the load equally at all times, or they may be divided into the primary and backup servers, with backup machines being activated when primary ones cannot handle the load. Overprovisioning not only helps withstand DDoS attacks, but also accommodates spikes in the legitimate traffic due to sudden popularity of the service, so-called flash crowds. For more information on flash crowds and their similarity to DDoS attacks see [JKR02] and the discussion in Chapter 7.
1908
1909Another approach is to purchase content distribution services from an organization that owns numerous Web and database servers located all over the Internet. Critical services are then replicated over these distributed servers. Client requests are redirected to the dedicated content distribution server, which sends them off to the closest or the least loaded server with the replicated service for processing. The content distribution service may dynamically increase its replication degree of a user's content if enough requests are generated, possibly keeping ahead of even rapidly increasing volumes of DDoS requests.
1910
1911After the attack on the DNS root servers in October 2002, many networks operating these services set up extra mirror sites for their service at geographically distributed locations. For example, ISC, which runs the DNS root server designated as the F server, expanded its mirroring to 20 sites on five continents, as of this writing, with plans to expand even further. The fairly static nature of the information stored at DNS root servers makes them excellent candidates for this defense technique.
1912
1913Overprovisioning is by far the most widely used approach for DDoS defense. It raises the bar for the attacker, who must generate a sufficiently strong attack to overwhelm abundant resources. However, overprovisioning does not work equally well for all services. For instance, content distribution is easily implemented for static Web pages, but can be quite tricky for pages with dynamic content or those that offer access to a centralized database. Further, the cost of overprovisioning may be prohibitive for small systems. If a system does not usually experience high traffic volume, it needs modest resources for daily business. Purchasing just a bit more will not help fend off many DDoS attacks, while purchasing a lot more resources is wasteful, as they rarely get used. Finally, while it is more difficult to perpetrate a successful attack against a well-provisioned network, it is not impossible. The attacker simply needs to collect more agents—possibly a trivial task with today's automated tools for malicious code propagation. With known attack networks numbering 400,000 or more, and some evidence suggesting the existence of million-node armies (see http://www.ladlass.com/archives/001938.html), one might question whether it is sufficient to prepare for DDoS attacks by overprovisioning.
1914
19155.6.2. Attack Detection
1916If protection approaches cannot make DDoS attacks impossible, then the defender must detect such attacks before he can respond to them. Even some of the protection approaches described above require attack detection. Certain protection schemes are rather expensive, and some researchers have suggested engaging them only when an attack is taking place, which implies the need for attack detection.
1917
1918Two major goals of attack detection are accuracy and timeliness.
1919
1920Accuracy is measured by how many detection errors are made. A detection method can err in two ways. It can falsely detect an attack in a situation when no attack was actually happening. This is called a false positive. If a system generates too many false positives, this may have dire consequences, as discussed in Section 5.3.2 The other way for a detection method to err is to miss an attack. This is called a false negative. While any detection method can occasionally be beaten by an industrious and persistent attacker, frequent false negatives signify an incomplete and faulty detection approach.
1921
1922As the attack detection drives the engagement of the response, the performance of the whole DDoS defense system depends on the timeliness of the detection. Attacks that are detected and handled early may even be transparent to ordinary customers and cause no unpleasant disruptions. Detection after the attack has inflicted damage to the victim fails to prevent interruptions, but minimizes their duration by quickly engaging an appropriate response.
1923
1924The difficulty of attack detection depends to a great extent on the deployment location and the desired detection speed. Detecting an attack at the victim site is trivial after the DoS effect becomes pronounced. It is like detecting that the dam has broken once your house is underwater. Usually, the network is either swamped by a sudden traffic flood or some of its key servers are slow or have crashed. This situation is so far from the desired that the crudest monitoring techniques can spot it and raise an alert. However, denial of service takes a toll on network resources and repels customers. Even if the response is promptly engaged, the disruption is bad for business. It is therefore desirable to detect an attack as early as possible, and respond to it, preventing the DoS effect and maintaining a good face to your customers. Although agent machines are usually synchronized by commands from a central authority and engaged all at once, the attack traffic will take some time (several seconds to a few minutes) to build up and consume the victim's resources. This is the window where early detection must operate. What is desired is to detect that the water is seeping through a dam and evacuating the houses downstream minutes before the dam breaks.
1925
1926The sensitivity and accuracy of attack detection deteriorate as monitoring is placed farther away from the victim. This is mostly due to incomplete observations, as monitoring techniques at the Internet core or close to attack sources cannot see all traffic that a victim receives, and cannot closely observe the victim's behavior to spot problems. This is like trying to guess whether a dam will break by checking for leaks at a single spot in the dam. It may happen that the other places leak profusely while the one we are monitoring is dry and safe. It also may happen that all observed places leak very little and seem innocuous, but the total amount of water leaked is enough to flood the houses downstream.
1927
1928Core-based detection techniques must be very crude, as core router resources are limited. This further decreases the accuracy. On the other hand, source-based detection techniques can be quite complex. Fortunately, since sources see only moderate traffic volumes even during the attack, they can afford to engage in extensive statistics gathering and sophisticated profiling.
1929
1930Since target-based detection is clearly superior to core- and source-based attempts, why do we have detection techniques located away from the target? The reason lies in the fact that autonomous DDoS defense is far simpler and easier to secure than a distributed defense. DDoS response near the source is most effective and incurs the least collateral damage, and co-locating a detection module with the response builds an autonomous defense at the spot. Similarly, core-based response has the best yield, since a core deployment at a few response points can control a vast number of attack streams, irrespective of the source and victim locations. Adding a detection mechanism to corebased response builds autonomous and stable defense in the Internet core. Balancing the advantages and disadvantages of various detection locations is another complex task for defenders.
1931
1932Once the attack has been successfully detected, the next crucial task is attack characterization. The detection module must be able to precisely describe the offending traffic, so that it can be sifted from the rest by the response module. Legitimate and attack traffic models used in detection, sometimes coupled with additional statistics and profiling, guide the attack characterization. The goal is to obtain a list of parameters from the packet header and contents, along with a range of values that indicate a legitimate or an attack packet. Each incoming packet is then matched against the list, and the response is selectively applied to packets deemed to be a likely part of an attack. Attack characterization is severely hindered by the fact that the attack and legitimate traffic look alike. However, good attack characterization is of immense importance to DDoS defense, as it determines the amount of collateral damage and the effectiveness of the response.
1933
1934Three main approaches to attack detection are signature, anomaly, and misbehavior detection.
1935
1936Signature Detection
1937Signature detection builds a database of attack characteristics observed in the past incidents—attack signatures. All incoming packets are compared against this database, and those that match are filtered out. Consequently, the signature must be carefully crafted to precisely specify the attack, but also, ensure that no legitimate traffic generates a match. The goal is reach a zero false-positive rate, but the effectiveness of signature detection is limited to those attacks that involve easy-to-match packet attributes. For example, the Land DoS attack [CER98a] sends packets whose source IP address and source port are the same as their destination IP address and port, causing some TCP/IP implementations to crash. As no legitimate application will ever need to send a similarly crafted packet, a check for equality of source and destination IP address and port can form a valid attack signature. This kind of check is so simple that it should always be performed. Other signatures can be much more complex.
1938
1939Since vulnerability attacks can be successful with very few packets, signature detection that accurately pinpoints these packets (and helps filtering mechanisms to surgically remove them from the input stream) is an effective solution. On the other hand, signature detection cannot help with flooding DDoS attacks that generate random packets similar to legitimate traffic.
1940
1941In addition to victim-end deployment, signature detection can be used at the source networks to identify the presence of agent machines. One approach is to monitor control traffic between agent machines and their handlers to look for telltale signs of DDoS commands. Most DDoS tools will format their control messages in a specific manner, or will embed some string in the messages. This can be used as a signature to single out DDoS control traffic. For example, one of the popular DDoS tools, TFN2K [CERb], pads all control packets with a specific sequence of ones and zeros. Modern DDoS tools use encrypted channels for control messages or use polymorphic techniques, both of which defeat signature-based detection of control traffic.
1942
1943Another approach is to look for listening network ports used for control. Some DDoS tools using the handler/agent model require agents to actively listen on a specific port. While this open port can easily be changed by an attacker, there are a handful of widely popular DDoS tools that are usually deployed without modification. Hence, a tool-specific port can frequently make a good signature for agent detection. Detecting open ports requires port scanning suspected agent machines. Most of the modern DDoS tools evade port-based detection through use of IRC channels (sometimes encrypted) for control traffic. All agents and the attacker join a specific channel to send and receive messages. While the mere use of IRC does not provide a signal that a machine is involved in a DDoS attack, if the DDoS agents use cleartext messages on the channel (as many actually do), signature detection can be performed by examining the messages sent over IRC channels. If the use of IRC is prohibited on your machines (making the presence of IRC traffic a clear signal of problems), the attacker can instead embed commands in HTTP traffic or other forms of traffic that your network must permit.
1944
1945A more sophisticated detection approach is to monitor flows to and from hosts on the network and to detect when a host that formerly acted only as a client (i.e., establishing outbound connections to servers) suddenly starts acting like a server and receiving inbound connections. Similarly, you can check if a Web server that has only received incoming connections to HTTP and HTTPS service ports suddenly behaves like an IRC server or a DNS server. Some of these techniques step across the boundaries of signature detection into the realm of anomaly detection, discussed later in this section. Stepping stones may also be detected using these techniques (by correlating inbound and outbound flows of roughly equal amounts). Note that some attacker toolkits do things like embed commands in other protocols (e.g., using ICMP to tunnel commands and replies), or may use TCP as a datagram protocol, fooling some defense tools into thinking that the fact that there was never an established TCP connection implies that no communication is occurring.
1946
1947Finally, it is possible to detect agents by examining each machine, looking for specific file names, contents, and locations. All popular and widely used DDoS tools have been carefully dissected and the detailed description of the tool-specific ports, control traffic features, and file signatures can be found at the CERT Coordination Center Web page [CERe] or at Dave Dittrich's DDoS Web page [Ditd]. Of course, one cannot look for file details on machines one does not own and control. Also, attackers may try to avoid detection by installing a rootkit at the subverted machine to hide the presence of malicious files and open ports.
1948
1949Intrusion Detection Systems (IDSs) can also be used to detect compromises of potential agent machines. They examine the incoming traffic looking for known compromise patterns and drop the suspicious packets. In addition to preventing subversion for DDoS misuse, they protect the network from general intruders and promote security [ACF+99]. One major drawback of simple IDS solutions is that they often have a high alert rate, especially false-positive alerts. Newer IDSs employ combinations of operating system detection and service detection, correlating them with attack signatures to weed out obvious false alarms, such as a Solaris/SPARC-based attack against a DNS server that is directed at an Intel/Windows XP desktop that never had a DNS server in the first place.
1950
1951Anomaly Detection
1952Anomaly detection takes the opposite approach from signature detection. It acknowledges the fact that malicious behaviors evolve and that a defense system cannot predict and model all of them. Instead, anomaly detection strives to model legitimate traffic and raise an alert if observed traffic violates the model. The obvious advantage of this approach is that previously unknown attacks can be discovered if they differ sufficiently from the legitimate traffic. However, anomaly detection faces a huge challenge. Legitimate traffic is diverse—new applications arise every day and traffic patterns change. A model that specifies legitimate traffic too tightly will generate a lot of false positives whenever traffic fluctuates. On the other hand, a loose model will let a lot of attacks go undetected, thus increasing the possibility of false-negatives. Finding the right set of features and a modeling approach that strikes a balance between false positives and false negatives is a real challenge.
1953
1954Flow monitoring with correlation, described in a previous section, is another form of anomaly detection, which also combines features of behavioral models.
1955
1956Behavioral Models Behavioral models select a set of network parameters and learn the proper value ranges of these parameters by observing network traffic over a long interval. They then use this baseline model to evaluate current observations for anomalies. If some parameter in the observed traffic falls out of the baseline range by more than a set threshold, an attack alert is raised. The accuracy and sensitivity of a behavioral model depend on the choice of parameters and the threshold value. The usual approach is to monitor a vast number of parameters, tuning the sensitivity (and the false-positive rate) by changing threshold values. To capture the variability of traffic on a daily basis (for instance, traffic on weekends in the corporate network will have a different behavior than weekday traffic), some detection methods model the traffic with a time granularity of one day.
1957
1958Behavioral models show definite promise for DDoS detection, but they face two major challenges:
1959
1960Model update. As network and traffic patterns evolve over time, models need to be updated to reflect this change. A straightforward approach to model update is to use observations from the past intervals when no attack was detected. However, this creates an opportunity for the attacker to mistrain the system by a slow attack. For instance, suppose that the system uses a very simple legitimate traffic model, recording just the incoming traffic rate. By sending the attack traffic just below the threshold for a long time, the attacker can lead the system to believe that conditions have changed and increase the baseline value. Repeating this behavior, the attacker will ultimately overwhelm the system without raising the alert.
1961
1962While these kinds of training attacks are rare in the wild, they are quite possible and easy to perpetrate. A simple fix is to sample the observations at random times and derive model updates from these samples. Another possible fix is to have a human review the updates before they are installed.
1963
1964Attack characterization. Since the behavioral models generate a detection signal that simply means "something strange is going on," another set of techniques is necessary for traffic separation. One possible and frequently used approach is to profile incoming packets looking for a set of features that single out the majority of packets. For instance, assume that our network is suddenly swamped by traffic, receiving 200 Mbps instead of the usual 30 Mbps. Through careful observation we have concluded that 180 Mbps of this traffic is UDP traffic, carrying DNS responses. Using UDP/DNS-response characterization to guide filtering, we will get rid of the flood, but likely lose some legitimate DNS responses in the process. This is the inherent problem of behavioral models, but it can be ameliorated to a great extent by a smart choice of the feature set for traffic separation. Another possible approach is to create a list of legitimate clients' source addresses, either based on past behavior or through some offline mechanism. This approach will let some attack traffic through when the attacker spoofs an address from the list.
1965
1966Standard-Based Models Standard-based models use standard specifications of protocol and application traffic to build legitimate models. For example, the TCP protocol specification describes a three-way handshake that has to be performed for TCP connection setup. An attack detection mechanism can use this specification to build a model that detects half-open TCP connections or singles out TCP data traffic that does not belong to an established connection. If protocol and application implementations follow the specification, standard-based models will generate no false positives. Not all protocol and application implementations do so, however, as was pointed out by Ptacek and Newsham [PN98].
1967
1968The other drawback of the standard-based models is their granularity. Since they model protocol and application traffic, they have to work at a connection granularity. This potentially means a lot of observation gathering and storage, and may tax system performance when the attacker generates spoofed traffic (thus creating many connections). Standard-based models must therefore deploy sophisticated techniques for statistics gathering and periodic cleanup to maintain good performance.
1969
1970While standard-based models protect only from those attacks that clearly violate the standard, they guarantee a low false-positive rate and need very little maintenance for model update, except when a new standard is specified. The models can effectively be used for traffic separation by communicating the list of misbehaving connections to the response system.
1971
1972Misbehavior Modeling
1973Instead of trying to model normal behavior and match ongoing behavior to those models, one can model misbehavior and watch for its occurrence. The simple method of detecting DDoS attacks at the target is misbehavior modeling at its most basic: The machine is receiving a vast amount of traffic and is not capable of keeping up. Yep, that's a DDoS attack. At one extreme, misbehavior modeling is the same as signature-based detection: Receiving a sufficiently large number of a particular type of packet on a particular port with a particular pattern of source addresses may be both a misbehavior model and a signature of the use of a particular attack toolkit. But misbehavior modeling can be defined in far more generic terms that would not be recognized as normal signatures. At the other extreme, misbehavior modeling is no different than anomaly modeling: If it is not normal, it is DDoS. But misbehavior modeling, by trying to capture the characteristics of only DDoS attacks, characterizes all other types of traffic, whether they have actually been observed in the past or not, as legitimate. True misbehavior modeling falls in the range between these extremes.
1974
1975The challenge in misbehavior modeling is finding characteristics of traffic that are nearly sure signs that a DDoS attack is going on, beyond the service actually failing under high load. Perhaps a sufficiently large ramp-up in traffic over a very short period of time could signal a DDoS attack before the machine was actually overwhelmed, but perhaps it signals only a surge in interest in the site or a burst of traffic that was delayed somewhere else in the network and has suddenly been delivered in bulk. Perhaps a very large number of different addresses sending traffic in a very short period of time signals an attack, but perhaps it only means sudden widespread success of your Web site. It is unclear if it is possible to model DDoS behavior sufficiently well to capture it early without falsely capturing much legitimate behavior. (Such mischaracterization could be either harmless or disastrous, depending on what you do when a DDoS attack is signaled.)
1976
19775.6.3. Attack Response
1978The goal of attack response is to improve the situation for legitimate users and mitigate the DoS effect. There are three major ways in which this is done:
1979
1980Traffic policing. The most straightforward and desirable response to a DoS attack is to drop offending traffic. This makes the attack transparent both to the victim and to its legitimate clients, as if it were not happening. Since attack detection and characterization are sometimes inaccurate, the main challenge of traffic policing is deciding what to drop and how much to drop.
1981
1982Attack traceback. Attack traceback has two primary purposes: to identify agents that are performing the DDoS attack, and to try to get even further back and identify the human attacker who is controlling the DDoS network. The first goal might be achievable, but is problematic when tens of thousands of agents are attacking. The latter is nearly impossible today, due to the use of stepping stones. These factors represent a major challenge to traceback techniques. Compounding the problem is the inability of law enforcement to deal with the tens, or hundreds of thousands, of compromised hosts scattered across the Internet, which also means scattered across the globe. Effective traceback solutions probably need to include components that automatically police traffic from offending machines, once they are found. See Chapter 7 for detailed discussion of traceback techniques.
1983
1984Service differentiation. Many protection techniques can be turned on dynamically, once the attack is detected, to provide differentiated service. Clients are presented with a task to prove their legitimacy, and those that do receive better service. This approach offers a good economic model. The server is generally willing to serve all the requests. At times of overload, the server preserves its resources and selectively serves only the VIP clients (those who are willing to prove their legitimacy) and provides best-effort service to the rest. A challenge to this approach is to handle attacks that generate a large volume of bogus legitimacy proofs. It may be necessary to distribute the legitimacy verification service to avoid the overload.
1985
1986As each response has its own set of limitations, it is difficult to compare them to each other. Service differentiation creates an opportunity for the legitimate users to actively participate in DDoS defense and prove their legitimacy. This is the most fair to the customers, as they control the level of service they receive, not relying on (possibly faulty) attack characterization at the victim. On the other hand, service differentiation requires changes in the client software, which may be impractical for highly popular public services. Traceback requires a lot of deployment points in the core, but places the bulk of complexity at the victim and enables response long after the attack has ended. Traffic policing is by far the most practical response, as its minimum number of deployment points is one—in the vicinity of the victim. However, traffic policing relies on sometimes inaccurate attack characterization and is bound to inflict collateral damage.
1987
1988Finally, there is no need to select a single response approach. Traceback and traffic policing can be combined to drop offending traffic close to its sources. Traffic policing can work with service differentiation, offering different policies for different traffic classes. Traceback can bring service differentiation points close to the sources, distributing and reducing the server load.
1989
1990Traffic Policing
1991Two main approaches in traffic policing are filtering and rate limiting. Filtering drops all the packets indicated as suspicious by the attack characterization, while rate limiting enforces a rate limit on all suspicious packets. The choice between these two techniques depends on the accuracy of attack characterization. If the accuracy is high, dropping the offending traffic is justified and will inflict no collateral damage. When the accuracy is low, rate limiting is definitely a better choice, as some legitimate packets that otherwise would have been dropped are allowed to proceed to the victim. This will reduce collateral damage and facilitate prompt recovery of legitimate traffic in the case of false positives. Signature detection techniques commonly invoke a filtering response, as the offending traffic can be precisely described, while anomaly detection is commonly coupled with rate limiting as a less restrictive response.
1992
1993The main challenge of traffic policing is to minimize legitimate traffic drops—one form of collateral damage. There are two sources of inaccuracy that lead to this kind of collateral damage: incorrect attack characterization and false positives. If the attack characterization cannot precisely separate the legitimate from the attack traffic, some legitimate packets will be dropped every time the response is invoked. The greater the inaccuracy, the greater the collateral damage. False positives needlessly trigger the response. The amount of the collateral damage again depends on the characterization accuracy, but false alarms may mislead the characterization process and thus increase legitimate drops.
1994
1995How bad is it to drop a few legitimate packets? At first glance, we might conclude that a small rate of legitimate drops is not problematic, as the overwhelming majority of Internet communication is conducted using TCP. Since TCP is a reliable transmission protocol, dropped packets will be detected and retransmitted shortly after they were lost, and put in order at the receiving host. The packet loss and the remedy process should be transparent to the application and the end user. This works very well when there are only a few drops, once in a while. The mechanisms ensuring reliable delivery in the TCP protocol successfully mask isolated packet losses. However, TCP performance drops drastically in the case of sustained packet loss, even if the loss rate is small. The reason for this lies in the TCP congestion control mechanism, which detects packet loss as an early sign of congestion. TCP's congestion control module responds by drastically reducing the sending rate in the effort to alleviate the pressure at the bottleneck link. The rate is reduced exponentially with each loss and increased linearly in the absence of losses. Several closely spaced packet drops can thus quickly reduce the connection rate to one packet per sending interval. After this point, each loss of the retransmitted packet exponentially increases the sending interval. Overall, sustained packet loss makes the connection send less and with a reduced frequency.
1996
1997While very effective in alleviating congestion, this response severely decreases the competitiveness of legitimate TCP traffic in case of a DoS attack. In the fight for a shared resource, more aggressive traffic has a better chance to win. The attack traffic rate is usually unrelenting, regardless of the drops, while the legitimate traffic quickly decreases to a trickle, thus forfeiting its fighting chance to get through. Rate limiting for DDoS response introduces another source of drops in addition to congestion, trying to tip the scale in favor of the legitimate traffic. If the rate limiting is not sufficiently selective, packet drops due to collateral damage will have the same ill effect on the legitimate connection as congestion drops did. Even if the congestion is completely resolved (the response has successfully removed the attack traffic), those legitimate connections that had severe drops will take a long time to recover and may be aborted by the application. It is therefore imperative to eliminate as many legitimate drops as possible, not only by making sure that the response is promptly engaged, but also by increasing its selectiveness.
1998
1999The traffic-policing component can be placed anywhere on the attack path. Placing the response close to the victim ensures the policing of all attack streams with a single response node, but may place substantial burden on the DDoS defense system when the victim is subjected to a high-volume flood. Victim-end deployment also maximizes the chances for collateral damage, if rate limiting is the response of choice, as imperfect drop decisions affect all traffic reaching the victim. Better performance can be achieved by identifying those network paths that likely carry the attack traffic and pushing the rate limit along those paths as close to the sources as possible. This localizes the effect of erroneous drops only to those legitimate clients who share the path to the victim with an attacker. Unfortunately, this approach causes the number of the response points needed to completely control the attack to grow, as a response node must be installed on each identified path.
2000
2001One technique currently used to counter large attacks that last for a long time is to start by trying to filter locally. If that is not sufficient, the victim then contacts his upstream network provider to request the installation of filters there. In principle, this manual pushing of filters back further into the network could continue indefinitely, but since each step requires human contact and intervention, it rarely is done too far into the network. One example of successful use of this technique occurred during the DDoS attack on the DNS root servers. One root server administrator contacted his backbone provider to install filters to drop certain types of packets in the attack stream, thus reducing the attack traffic on the link leading to his root server. The manual approach has some strong limitations, however. One must carefully characterize the packets to avoid collateral damage, and not all network providers will respond quickly to all customers' requests to install filters. This issue is discussed in more detail in Chapter 6.
2002
2003Attack Traceback
2004Attack traceback has two primary purposes: to identify (and possibly shut down) agents that are implementing the actual DDoS attack, and to try to get even further back and identify the human attacker who is controlling the DDoS network. Traceback would thus be extremely helpful not only in DDoS defense, but also in cases of intrusions and worm infections when the attack is inconspicuous, contained in a few packets, and may be detected long after the attack ends. Traceback techniques enable the victim to reassemble the path of the attack, with help of the core routers. In packet-marking techniques [SPS+01, DFS01, SWKA00], routers tag packets with extra information stating, "The packet has passed through this router." In ICMP traceback [BLT01], additional control information is sent randomly to the victim, indicating that packets have passed through a given router. The victim uses all such information it receives to deduce the paths taken by attack packets. In hash-based traceback [SPS+01], routers remember each packet they have seen for a short time and can retrieve this knowledge in response to a victim's queries. Obviously, all these approaches place a burden on the intermediate routers, either to generate additional traffic, or to rewrite a portion of the traffic they forward, or to dedicate significant storage to keep records of packets they have seen. More overhead is incurred by the victim when it tries to reassemble the attack path. This process may be very computationally intensive and lead to additional control traffic between the victim and the core routers. As the attack becomes more distributed, the cost of the traceback increases.
2005
2006Another drawback is tracing precision. It is impossible to identify the actual subverted machine. Rather, several networks in the vicinity of the attacking machine are identified. In a sparse deployment of traceback support at core routers, the number of suspect networks is likely to be very high. While this information is still beneficial if, for instance, we want to push a traffic-policing response closer to the sources, it offers little assistance to law enforcement authorities or to filtering rule generation.
2007
2008An open issue is what action to take when tracing is completed. An automatic response, such as filtering or rate limiting, is the best choice, as the number of suspect sites is likely to be too large for human intervention. In this case, suspected networks that are actually innocent (i.e., networks that do not host agents but share a path with a network that does) will have their packets dropped. This is hardly fair. Another point worth mentioning is that even a perfect tracing approach up to the sending machine is useless in a reflector DoS attack. In this case, the machine sending problematic traffic is simply a public server that responds to seemingly legitimate queries. Since such servers will not themselves spoof their IP address, identification of them is trivial and no tracing is needed.
2009
2010As noted in Chapter 4, even a workable traceback scheme has two other significant problems. First, in the face of traceback of DDoS flood traffic, it gets you only to the agents, not all the way back to the actual attacker (through all her handlers, IRC proxies, or login stepping stones). This may offer some opportunity to relieve the immediate attack but does not necessarily help catch the actual attacker or prevent her from making future attacks on you. Second, if a successful attack can be waged using only a few hundred or even a few thousand hosts, yet the attacker can gain access to 400,000 hosts, she can simply cycle through attack networks and force the victim to repeat the traceback and flood mitigation steps. Because these actions occur on human timescales today, the attacker would consume not only computer resources of the victim, but also human resources. Even at future automated speeds, the difficulties and costs of dealing with this sort of cycling attack could be serious. Having some kind of understanding of how a particular attack is being waged would help the victim to know when such a tactic is in use and to adjust its response accordingly.
2011
2012Service Differentiation
2013As mentioned above, some of the protection approaches can be engaged dynamically, when an attack is detected, to provide differentiated service to those clients who can prove their legitimacy. A dynamic deployment strategy has an advantage over static deployment, as operational costs are paid only when needed. There is an additional advantage in cases when the protection approach requires software changes at the client side. Were such approaches engaged statically, the server would lose all of its legacy clients. With dynamic engagement, legacy clients are impacted only when the attack is detected, and even then the effect is degradation of their service, since the protection mechanism favors those clients that deploy software changes. As the attack subsides, old service levels are restored.
2014
2015Source validation approaches can be used to differentiate between preferred and ordinary clients, and to offer better service to the preferred ones during the attack. Proof-of-work approaches can be engaged to challenge users to prove their legitimacy, and resources can be dedicated exclusively to users whose legitimacy has been proven during the attack.
2016
2017Chapter 6. Detailed Defense Approaches
2018We have seen how DDoS attacks are waged, starting with the first phase (recruitment of a large number of hosts through remote compromise and establishment of a command and control coordination infrastructure), then moving into the second phase, the actual DDoS attacks (wielding this set of refitted attack computers to implement a series of debilitating attacks on various network-attached computer systems).
2019
2020In Chapter 5, we saw a high-level view of defense tactics that addresses both of these two phases. Right away it should start to become clear that there simply is no single "solution" that addresses both of these phases. There cannot be a single solution to such a diverse set of problems. There is, instead, an overlapping set of "solutions" (plural) that must be woven together in order to address all aspects of information assurance: the goals of integrity, availability, and confidentiality of information systems by operational implementation of protection, detection, and response capabilities.
2021
2022
20236.1. Thinking about Defenses
2024Some of the defense approaches discussed in Chapter 5 are available for deployment in real networks today, as part of open source security applications and practices, as well as commercial DDoS defense systems. Other approaches are still being examined through research prototypes and simulations and are not available for immediate deployment. But the DDoS threat is here today and must be countered. What can you do to make your networks less susceptible to DDoS attacks? If your site is being used to attack someone else, how do you detect this and respond? And if you are a victim of such an attack, what can you do with the technology and tools available today to minimize your damages?
2025
2026While the problem of defending against all possible DDoS attacks is indeed extremely hard, the majority of the attacks occurring today are very simple. The reason for this is the lack of awareness of the DDoS threat in many potential target networks, the poor level of preparation, and the absence of even simple defense measures. Since many potential targets are "sitting ducks," there is no need for sophistication—simple attacks do as much damage and they are easily performed. A typical DDoS attack today can be quickly foiled by a few timely preparations, the use of some available tools, and quick intelligent action by network operations staff. All three components are necessary to achieve effective defense. Preparations close obvious security holes and minimize reaction time when the attack occurs, supplying already devised response procedures. Commercially available or homegrown DDoS defense tools fend off known or simple attacks. Informed and well-trained network staff are required to deal with stealthy attacks that bypass the first two defense measures.
2027
2028This chapter gives you some guidelines on how to avoid falling prey to the gardenvariety DDoS attacks being launched today, and also tells you what to do if you do become the victim of a DDoS attack. Even though attackers are constantly improving their strategies, the defense measures described here will always improve your survival chances.
2029
2030This book alone is not enough. In fact it is just the beginning of a long path of learning the tools and tactics of those who would attack you, and developing all the necessary skills—both technical skills with defensive tools and strategic and tactical thinking skills—that will allow you to operate within your attacker's "OODA loop" [Boy] and gain the upper hand in an attack (as mentioned at the end of Chapter 4). Other resources that you may wish to consult in learning the tools and techniques of both attackers and responders include [Hon04], with chapters on Unix forensics, Windows forensics, network forensics, and reverse engineering; [Naz03] on strategies against worms with details on the relationship between worms and DDoS, as well as both network- and host-based detection and defense strategies that are shared with DDoS tools; [Bej04] on network security monitoring, which covers a plethora of network traffic analysis tools and techniques; and [Car04] describing Windows forensics tools and techniques in great depth, including tools written by its author.
2031
2032In this chapter we will also mention many Unix and Windows commands and settings. Having on hand a good book on system administration and system tuning for your particular flavor of Unix or Windows, your routing hardware, etc., would also be advisable. You should also ask the vendors of your hardware and software products about security-specific resources they produce. Many vendors have security sections of their Web page that include security tools, online documents covering secure implementation and management practices, security feature lists and comparisons, and even multimedia security training CD-ROMs or DVDs.
2033
2034While the majority of attacks are simple, there are still the more advanced attacks that must be dealt with, and these are occurring at a higher frequency due to advanced attack tools like Phatbot. Phatbot is an advanced "blended threat" that includes a vast array of features, which are described in detail in Chapter 4. Networks of tens of thousands of hosts can be easily set up, and detection and cleanup of these bots can be very difficult. Training, the use of network flow monitoring (or DDoS mitigation) tools, the information provided in this chapter, the books referenced above, and some practice will allow your site to deal with this threat.
2035
2036DDoS defense is an arms race—new attacks produce better defenses, which in turn entice attackers to work harder. In the future, your network may need new defense mechanisms, but the ones presented in this chapter will never be obsolete. Consider them as the foundation of your resilience to DDoS attacks. Without these, sophisticated defense mechanisms you may purchase will be like a fancy roof on a house without a solid foundation—decorative, but providing little real protection.
2037
2038As discussed in Chapter 5, the design of an effective DDoS defense involves several very hard challenges. A defense system must be able to differentiate between legitimate and attack traffic, so that its response can be selective. In simple attacks, the traffic is generally somewhat differentiable from legitimate traffic, but you must be prepared to find those differences, either manually or automatically. You must strike a balance between gathering enough information to characterize the attack and not overloading your logging and analysis capabilities.
2039
2040Another obstacle to designing an effective defense is the variability of the threat. A good defense system must catch the majority of the attacks, while yielding low levels of false alarms. Nothing forces attackers to generate one type of packets, or use specific packet contents, limit spoofing to certain addresses or generate packets of only a certain length, or to set an "evil bit" [Bel03] in the header of their packets to warn firewalls that these are malicious. Anything is fair game, as long as it seems legitimate, or is simply too much to handle. In particular, if you stop a DDoS attack based on one type of traffic, an observant attacker might—and in many cases will—switch to another, or may even mix or randomize her attack. Be prepared to alter your defenses accordingly.
2041
2042The distributed nature of the threat makes localized solutions ineffective against some possible attacks. However, these solutions are still very effective against many real-world attacks. In practice, with today's technology most available defenses must be located close to the victim. Pushing the defenses further into the Internet core and closer to the attack sources potentially reduces collateral damage, but does not fit today's typical business models for deploying network defenses. Remote networks are generally unwilling to deploy systems that do not bring them direct benefit. Furthermore, since the attack is distributed, many deployment points may be needed to handle it completely. Enforcing wide deployment of any service in the Internet is infeasible in the short term. If the service is cooperative, such as tracing attack packets, this also raises policy issues [Lip02].
2043
2044Defensive systems located near the target can themselves be easily overwhelmed by a sufficiently large attack. Consider how much traffic your defense system can handle when determining if it will be sufficient for your needs, since any attacker who exceeds this capacity is likely to be successful, regardless of the sophistication and power of your defenses. To assist in constructing a layered defense, there are many common practices and defense techniques that have been very effective in increasing resilience to attacks, handling specific attack types, and minimizing damages. The report of the Distributed-Systems Intruder Tools Workshop [CER99] held in 1999 gives a useful listing of best security practices for managers, system administrators, Internet Service Providers (ISPs) and incident response teams.[1] There are simple and straightforward steps you can take to fortify your network and make it robust and self-contained, so that it does not become easy prey. There are monitoring techniques that help you discover if you are a victim or a source of DDoS attack. If you have prepared in advance, there are approaches that will weather many DDoS attacks and minimize your damages. A determined attacker with a lot of time and resources may still be able to hinder your operation, but it will be much harder.
2045
2046[1] While this document was created in 1999, it was written carefully to avoid becoming dated quickly. In most venues where DDoS is discussed, many of the questions that come up from audience members are answered by this document. It is still viable as a starting point for anyone wanting to understand the complexity of DDoS and how to respond to it in the short, medium, and long term.
2047
2048
20496.2. General Strategy for DDoS Defense
2050Regardless of whether your site is the victim of a DDoS attack, is being used as a stepping stone by attackers to anonymize their activity, or is hosting DDoS agents or handlers, the general defense strategies are the same. These strategies tend to fall into the classic Protect, Detect, and React categories, mirroring the general incident response life cycle [CERc, HMP+01]:
2051
2052Preparation. It is important to understand how your network operates and have tools in place to perform both host- and network-level data capture and analysis, have procedures established in advance, and practice using the tools. Many preparation techniques that aim at understanding and strengthening your network will, in fact, protect you against simple attacks.
2053
2054Detection. Not all attacks will cause your network to fail, so if complete failure is the only way to know when a problem exists, only the most severe problems will be detected and a larger percentage of incidents will go completely unrecognized. These unrecognized incidents can still be harming your operations and may also serve as a sign that you have an enemy out to get you. If he fails now, he might improve his attack and succeed later. Measures should be in place to detect a range of activities, with logs kept for a sufficient period of time to support forensic analysis tasks. Flow logging, for example, can also be used to detect stepping stones and multiple-system intrusions, and deal with a host of serious attacks on your network (we will discuss one tool, SiLK, in a moment). Intrusion Detection Systems (IDSs) can also add to the visibility of malicious activity on the network, and can be tuned in an emergency to watch for specific aspects of DDoS networks (e.g., command/control traffic, use of specific protocols or ports, or connections to/from specific suspect network blocks) [ACF+99].
2055
2056Characterization. It often does not take very much captured traffic to determine the kind of DDoS tool in use. Many analyses exist of common tools [Ditf, Dith, CERb, Ditg, CER01b, DWDL, DLD00], which can guide incident response teams in understanding the role being played by hosts on their network, how the DDoS network functions, and how to efficiently communicate and cooperate with other sites. While removing agents from a specific network definitely helps DDoS response, the ultimate goal of characterization is to learn and share as much information about the attack as possible to help bring the entire DDoS network down. Any delay in gathering evidence and communicating it to law enforcement or other incident response teams and network providers can magnify the duration and significance of the damage inflicted by the attack.
2057
2058Another aspect of characterization is to determine where the attack appears to be coming from. It may not be possible to trace the attack all the way back to even one of the agents, but it should be possible to trace the attack to ingress or egress points of your network and perhaps to peers or your upstream providers (or downstream customers, if you are an ISP). Provide the outside entities with as much of the information you have gathered to characterize the attack as possible, to help them do their own traceback and mitigation. They may be in a better position to get closer to the attacker, and this is critical information for law enforcement to use in their investigation, should it come to that.
2059
2060Reaction. Your reaction may be to block traffic to stop the attack, identify compromised hosts and gather evidence, and do forensic analysis, or invoke contingency plans for dealing with a severe network outage. Having established procedures makes reaction easier and faster in a time of crisis, as well as establishing standards for investigation, documentation, and reporting. As mentioned earlier, use of detection capabilities to augment reaction will also produce a better result.
2061
2062Postmortem analysis. After the attack, it is very important to review whether your procedures did or did not work, how well your network provider responded, which tools provided the best or worst assistance in responding, etc. Make sure that you integrate these lessons learned back into procedures, training of staff, and contract language for your provider. Do your best to understand how severe this attack was in relation to what it could have been, to identify potential weaknesses in your planning and mitigation procedures.
2063
2064We will now look more closely at the tactics involved in preparing for and responding to DDoS attacks.
2065 Previous Section < Day Day Up > Next Section
2066
20676.3. Preparing to Handle a DDoS Attack
2068As in any risk management activity, preparation is crucial. Understanding how your network is organized and how it works will help you identify weak spots that may be a target of the attack. Fortifying those weak spots and organizing your network to be robust and self-contained will hinder most simple attacks and minimize the damage that can be inflicted. Finally, preparing emergency procedures, knowing your contacts, and having multiple ways to reach them (including out-of-band, in terms of your network), will enable you to respond quickly to an ongoing attack and improve your chances of weathering it.
2069
20706.3.1. Understanding Your Network
2071The DoS effect usually manifests itself through large network delays and loss in connectivity. Depending on the targeted resource, your whole network may experience a DoS effect, or only specific services, hosts, or subnetworks may be unavailable. Understanding how your network functions will aid in risk assessment efforts by establishing:
2072
2073How important network connectivity is in your daily business model
2074
2075How much it would cost to lose it
2076
2077Which services are more important than others
2078
2079The costs of added latency, or complete loss of connectivity, to your key services
2080
2081Most businesses today rely on the public Internet for daily activities, such as e-mail, ordering supplies online, contacting customers, videoconferencing, providing Web content, and voice-over-IP services. Some of those activities may be critical for the company's business, and may have no backup solutions. For instance, if supplies are ordered daily and must be ordered through online forms, or your company uses "voice-over-IP" exclusively for all business telephone calls, losing network connectivity may mean stalling the business for a few days. Other activities may have alternatives that do not require Internet access—e-mails can be replaced by telephone calls, videoconferencing by conference calls or live meetings; some activities can even be postponed for a few days. In this case, Internet access increases effectiveness but is not critical for business continuity.
2082
2083Some companies make their profit by conducting business over the Internet. Take, for example, a company that sells cat food through online orders. Certain products or services are at a higher risk of loss due to even short-duration DDoS attacks. These include:
2084
2085Products with a short shelf-life that must be sold quickly, such as flowers or specialized holiday foods
2086
2087Commodities that could easily be obtained from many sources, so customers would simply leave and go somewhere else if they cannot get immediate access, such as pornography
2088
2089Time-critical transactions, such as betting on sports events, stock trading, mortgage applications, news delivery and major media events, and event or transportation ticket sales
2090
2091Low-margin, high-volume purchases that require a constant transaction rate to maintain viability of the business, such as major online booksellers and airline ticket services
2092
2093Businesses that offer free services supported by advertising, such as search engines and portals
2094
2095Network connectivity is a crucial asset in these business models, and losing connectivity means losing daily revenue (possiblya a lot of it). Additionally, if a company is well known, the fact that it was out of business for even a few hours can make headline news and damage its reputation—a fact that may lose them more business than a few hours of network outage.
2096
2097The first step in risk assessment is making a list of business-related activities that depend on constant Internet access. Each item on the list should be evaluated for:
2098
2099Alternative solutions that do not require Internet access
2100
2101Frequency of the activity
2102
2103Estimated cost if the activity cannot be performed
2104
2105In addition to costs relating directly to loss of connectivity, there may be hidden costs of a DDoS attack from handling extreme traffic loads, or diverting staff attention to mitigate the problem. In some cases, diverting attention and/or causing disruption of logging is a prime motivation of some DDoS attacks, overwhelming firewall or IDS logging to blind the victim to some other attack, or allowing a blatant action to go unnoticed. An attacker who wants to slip in "under the radar" can do so better if the radar screen is filled with moving dots.
2106
2107For example, a DDoS attack may fill your logs. Logging traffic may amplify the DoS effect, clogging your internal network with warning messages. Understanding how your logging is set up will help you identify hot spots ahead of time and fortify them, for instance, by providing for more log space or sending log messages out of band.
2108
2109Sophisticated DDoS attacks may manifest themselves not as abrupt service loss but as a persistent increase in incoming traffic load. This may lead you to believe that your customer traffic has increased and purchase more assets for handling additional load. Imagine your (or your stockholders') disappointment when the truth finally becomes clear. You may be paying for something that is not even necessary due to the way your ISP charges you. If you pay per byte of incoming bandwidth, this cost will skyrocket in such a subtle, slowly increasing attack. Some ISPs will be willing to waive this cost, but others will not. Whether they do may depend on how long the situation existed before you noticed it. Understanding how conditions of your service agreement apply to the DDoS attack case ahead of time will enable you to negotiate the contract or change the provider. Other hidden costs include increased insurance premiums and legal costs for prosecuting the attacker. If your assets are misused to launch the attack on someone else, you may even face civil liability.
2110
2111Once critical services are identified, it is important to understand how they depend on other services. For instance, e-mail service needs DNS to function properly. If e-mail is deemed critical, then DNS service is also critical and must be protected.
2112
21136.3.2. Securing End Hosts on Your Network
2114Preparation for dealing with both phases of DDoS attacks starts with addressing end-host security issues. These include reducing vulnerabilities that could result in compromise of systems, and tuning systems for high-performance and high-resilience against attack.
2115
2116Reducing Vulnerabilities on End Hosts
2117While the most common strategy for creating the DoS effect is to generate excess traffic, if the target host has a software vulnerability, misusing it may take only a few packets that shut down the host and effectively deny service with much less effort and exposure to the attacker. There are many attacks that function this way. Additionally, all techniques for acquiring agent machines are based on exploiting some vulnerability to gain access. Fixing vulnerabilities on your systems not only improves your security toward many threats (worms, viruses, intrusions, denial of service), it also makes you a good network citizen who will not participate in attacks on other sites.
2118
2119It is not uncommon today for applications and operating systems that run on end hosts and routers to have bugs that require regular patching and upgrading. Many vendors have an automatic update system to which you can subscribe. This system will inform you when new vulnerabilities have been discovered, and it will usually deliver patches and updates to your hosts, ready to be installed. For example, Microsoft maintains a Windows update Web site (http://www.windowsupdate.com) where users can have their machines scanned for vulnerabilities and obtain relevant patches and updates. Users subscribing to automatic Windows updates would have them delivered directly to their computer. Red Hat, a commercial Linux distributor, maintains a Web site with security alerts and bug fixes for current products at http://www.redhat.com/apps/support/errata/. Users can subscribe for automatic updates at http://www.redhat.com/software/rhn/update/. Other desktop systems, such as MacOS, also offer software update services.
2120
2121Virus detection software needs to be frequently updated with new virus signatures. In many cases this can help detect and thwart intrusion attempts on your hosts and keep your network secure. Each major virus detection product comes with an option to enable automatic updates. If you enable this option, new virus signatures will be automatically downloaded to your machine. However, any kind of automatic action may inflict accidental damage to your computer because of incompatibility between the update and other installed software, or may be subverted by an attacker to compromise your computer. Automatic features should be carefully scrutinized and supported by a form of authentication and by backups and extra monitoring to quickly detect and react to failures.
2122
2123Some protocols are asymmetric; they make one party commit more resources than the other party. These protocols are fertile ground for DDoS attacks, as they enable the attacker to create a heavy load at the target with only a few packets. The TCP SYN attack, discussed in Chapter 4, is one example, based on filling the victim's connection table.
2124
2125A modification of the TCP protocol, the TCP syncookie [Ber] patch (discussed in more detail in Chapter 5), successfully handles this attack by changing connection establishment steps so that server resources are allocated later in the protocol. This patch is compatible with the original protocol: Only the server side has to be updated. Linux, FreeBSD, and other Unix-based operating systems have deployed a TCP syncookie mechanism that can be enabled by the user (it is disabled by default). For instance, to enable TCP syncookies in Linux you should include "echo 1 > /proc/sys/net/ipv4/tcp_syncookies" in one of the system startup scripts. WindowsNT protects from SYN flood attacks by detecting the high number of half-open connections and modifying the retransmission and buffer allocation behavior, and timing of the TCP protocol. This option can be enabled by setting the parameter value HKLMSystemCurrentControlSetServicesTcpipSynAttackProtect in the System Registry to 1 or 2. FreeBSD implements syncookie protection by default, but if you wanted to control this setting, you would use "sysctl -w net.inet.tcp.syncookies=1" to enable it.
2126
2127An authentication protocol is another example of an asymmetric protocol. It takes a fairly long time to verify an authentication request, but bogus requests can be generated easily. Potential solutions for this problem involve generating a challenge to the client requesting authentication, and forcing him to spend resources to reply to the challenge before verifying his authentication request. Unfortunately, this requires clients to understand the challenge/response protocol, which might not always be possible. Other alternatives are to consider whether you really need to authenticate your clients or to perform a stepwise authentication by first deploying weak authentication protocols that provide for cheap verification and then deploying strong ones when you are further along in your interactions with the client. If you have a fixed client pool, a reasonable alternative is to accept authentication requests only from approved IP source addresses. In any case, strengthening your authentication service by providing ample resources and deploying several authentication servers behind a load balancer is a wise decision. Understanding how the protocols deployed on your network function, and keeping them as symmetric as possible, reduces the number of vulnerabilities that can be misused for DDoS attack.
2128
2129Many operating system installations enable default services that your organization may never use. Those services listen on the open ports for incoming service requests and may provide a backdoor to your machine. It is prudent to disable all but necessary services by closing unneeded ports and filtering incoming traffic for nonexistent services. For instance, if a host does not act as a DNS server, there is no need to allow incoming DNS requests to reach it. This filtering should be done as close to the end host as possible. For example, ideally you would filter at the host itself, using host-based firewall features (such as iptables or pf on Unix systems or personal firewall products on Windows or MacOS). This is the easiest place, resource-wise, to do the filtering but has implications if you do not control the end hosts on your network. Filtering at the local area network router (i.e., using a "screened subnet" style of firewalling) would be a good backup and is one way of implementing a robust layered security model. If your network has a perimeter firewall (which is not always the case), traffic can be blocked there as well. Trying to block at the core of your network, or at your border routers, may not be possible if your network design does not provide for sufficient router processing overhead (and this also violates the spirit of the end-to-end network design paradigm). To discover services that are currently active on your hosts, you can look at list of processes or a list of open ports or do a ports can using, for instance, the nmap tool—an open source vulnerability scanner freely downloadable from http://www.insecure.org/nmap/index.html. If you opt for port scanning, be advised that some types of scans may harm your machines. Inform yourself thoroughly about the features your port scan tool of choice supports and use only the most benign ones that do not violate protocols and scan at moderate speed.
2130
2131Many DDoS attacks employ IP spoofing, i.e., faking the source address in the IP header to hide the identity of actual attacking agents. This avoids detection of the agent and creates more work for the DDoS defense system. It is a good security measure to deploy both ingress and egress filtering [FS00] at your network perimeter to remove such spoofed packets. (Because "ingress/egress filtering" can be a confusing concept, please refer to the descriptions in Chapter 4 and Appendix A.) As seen by an edge network, antispoofing egress filters remove those outgoing packets that bear source addresses that do not belong to your network. The equivalent ingress filters similarly remove those incoming packets that bear source addresses that belong to your network. Both of those packet address categories are clearly fake, and many firewalls and routers can be easily configured to perform ingress/egress filtering (as well as other types of filtering). Advanced techniques for elimination of spoofed addresses include detecting source addresses from those network prefixes that are reserved and filtering them from your input stream, or using a list of live internal network addresses to allow only their traffic to get to the outside world.
2132
2133In general, fixing vulnerabilities raises the bar for the attacker, making him work harder to deny service. It protects your network from specific, low-traffic-rate attacks. In the absence of vulnerabilities that could quickly disable network services, the attacker instead must generate a high traffic rate to overwhelm your resources.
2134
2135Tuning System Parameters
2136Beyond just fixing vulnerabilities, one of the first things that should be done in cases in which a DDoS attack is affecting a service or end system—but is not large enough to cause noticeable network disruption—is to ensure that the target of the attack is adequately provisioned and tuned. Even in cases in which DDoS mitigation tools are in place at the perimeter of your network, and are functioning as they should to scrub incoming packets and ensure that only "legitimate" requests are coming in, the server may still be overwhelmed and cease to function.
2137
2138Examples of things to look for include:
2139
2140Processor utilization. Programs like top, ps, and vmstat are useful for checking processor utilization. The uptime program also shows processor load averages. If those programs indicate a single application that is consuming an unusually high amount of CPU time (e.g., 90%) this may be a vulnerable application targeted by a DoS attack. You will need to keep a model of normal CPU utilization to quickly spot applications gone wild due to vulnerability exploits or specifically crafted attacks.
2141
2142Disk I/O performance. Disk I/O performance can be determined using programs like vmstat, iostat, and top. If you are using NFS, the nfsstat program should be used. Tuning of IDE drives can be accomplished on Linux systems using hdparm. If disk-monitoring programs, such as iostat, indicate unusually high disk activity, this may be a vulnerable application under attack. Again, you will need a model of normal disk activity to be able to spot anomalies.
2143
2144Network I/O performance. If the network interface is saturated or there are other problems on the Local Area Network (LAN) segment, you may see dropped packets or a high rate of collisions. You can see these using the statistics option of netstat. Network socket state information can also be seen with netstat. If netstat indicates that you are experiencing a significant number of dropped packets and collisions when no attack is under way, then you are already running close to capacity. An attacker can tip you over into an overload situation by adding a rather small quantity of traffic. You need to improve the bandwidth on the highly utilized links if you want to avoid falling easy prey to DDoS. This observation is most important for those links that are publicly accessible. A fairly congested link on a purely internal LAN that does not directly accept traffic from the outside network is less of a risk for a DDoS attack than the same situation on the main link between your subnetwork and your ISP.
2145
2146Memory utilization. If memory is low, use ps and top to determine which programs have the largest Resident State Sizes (RSS). You may need to kill some of them off to free up memory. Memory is very cheap these days, so make sure that you have as much as your motherboard and budget can afford. If you cannot increase memory, yet still have problems with memory utilization, consider upgrading your hardware.
2147
2148Swapping/paging activity. Paging is a normal activity that occurs when portions of a program that are necessary for execution must be brought in from disk. Swapping occurs when physical memory is low and least-recently used pages of programs are written out to disk temporarily. Because disk speed is far slower than memory, any reading or writing of the disk can have significant performance impacts. You can check on paging and swapping activity and swap utilization using vmstat, top, or iostat.
2149
2150Number of server processes. Web servers typically have one process responsible for listening for new connections, and several child processes to handle actual HTTP requests. If you have a very high rate of incoming requests, you may need to increase the number of server processes to ensure that you are not overloading the existing processes and delaying new requests. Use top, ps, and netstat to check for overloading of server processes.
2151
2152Tuning system parameters will help protect your network from small- to moderaterate attacks, and in-depth monitoring of resource usage should ensure better detection of attacks that consume a large amount of resources.
2153
21546.3.3. Fortifying Your Network
2155In addition to securing the hosts on your network, there are also things you should do to improve the security of the network as a whole. These include how the network is provisioned and how it is designed and implemented.
2156
2157Provisioning the Network
2158A straightforward approach to handle high traffic loads is to buy more resources, a tactic known as overprovisioning. This tactic is discussed in detail in Chapter 5. There are many ways in which overprovisioning can be used to mitigate the effects of a DDoS attack.
2159
2160The problem here, from a cost perspective, is the asymmetry of resources. There is very little or no cost for an attacker to acquire more agent machines to overwhelm any additional resources that a victim may employ, while the victim must invest money and time to acquire these added resources. Still, this technique raises the bar for the attacker and will also accommodate increased network usage for legitimate reasons.[2]
2161
2162[2] For instance, overprovisioning can help in the case of "flash crowds," when some popular event motivates many clients to access your network simultaneously.
2163
2164One form of overprovisioning has to do with available network bandwidth for normal traffic. This approach is taken by many large companies that conduct business on the Internet. The attacker looking to overwhelm your network with a high traffic load will either target the network bandwidth by generating numerous large packets of any possible type and contents, or he will target a specific service by generating a high number of seemingly legitimate requests. Acquiring more network bandwidth than needed is sometimes affordable, and makes it less likely that bandwidth will be exhausted by the attack. A smartly configured network-level defense system sitting on this highly provisioned link will then have a chance to sift through the packets and keep only those that seem legitimate
2165
2166Another form of overprovisioning is to have highly resourced servers. This can be (1) keeping hosts updated with the fastest processors, network interfaces, disk drives, and memory; (2) purchasing as much main memory as possible; or (3) using multiple network interface cards to prevent network I/O bottlenecks. Further, duplicating critical servers and placing them in a server pool behind a load balancer multiplies your ability to handle seemingly legitimate requests. This may also prove useful for legitimate users in the long run—as your business grows your network will have to be expanded, anyway. Performing this expansion sooner than you may otherwise plan also helps withstand moderate DDoS attacks.
2167
2168These two forms of overprovisioning can be combined in a holistic manner, ensuring fewer potential bottlenecks in the entire system. In the electric sector, for example, sites are required to have nominal utilization rates for the entire system that are no larger than 25% of capacity, to provide an adequate margin of unused processing capacity in the event of an emergency. This minimizes the chances that an emergency situation causes monitoring to fail, escalating the potential damage to the system as a whole.
2169
2170If your network management and communication to the outside world is done in-band over the same network as potential DDoS targets, (e.g., if you use voice-over IP for your phone line), the DDoS attack may take out not only your services, but all means of communicating with your upstream provider, law enforcement, vendors, customers—in short everyone you need to communicate with in a crisis. The added cost of purchasing extra bandwidth can be viewed as a cheaper form of insurance.
2171
2172Designing for Survivability
2173Since some DoS attacks send a high amount of seemingly legitimate requests for service, techniques that improve scalability and fault tolerance of network services directly increase your ability to weather DDoS attacks. Designing for survivability means organizing your network in such a way such that it can sustain and survive attacks, failures, and accidents (see [EFL+99, LF00]). Sometimes, adding survivability provisions has surprising benefits in protecting against unexpected events [Die01].
2174
2175Survivability design techniques include:
2176
2177Separation of critical from noncritical services. Separating those services that are critical for your daily business from those that are not facilitates deployment of different defense techniques for each resource group and keeps your network simple. Separation can occur at many levels—you can provide different physical networks for different services, connect to different service providers, or use subnetting to logically separate networks. A good approach is to separate public from private services, and to split an n-tier architecture into host groups containing Web servers, application servers, database servers, etc. Once resources are separated into groups, communication between resource groups can be clearly defined and policed, for instance, by placing a firewall between each pair of groups.
2178
2179Segregating services within hosts. Rather than assigning several services to a single host, it is better to use single-purpose servers with well-defined functionality.
2180
2181As an example of segregated services, having a dedicated mail server means that all but a few ports can be closed to incoming traffic and only a few well-defined packet types should be exchanged between the server and the rest of the network. It also means that monitoring server operation and detecting anomalies will be simplified. Having several services assigned to a single host not only makes monitoring and policing difficult, but finding and exploiting a vulnerability in any of these services may effectively deny all of them.
2182
2183An advanced alternative for segmenting services that addresses just the issue of process separation is to use highly secure operating systems such as SELinux or TrustedBSD which implement Mandatory Access Control (MAC) for processes.[3] This will not help very much for DDoS mitigation, however, unless these systems are also configured not just to use MAC, but to also limit particular services to maximum usage of particular system resources. If both a DNS service and a Web server are run on such a machine and the Web service receives many seemingly legitimate requests that take a long time to process, MAC will state that all of them should get service. After all, the Web server must be permitted to do such things in its legitimate operations. Only enforcement of QoS guarantees for the DNS server by the OS can prevent the Web requests from eating up all the machine's resources and starving the DNS server.
2184
2185[3] Such systems are not yet commonly used by businesses, as their policy management aspects and debugging are quite complicated, so they will not be covered here. Still, you should watch for them to start making inroads in commercial and open-source operating system offerings in the next few years.
2186
2187Compartmentalizing the network. Identifying bottlenecks in the risk assessment step should provide guidelines for reorganizing the network to avoid single points of failure. Dividing the network into self-contained compartments that communicate with the outside only when necessary enables your business to continue operation even when some portions of the network are down. For example, having a database server distributed across several physically disjoint networks that connect to the Internet via different ISPs may require a lot of management, but may enable you to continue serving database requests even if several servers are targeted by the attack or their incoming links are overwhelmed. Having a mail server for each department may mean that when the finance department is under attack, employees from the planning division can still send and receive e-mails. As always, decisions about which services to replicate and to what extent demand detailed cost/benefit analysis.
2188
2189Reducing outside visibility. If attackers are able to learn your network organization, they can also assess the risks and identify bottlenecks that can be targeted by the attack. There are numerous techniques that aid in hiding the internals of your network. Blocking ICMP replies to outside hosts prevents attackers from learning your routing topology. Using a split DNS effectively creates two separate DNS zones for your network with the same DNS names. One zone will contain a list of externally visible services that can be accessed through the firewall. Your external DNS server will serve this zone. Your external customers will be able to access only the external DNS server and will see only this list of services. Another zone will contain a list of internally accessible services that are available to your employees. This zone will be served by your internal DNS server. Your employees' machines will be configured with the address of the internal DNS server and will access these services through your internal network. Separating this information minimizes the data you leak about your internal network organization. It also provides separate access paths for external and internal clients, enabling you to enforce different policies.
2190
2191Network Address Translation (NAT) hides the internals of the network by providing a single address to the outside clients—that of the firewall. All outside clients send their requests for service to the firewall, which rewrites packets with address of the internal server and forwards the request. Replies are similarly rewritten with the firewall's address. This technique creates a burden on the firewall and may make it a single point of failure, but this problem can be addressed by distributing firewall service among several routers. Generally, if attackers can only see a large, opaque network, they must either attack the ingress points (which are probably the most capable and highly provisioned spots, and thus the easiest to defend) or use e-mail or Web-based attacks to gain control of a host inside the perimeter and tunnel back out.
2192
21936.3.4. Preparing to Respond to the Attack
2194Having a ready incident response plan and defense measures that you can quickly deploy before the attack hits will make it easier to respond to the attack. Further, knowing who to contact for help will reduce your damages and downtime.
2195
2196Responding to the attack requires fast detection and accurate characterization of the attack streams so that they can be filtered or rate limited. Devising detailed monitoring techniques will help you determine "normal" traffic behavior at various points in your network and easily spot anomalies. Detection, characterization, and response can be accomplished either by designing a custom DDoS defense system or by buying one of the available commercial products.
2197
2198You should choose wisely how you configure and use a DDoS defense mechanism. For example, if you choose to make its actions fully automated, an attacker may be able to exploit the unauthenticated nature of most Internet traffic (at least traffic that does not use IPSec Authentication or Encapsulation features) to trick the DDoS defense system into acting incorrectly and producing a DoS effect that way. Assume an attacker knows that your site uses a DDoS defense mechanism that does not keep state for UDP flows, and that you have it configured to automatically block inbound UDP packet floods. She also knows that many of your users frequent Web sites that rely on some company's distributed DNS caching service. The cache provider has thousands of DNS servers spread around the Internet, which the attacker can determine by having her bots all do DNS lookups for the same sites and storing the results. DNS typically uses UDP for simple requests. Putting these facts together, the attacker could forge bogus UDP packets with the source address of all of the DNS caching service's servers, sending them all to random IP addresses at your site. Depending on how the DDoS defense system is programmed, it might assume that this is a distributed UDP flood attack and start filtering out all UDP traffic from these thousands of "agents" (really the caching DNS servers), preventing your users from getting to any Web sites served by this DNS cache provider, because their DNS replies are blocked as they come back.
2199
2200Fully manual operation has its own problems. The reaction time can be significantly slowed, and in some cases slow defense may cause more problems than it solves. The network operations and security operations staff should both well understand the capabilities and features of the DDoS mitigation system and how best to deploy and control it. Appendix B offers a detailed overview of some currently available commercial products. This should serve only as an introduction to a wide variety of security products that are currently available. The reader is advised to investigate the market thoroughly before making any buying decisions.
2201
2202Creating your own DDoS defense system generally makes sense only for large organizations with sophisticated network security professionals on staff. If your organization has those characteristics, a careful analysis of your system's needs and capacities might allow you to handcraft a better DDoS solution than that offered by a commercial vendor. Building a good defense solution from scratch will be an expensive and somewhat risky venture, however, so you should not make this choice lightly. If you do go in this direction, make sure you have a thorough understanding of all aspects of your network and systems and a deep understanding of DDoS attack tools and methods, as well as the pros and cons of various defensive approaches.
2203
2204It is also important to balance the requirements of the network operations and security operations staff. Many sites separate these groups, often having an imbalance of staffing and resources dedicated to building and supporting the complex and expensive network infrastructure vis-Ã -vis handling security incidents and mitigation at the host level. Having these groups work closely together and share common goals improves the situation and causes less internal friction.
2205
2206Many sites with large networks and high bandwidth costs are now purchasing or implementing traffic analysis tools, but often more with an eye toward cost containment and billing, as opposed to security. When an attack occurs, there is sometimes a distinct issue of not having visibility below the level of overall bandwidth utilization and router/switch availability statistics. There may not be flow- or packet content–monitoring tools in place, or the ability to preserve this data at the time of an attack to facilitate investigation or prosecution. Network traffic analysis is a critical component of response. It is said that one person's DoS attack is another person's physics experiment dataset.
2207
2208There may also be a lack of tools, such as network taps, systems capable of logging packets at the network borders without dropping a high percentage of the packets, or traffic analysis programs. These tools, and the skills to efficiently use them, are necessary to dig down to the packet level, identify features of the attack and the hosts involved, etc. Many high-profile attacks reported by the press have been accompanied by conflicting reports of the DDoS tool involved, the type of attack, or even whether it was a single attack or multiple concurrent attacks. In some cases, sites have believed they were experiencing "Smurf" (ICMP Echo Reply flood) attacks inbound, because they saw a spike in ICMP packets. In fact, some host within their network was participating in an attack with an outbound SYN or UDP flood that was well within the normal bandwidth utilization of the site, and they were getting ICMP replies from the target's closed port. In other cases "attacks" have turned out to be misconfigured Web servers, failed routers, or even a site's own buggy client-side Web application that was flooding their own servers![4]
2209
2210[4] The situation of self-inflicted DoS happens more than one would think. Some victims of "DDoS attacks" have suffered costly downtime and customer complaints for hours. Their ISPs often confirm the "attack" from packet counts and flow direction information obtained from simple network-monitoring tools, but nobody gathers even a short sample of network traffic to analyze. When expensive consultants are brought in and manage to get the provider to find a way to gather network traffic, or make an on-site call to the victim's server location, it is quickly determined that the problem has to do with a software bug and the "attack" is then halted in a matter of minutes. Had the victim, or its ISP, been prepared to analyze network traffic, the event would have lasted only a brief time and had minimal cost.
2211
2212Investing in backup servers and load balancers may provide you with assets that you can turn on in case of an emergency. Backup servers can take the load off the current server pool or can supplement hosts that are crashing. Of course, there is a cost to having spare equipment lying around, and an attack may be over by the time someone is able to reconfigure a server room and add in the spare hardware. If you provide static services, such as hosting Web pages or a read-only database, it may be possible to replicate your services on demand and thus distribute the load. Service replication can even help if you deliver dynamic content. Contracting with a service that will replicate your content at multiple network locations and transparently direct users to the nearest replica provides high resiliency in case of a DDoS attack. Since these services are themselves highly provisioned and distributed, even if they are successfully attacked at one location, the other replicas will still offer service to some of your clients. The downside to such highly provisioned and distributed services is an equally high cost. This option may be viable financially for only very large sites. Very careful risk analysis and cost/benefit calculations are necessary, as well as investigation of alternatives for a disruption of business operations, such as insurance coverage.[5] Another consideration is that while replication services are highly provisioned, they may themselves be taken down by a sufficiently large attack, so this approach is not a panacea.
2213
2214[5] Without recommending specific companies, search the Web for "DDoS insurance coverage" to find some options. Credit card companies, as well as some insurance companies, are now offering such protection.
2215
2216Another alternative is to consider gracefully degrading your services to avoid complete denial. For instance, when a high traffic load is detected, your server can go into a special mode of selectively processing incoming requests. Thus, some customers will still be able to receive service.
2217
2218If the DDoS attack targets network bandwidth, no edge network defense will ameliorate the situation. Regardless of sophisticated solutions you may install, legitimate users' packets will be lost because your upstream network link is saturated and packets are dropped before they ever reach your defense system. In this situation, you need all the help you can get from your upstream ISP, and perhaps also their peers, to handle the problem.
2219
2220Cultivating a good relationship with your ISP ahead of time and locating telephone numbers and names of people to reach in case of a DDoS attack will speed up the response when you need it. Many ISPs will gladly put specific filters on your incoming traffic or apply rate limiting. Be aware of the information you need to provide in order to get maximum benefit from the filtering. Sometimes it may be necessary to trace the attack traffic and have filters placed further upstream to maximize the amount of legitimate traffic you are receiving.[6] This usually involves contacting other ISPs that will generally be unwilling to help you, given that you are not their customer. If you have a good relationship with your ISP, they will be in a far better position to negotiate tracing with their upstream peers. Specifying the responsibilities and services your ISP is willing to offer in case of DDoS attack in a service agreement will also simplify things once an attack occurs.
2221
2222[6] Filtering is usually imprecise and inflicts some collateral damage. If the route that attack traffic takes can be identified and filtering placed as much upstream as possible, this minimizes the amount of legitimate traffic passing the filter and thus minimizes the collateral damage from the response.
2223 Previous Section < Day Day Up > Next Section
2224
22256.4. Handling an Ongoing DDoS Attack as a Target
2226Handling an ongoing DDoS attack on your network requires you to detect it, characterize the attack streams, and apply mitigation techniques. Detecting the attack is usually automated either through standard network-monitoring software or through a commercial DDoS defense system. While the attack will undoubtedly be detected once your services are crippled, early detection will provide more time for response and may even make the occurrence of the attack transparent to your customers.
2227
2228Choosing a set of parameters to monitor for anomalies directly affects detection accuracy. You can choose to monitor levels of the incoming network traffic, the number of external clients with active requests (to spot the occurrence of IP spoofing), client behavior, server load, server resources, etc. A properly chosen set of parameters will not generate too many false positives, while still detecting the majority of the attacks early.
2229
2230Once detected, the attack should be characterized as narrowly as possible. This includes: identifying network protocols, applications, and hosts that the attack targets; identifying source addresses used in attack packets, packet length, contents, etc.; identifying detailed attack characteristics facilitates setup of precise filtering and rate-limiting rules. This is where the border-level network-monitoring tools and skills, mentioned in the previous section, really pay off.
2231
2232Mitigation techniques involve contacting your ISP and providing attack characteristics, and deploying filtering and rate limiting at your border routers, DMZ router, or firewall (if the target is within a perimeter defense). Predeploying load balancers and having hardware available, in an emergency, to increase server capacity can also be of use but is expensive and may take hours or days to implement (depending on where the hardware and staff are located in relationship to the network being attacked). Redirection of traffic through routing configurations may ease such topology or resource allocation changes.
2233
2234If you have purchased a commercial DDoS defense system, many of those will automatically devise appropriate filtering rules that your network operations staff can then choose to deploy. Some systems can even be instructed to respond autonomously, without human supervision. They will deploy filters and notify the system administrator after the fact. If you use one of these systems, it would be wise for your administrators to keep a careful eye on any filters that is reports deploying, both to be aware of actual attacks and to ensure that the system is not mistakenly filtering legitimate traffic, as described earlier. There is a distinct possibility that a self-inflicted denial of service could result from a skillful attack.
2235
2236Taking a close look at the attack packets may reveal weaknesses in the attack that can be used for effective response. For example, do all attack packets target the same server? If so, it may be possible to change the IP address of the server.
2237
2238Many DDoS attack tools are poorly designed and may omit DNS lookup and hardcode your server's IP address in the attack script. A simple change of IP address will cause all the attack packets to be dropped at the last hop. Then, enlisting help from your ISP, a simple filtering rule deployed upstream should completely relieve your network of the flood. ISPs can further attempt to trace back the flood and stop it at the entry point to their network.
2239
2240Realize, however, that this address mapping change technique may not work as desired if some clients have cached the mapping. This is likely to happen if the server's IP address is listed in public DNS records. Clients that have cached these records will receive a mapping to the old address that is being attacked and will thus still suffer the DoS effect. Sometimes the application itself can get around the DNS caching issue (some Web application services can do this).
2241
2242UUNET's backbone security engineers claim to have had great success using a technique they have developed, called backscatter traceback [GMR01], for tracing flood traffic with forged source addresses back to its ingress points into UUNET's network cloud. The technique leverages several "tricks of the trade" that may be adopted by other network service providers to implement a similar capability. (In a very abstract and succinct fashion, the technique works by injecting a fault into the network and observing the effects on the smallest set of traffic illustrated in Figure 6.3 as it bounces off the artificial fault.) Note that the examples provided by UUNET assume functionality provided by Cisco routers.
2243
2244The first step is to keep a black hole route ("route to Null0") installed on each of the network provider's routers so that it can be invoked quickly as needed. For example, a single IP address out of the IANA special-use prefix TEST-NET, say 192.0.2.1, can be used for this purpose, as it will never appear as a valid address in the Internet. A static route is established on each router that sends all traffic destined for 192.0.2.1 to the Null0 interface, effectively dumping the traffic. Normally, no traffic follows this route.
2245
2246The next step is to configure a BGP-speaking router so that it can be used to quickly disseminate a route update to all routers whenever the need arises to black hole a real network, whether a single address or a larger network address block. A route map is used to set the next hop of matching tagged routes to the null-routed address 192.0.2.1.
2247
2248When an address needs to be black-holed, a static route for the target address is installed on the above router with a tag that causes it to be processed by the route map. This static route will be propagated via the BGP routing protocol to the rest of the service provider's routers, who will now have Null0 as the next hop for the target address. Thus, all of the service provider's routers will be instructed to drop all traffic to the target address at all ingress points, effectively black-holing the address at the network edge. Operationally, the main feature of all this is to allow a black-hole route on all edge routers to be remotely triggered from a single control point via BGP.
2249
2250Another necessary step is to establish a sinkhole network (i.e., a router designed to withstand heavy flood traffic to which attack traffic can be redirected for study). Attached to this router should be a workstation (e.g., the sensor in Figure 6.2) of sufficient capacity to capture and analyze the redirected attack traffic.
2251
2252As mentioned above, the sinkhole BGP router advertises TEST-NET as the next hop for the target address, causing all incoming traffic destined for the target to be redirected to the Null0 interface.
2253
2254The final step is to configure the sinkhole router to advertise itself as the next hop for a block of unallocated IP address space. (UUNET recommends using 96.0.0.0/3, as it is the largest unallocated address block on the planet.) The assumption here is that the flood traffic's forged source addresses will occasionally fall within this unallocated range, as they often do when the flood tool generates packets with randomly chosen source IPs. This route is advertised to all of the service provider's other routers, constrained by BGP egress filtering to guarantee that the route does not leak outside of the service provider's realm. This causes all the service provider's routers to reflect any outbound traffic destined for the unallocated range back to the sinkhole network.
2255
2256We now describe in detail the backscatter using Figure 6.1. When attack traffic has been noticed, the service provider performs the following steps:
2257
22581. The sinkhole router is configured to advertise a new route for the target machine with a next hop of the TEST-NET host address. The route propagates via BGP to all of the other routers, causing all incoming attack traffic to be (temporarily) blackholed at the network edge. This causes the target to be completely unreachable for the duration of this analysis. In practice, UUNET has found that redirecting the target's traffic for 45 seconds is usually enough to capture sufficient evidence for a correct traceback to occur.
2259
2260
22612. Another static route is added to the sinkhole router to redirect any 96.0.0.0/3 traffic to the sinkhole network. This route is also propagated to all of the other routers.
2262
2263
22643. As the packets headed for the target, including both the legitimate packets and the spoofed attack packets, are dropped by the service provider's edge, ICMP Unreachable messages are generated by the edge routers and sent to the source addresses. This is referred to as backscatter.
2265
2266
22674. Any attack traffic entering the service provider's network with a forged source address from the 96.0.0.0/3 block will cause the edge routers to generate ICMP Unreachable messages destined for the forged source addresses in 96.0.0.0/3.
2268
2269
22705. The ICMP Unreachable messages destined for 96.0.0.0/3 will be redirected to the sinkhole network. The sinkhole network's router is configured to log incoming ICMP Unreachable messages.
2271
2272
22736. These log messages include the source address of the edge router that generated the ICMP Unreachable message (i.e., the ingress point of the flood traffic). The traceback to the service provider's ingress point(s) is now complete. Figure 6.1 shows three such ingress points. Figure 6.2 shows further traffic analysis by a sensor.
2274
2275
2276
2277The ISP now knows precisely which of its routers need to install defense measures (such as filtering or rate limiting) to control a long-term DDoS attack, while minimizing collateral damage to the victim and other nodes.
2278
2279Note that this technique relies heavily on the assumption that the distribution of the attack traffic's forged source addresses is spread randomly over the entire IP space. The technique will be thwarted by attack traffic crafted to avoid using the unallocated space being monitored by the sinkhole network. This avoidance can be mitigated by the service provider in some cases by analyzing the attack traffic for other patterns in source address distribution and redirecting a different unallocated address range accordingly. However, a clever attacker who chooses forged IP addresses only from the allocated range of IP addresses will be able to avoid this form of tracing entirely (see Figure 6.3 for an overview of traffic classes). The technique is thus imperfect, although in practice it may work successfully in the majority of cases.
2280
22816.5. Handling an Ongoing DDoS Attack as a Source
2282Since DDoS attacks occur regularly, this indicates that either agent-hosting sites do not care enough about their machines participating in attacks to bother stopping them, or the bandwidth available to these sites may be so great that they may not even notice the flooding. Sites should care, however. Being a good network citizen will make everyone's experience of the Internet better, and only if most online participants behave responsibly will the Internet continue to be useful. If that rationale does not sway you, consider that hosting an agent is a sure sign that your network has been compromised. In addition to participating in an attack on others, your own network and assets are at risk, and prudence dictates that you should investigate and clean up this problem.
2283
2284Finally, there is a growing level of discussion of liability issues surrounding due care taken by those whose sites are used for an attack. If sufficient financial damage is incurred by a victim, and if the victim can trace the attacks back to one or more sites that are primarily responsible, then those sites may get sued. The liabilities range from failing to secure one's computers from intrusion to failing to stop an attack in progress. The sites may be found negligent for not stopping an attack, regardless of whether the attack affects their own network availability. They may also be charged with obstruction of justice by destroying evidence if they have been informed of an attack and potential legal action, yet still wiped the disks of compromised hosts and reinstalled the operating system. (The topic of liability is discussed in more depth in Chapter 8.)
2285
2286The first step in handling a DDoS attack as a source is to detect that it is happening. This can in general be done by triggering an alarm whenever you notice a high outgoing traffic rate targeting a single destination or a small set of machines. While the attacker may in principle deploy numerous agent machines, instructing each of them to generate only a few packets, typical DDoS agents flood with all their might and create large traffic loads. Thus, monitoring the outgoing traffic rate for each of your machines should catch the majority of the attacks. Detecting an attempt to use IP spoofing in outgoing traffic is also a likely sign that your network is being misused for malicious purposes and requires prompt investigation.
2287
2288Even if you have set up ingress/egress filtering at your border to prevent spoofed packets from leaving your network, watching internally for spoofed packets using an IDS, a firewall, or router ACLs that counts packets, may provide an early warning of trouble.
2289
2290Your next step should be to determine how you can filter outgoing traffic to the target(s) and begin this filtering. While doing this, try to also take steps to identify agent machines, usually by monitoring various internal links. (Note that after you have placed filters on routers, you may no longer be able to use your network taps to gather any traffic, or to scan for handlers/agents.) Even a short sample of all network traffic to/from suspect hosts, or flows that have been identified by network monitoring tools as being DDoS-related, taken before you apply filters is helpful. Nobody can analyze traffic that you can no longer see, or hosts that are no longer reachable via the network. Of course, this needs to be balanced against the risk of continued damage, but if made a part of normal operating procedures for responding to a DDoS attack, it will not cause significant delays.
2291
2292In the early days of DDoS, several host- or network-based DDoS agent scanning tools were available to make the task of identifying agent machines easier. In fact, the initial DDoS analyses done by David Dittrich, Sven Dietrich, Neil Long, and others in subsequent analyses over the following years included Perl-based scripts or other mechanisms that would expose and/or control the DDoS agents. (More on the historical DDoS analyses and identification of malware using scanners is found later in this chapter.)
2293
2294The DDoS tool scanners mentioned above have their limitations, the major one being that tools they scan for are either obsolete or in use but with modified source code that will not be detected by file-system–level scanners or respond to networklevel scanners. For Windows-based DDoS tools, such as Knight/Kaiten compiled with Cygwin, anti-virus software is likely to be of more help.[7] Sophisticated tools, such as Agobot/Phatbot, use code polymorphism and other techniques to (a) avoid detection by antivirus software, (b) detect when they are run under single-step debuggers or in a virtual machine environment, and (c) disable antivirus software as one of the first steps upon infecting the host. You should not fully trust any program you run on a system that has been compromised at the administrative level.
2295
2296[7] Antivirus software should be used in a mode that does not automatically clean up and delete things, as this destroys evidence or data that you may need to help identify command and control channels on Internet Relay Chat networks, etc.
2297
2298Once agent machines are found, they need to be taken off the network, their disk drives imaged (and the images preserved as evidence), examined for the attack code, and finally cleaned. Unfortunately, many DDoS attack toolkits change system directories and data to hide the presence of the code and restart the code whenever the machine is rebooted. Locating the attack code can be a long and painful process. Steps to fully clean such machines usually involve reinstallation of the operating system, and are generally similar to the procedures for cleaning up any compromised machine.
2299
2300The bottom line here is that these tools will require careful analysis of the compromised host by a competent system administrator or incident responder who is familiar with forensic analysis as well as with anti-forensic techniques.
2301
2302The one step in the action list just given that is most often not performed is the imaging of disk drives of attacking systems. If you have done sufficient analysis of the attack traffic, as recommended here, you will know who the victim or victims are and will have some idea of whether legal action may ensue. If the victim of the attack is, say, an online retailer, media outlet, or government agency (especially a military, intelligence, space agency, or a contractor to any of those agencies), it is highly advisable to preserve evidence before cleaning any attacking hosts. These cases also warrant notification of your own organization's legal counsel, federal law enforcement agencies, and national incident coordination centers. A breakdown in timely communication of an attack, which may be national in scope, will complicate and slow down a nationallevel response. If this is a concerted attack by a terrorist organization or nation state, this failure may have national security implications.
2303
2304Regardless of the pain involved, you should clean up any agent machines in your network. Apart from helping others, cleaning up those machines increases your security. An attacker who has turned your machine into an agent has broken into this machine first. She can also steal, alter, or destroy your critical information; use your machine to provide illegal services to others; or disrupt your operation. As long as she controls your computers, you are essentially at her mercy.