DNS Survivial Guide
Posted by simonw on Mon 14 Jul 2008 at 10:38
Hopefully you've all heard of CERT VU#800113, this is for people who didn't understand it.
What is wrong?
We don't know as the issue hasn't been fully disclosed.
But we know that the DNS protocol is vulnerable to attack because the way a DNS response is validated is to check the transaction ID ( hence forth called "TXID") a 16 bit number sent with a request, matches the TXID in the answer.
- The response needs to come from the IP address the request was sent to.
- It needs to come back from port 53 on the remote server, to the port that sent the request.
- It needs to have the same TXID.
- It needs to answer the question asked (in some way?! It can contain additional information!).
- It needs to arrive first, since the first answer that matches will be accepted and close down the outstanding query.
If you can observe the DNS queries on the wire, you can just read the TXID and send back the packet expected.
If you can't observe the DNS queries, but you can force the resolver to query one of your DNS servers, you know IP address, and source port. Thus all you need to spoof the query is to guess a TXID, and some luck in getting your spoofed answer back before the genuine one (a quick DDoS attack on the real authoritative servers might help here!). Given there are only 65536 TXIDs you'll hit lucky one times in 65536, which means it isn't that hard to do even without whatever Dan's great announcement is.
The recommended "hack" (it is not a proper fix) is to enable source port randomisation. So that the query may come from any port in the ephemeral port range, so that we now have 65536 x [size of emphemeral port range]. My estimate is this takes a naive spoofing attempt with a million spoofed packets arriving in timely fashion a day to a recursive resolver from a few hours to succeed in a spoof, to a few years, on a typical Debian DNS server running BIND9.
This fix does nothing to protect you against the attack where the DNS query can be inspected by the bad guys, you'll have to live with that one for the moment (you have done till now!).
What is the ephemeral port range for IPv4 on recent Linux kernels?
$ cat /proc/sys/net/ipv4/ip_local_port_range # My system has: $ cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000
What to do?Patch!
Dan Bernstein's dnscache has always used source port randomisation.
With BIND you want to be running 9.5.0-p1
This is already released for Debian see: http://www.debian.org/security/2008/dsa-1603. Thus all Debian servers running Etch, Lenny or Sid, which are fully patched should be fine.
I don't run a recursive DNS server - could this affect me?
Well someone runs a recursive DNS server for you!
For example my broadband router at home will forward DNS queries to a couple of DNS servers run by Entanet. When I tested I found that people connecting to my router (and relying in its DNS settings) were having their DNS queries forwarded to DNS servers that aren't yet patched.
How can I check if my recursive resolvers are fixed?
Duane Wessels put together a nice little checker here....
$ dig +short porttest.dns-oarc.net TXT
Duane's checker is handy, as you can use the "dig @IP.AD.DR.ES" syntax to check all the name servers in your /etc/resolv.conf file without having to comment the others name servers out.
A Good result for 10.254.239.1
$ dig +short @10.254.239.1 porttest.dns-oarc.net txt z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "22.214.171.124 is GOOD: 26 queries in 4.3 seconds from 26 ports with std dev 16739.26" $ dig +short @10.254.239.1 version.bind chaos txt "9.5.0-P1"
A not so good result for my ISPs name servers (I'm sure they'll upgrade them soon)
$ dig +short @126.96.36.199 porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. 60 IN TXT "188.8.131.52 is POOR: 26 queries in 45.9 seconds from 1 ports with std dev 0.00" $ dig +short @184.108.40.206 version.bind chaos txt "8.4.7-REL"
What else could/should be done?
Ultimately DNS needs proper security - one proposal is DNSSEC. DNSSEC uses cryptographic signatures to validate the answers. This would stop both types of attack discussed above, but at the cost of increased complexity in the management of domain names.
ISPs also need to prevent spoofing of IP addresses. The attack outlined only works if you can spoof the source address on the response packets. In well run ISP networks this behaviour is prevented by appropriate routing configuration.Best Current Practice: Network Ingress Filtering - May 2000
Other - until the details are released we can't know for sure the scope of the problem. All we know is people entrusted with the DNS are taking it seriously. Although given how bad current exploitation of DNS spoofing could be it is hard to imagine how it could get much worse than the obvious. On the upside it is still considered too much like hard work by the many spammers and other bad guys, but that is probably a reflection on how easy it is to own half a millions websites by SQL injection.