Dan Kaminsky described how DNS servers could be poisoned with spoofed DNS responses [1]. As I understand it, the problem was that Kaminsky found a way to account for most other sources of randomness in a DNS query such that the main barrier to an attacker was in guessing the DNS query id (16 bits of entropy) when generating a spoofed response. An attacker could, on average, spoof the response within 32k guesses. So, the recommended mitigation was to randomize the source port, and everyone applied their patches and all was well.
Except that this only brought up the number of guesses from 32k to somewhere between 134m to 4b. Sure, it couldn't be done quickly, but a patient attacker could still do this slowly - in fact, Bert Hubert calculated that an attack at 100qps has 50% chance of success within 6 weeks. [2]
I don't have sufficient reputation to post more links. However, I see that many technical approaches have been considered, such as draft-wijngaards-dnsext-resolver-side-mitigation-01 and draft-vixie-dnsext-dns0x20-00 on tools.ietf.org, RFC5452 as well as the Google Public DNS security docs:
DNS label bit 0x20 (ie, cAsE.gAmEs)
- does Bind do this? I can't believe that Bind wouldn't implement something that Vixie proposed
- still, an attack could force the query of domains whose case cannot be significantly munged. eg. "d293823."
RTT banding, IPv4/IPv6 selection, source address randomisation (from wijngaards)
- I don't think this will add significant entropy, but I'd do it if Bind can.
Authority query for NS/nameserver/A/AAAA after referral (from wijngaards)
- This seems to be an elegant solution. Don't understand the problems with it. It might not be the preferred solution for large scale deployment, but it seems reasonable for my site. Can Bind do this?
Attack mode trouble counter
- Can Bind do this?
- However, if I have a statefull firewall in front of the DNS server, the DNS server's trouble counter will never see spoofed responses arriving with the wrong destination port right?
Fallback to TCP (especially after going into attack mode)
Ask twice/thrice (especially after going into attack mode)
Removing duplicate queries (from Google Public DNS)
Unfortunately, I don't see any configuration options for turning these on even in the latest version of Bind.
So I would like to ask what else can be done to protect against this style of spoofing attacks, specifically when I am running Bind. If the mitigation remains a probabilistic thing, I'd like for the odds to be stacked against the attack succeeding in a million years.
[1] http://s3.amazonaws.com/dmk/DMK_BO2K8.ppt
[2] http://ds9a.nl/har-presentation-bert-hubert-3.pdf slide 24.
Comments
Post a Comment