Much Ado About DNS Amplification Attacks

There's been much wailing and gnashing of teeth from one or two people over DNS amplification attacks, following an over-hyped DDoS attack on Spamhaus using this technique. The attack relies on sending DNS requests with the source IP address spoofed to be the address of the victim, which is swamped by comparatively large reply datagrams, Here are two techniques to make sure that your systems can't be used by Bad Guys to conduct these attacks.

For years now, in my CISSP Fast Track Review Seminars, I've been advocating the use of reverse path filtering in routers and firewalls. In fact, it's an Internet Best Practice - see BCP 38 [1]. It's implemented in the Linux kernel and many distributions turn it on by default. On Red Hat Enterprise Linux, CentOS or Scientific Linux, for example, take a look at the /etc/sysctl.conf file, looking for the following lines near the top:

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

If you change that to:

net.ipv4.conf.default.rp_filter = 2

you have solved the problem - before forwarding a packet, the kernel essentially asks itself, "If I was sending a reply to the source address of this packet, would I send that reply back out the interface that I received this packet on?". If the answer is no, the packet is dropped. So, for example, if a packet with a source address on your internal network arrived on the external interface, it would be dropped.

If your distro does not use the sysctl.conf file, you can achieve the same effect with the following command in a startup script such as /etc/rc.d/rc.local:

echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter

The default value of 1 enables reverse path filtering only of addresses on directly connected networks. This is a safer option - full reverse path filtering can break networks which use asymmetric routing (e.g. the combination of satellite downlinks with dial-up back-channels) or dynamic routing protocols such as OSPF or RIP.

However, reverse path filtering really needs to be implemented by all ISP's, to stop datagrams with spoofed source addresses from getting anywhere on the Internet. For those of us who aren't ISP's but just operate our own networks, a better fix is to make sure that your DNS either does not support recursive lookups, or supports them only for your own networks.

If your DNS is intended only as a primary or slave master for your own public zones, and will therefore be authoritative, then just edit the named.conf file to set the global options:

options {
     allow-query-cache { none; };
     recursion no;
};

However, if your DNS will provide recursive lookups for your internal machines, then restrict recursive lookups like this:

acl ournets {203.35.0.152/29; 192.168.0.0/21; };

options {
        directory "/var/named/data";
        version "This isn't the DNS you're looking for";
        allow-query { ournets; };
        allow-transfer { ournets; 139.130.4.5; 203.50.0.24; };
        allow-recursion { ournets; };
};

(Replace the network addresses in the ournets acl with your own addresses, obviously.)

The allow-transfer directive restricts zone transfers, and you would normally only allow slave DNS's (e.g. those provided by your ISP) and perhaps a few addresses within your own network - I've allowed transfers from all addresses in ournets, so that the dig command can be used for diagnostics. The allow-recursion directive allows recursive lookups only from our own machines

Finally, the allow-query directive means that only your own network(s) can even query this DNS - if you need to allow queries of your public zones, you can allow that in their specific options, later:

zone "ourcorp.com.au" IN {
        type master;
        file "db.ourcorp.com.au";
        allow-query { any; };
};

Should you choose to go even further, there are even patches for BIND which allow you to rate-limit responses, so that you can provide protection for your own addresses against DNS amplification attacks.

The bad news is that if you are running Windows, the only option that you have is to completely disable recursion - the Windows DNS is originally based on really old BIND code and does not have most of these options.

Implement these two simple fixes, and you can be confident that your systems won't be part of the problem.

References:

[1] BCP 38: Network Ingress Filtering - Defeating Denial of Service Attacks which employ IP Source Address Spoofing - available online at http://tools.ietf.org/html/bcp38

[2] US CERT Alert TA13-088A, DNS Amplification Attacks. Available online at http://www.us-cert.gov/ncas/alerts/TA13-088A