The largest DDoS attack didn't break the internet, but it did try

A 300Gbps distributed denial-of-service attack thought to be the largest in the world has put key internet infrastructure to the test, and, so far, the attack has failed.
Written by Michael Lee, Contributor

CloudFlare has claimed to have mitigated the biggest distributed denial-of-service (DDoS) attack in the history of the internet.

Spamhaus, a not-for-profit anti-spam organisation, came to CloudFlare last week for assistance against a large DDoS attack it was experiencing. Switching over to CloudFlare's network on March 19, the attack began with a 10Gbps flood of traffic, ramping up in excess of 100Gbps later that night. It initially took Spamhaus' website down, with the outage independently observed by the Internet Storm Center at the time.

According to CloudFlare, the majority of the attack was traffic sent using a technique called DNS (domain name system) reflection. Under normal circumstances, DNS resolvers wait for a user request, such as a lookup for the IP address for a domain name, then respond accordingly.

The issue with this system is that the source address of such requests can easily be forged, and in the absence of any checking or authentication, the DNS resolver simply replies to the source IP address. While this is a simple way of "bouncing" a request off a different server, it also has the added benefit of amplifying the damage that an attacker can do, as the response sent from the DNS resolver is often many times larger than the request.

Restricting DNS resolver responses to known IP addresses is one way to control who can or cannot be a potential target, but many DNS resolvers simply aren't configured in this manner — or, as with Google's Public DNS service, are meant to be open to the public.

To mitigate against abuse, a generally accepted practice is to throttle responses, which is what Google currently does. But, according to CloudFlare, the attackers used multiple DNS resolvers to spread the load across many targets, stop any throttling from occurring, and fly under the radar of any security measures. According to the company, it initially recorded over 30,000 DNS resolvers that were tricked into participating in the attack.

CloudFlare's strategy to respond to such distributed attacks is similar. DDoS attacks are typically successful, as a single target is unable to cope with the combined effects of multiple incoming traffic streams, so CloudFlare's response is to create more "targets", each capable of handling a smaller chunk of the traffic. It took the traffic and spread it across 23 of its own datacentres, while also dumping any requests it knew to be bogus.

Moving upstream

Realising their attack wasn't working, the attackers changed tactics, circumventing CloudFlare entirely by moving the attack upstream to CloudFlare's suppliers, which in turn pushed the traffic further up to even larger networks — in simplistic terms, those that service the connections to and from major ISPs that allow countries to talk to each other.

According to CloudFlare, the attack on these networks was in excess of 300Gbps, and further attacks "risk overwhelming the systems that link together the internet itself", referring to the internet exchanges (IXs) that many high-tier ISPs use to talk to each other.

"The largest routers that you can buy have, at most, 100Gbps ports. It is possible to bond more than one of these ports together to create capacity that is greater than 100Gbps; however, at some point, there are limits to how much these routers can handle. If that limit is exceeded, then the network becomes congested and slows down," the company wrote.

Despite admitting that it doesn't have "direct visibility into the traffic loads" that Tier 1 networks are seeing, CloudFlare said, "we've seen congestion across several major tier ones, primarily in Europe, where most of the attacks were concentrated, that would have affected hundreds of millions of people even as they surfed sites unrelated to Spamhaus or CloudFlare. If the internet felt a bit more sluggish for you over the last few days in Europe, this may be part of the reason why."

Sophos Asia-Pacific director Rob Forsyth agreed with CloudFlare's assessment of the impact on the European network, telling ZDNet that Europe is experiencing quite a lot of interruption to its usual flow of traffic, depending on what users are doing. However, he disagreed with any notion that the global internet as a whole was affected.

"People might notice streaming might be disrupted in Europe, but things like delivery of email and traffic of data files and so on is not the sort of thing that's going to be interrupted to any large extent," he said.

"The issue, for the time being, is confined to Europe."

As for Australia, Forsyth said there is "no noticeable reduction of internet capacity", indicating that the attack is not one that "almost broke the internet".

"The internet has been designed to be resilient, and I think internet traffic will be routed around any type of disruption."

As for CloudFlare's claims that the largest routers won't be able to scale to support the amount of traffic, some of Cisco's own products appear to more than exceed the capacity required. The multi-shelf version of Cisco's CRS-1 (carrier routing system) router, for example, is able to scale to 92Tbps. Cisco did not return ZDNet's queries as to whether these would be suitable for this application, but it appears that many IXs can handle the 300Gbps of traffic with their existing or minimal upgrades to their infrastructure.

To highlight a few IXs for comparison, Amsterdam IX AMS-IX had peak annual traffic of about 2.2Tbps in the past year, Sweden IX Netnod had peak annual traffic of about 340Gbps, and Moscow IX MSK-IX had peak annual traffic of about 1Tbps.


Although a security initiative aimed at making DNS more secure exists — DNSSEC — it does not necessarily address the issue of spoofed source addresses. DNS requests and responses typically use the UDP protocol, rather than the TCP protocol. The latter requires a three-way handshake to establish a channel and confirm with the machine it is talking to that it did, in fact, initiate a connection. The former, however, does not.

Instead of being an issue that DNSSEC might solve, it is actually a transport protocol problem that has little to do with the additional security measures that DNSSEC might offer. However, as Cloudflare and others have pointed out in the past, DNSSEC can make the issue worse, as the additional keys required to authenticate records further increases the magnitude of amplification that an attacker has access to.

Yet, Forsyth said that such attacks may have a silver lining, raising awareness of the flaws in DNS and DNSSEC's importance.

"DNSSEC tightens up the rules around the way which the domain name service behaves and provides an additional layer of security, so, as you increase the security on any component, perhaps the cybercriminals will focus on a weaker link somewhere else," he said.

"This might be the catalyst to review all aspects of security, including DNSSEC."

Editorial standards