A distributed denial of service (DDoS) attack on Spamhaus (Figure 1), a provider of real-time DNS blacklists, affected a part of the Internet last March with a flood of data reported to reach 300Gbps.

Figure 1: Spamhaus, an organization that fights spam by issuing blacklists, fell prey to a DDoS attack on the Internet.

Innocent users whose addresses had been added to blacklists had no way of asking for their entries to be deleted during the attack. Innocent domains thus remained blocked and many legitimate pieces of email were not delivered.

After Spamhaus commissioned cloud security provider CloudFlare to defend its infrastructure, it was able to resume its usual services. The attackers, however, didn’t give up. A week later on March 23, LINX, one of the Internet’s backbone providers saw significant interruptions in their usual traffic, which peaks at around 1.5Tbps. Despite affecting this large Internet exchange, most people did not see any disruptions in their service.

Also in March, the German Finanzwelt portal was only partially accessible for several days because of a DDoS attack, and last fall, the infrastructure of German power utility 50Hertz was temporarily disrupted under a DDoS attack. In 2012, US banks, including Bank of America, Citigroup, Wells Fargo, and many others, were hit by a wave of DDoS attacks that, although the attackers were bent on disruption rather than robbery, cost over a billion dollars to clean up.

Many Vectors and DNS Floods

Today’s DDoS attacks in the cloud have very little in common with the chaotic flood of data used by legacy DDoS attacks in previous years (also see the “What Is DDoS?” box). According to a survey by Arbor Networks, typical bitrates in DDoS attacks last year were around 1.48Gbps. Almost one in two incidents in 2012 were carefully orchestrated multiple-vector attacks, some of which went on uninterrupted for several weeks.

Multiple-vector attacks alternately and systematically target various vulnerabilities in the infrastructure of the victim with an unceasing flood of DDoS offensives. If the victim then makes a configuration error while under fire, it can have fatal consequences.

One particularly popular form of attack in the cloud targets the vulnerabilities of the DNS system: the DNS flood attack. Attackers create DNS packets and send them via the UDP protocol to DNS servers with the aim of overloading the servers with requests and using up their computational resources. These attack methods are frequent because they are relatively easy to implement, can have massive leverage, and enable their attackers to hide their identity behind a third party.

DNS servers are designed to provide information. Some providers run their DNS servers as open DNS resolvers; in this configuration, recursive requests for name resolution outside of their own administrative domains are answered. Requests that concern large parts of the Internet can cause massive volumes of data. According to CloudFlare CEO Matthew Prince, the DDoS attack on Spamhaus was triggered by 36-byte data packets, each of which triggered a 3,000-byte response.

Although a normal desktop PC can handle about 1,000 DNS requests per second, a single DNS server will typically collapse under the load of about 10,000 DNS requests per second. If one DNS server fails, multiple hosts are affected. At the same time, almost all domain owners rely on the technical minimum of precisely two DNS servers, and because they completely ignore the requirement for geographic distribution, all of their services are taken down in even a minor DDoS attack.

Reflexive DNS Attacks

Reflexive DNS attacks involve the attackers’ sending DNS requests to a third party, rather than directly to the victim. These third parties are not the actual targets of the DNS attack. The attacker spoofs the IP address of the source in the DNS attack so that it matches the victim’s address. When the hosts then respond correctly to the requests, they send their responses to the spoofed source address and thus flood the real target with data. The reflexive DNS attack leverages the amplifying factor of the DNS system; after all, the DNS response is typically three to 10 times larger than the DNS request that triggered it.

In a reflexive DNS attack, targets can still become victims, even if they don’t have their own DNS servers. However, the attackers consume the victim’s Internet bandwidth, take down the firewall, or both.

In reflexive DNS attacks in the cloud, a distinction is made between three versions, each with different amplification stages: native, selective, and sophisticated. In native reflexive DNS attacks, the reply packets are significantly larger than the request packets. The amplification factor here is only 3 or 4.

A selective, reflexive DNS attack relies on the fact that DNS responses do not have uniform length. Some DNS answers are quite short; others are several times longer. With this attack method, the attacker first identifies domains that return very long DNS responses. This typically results in up to a 10 times amplification factor.

CloudFlare claims the Spamhaus attacker achieved an amplification factor of about 100 by requesting information about the ripe.net domain. Because it distributed the attack against Spamhaus over no fewer than 30,000 DNS resolvers using a remote-controlled botnet, none of the DNS server operators even noticed.

However, these examples do not exhaust the repertoire of DNA reflexive attacks. Some attackers use their own top-level domains, which serve the sole purpose of performing sophisticated DNS attacks. These domains give the perpetrators the ability to leverage DNS responses with up to a 100 times amplification factor.

Recursive DNS and Junk Data Attacks

Recursive DNS attacks rely on the fact that a DNS server that cannot provide information for a request will try to request the missing information from other DNS servers. The server must reserve a relatively large volume of resources (CPU cycles, memory, and bandwidth) to route and manage these requests. An attacker requesting information about a non-existing DNS record can easily overload a DNS server and cause its failure.

A DNS attack with junk data floods the DNS server by delivering large amounts of data to UDP port 53 (less frequently, UDP port 80). In each scenario, with the exception of a DNS server, the victim has the option of disabling the port that is under fire. However, the DNS server cannot block the port through which it offers its services.

Anycast DNS for Defense

In its defensive actions for Spamhaus, CloudFlare, the provider of the content delivery network (CDN) rescued its customer with a clever trick: With the help of anycast addressing with load balancers and a private CDN using nodes in a total of 23 data centers, they managed to intercept the flood of data in the cloud.

The most common type of addressing on the Internet is unicast, in which a unique IP address belongs to precisely one host. In anycast, however, a single IP address is assigned to multiple hosts, and the router provides the data packets to those hosts with the destination address that is geographically closest. Thus, the data packets always take the shortest route and end up on a number of servers, not just one.

In the case of Spamhaus, CloudFlare spread the victim’s IP addresses across 23 different data centers in this way. The shares that reached each data center were filtered by various criteria. The data packets were finally only sent to Spamhaus, after they had passed tests proving that they were legitimate. This allowed CloudFlare to separate the wheat from the chaff and discard the malicious requests.

CloudFlare takes this anycast idea to the extreme and assigns the same IP address to all of its customers. This strategy, which the provider dubbed Global Anycast DNS, makes it impossible for the attackers to focus on one target. Load balancers always forward requests to the nearest data center with spare capacity. Thus, no single element of the cloud infrastructure can collapse from the flood of data (there is no single point of failure).

Global anycast DNS is already available from CloudFlare in the scope of a free basic subscription. Similar services are also offered by other commercial CDN providers, including Akamai, Neustar, OpenDNS, and Prolexic.

SMURF and ACK Reflection Attacks

In a SMURF attack, the attacker sends ICMP packets to third parties with a spoofed source IP that points to the victim. The attackers target a router that is responsible for forwarding ICMP requests to other devices. By addressing the associated broadcast address (xxx.xxx.xxx.255), the perpetrators can reach all devices in the respective network behind the router. Because of the lack of a handshake procedure when connecting, the receiver cannot distinguish legitimate from illegitimate requests, and by properly responding to the ICMP request, they bombard the victim with their IP packets. To prevent such an attack, you just need to suppress ICMP request forwarding on the affected routers.

An ACK reflection attack makes use of the TCP three-way handshake. A TCP client initiates the connection by sending a SYN packet. On receiving this packet at an open port, the server responds with a SYN/ACK packet to accept the connection. It allocates memory, writes to the log, and waits for the final ACK response of the communication partner to acknowledge receipt of the message. In an ACK reflection attack, however, the source IP in the SYN request is spoofed; thus, the server sends a reply to the wrong recipient, that is, the victim.

For a successful defense, the message recipient needs to discard unsolicited incoming handshake packets.

Web Workers and Cross-Origin Requests

In a DDoS attack with Web Workers, the attackers take advantage of a part of the HTML5 specification: cross-origin requests. In the first step, they attract web visitors to a website by planting a link, for example, in an image or a script like a cuckoo’s egg. The website then starts a Web Worker, which causes the browser to send cross-origin requests to the victim. These are preferably based on a URL that causes the server hard work.

However, further requests would be prevented if it did not receive a valid answer to the Access-Control-Allow-Origin header. Therefore, the URL must be modified slightly for each instance of access. Thus, just 6,000 unsuspecting users of a browser like Chrome can generate a flood of up to one million requests per second.

Attacks of this type can be prevented just as easily as they are triggered: Because all cross-origin requests include the Origin header, you just need a setting on the firewall to prevent such requests via the header.

Application-Level DDoS

Recently, DDoS attacks have increasingly targeted very specific, well-documented vulnerabilities in certain services; this approach is known as DDoS at the application level (the seventh level in the OSI Reference Model; Figure 2).

Figure 2: Data volumes of typical DDoS attacks against network resources (red) and server applications (blue).

Attackers basically use the same approach as the Slow Read attack on the Apache web server, wherein Apache opens a new thread for each connection and maintains it for the duration of the communication. Attackers take advantage of this behavior by feeding Apache carefully metered data packets extremely slowly and simultaneously from as many sources as possible.

This approach is the easiest way to exploit Apache’s capacity. According to Gartner researchers, about a quarter of all DDoS attacks in 2013 will target the application layer.

DDoS via HTTP

The defense against ACK reflection and SYN flood attacks relies on the same principle, regardless of whether the attacker uses HTTP or HTTPS. However, this is no longer true of application-level DDoS attacks. Sadly, the solutions designed to mitigate the effects of DDoS attacks are only capable of preventing DDoS via HTTP.

Data transferred via HTTPS are encrypted on their path through the Internet via firewalls, routers, and other computers up to the load balancer and finally to the web server. The cloud provider’s DDoS protection measures and even the victim’s defense mechanisms are completely ineffective if the data packets are encrypted.

Using WordPress in the DDoS Botnet

A new trend started to emerge in 2012: Perpetrators are increasingly gaining control not over desktop PCs but over high-performance servers in the cloud for performing carefully orchestrated DDoS attacks. In the DDoS attacks on US financial institutions last year, the offenders achieved 20 times the effect of ordinary desktop botnets with a handful of servers.

This trend exacerbated brute force attacks on WordPress sites in the cloud. A botnet with about 90,000 IP addresses bombards the popular CMS system with username-password combinations, giving the perpetrators time to gain access to its upload capabilities. The attackers then install their scripts and set up a back door to integrate the respective web server permanently into their existing botnet.

The problem of increasing prevalence of DDoS attacks is particularly severe for corporations with a scalable infrastructure. A few years ago, outsourcing some of the load to the cloud was common practice when facing a DDoS attack, to take advantage of the elastic scalability of the cloud. Meanwhile, however, the attack methods have become so sophisticated that the biggest advantage of the cloud, namely its scalability, can be fatal for the victim.

Scalability: A Double-Edged Sword

IT security experts have been focusing their efforts on two phases of a DDoS confrontation: preventive measures and subsequent improvements. So far, people have been able to sit out the DDoS attack, but that is no longer possible with DDoS in the cloud. If you still implement this two-phase defense model, you could be out of luck. DDoS attacks in the cloud typically last between several days to several weeks and alternately use multiple vectors. IT staff have no choice but actively to counter the DDoS attack.

DDoS from Cloud to Cloud

Hosting CDNs in the cloud is gaining in popularity. However, a scalable cloud architecture provides no protection against DDoS attacks; on the contrary, the attacker can use the victim’s own infrastructure to take down IP-based defense mechanisms on the target server. A CDN can absorb attacks with high data volume and considerably complicate the exploitation of the available resources.

Unfortunately, the cloud offers IT professionals a false sense of security. The CDN forwards requests for dynamically generated data to the origin server. By slightly modifying requests for non-existing data, the attacker can cause the CDN to kick off a DDoS attack against its own data center. The offenders can also work around the CDN with cache directives in the HTTP header (e.g., with cache-control: no-cache or Pragma: no-cache).

If malicious requests are routed by the CDN to the origin server, they also undermine existing security systems because they now identify themselves with a trusted IP address of your own CDN. The result is a DoS attack by your own CDN on your own data center. In this case, illegitimate requests cannot be identified by IP address or blocked on the basis of volume of data. Load distribution of incoming attacks across different nodes of the CDN ensures that they are multiplexed with legitimate data streams and thus unrecognizable; they then bombard the target systems in a highly concentrated attack.

The only way to distinguish legitimate from illegitimate requests in an attack from your own CDN is to inspect the HTTP headers. Only the X-Forwarded-For header (XFF) sheds some light on the origin of the request and then allows selective blocking of the attack on the basis of the IP address.