Suppose:

 1. Dan Kaminsky's recently announced DNS cache poisoning vulnerability
    is anywhere near as serious as he and others have made it out to be,
    and

 2. Simple UDP source port randomization of DNS requests is indeed
    sufficient to mitigate the vulnerability.

I think we have little reason to doubt the first point, given the
response to this bug of those credible individuals and companies already
privy to its details.  If we assume the second point as well, then users
of OpenBSD's named may be interested a simple workaround that uses PF to
implement source port randomization on behalf of named, until OpenBSD
has the chance to release a patch of the usual quality & reliability.
Such a workaround can be implemented with a single NAT rule in pf.conf,
as Jon Hart has described:

http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html

The configuration line in question:

    nat on $WAN_IF inet proto { tcp, udp } from a.b.c.d to any \
        port 53 -> a.b.c.d

Or, if you have a dynamic IP address on a cable modem, etc.:

    nat on $WAN_IF inet proto { tcp, udp } from ($WAN_IF) to any \
        port 53 -> ($WAN_IF)

Of course, this won't help at all if your resolver is behind a NAT on
another box that performs source port rewriting; in that case, you'll
need to take a look at your outermost NAT instead and make sure its port
rewriting is "random enough" to keep you safe.  PF is fine, for
instance, but many consumer-oriented NAT routers -- e.g., the D-Link
WBR-1310 -- rewrite port numbers sequentially, which is Bad.  Linux
iptables NAT is a special case: it does not rewrite source port numbers
by default, unless a collision occurs.

-- 
Mark Shroyer
http://markshroyer.com/contact/

Reply via email to