5.3. Prevention versus Protection and Reaction


As 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.

5.3.1. Preventive Measures

Prevention 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.)

There 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.

Measures 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.

Hardening 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.

Hardening 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.

While 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:

  • Better 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.

  • Improvements 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.

  • Improvements 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.

  • Automated 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.

Beyond 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.

Immunity 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.

Some 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.

The 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.

5.3.2. Reactive Measures

If 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.

Reaction 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.

Unlike 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.

Reactive 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.

Regardless 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.



Internet Denial of Service. Attack and Defense Mechanisms
Internet Denial of Service: Attack and Defense Mechanisms
ISBN: 0131475738
EAN: 2147483647
Year: 2003
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net