There has been plenty of buzz and chatter on the Internet recently concerning a very large DDoS attack against CloudFlare, with coverage on their blog, the New York Times, and the BBC, among many others.

While attacks of this nature are certainly nothing new, the scale of this attack was surprising, reported to hit 120Gbps. For a sense of scale, your average cable modem is only about 20Mbps, or about 0.016% of that bandwidth.

So how does one generate an attack of that size? The technique that appears to have been used is called DNS Amplification. The attacker will typically use a network of infected hosts, known as a botnet, to send DNS queries to servers, faking the source address to be that of their target. When the servers reply to these queries, they send the reply to that false address.

Since the response packet is bigger than the query packet, the DNS server is helping out in the attack by increasing the amount of bandwidth being used. This is not a new technique, and has been around since at least the late 1990s.

What has changed is how effective this attack is, mostly due to the introduction of DNSSEC records. For example, a DNS query for isc.org/ANY with DNSSEC is only 78 bytes, but the reply is 3,586 bytes—so big it gets fragmented and spread across three packets. This makes it very easy to use a little bit of bandwidth to make a huge attack, and since your compromised hosts don’t need to send out a lot of data, it’s less likely they’ll be detected and shut down.

Open Recursives Are Not the (Only) Problem

A lot of these attacks make use of recursive resolvers to perform this amplification. These are the servers that are typically run by your ISP or by services such as Dyn’s Internet Guide, OpenDNS, or Google’s Public DNS.

It is intended that the end user will query these servers, they’ll take care of finding the answer, caching it, and returning it to the user. In the case of an ISP’s resolvers, these are usually locked down so only the ISP’s customers can use it. It has long been considered a security risk to operate a resolver that will respond to just anyone (an “open” resolver) without taking special care to consider the consequences.

There has been a lot of renewed interest in finding and shutting down unintentional open resolvers, through things like the Open DNS Resolver Project. This is a good thing, but it only addresses part of the problem. These attacks do not need to use open resolvers; they can use the authoritative servers directly to do their amplification. The authoritative servers are the systems that ultimately serve the answers in DNS.

These are the sorts of systems operated by DynECT Managed DNS and Standard DNS. And since these servers must be open in order to function, it’s much more difficult to secure them against abuse and the attackers are using them.

Dyn observed this activity back in December 2011, and it has only gotten worse since then. Other authoritative operators have seen the same behavior, typically DNS queries for “ANY” records on zones that have been DNSSEC signed. We have our own in-house tools for mitigating these attacks, but there has been public work to counter the problem, such as the Response Rate Limiting patches to the BIND nameserver software.

But these are really only temporary fixes in an arms race between DNS operators and the people who want to abuse their systems.

The Real Problem and its Solution

At its core, the problem that enables these attacks to work is source address spoofing. This is when a packet is sent from a computer using a source address that isn’t actually on that computer, but instead belongs to some other system—usually not even on the same network, such as a home PC on a cable modem, sending traffic that appears to be from a popular website. This has been seen as a security problem for a long time, and yet there are still plenty of networks that allow it to happen.

The solution has also been around for a while, known as BCP38. This document, part of a series of Best Common Practices, describes a very simple concept of not allowing packets to pass through a router from hosts that shouldn’t be sending from those addresses. It was published nearly 13 years ago, and is often brought up in tech circles as a solution to a number of problems, but there is still a lack of implementation on the Internet at large.

It boils down to a very simple logic, described in section 4:

IF packet’s source address from within [its assigned space]
THEN forward as appropriate

IF packet’s source address is anything else
THEN deny packet

There has been a renewed effort recently to push the adoption of this practice, with a boost from this recent DDoS attack on CloudFlare, with some new websites popping up, such as BCP38.info, and a lot of discussion in public forums. This is something that really needs to be done for the security of the Internet as a whole.

So, if you’re a network operator, please consider implementing BCP38. If you’re buying internet service, ask your provider about BCP38. The rest of the Internet will thank you.