Home / server / Questions / 557297
Accepted
user145837
Asked: 2013-11-26 08:27:10 +0800 CST

trustwave pci scan: dns amplification denial of service, Bind 9.8.1-P1, doesn't seem like it

  • 772

In our last TW PCI scan, one of our flags was "DNS Amplification Denial of Service".

Right now, the DNS server is running Bind 9.8.1-P1. It seems like the CVEs are for a much older version: CVE-2006-0988, CVE-2006-0987.

Given as evidence was: Finding: A 26 byte ANY query for [my domain] resulted in a much larger answer, at 283 bytes in size.

So, from the outside world I run a dig:

taco $ dig -t NS . @[my domain]

For which I get back:

; <<>> DiG 9.8.1-P1 <<>> -t NS . @[my domain]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54954
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;.              IN  NS

;; Query time: 47 msec
;; SERVER: [my ip address]#53([my ip address])
;; WHEN: Mon Nov 25 15:53:24 2013
;; MSG SIZE  rcvd: 17

So to ME it seems like my BIND server is doing the right thing and refusing. But the scan is right in that for a small input it got back a much larger output. Even if it wasn't allowing recursion from the outside.

Is there a way to make BIND not answer at all, or send a shorter response? Is there something else entirely I need to do to make TW PCI scan happy?

domain-name-system

2 Answers

  1. Best Answer

    The query that they're talking about is probably more like dig -t any [your domain] @[your nameserver], which is likely to return the kind of larger response they're referring to.

    Is this an authoritative name server? If so.. well, there's really not a lot you can do about it being used in reflection, aside from rate limiting queries.

    DNS reflection is a nasty thing for the internet on the whole, but I fail to see why your authoritative DNS server's bandwidth being abused to amplify DDoS traffic has to do with your PCI compliance.

    • 3

  2. Shane Madden's answer above is on point -- you are doing the right thing for recursive service if you are limiting recursion to your own clients and denying it to those outside whatever boundaries you have defined concerning who you serve. Don't operate an open resolver without good reason and if you decide you need to do it for some reason you must actively monitor for abuse and block ASAP; otherwise you are a hazard to other network participants.

    Concerning authoritative service, he is again correct -- there's not much you can do except for response rate limiting (RRL.) [For what it's worth ISC (the authors of BIND, and also operators of the F-root, one of the thirteen root nameservers) -- suffer greatly from this, being one of the chief targets for reflection because the short query length, combined with the large response to an ANY query, make for a substantial amplification factor. We're kind of stuck with it as long as UDP source spoofing remains easy.]

    Regarding your current version (BIND 9.8.1-P1): assuming you are running stock code from ISC, there are a number of outstanding vulnerabilities that affect 9.8.1-P1 that you might want to address. The majority of them, if exploited, result in denial-of-service when the server crashes with an ASSERT or INSIST failure -- BIND 9 is actually designed to crash as soon as it detects an inconsistent state, rather than to continue and possibly risk worse.

    You can find a list of security advisories that apply by consulting the BIND Security Matrix Depending on what features you are using, not all of the vulnerabilities below will necessarily apply, but you should check them nevertheless to be sure. BIND 9.8 is currently at version 9.8.6-P1, or you can upgrade to BIND 9.9.4-P1 and get RRL for free (well, it's an optional compilation, but for the price of an extra command line argument to configure you can have it and help make your authoritative server a less attractive reflection target.)

    CVE Number  Short Description
2013-6320   A Winsock API Bug can cause a side-effect affecting BIND ACLs
2013-4854   A specially crafted query can cause BIND to terminate abnormally
2013-2266   A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
2012-5689   BIND 9 with DNS64 enabled can unexpectedly terminate when resolving domains in RPZ
2012-5688   BIND 9 servers using DNS64 can be crashed by a crafted query
2012-5166   Specially crafted DNS data can cause a lockup in named
2012-4244   A specially crafted Resource Record could cause named to terminate
2012-3817   Heavy DNSSEC validation load can cause a "bad cache" assertion failure
2012-1667   Handling of zero length rdata can cause named to terminate unexpectedly
2011-4313   BIND 9 Resolver crashes after logging an error in query.c
    • 1