Cloud Wars

A distributed denial of service (DDoS) attack on Spamhaus [1] (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 [2]. 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.

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

After Spamhaus commissioned cloud security provider CloudFlare [3] 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 [4] 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.