DDoS Attacks Via DNS Recursion

JehCt writes "Associated Press is running a story about how the recursion feature of open DNS servers can be used to launch massive distributed denial of service (DDoS) attacks: 'First detected late last year, the new attacks direct such massive amounts of spurious data against victim computers that even flagship technology companies could not cope.' A thread at WebmasterWorld explains, 'To make a long story short, having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'"

djbdns

[Russ Nelson]

That's why you run djbdns [cr.yp.to] -- by default it's closed to recursive queries.

Re:djbdns

[PaisteUser]

It's not that difficult to make BIND9 not respond to recursive queries, add "recursion no;" to the "options {};" section of the named.conf file, reload the config and your good to go.

Separate authoritative and recursive

[Aspirator]

I am quite a fan of djbns, but the key here is to separate authoritative and
recursive, which is something that DJB has been preaching for a while.

Consequently djbdns won't do this, but it is quite possible to make bind not
do this also. (In fact Bind now has come round and reccomended this.)

It seems to me like a no-brainer, why is splitting the two such a problem?

SDNS wouldn't hurt either, but that will take a lot more doing.

Disable recursion in BIND

[Ponga]

Put this line in your zone definition:
recursion no;

Problem solved.

overwhelming floods of amplified data

[digitaldc]

Name servers are specialized computers that help direct Internet traffic to its destinations. The attacker then sent falsified requests to the compromised directory computer, which unleashed overwhelming floods of amplified data aimed wherever the attacker wanted.

Suggestion:
-Verify requests
-Verify directory computers have not been comprimised
-Disallow amplified data
-Build a new secure system for handling traffic

Re:I must resist

[AKAImBatman]

That's self-referential, not recursive. One does not immediately imply the other. GNU, on the other hand, is recursive.

Re:Could someone explain how the attack works?

[Anonymous Coward]

No compromise needed. You just send requests to the DNS server spoofing yourself as the victim's IP. (UDP is much easier to spoof, and can be sent out very quickly.) The replies, which are some 30 times larger than the requests, get sent to the spoofed IP (victim). It is a classic form of amplification attack.

Re:Could someone explain how the attack works?

[LurkerXXX]

Then you don't understand DNS resolvers. Did you bother reading the linked site? All you need to do is query an open resolver with some domain you set up (ex my.span.com), then change the authoritiative DNS of your registered domain as the target open DNS resolver. Now whenever someone anywhere in the world queries for my.spam.com, it hits your DNS server (until their local server caches it). It looks like you are hosting the spammer.

Another problem:
(Quoting a post on the other site)"they can send a 70 byte packet to your DNS server, and your DNS server will send a 500+ byte packet to the victim. With EDNS0, that can be 4,000+ bytes.

So with a dialup account, it would be possible to saturate a T1.

There's plenty of ways for them to mess with you without any 'compromised' machines on your network.

Re:Separate authoritative and recursive

[Russ Nelson]

why is splitting the two such a problem?

It isn't that hard, but it's perceived to be difficult. You have to set up your authoritative records on a separate IP address from your current DNS server (e.g. using tinydns). Then you tell your registrar that your nameserver has a different IP address. At that point, the only queries coming to your old IP address should be recursive queries coming from your users. Then you can close off recursive queries coming from the rest of the net (e.g. using dnscache).

Then you have to make your secondarying work, which may be easy, or merely annoying depending on your setup.

Re:That's by Berenstain?

[Russ Nelson]

No, most of his software is copyrighted. The only djb software which is in the public domain is software that he has explicitly given to the public domain. The term for the rest of his software is "license-free". You don't need a license to use it. Just download it! Copyright law lets you do anything you want with a copyrighted work, except redistribute it. You can publish patches, as we've done with netqmail [qmail.org].

Wrong wrong wrong

[A nonymous Coward]

His license forbids distributing binaries unless they are made from his sources. You want to add any of the many well known patches? Great, you distribute his source and your patches, you do not distribute patched sources and you do not distribute binaries.

No way is DJB software public domain.

In fact, I bet a dollar you don't even know what public domain is.

Re:Old NEws

[Intron]

Correct. Here [cert.org] is the CERT writeup from 2000.

Re:djbdns

[Russ Nelson]

Your users are going to be a little upset when they discover that their DNS server doesn't resolve anything anymore.

You see, the chief difficulty is *exactly* the same as the open smtp relay problem. Back when everybody on the Internet knew each other, and abuse was resolved with a phone call, nobody understood that some services needed to be authorized, and some needed to be public. Thus, relaying and delivery SMTP servers were the same thing, and caching and authoritative DNS servers were the same thing. The big challenge with this issue is not reconfiguring BIND 9 to not recurse. The big challenge is to split your caching from your authoritative DNS servers.

Re:djbdns

[Anonymous Coward]

Really?

Why, then, does the OpenBSD team use a hardened version of BIND whilst DJBDNS remains a bit player?

Split-split DNS Design

[lazarus]

For enterprise systems a split-split DNS design is the best. There are three components to this design:

ADVERTISER
RESOLVER
INTERNAL

The advertiser sits outside, Internet-facing, and is only responsible for resolving outside queries for your own domains. It does not do recursion or dynamic updates, and has a secured cache.

The resolver and internal sit inside, are intranet-facing, and handle internal requests for outside domains, and internal requests for internal domains respectively.

There are lots of articles on-line which show how to set this up.

Re:I must resist

[AKAImBatman]

That's a self-referential paradox, not a recursive statement. The grandparent is an example of a recursive statement.

Fixing bind9

[pjkundert]

If you run an internet facing bind9 DNS server, you may want to allow recursion (caching) to your internal clients, while continuing to serve DNS requests to external clients for your domains (those for which you are "authoritative").

Lets say that your local LAN and WLAN networks are 192.168.0/24 and 192.168.1/24, respectively. Make the following additions to your /etc/bind/named.conf.options (or equivalent):

options { allow-query { any; }; allow-recursion { 192.168.0.0/24; 192.168.1.0/24; localhost; }; ...

Re:Could someone explain how the attack works?

[Anonymous Coward]

The problem is not only with the amplitude increase, but with the multiple responses. The most common amplification ratio is 2.5:1 (a 47 byte packet with a 117 byte return). Compound that with the fact that it is trivial to find servers that replay this back 8-12 times, and you've got a real problem. 8 * 2.5 gives you a total of a 20x amplification of the packets you send out, which is fairly significant. Also, servers that replay these responses up to 24 times are not uncommon. This type of thing has been around for years, but it is only now coming into the spotlight as it becomes a more common method of attack.

old new

[7x7]

This is old news. If you're running an open DNS server, you're very likely participating in someonelse's DDoS attack and have been for the last couple years. We bought a company last year and part of my job was to assimilate their DNS systems that were reportedly flaking out constantly. I can't speak to the people running the servers before me, but the diagnosis was easy. Once we turned off recursion and convinced the network not to let spoofed UDP packets enter the network, the attacks stopped instantly.

slashdot DNS is OPEN!

[Anonymous Coward]

http://www.dnsreport.com/tools/dnsreport.ch?domain =slashdot.org [dnsreport.com]

FAIL Open DNS servers ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are:

Server 66.35.250.12 reports that it will do recursive lookups. [test]
Server 12.152.184.136 reports that it will do recursive lookups. [test]
Server 12.152.184.135 reports that it will do recursive lookups. [test]

See this page for info on closing open DNS servers.

Of course there is...

[emil]

There really isn't a good reason one nameserver can't serve internal and external users.

Back in the bind 4 days, when I did serious DNS, my company wanted a few servers visible in their domain(s) for external dns host resolution.

For people behind the firewall, they wanted a far more extensive list of hosts that were not to be seen for queries outside the firewall.

I did this by using scp to transfer the zone files from the external to the internal DNS server; the internal server would then "cat" the additional hosts to the zone and HUP the named.

AFAIK modern BIND uses "zones" so you can accomplish the above on one server, if you want. I've never used it, but I can see a number of situations where I'd need my above solution even with this feature.

What BIND needs is not a "recursion no;" option, but instead a "recursion eth0;" or "recursion 1.2.3.*;" so recursive queries must originate from a trusted network.

Remember also that not everyone in the world uses BIND - people with ActiveDirectory or NDS name servers might be screwed until a vendor patch.

Re:When BIND is fixed I'll implement it

[19thNervousBreakdown]

view "internal" {
  match-clients {
    10.0.0.0/8;
  };
  recursion yes;
  zone "example.com" {
    yadda yadda yadda;
  };
};

view "external" {
  match-clients {
    any;
  };
  recursion no;
  zone "example.com" {
    blah blah blah;
  };
};

DDoS? "R", matey!

[spyrochaete]

This isn't just a simple DDoS because DNS servers point many other resources to the attack target. This makes this a Distributed Reflective Denial of Service Attack, or DRDoS. I published an article on this topic in 2600 Hacker Quarterly magazine in 2004. I was a network\security student when I wrote it so it might not teach you ubergeeks anything new.

http://hyppy.zapto.org/DRDoS-Spyrochaete.html [zapto.org]

Re:When BIND is fixed I'll implement it

[GeekWithGuns]

There already is a fix in BIND (at least in the 9.2.4 release shipped with RHEL 4 & all like distros). Just add this to your "options" section of your bind.conf:

allow-recursion { localhost; mygroup; 10.10.10.1; 10.2.3.0/24; };

This would allow the localhost, the machines on the mygroup ACL, one computer at 10.10.10.1 and all the hosts in 10.2.3.0/24 access to recursive queries.

If you don't need to provide recursive lookups at all, you can just use this:

recursion no;

Re:Split-split DNS Design

[eqdar]

Exactly -- a split DNS setup is quite easy to implement, and is an elegant solution

There are lots of articles on-line which show how to set this up.

You might want to check http://www.castalie.org/Linux/DNS.html [castalie.org] for an example implying BIND as an internal resolver and NSD as an authoritative-only advertiser,

Re:Of course there is...

[cortana]

allow-recursion { 1.2.3.0/24; };

Re:When BIND is fixed I'll implement it

[gkitty]

In Bind9 you don't have to return cached data, so though it happens by default you can turn it off ("additional-from-cache"):

view "internal" {
        match-clients { internals; guests; };
        recursion yes;

        zone "." {
                type hint;
                file "bootstrap/cache";
        };

        zone "example.com"{
                type master;
                file "example-int.com";
        };
};

view "external" {
        match-clients { any; };
        recursion no;
        additional-from-auth no;
        additional-from-cache no;

        zone "example.com"{
                type master;
                file "example-ext.com";
                allow-query { any; };
        };
};

---------

I believe that should prevent bind from being too useful from the outside.

Re:Disable recursion in BIND

[kence]

Depending on the DNS server, turning off recursion completely is not the answer. Granted most internet-facing DNS servers can simply turn recursion off without negatively impacting lookups (generally) but doing so for an internal system (or one that bridges an internal and external) is begging for trouble.

According to Chapter 2.2.6.2 of Pro DNS and BIND (http://www.zytrax.com/books/dns/ch2/index.html#re cursive) [zytrax.com])

Note: The above sequence is highly artificial since the resolver on Windows and most *nix systems is a stub resolver - which is defined in the standards to be a minimal resolver which cannot follow referrals. If you reconfigure your local PC or Workstation to point to a DNS server that only supports Iterative queries - it will not work. Period.

A better solution would be to use allow-recursion [zytrax.com] to specify which clients will receive recursive DNS responses.

Re:old new

[7x7]

Set up an open DNS server with recursion turned on and do not allow UDP spoofing. If you know anything about UDP, you know it is connectionless. The only way you could possibly know if a UDP packet is spoofed is if it is *your* IP space (packets coming in from the internet could be from anywhere). Your own IP space cannot source from outside your network, so you discard any packets that do.

From outside your network, send a request for a DNS record to your server: a.example.com Your server will try to look up a.example.com from example.com's name servers. It will send an answer to the source IP in the UDP packet.

Now send another request for b.example.com and forge the source IP. Your server will try to look it up and send the answer back to the fake IP.

Now send millions of packets looking up [randomnumber].example.com, each with a unique source IP. Your server will essentially flood the name servers for example.com with requests for zones that do not exist and scatter the answers to the far corners of the internet where the UDP packets are simply discarded.

Now combine your recursion set up with a few others and watch example.com drop from the face of the planet.

That is what I found when I took over the servers from the other company. They had a high capacity system with loads and loads of bandwidth (phone company). Their machines could knock out a small name server without sweating. Combined with other networks, they could knock out much larger installations.

The attack is simple to perform and simple to avoid.

Re:djbdns

[TCM]

BIND9 has a concept called views. Views are separate sets of option{}; and zone{}; scopes based on client address or destination address or even something else.

It's very easy to define an external zone without recursion and some master zones and an internal zone that recurses. This also has the benfit of split caches. If you just disabled recursion for some clients in a "single-zone" BIND, you still are "vulnerable" to information leakage where external clients can probe your cache for records.

http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch06 .html#view_statement_grammar [bind9.net]