(UPDATED) DNS Cache Poisoning and Network Address Translation

Posted by Tom Cross on July 10, 2008 at 6:56 PM EDT.

     On July 8th a number of DNS software vendors published security updates which improve the randomness of UDP source port assignments to protect against DNS Cache Poisoning. The following day someone called imipack posted an interesting observation to the Full Disclosure mailing list. He noticed that the UDP source ports for DNS transactions coming from a patched server were still sequential when placed behind a firewall performing Network Address Translation.

     I’m writing this blog post in order to draw more attention to that observation, as I’m not sure that the security industry has realized its full implications. As far as we know, this observation applies to any NAT device, not just the firewall imipack tested, and we think it has significant implications for network architecture. (See update below.)

     When a host on a computer network selects a source port for a UDP request, it selects a port that is unique for that host. When a one-to-many hiding NAT device receives that request and translates it, it has to assign a new source port, because the NAT device has to assign unique ports for all of the hosts on the internal network. X-Force is not aware of any NAT device on the market that randomly selects UDP source ports. Therefore, when patched DNS clients and servers are used behind NAT, they are still vulnerable to attack. The source port entropy introduced by the recent patches is cancelled out by the NAT device.

     It is our opinion that network administrators who have caching internal DNS servers behind NAT should plan to move those servers into a DMZ where they can be directly assigned a unique Internet IP address. Any servers that remain behind NAT devices will remain vulnerable after patches have been applied, and X-Force suspects that given the amount of media attention DNS Cache Poisoning has received this week that an increased frequency of attack is likely in the coming months.

     We’ve also been wondering whether NAT devices ought to randomly assign UDP source ports, although no NAT vendor that we’re aware of has done this to date. Some DNS client software was updated on Tuesday, and while servers might be moved outside of NAT devices, clients will have to remain behind them.

     If clients are relying on random UDP port assignments to protect their security, there is an argument that NAT devices should preserve that randomness. However, this suggestion might not be practical for NAT device vendors to implement, either for performance reasons, or because port assignment is performed at a layer of software abstraction that is outside of that vendor’s control. It will be interesting to see in the coming months how different vendors react to this issue.

(Thanks to Jonathan Lusky for contributing to this post.)

UPDATE:

     In the hours after I originally posted this blog entry to the Full Disclosure list a number of readers, including Riad S. Wahby, wrote in to say that they tested their linux boxes running ipchains and found that they preserved the UDP source port selections made by clients running behind them. I'm not sure what ipchains does when it encounters a collision, but in general I think this is a good strategy, as it preserves the randomness introduced by the client in most cases. You'd have to have many thousands of simultaneous UDP transactions in order for randomly selected source ports to be colliding frequently enough for a poor collision handling strategy to present a substantial security problem.

      On the other hand, I've also been contacted by readers who confirm that other devices besides the firewall in the original post share it's behavior. There appears to be room for some research here into what collision avoidance strategies are employed by different NAT devices, what happens to those devices under high load, and what the security implications are. Fortunately, Linux appears to do a good job with this right now, and provides an example approach that NAT vendors can look to.