DNS Darwinism
This is why yesterday’s DNS vulnerability in Windows server should be a non-issue and in cases where it is an issue, they should be pwned.
Bullet-proof DNS
Any AD crew worth their salt has implemented split-DNS. Ideally that includes non-Windows DNS servers on the public side, which are completely independent (and intentionally ignorant) of the workings of the AD domain on the private side.
The public DNS servers should be distributed and redundant. All public zone transfers should be encrypted. These servers shouldn’t answer queries for domains for which they aren’t authoritative, from hosts they don’t trust.
You could even get fancy and throw in a shadow DNS server that does nothing but maintain a pristine copy of your public zone to replicate one way out to your normal DNS servers.
Draconian Firewall Rules
Firewall rules should be written such that only the DNS servers on the private side can communicate with the DNS servers on the public side, and only on UDP:53 (long replies be damned). This prevents your normal hosts from being redirected to DNS servers outside your network (and thus outside your control).
In this set up, if your internal DNS servers can’t resolve the query, they forward it to the external servers, who forward it on down the line, then back again with the answer. Never do your internal DNS servers talk to an untrusted external DNS server, and never do your hosts talk to an external DNS server, period.
A good write-up on the attack scenario of this vulnerability is here (thanks for the link Scott). In this scenario, the publicly-accessible, Windows DNS server resolves DNS queries for the world, for domains for which it isn’t authoritative. To me this is the perfect storm, the trifecta of blunders; 1. publicly accessible Windows machine*, 2. answering queries from untrusted hosts 3. for domains out of your control.
*Why I believe Windows platforms are more vulnerable than *nix platforms is beyond the scope of this post. Maybe I’ll tackle that in another post.
Your comment about blocking TCP/53 and ‘long replies by damned’ is 100% incorrect and is harmful in the extreme. Instead, DNS servers should be tiered, and public-facing DNS servers simply shouldn’t allow zone transfers from hosts outside one’s own network(s).
Also, firewalls should not be placed in front of public-facing DNS servers; the state of the firewall is a DoS vector. Instead, stateless ACLs (hopefully on an ASIC-based router platform) coupled with tight sysadmin practices and other reaction/mitigation systems (S/RTBH, DDoS scrubbers, etc.) should be utilized as circumstances warrant.
By Roland Dobbins on 11.14.07 9:11 pm
By blocking TCP/53 from leaving my network, I prevent zone transfers from leaving my network at all. In an Active Directory environment, if someone can transfer your zone out of your network they are able to gain an enormous amount of intelligence about your network, which would amount to a ‘check’ situation, with only a few moves to ‘check mate’.
When I said that external DNS servers should be ‘intentionally ignorant’, I was implying a tiered solution, where externally, the DNS infrastructure does not maintain a copy of the internal zone.
I’ve blocked TCP/53 for years and have yet to see a problem arise because of it.
I’m curious how its harmful in the extreme.
You bring up an interesting point about state-full firewalls in front of DNS servers. I would assume that would be a DoS vector for any service, not just DNS. Though I’ll be the first to admit I’m no DNS guru.
By Michael on 11.15.07 10:04 am
I’d also like to add that DoS conditions are of little concern for our shop. In six years working here I’ve only once witnessed a DoS event impact us and it was indirect; one of our hosts was zombified and was trying to participate in a DDoS, which effectively DoS’ed the local network. The cause of that was a worm, which has been a realized threat to us, and one that we’ve spent considerable time and money to combat (quite effectively I might add).
The truth is that we would end up spending an equal amount of time and energy addressing DoS vectors as we have addressing worm vectors and the latter has proven to be a much more worthwhile venture. Our publicly-accessible services are far more *expendable*, for lack of a better word, than are our internal services.
I’ve read some of your information on DoS mitigation and it’s impressive and certainly worth reading for shops who are concerned about DoS mitigation.
By Michael on 11.15.07 10:15 am