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

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

Re:djbdns

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.

Fixing bind9

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:djbdns

I have 3 dns servers are NAT'd on the private lan and allow recursion, the public one outside doesn't. I'm not a DNS expert but I haven't had any issues from users or attacks.

Re:djbdns

You have a correct configuration. You gain 2 skill points.

Re:djbdns

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]

Separate authoritative and recursive

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.

Doctor, it hurts when I go like this

> 'To make a long story short, having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'

OK, don't do that then.

Recursion == recursion == recursion == ...

recursion: n.

    See recursion [catb.org]. See also tail recursion [catb.org].

From the Jargon File [catb.org].

Could someone explain how the attack works?

From what I understand of DNS resolvers, this attack can't work unless there's another compromise at play here. Either a compromise of one of the victim host's zones, or a compromise of the servers hosting the open resolvers themselves.

Re:Could someone explain how the attack works?

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?

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.

That's a bold statement

having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'

Anyone want to discuss how DNS Cache [cr.yp.to] addresses this? AFAIK this is a pretty "safe" way to provide DNS to at least a small sized network - but that's all I run it on. Comments, concerns, advice?

Disable recursion in BIND

Put this line in your zone definition:
recursion no;

Problem solved.

overwhelming floods of amplified data

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

There is a defense

FTA: "Silva said the attacks earlier this year used only about 6 percent of the more than 1 million name servers across the Internet to flood victim networks. Still, the attacks in some cases exceeded 8 gigabits per second, indicating a remarkably powerful electronic assault."

/.ers will know that only the mighty foot of Chuck Norris [chucknorrisfacts.com] is powerful enough to kick back such a massive DDoS attack. There is a problem though: since there is only 1 of him, Chuck can't defend more than one site at a time. And ofcourse his ourly rates are a bit steep, too.

Vary your mileage may.

Split-split DNS Design

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.

Recursion considered harmful

Should have used gotos! -1 for the functional language weenies!

In other news...

...researchers have confirmed that posting a link in a Slashdot article is just as effective as other DDoS Attacks.

When BIND is fixed I'll implement it

There really isn't a good reason one nameserver can't serve internal and external users. All that is needed is recursive lookups need to be restricted to the internal IP space. It doesn't look like BIND can currently do that but I suspect that if this problem is really serious it will quickly gain the ability.

Some of us don't like the idea of maintaining more servers than are absolutely required, this looks like a pretty bogus reason to install another set of nameservers.

Of course there is...

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

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;
  };
};

Re:When BIND is fixed I'll implement it

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.

old new

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.

1 question?

Would doing this get you banned from WoW?

slashdot DNS is OPEN!

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.

History repeats itself

Back in 1983, IBM put Microsoft's "PC-DOS" on a "microcomputer." It was later named by Microsoft to MS-DOS, then simply DOS.

Digital Research cloned it and improved it in the late 1980s (early '90s?), making a program called DR-DOS that pundits called "a better DOS than DOS."

Flash forward to Yahoo News: [yahoo.com]

"Experts call the attack technique a 'distributed reflector denial of service,'" says the site.

So once again, DoS has been supplanted by DRDoS.

DDoS? "R", matey!

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]

TV Media

Oddly enough, just the title of this article alone explained the threat much more clearly than the anchorwoman on TV at noon. Why do they even report tech stuff if they can't even explain the problem? Sorry, this is off topic but I felt like whining about something..

StormPay: A recent example of this attack

The credit card processing gateway StormPay was knocked offline [netcraft.com] by this type of DNS amplification last month. The traffic peaked above 6 gigabits per second, and continued for weeks.

As previous posters have noted, these attacks have become more frequent in recent months, prompting an advisory from US-CERT (PDF) [us-cert.gov] in December. It's a hot topic on several security lists, and a special focus of SecuriTeam blogger Gadi Evron [securiteam.com].

Well duh!

It's taken them this long to notice this one? The cricket book discusses it, fer cryin' out loud, and had a good recommended solution: refuse recursive queries by default, then enable them only on those nameservers that'll be used by your client machines and only if the query comes from your local network. I thought everybody setting up a nameserver knew this one, BIND even comes with options specifically to make it easy to do.

Disable Recursion in old versions of BIND

If, like me, you are still running some old version of BIND (like 4.9 or 5.X) you can turn off recursion by adding the following line to named.boot & restarting named:

      options no-recursion

Another recommended configuration is

      options no-recursion no-fetch-glue

NOTE:
If you turn off recursion on any DNS server make sure you don't list that server in any other computer's resolv.conf file.

Attacks reflected by authorative servers?

What would be the difference to start a DRDOS attack by sending spoofed requests to authorative servers, querying for records they are authorative for?

detailed technical paper on the subject

Was just released: http://www.isotf.org/news/DNS-Amplification-Attack s.pdf [isotf.org]

DNS Amplification Attacks - A Smokescreen?

We need to be careful in proposing a suggested solution.

Inclusive Namespace roots provide public resolvers for users whose ISPs are too stubborn or dumb to provide their users with choice. Customers of such ISPs can simply decide to use the public resolvers provided by the INS roots, like Public Root or ORSC.

Shutting off user choice by suggesting that ISPs block outbound 53/TCP, 53/UDP will take away that choice.

I'm sure that some ICANN synchophants will be happy about this and if I were the suspicious type, I'd say that this sudden "awareness" of a "severe security problem" that has been around for a long time may be planned by those who are becoming uncomfortable with the ever increasing number of people who are abandoning the ICANN root in favor of DNS Service Providers (DSPs) who provide a view of the entire internet and don't impose non-related policies (UDRP) on domain registrants.

What better way to kill the INS than by putting up a security straw man and scaring people, especially ISPs, into taking away DNS choices from internet citizens. I am especially suspicious about this after seeing who was quoted in the recent MSNBC piece about the so-called "new" security risk that has "just been discovered". His jihad against allowing internet citizens to have freedom to chose their DSP from among global choices is well known to all.

Watch out here - there may be more to this story than meets the eye...

Now if only....

microsoft and sco and all the other evil corps hosted DNS with joker it would be alright. :) Has anyone actually been unable to get to sites because of this? 500,000 domains isn't that many really. And the sites thet the majority of the world visit (google/yahoo/slashdot/myspace) are all up and accessible. So I don't see what the big deal is. Unless this DdOS spreads to the rest of the name server system or causes it to overload.

MOD REPLY TO PARENT UP

Seriously, when one of these really impacts something or other, the people who are responsible will figure out what went wrong, fix it, and life will go on as usual. Maybe some of us will get away from the keyboards for a while, chat at the water cooler or something. Some of us will get a day off and others will get plenty of overtime.

The real risk is perhaps The Final Virus [catb.org].

Re:I must resist

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

Re:I must resist

To know recursion, you must first know recursion.

Re:Old NEws

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

Re:I must resist

No, that's just self-referential.

Recursive would be something like what the acronym LAME stands for: "LAME Ain't an MP3 Encoder." [acronymfinder.com]

(Which, originally, it wasn't.)