DNS and NAT (was: DNS and CheckPoint)

[Thomas Cross <tcross () us ibm com>]

I thought imipack's post made an important observation and some readers
might not have grasped its full implications, so I wrote up a blog post on
the subject. The text is copied below.

Thanks,
Tom Cross
IBM X-Force

http://blogs.iss.net/archive/dnsnat.html

-------

    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.

     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.)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/