Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

DDoS Attacks Via DNS Recursion 192

Posted by Zonk from the to-understand-recursion-you-must-understand-recursion dept.
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.'"
This discussion has been archived. No new comments can be posted.

DDoS Attacks Via DNS Recursion More

DDoS Attacks Via DNS Recursion

Comments Filter:

  • djbdns (Score:3, Informative)

    by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Thursday March 16, 2006 @01:40PM (#14935491) Homepage
    That's why you run djbdns [cr.yp.to] -- by default it's closed to recursive queries.

    • Re:djbdns (Score:5, Informative)

      by PaisteUser ( 810863 ) on Thursday March 16, 2006 @01:51PM (#14935592)
      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 (Score:5, Informative)

        by pjkundert ( 597719 ) on Thursday March 16, 2006 @02:28PM (#14935972) Homepage
        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; }; ...
        • It's better to write your example as:

          allow-recursion {
          192.168.0.0/16;
          172.16.0.0/12;
          10.0.0.0/8;
          127.0.0.0/8; ::1;
          };

          This way, those who mindlessly cut&paste will be less likely to shot themselves in the foot. And, since people are going to leave the old wide-open but working version if anything breaks, it's better to have it work out of the box.
        • With that config, bind will still give out already cached data. That could be used in information gathering attacks.
          It would be better to use:

          allow-query { clients; };
          allow-recursion { clients; };

          acl clients {
          192.168.1.0/24
          }

          and then in your zones

          zone "example.com" {
          type master; ...
          allow-query { any; };
          };
      • Turning recursion off is likely to result in lots of support calls from people who are dependent on your servers. A better solution is to deny queries that don't come from trusted hosts.

        First, make an ACL that lists all the IP addresses for which you want to provide general DNS services. These are IP addresses you should trust... any of these can use your server as a DoS attacker.

        acl internal { 127.0.0.0/8; 1.2.3.0/24; }; // we trust 1.2.3.0 not to DoS anyone

        options {

    • Separate authoritative and recursive (Score:4, Informative)

      by Aspirator ( 862748 ) on Thursday March 16, 2006 @01:54PM (#14935635)
      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.
      • 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).

        The
        • You have to set up your authoritative records on a separate IP address from your current DNS server

          I don't think so.

          Why don't you just add a "query { trusted-hosts; }" line to the global options, and a "query { any; }" line to your authoritative zones? It's not rocket science.
    • With his weird license? God. He writes good software. He's even a bloody certified genius, but he's amost as insufferable as Dave Weiner. Don't try and submit a patch - unless you are just donating to his case, and want nothing as a contributor. Also, be prepared for the contempt of his responses.

      Besides, who wants software written by a cartoon bear?
      • Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making copies.

        Oh, and look at qmail-1.03.tar.gz#CREDITS -- my name is in there because of patches I've submitted to djb. Granted, he rewrote most of my code because his design was better than mine, but just because most patches 1) suck, 2) aren't necessary, 3) make the code worse, and 4) are badly design, doesn't mean that all are.

        • Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making copies.

          You got that ALMOST right. Let's correct it:

          Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making and distributing copies which are not in accordance with the Fair Use clause.

          There. Much better. Methinks you work for the MPAA or RIAA.
          • Yeah, but we're not talking about copying which falls under fair use. Incorporating a copy of code into a unidiff patch would be fair use (commentary). Making a copy of a djb subroutine for pedantic purposes ("see how he does this") would be fair use. Making a copy of code which is no longer for sale and cannot be purchased for any reasonable price might be fair use. Making a copy of code which is freely downloadable elsewhere -- even if you use it to create a derived work -- is almost certainly not fai
        • Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making copies.

          As I'm sure you know Rick Moen [linuxmafia.com] has an informative text on this. IMO you'd have to be insane not to have a license on software you are using for SMTP/DNS (Ie. speaking directly with the outside world).

          But, hey, you're free to be insane. Just don't act surprised when people don't want to join you for a glass of kool-aid.

    • Isn't this just anothery iteration of, "people abuse technology?"

      Though if you're setting up a DNS server, you should have a fair amount of expertise on how those abuses can arise and limit the possibility.
    • Shades of OpenBSD. "By default there are no vulnerabilities" - but in the Real World [TM] systems require configuration, and that process will introduce vulnerabilities if the human being involved in configuration is an idiot or insufficiently skilled.

      That's why I have all my systems configured by CHUCK NORRIS.

      No, just kidding. Anyway, no DNS system works without configuration, and a properly configured system is immune to this problem regardless of whether you run Vixie's code or Bernstein's.

  • Doctor, it hurts when I go like this (Score:3, Insightful)

    by $RANDOMLUSER ( 804576 ) on Thursday March 16, 2006 @01:46PM (#14935545)
    > '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 == ... (Score:3, Funny)

    by bcat24 ( 914105 ) on Thursday March 16, 2006 @01:49PM (#14935581) Homepage Journal
    recursion: n.

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

    From the Jargon File [catb.org].

  • 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? (Score:5, Informative)

      by Anonymous Coward on Thursday March 16, 2006 @01:58PM (#14935677)
      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? (Score:5, Informative)

      by LurkerXXX ( 667952 ) on Thursday March 16, 2006 @02:01PM (#14935700)
      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.

      • 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.

        No, the problem was that I did read the article and was utterly confuse

      • Comment removed based on user account deletion

  • That's a bold statement (Score:3, Interesting)

    by fak3r ( 917687 ) on Thursday March 16, 2006 @01:51PM (#14935602) Homepage
    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?
    • Well to start with, dnscache supports simple ACLs for recursion requests. You can have a publically accessible DNS cache for your organization, which won't resurse for the whole world. Better to use a VPN, though, but not everyone can do that. So if you gotta do it, dnscache is a good choice.

      The authoritative server tinydns does not cache at all, and so it is useless for this attack.

  • Disable recursion in BIND (Score:5, Informative)

    by Ponga ( 934481 ) on Thursday March 16, 2006 @01:55PM (#14935646)
    Put this line in your zone definition:
    recursion no;

    Problem solved.
    • I tightened up my DNS configuration when it was being abused for one of these attacks [geckotribe.com] last October by adding the following to named.conf:

      options {
      allow-recursion { 127.0.0.1/32; };
      };

      That allows my server to use the local copy of bind for recursive queries, but limits everyone else to queries for which my server is authoritative. Bandwidth usage went from practically off the chart to low enough not to cost me extra for bandwidth immediately, and soon the attacker stopped trying to abuse

    • 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 s

    • Put this line in your zone definition: [...] Problem solved

      Hey, great man! Tha Host slashdot.org not found: 3(NXDOMAIN)

  • 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 (Score:3, Funny)

    by Alwin Henseler ( 640539 ) on Thursday March 16, 2006 @02:11PM (#14935793)
    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 (Score:5, Informative)

    by lazarus ( 2879 ) on Thursday March 16, 2006 @02:25PM (#14935945) Journal
    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.
    • That is almost correct. As stated it requires 3x2 machines (primaries and secondaries) which is a serious resource waste. In most cases the RESOLVER and ADVERTISER can be combined on one machine.

      You simply need to set listen statements in the named.conf's so that the ADVERTISER listens on an externally reachable address and the RESOLVER issues queries on an externally reachable address while listening on an address that can be reached only from the inside.

      Depending on your topology and security constraints

  • Recursion considered harmful (Score:4, Funny)

    by Anonymous Coward on Thursday March 16, 2006 @02:26PM (#14935952)
    Should have used gotos! -1 for the functional language weenies!
  • 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.
    • Hasn't it been fixed for some time via the allow-query and allow-recursion configuration options?

    • Of course there is... (Score:5, Informative)

      by emil ( 695 ) on Thursday March 16, 2006 @03:10PM (#14936309)
      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.

      • allow-recursion { 1.2.3.0/24; };
      • Yeah, there's a checkbox to disable all recursion in Windows Server DNS, under DNS > Forwarders and Advanced tabs.

        The problem is doing the cache for internal hosts (or an internal interface) and running zone authority for external (internet) users on one server. Apparently it's not possible using the built in configuration tool. There's probably a registry key which determines which interface will forward or not, around here: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Cu rrentVersion\DNS Server
        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;
        };
      };
    • 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;
    • As has been mentioned, BIND can do this without much issue - EXCEPT it doesn't QUITE follow all expectations. Apparently, BIND uses a common name cache - so although a recursive query with an uncached answer can arrive at a DNS server and be rejected, if that BIND server ALREADY has a cached answer (eg, from an internal query) - it'll serve that up to the requestor. This was true in implementations of BIND about 6 months ago - I'm not sure things have changed since...

      • Re:When BIND is fixed I'll implement it (Score:4, Informative)

        by gkitty ( 869215 ) on Thursday March 16, 2006 @04:06PM (#14936699)
        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.
        • > In Bind9 you don't have to return cached data, so though it happens by default you can
          > turn it off ("additional-from-cache"):

          Excellent. The commentary on the aite with the original article didn't seem to know about that trick. So now I just need to make sure I have wrapped my head around all of the details and start making the changes. Going to be a bit of bother this way but managable. Installing another pair of nameservers was right out, this way is doable.

  • old new (Score:3, Informative)

    by 7x7 ( 665946 ) on Thursday March 16, 2006 @02:36PM (#14936032)
    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.
  • Would doing this get you banned from WoW?

  • slashdot DNS is OPEN! (Score:4, Informative)

    by Anonymous Coward on Thursday March 16, 2006 @02:51PM (#14936157)
    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.
    • They don't seem to be anymore. http://www.dnsreport.com/tools/dnsreport.ch?domai n =slashdot.org [dnsreport.com] is now showing...

      OK. Your DNS servers do not announce that they are open DNS servers. Although there is a slight chance that they really are open DNS servers, this is very unlikely. Open DNS servers increase the chances that of cache poisoning, can degrade performance of your DNS, and can cause your DNS servers to be used in an attack (so it is good that your DNS servers do not appear to be open DNS servers).

  • DDoS? "R", matey! (Score:3, Informative)

    by spyrochaete ( 707033 ) on Thursday March 16, 2006 @03:13PM (#14936336) Homepage Journal
    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]
  • 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 (Score:3, Interesting)

    by miller60 ( 554835 ) on Thursday March 16, 2006 @04:17PM (#14936785) Homepage
    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].

  • 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.

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close