In Part 1 (“Botnets”) and Part 2 (“DDoS Attack Strategies”) of this series, we defined botnets and described the strategies they use to conduct Distributed Denial of Service (DDoS) attacks. Upon command from its bot master, a botnet can launch a massive amount of malicious traffic directed toward a victim system. This traffic overwhelms the capacity of the victim system and effectively takes it down.
Guest article by Dr. Bill Highleyman
Various defense strategies can be invoked to defend against DDoS attacks. Many of these depend upon the intensity of the attack. We discuss some of these in this article.
Some protection from DDoS attacks can be provided by firewalls and intrusion-prevention systems (systems that monitor for malicious activity). When a DDoS attack begins, it is important to determine the method or methods that the attacker is using. The web site’s front-end networking devices and the server’s processing flow may be able to be reconfigured to stop the attack.
UDP (User Datagram Protocol) attacks send a mass of UDP requests to a victim system, which must respond to each request. One example is a ping attack. It is an enormous influx of ping requests from an attacker that requires the victim server to respond with ping responses.
Another example of a UDP attack is when the Internet Control Message Protocol (ICMP) must be used by the server to return error messages. The messages may indicate that a requested service is unavailable or that a host or router cannot be reached. An attacker may send UDP messages to random ports on the victim server, and the server must respond with a “port unreachable” ICMP message.
In the case of a UDP attack, the firewall could be configured to reject all UDP messages. True, this would prevent legitimate use of UDP messages, such as pings sent by monitoring services to measure the uptimes and response times of the web site. However, to be shown as failed by a monitoring service is much better than actually being down.
In a SYN attack, a mass of connection requests are sent to the victim server via SYN messages. Typically, the victim server will assign connection resources and will respond with SYN ACK messages. The server expects the requesting client to complete the connections with ACK messages. However, the attacker never completes the connections; and the server soon runs out of resources to handle further connection requests.
In this case, the server connection facility could be reconfigured so that it did not assign connection resources until it received the ACK from the client. This would slightly extend the time required to establish a connection but would protect the server from being overwhelmed by this sort of an attack.
DNS Reflection Attack
A DNS reflection attack allows an attacker to send a massive amount of malicious traffic to a victim server by generating a relatively small amount of traffic. DNS requests with a spoofed victim address are sent to multiple DNS systems to resolve a URL. The DNS servers respond to the victim system with DNS responses. What makes this sort of attack so efficient is that the DNS response is about 100 times as large as the DNS request. Therefore, the attacker only needs to generate 1% of the traffic that will be sent to the victim system.
DNS reflection attacks depend upon DNS open resolvers that will accept requests from anywhere on the Internet. DNS open resolvers were supposed to have been removed from the Internet, but 27 million still remain.
A defense against DNS reflection attacks is to allow only DNS responses from the domain of the victim server to be passed to the server.
Given a sufficiently large DDoSattack, even the steps mentioned here may not protect a system. If nothing else, the attack can overwhelm the bandwidth of the victim’s connection to the Internet.
In such cases, the next step is to use the services of a DDoS mitigation company with large data centers that can spread the attack volume over multiple data centers and can scrub the traffic to separate bad traffic from legitimate traffic. Prolexic, Tata Communications, AT&T, Verisign, CloudFare, and others are examples of DDoS mitigation providers.
These services will also monitor the nature of the attack and will adjust their defenses to be effective in the face of an attacker that modifies its strategies as the attack progresses.
DDoS attacks are specifically outlawed by many countries. Violators in the U.K. can serve up to ten years in prison. The U.S. has similar penalties, as do most major countries. However, there are many countries from which DDoS attacks can be launched without penalty.
With respect to the Spamhaus attack described in Part 1, the CEO of CyberBunker, a Dutch company, was arrested in Spain and was returned to the Netherlands for prosecution.
Companies must prepare for the likelihood of losing their public-facing web services and must make plans for how they will continue in operation if these services are taken down. This should be a major topic in their Business Continuity Plans. For instance, in the case of the bank attacks described in Part 1, many banks made plans to significantly increase their call center capabilities to handle customer services should their web sites be taken down by a DDoS attack.
DDoS attacks are here to stay. They are motivated by too many factors – retaliation, political statements, aggressive competitors, ransom – and are fairly easy to launch. Botnets can be rented inexpensively. There are even sophisticated tools available on the darknet to launch significant attacks. The defenses against DDoS attacks are at best limited. The ultimate defense is to subscribe to a DDoS mitigation service that can be called upon when needed.
For more research and insights on the topic, visit Aberdeen’s IT Security page
Dr. Bill Highleyman brings more than 40 years’ experience in the design and implementation of mission-critical computer systems. He has published extensively on availability, performance, testing, and middleware issues. He is the author of Performance Analysis of Transaction Processing Systems, published by Prentice-Hall, and is co-author of the three-volume series Breaking the Availability Barrier. Dr. Highleyman is the Managing Editor of the monthly Availability Digest (www.availabilitydigest.com), which focuses on topics related to high- and continuous availability. He holds sixteen patents, many of which are in the areas of data replication and active/active systems. He is a graduate of Rensselaer Polytechnic Institute and MIT and earned his doctorate in electrical engineering from Polytechnic Institute of New York. He can be reached at firstname.lastname@example.org.