What the heck is a DNS amplification DoS attack?

Apr 08 2013 Published by under Basics, woo

A couple of weeks ago, there was a bunch of news about a major DOS attack on Spamhaus. Spamhaus is an online service that maintains a blacklist of mail servers that are known for propagating spam. I've been getting questions about what a DoS attack is, and more specifically what a "DNS amplification attack" (the specific attack at the heart of last week's news) is. This all became a bit more relevant to me last week, because some asshole who was offended by my post about the Adria Richards affair launched a smallish DoS attack against scientopia. (This is why we were interrmitently very slow last week, between tuesday and thursday. Also, to be clear, the DNS amplification attack was used on Spamhaus. Scientopia was hit by a good old fashioned DDoS attack.)

So what is a DoS attack? And what specifically is a DNS amplification attack?

Suppose that you're a nastly person who wants to take down a website like scientopia. How could you do it? You could hack in to the server, and delete everything. That would kill it pretty effectively, right?

It certainly would. But from the viewpoint of an attacker, that's not a particularly easy thing to do. You'd need to get access to a privileged account on our server. Even if we're completely up to date on patches and security fixes, it's probably possible to do that, but it's still probably going to be a lot of work. Even for a dinky site like scientopia, getting that kind of access probably isn't trivial. For a big security-focused site like spamhaus, that's likely to be close to impossible: there are layers of security that you'd need to get through, and there are people constantly watching for attacks. Even if you got through, if the site has reliable backups, it won't be down for long, and once they get back up, they'll patch whatever hole you used to get in, so you'd be back to square one. It's a lot of work, and there are much easier ways to take down a site.

What you, as an attacker, want is a way to take the site down without having any kind of access to the system. You want a way that keeps the site down for as long as you want it down. And you want a way that doesn't leave easily traced connections to you.

That's where the DoS attack comes in. DoS stands for "denial of service". The idea of a DoS attack is to take a site down without really taking it down. You don't actually kill the server; you just make it impossible for legitimate users to access it. If the sites users can't access the site even though the server is technically still up and running, you've still effectively killed it.

How do you do that? You overwhelm the server. You target some finite resource on the server, and force it to use up that resource just dealing with requests or traffic that you sent to the server, leaving it with nothing for its legitimate users.

In terms of the internet, the two resources that people typically target are CPU and network bandwidth.

Every time that you send a request to a webserver, the server has to do some computation to process that request. The server has a finite amount of computational capability. If you can hit it with enough requests that it spends all of its time processing your requests, then the site becomes unusable, and it effectively goes down. This is the simplest kind of DoS attack. It's generally done in a form called a DDoS - distributed denial of server attack, where the attacker users thousands or millions of virus-infected computers to send requests. The server gets hit by a vast storm of requests, and it can't distinguish the legitimate requests from the ones generated by the attacker. This is the kind of attack that hit Scientopia last week. We were getting streams of a couple of thousands malformed requests per second.

This kind of attack can be very effective. It's hard - not impossible, but hard - to fight. You need to identify the common traits of the attackers, and set up some kind of filter to discard those requests. From the attacker's point of view, it's got one problem: price. Most people don't have a personal collection of virus-infected machines that they can use to mount an attack. What they actually do is rent machines! Virus authors run services where they'll use the machines that they've to run an attack for you, for a fee. They typically charge per machine-hour. So to keep a good attack going for a long time is expensive! Another problem with this kind of attack is that the amount of traffic that you can inflict on the server per attacker is also used by the client. The client needs to establish a connection to the server. That consumes CPU, network connections, and bandwidth on the client.

The other main DoS vector is network bandwidth. Every server running a website is connected to the network by a connection with a fixed capacity, called it's bandwidth. A network connection can only carry a certain quantity of information. People love to make fun of the congressman who said that the internet is like a series of tubes, but that's not really a bad analogy. Any given connection is a lot like a pipe. You can only cram so much information through that pipe in a given period of time. If you can send enough traffic to completely fill that pipe, then the computer on the other end is, effectively, off the network. It can't receive any requests.

For a big site like spamhaus, it's very hard to get enough machines attacking to effectively kill the site. The amount of bandwidth, and the number of different network paths connecting spamhaus to the internet is huge! The number of infected machines available for an attack is limited, and the cost of using all of them is prohibitive.

What an attacker would like for killing something like Spamhaus is an attack where the amount of work/cpu/traffic used to generate the attack is much smaller than the amount of work/cpu/traffic used by the server to combat the attack. That's where amplification comes in. You want to find some way of using a small amount of work/traffic on your attacker machines to cause your target to lost a large amount of work/traffic.

In this recent attack on Spamhaus, they used an amplification attack, that was based on a basic internet infrastructure service called the Domain Name Service (DNS). DNS is the service which is used to convert between the name of a server (like scientopia.org), and its numeric internet address (184.106.221.182). DNS has some technical properties that make it idea for this kind of attack:

  1. It's not a connection-based service. In most internet services, you establish a connection to a server, and send a request on that connection. The server responds on the same connection. In a connection-based service, that means two things. First, you need to use just as much bandwidth as the target, because if you drop the connection, the server sees the disconnect and stops processing your request. Second, the server knows who it's connected to, and it always sends the results of a request to the client that requested it. But DNS doesn't work that way. In DNS, you send a request without a connection, and in the request, you provide an address that the response should be sent to. So you can fake a DNS request, by putting someone else's address as the "respond-to" address in the request.
  2. It's possible to set up DNS to create very large responses to very small requests. There are lots of ways to do this. The important thing is that it's really easy to use DNS in a way that allows you to amplify the amount of data being sent to a server by a factor of 100. In one common form of DNS amplification, you send 60 byte requests, which generate responses larger than 6,000 bytes.

Put these two properties together, and you get a great attack vector: you can send tiny, cheap requests to a server, which don't cause any incoming traffic on your attacker machine, and which send large quantities of data to your target. Doing this is called a DNS amplification attack: it's an amplification attack which uses properties of DNS to generate large quantities of data send to your server, using small quantities of data sent by your attackers.

That's exactly what happened to Spamhaus last week. The attackers used a very common DNS extension, which allowed them to amplify 60 byte requests into 4,000 byte responses, and to send the responses to the spamhaus servers.

There are, of course, more details. (For example, when direct attacks didn't work, they tried an indirect attack that didn't target the spamhaus servers, but instead tried to attack other servers that spamhaus relied on.) But this is the gist.

7 responses so far

  • Rob Ryan says:

    Fascinating, thanks for this. I must say that I don't always agree with you, particularly on political or sociological issues but your posts are (almost) invariably interesting.

  • Rob says:

    The "Russian Mafia" doesn't charge very much for a DDOS attack. One good ole' fashioned attack was an email flood. Basically send thousands of emails/hour and eventually fill up the disks on the server - which promptly crashes, or uses up the quota on gmail or office 365. (you keep the rate just low enough to not trip any network intrusion detection software and vary the "from:" field) It helps if the intermediate hosts can relay and it's not too hard to spoof the connections to make backtracking less than trivial.

    I found this out by once blogging about DOS attacks.

  • Lawrence says:

    Reminds me of the Ping of Death from NT4.

  • Kyle Szklenski says:

    If there's one thing on earth that's reliable, it's that you and Eric Lippert will post the most interesting blog posts anywhere.

  • Brendan says:

    I was hit by a DNS DOS attack last week. It was showing in my DNS log file as a denied cache query that was repeating about 50 times a second and the source IPs kept changing every few minutes.
    SOLUTION:
    I wrote a little script to automatically collect the IPs from the log file and feed them into a table that my firewall uses to determine which source IPs to block DNS requests from.
    My DNS(named) & Firewall(pf) both run on the same OpenBSD system.

    SHELL SCRIPT:
    #!/bin/sh
    while [ 1 ]
    do
    /bin/sleep 1
    badip=`/usr/bin/tail -n1 /var/log/messages | /usr/bin/grep named | /usr/bin/grep query | /usr/bin/grep cache | /usr/bin/grep denied | /usr/bin/cut -f 2 -d "client" | /usr/bin/cut -f 2 -d " " | /usr/bin/cut -f 1 -d "#"`
    /sbin/pfctl -t baddns -T add $badip
    done

    FIREWALL(pf) RULES:
    table persist
    block in on rl0 proto tcp from to 192.168.1.2 port 53
    block in on rl0 proto udp from to 192.168.1.2 port 53

  • Brendan says:

    Sorry guys, the posts on this blog do not allow the less-than and greater-than symbols so my firewall rules did not show correctly:
    FIREWALL(pf) RULES:
    table {baddns} persist
    block in on rl0 proto tcp from {baddns} to 192.168.1.2 port 53
    block in on rl0 proto udp from {baddns} to 192.168.1.2 port 53

    NOTE: replace "{" with less-than-symbol, replace "}" with greater-than-symbol

  • Tel says:

    I would have thought these guys were very easy to honeypot.

    Just leave a server that answers any query, and wait for someone to scan it out. Then if you see a blast of traffic you know that one of those scanners must be the controlling IP address (i.e. not spoofed) for the attack. Some simple algorithm would be able to deduce a way to only answer the controlling IP (which will query on a regular but low-volume basis) and not respond to high volume queries.

    This sort of server effectively soaks up the bandwidth of the trouble-maker.

    Really, there are two problems: ISP's are too lazy to filter out spoofed source addresses, and ISP's are too lazy to track back the traffic streams to their actual source (which can very easily be done, just by putting a few monitors on UDP port 53 traffic).

    Also, the DNS UDP protocol could very easily be extended by requiring the query to ask for a token, and then ask for real information (two step process). The token would be a hash based on the source IP address (only requires the server to store one random number, not a number per IP) and sufficiently difficult to guess that sending random tokens would be next to useless. Even a 32 bit token would be plenty. Tokens could stay valid for a day or more, so they end up getting cached and thus don't significantly slow down the query process.