IT Managers: Patch Your DNS Servers


System administrators and IT managers who need to CYA, listen up: You need to patch your DNS servers as soon as possible. For those who haven't patched already (since this has been all over the security blogs and tech news), I wouldn't sit on your hands on this one.

As reported over at Zero Day on ZDNet, there is a working domain server exploit that appears to be doing its thing and could make keeping a site up pretty difficult if attacked.

US-CERT, which is the department of homeland security's Computer Emergency Readiness Team, describes the potential impact as:

An attacker with the ability to conduct a successful cache poisoning attack can cause a nameserver's clients to contact the incorrect, and possibly malicious, hosts for particular services. Consequently, web traffic, email, and other important network data can be redirected to systems under the attacker's control.

As suggested over on Zero Day, IBM's Internet Security Systems group on The Frequency X Blog, has a nice resource page for dealing with this DNS situation. This page gives pretty straightforward advice on how to deal with the issues at hand, including how to locate the vulnerability, how to see if you've been attacked, how to mitigate and what to do if you've been attacked. Here's a snippet of info from IBM ISS:

What do I do to mitigate the vulnerability?
The US-Cert bulletin offers very good advice for mitigation. In general, you need to make sure that your DNS clients and servers are patched. There is an update available for Internet Scanner that will check Microsoft Windows clients and servers for the necessary patches, but you need to check Unix servers as well.

Furthermore, if you have a server behind a NAT device, some NAT devices will undo the UDP port randomness introduced by the patch. Fortunately, Linux iptables and OpenBSD's pf are not vulnerable, but many popular NAT devices are. If you have such a device you can either move your DNS server to a DMZ segment where it need not be NATed, or you can forward requests from that DNS server to a patched server that is not behind the NAT. If you forward make sure that you disable recursion.

If you are unable to patch a server, you can mitigate some attack vectors by forwarding requests from that server to a patched server. OpenDNS is one example of a patched DNS service that will accept forwards. Again, if you forward make sure that you disable recursion.

If you are relying on your ISP's DNS infrastructure, either directly, or through a forward, and the testing tools above are indicating that you are vulnerable, you may need to escalate the issue with your ISP.

DNS flaws are not really to be taken lightly, and I doubt that you do. If you outsource the management of DNS to your local telco or other provider, you'll need to get some legitimate confirmation that they are patching this flaw because according to some of the folks that track this stuff, there doesn't appear to be a lot of movement on patching from the telcos so far.

This is not a risk that should be ignored or put on the back burner of priorities. The main thing here is to not get caught in a situation where your sites are down and your management is calling emergency meetings on critical, publicly-visible, revenue-based Web sites.

If you're in to the inside-baseball of the security industry, there's a back story to these flaws that you can follow that's interesting. It's driven by a combination of secrecy, bravado and competitive drama. Most vendors in the industry employ some very bright, highly-skilled technicians who get drawn in to the show of hacking and patching. And, much like the open-source community, the ethics of what to communally expose and what to use for business are often at odds with each other.

It brings up a few issues: -Should you control your own DNS? -If not, are you confident in its security with a telco or other DNS outsourcer? -Are they responsive to your security concerns?

Let me know your take on the DNS situation.

Also, make sure to fully read the US-CERT information on this DNS flaw. It's very straightforward and resourceful.