Re: iptables, NAT, DNS & Dan Kaminsky

[Michael Rash <mbr@cipherdyne.org>]

On Jul 30, 2008, Richard Hartmann wrote:

> Hi all,
> 
> as you are very likely all aware, Dan Kaminsky uncovered a major exploit
> in RFC-compliant DNS caching servers the successful execution of which
> relies on port prediction/guessing.
> 
> After quite some research, I have come up with the following facts which
> I want to cross-check with you guys so I can be _sure_.
> 
> 
> 1) The --random target for SNAT exists since 2.6.22 to allow 'fixing' of
> broken DNS servers in your NATted LAN along the lines of
> 
> iptables -t nat -I POSTROUTING 1 -p udp -s 1.2.3.4 --dport 53 -j SNAT \
> --to 1.2.3.4 --random
> 
> Is that correct?

Yes (but see below) - you may be interested in this post:

http://www.cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html

> 2) Unless there is a collision, the original UDP source ports for
> requests are kept the same. I.e. boxes within the NATted LAN which use
> random UDP ports are secure and neither the 2.4.x nor the 2.6.x series
> of kernels will make those ports predictable while NATting the packets.
> Is that correct?
> 
> 
> 3) Ever since a commit that went into 2.6.24 [1], UDP ports that are
> NATted are randomized by the NATting forewarder, anyway. This means that
> any DNS lookup made from within a NATted LAN secured with iptables to a
> DNS server outside of said NAT is secure by default.
> Is that correct?

That commit applies to the UDP stack itself and is independent of any
iptables NAT functionality.  That is, the source port assigned to a
local UDP socket is randomized, but only if a bind() does not otherwise
request a specific source port.  You can also use the SNAT --random
option in an iptables rule to force a random source port even for those
applications that request a specific source port (the blog post above
has an example of this).

There is also another important factor for the attack which is that any
nameserver that is behind a NAT device that removes any randomness that
the server builds into the UDP source port (regardless of whether this
is accomplished by a patched nameserver or something like the SNAT
--random option is used) will once again make the server vulnerable (at
least from the source port predictability problem).  At this point
randomized transaction ID's become really important - and insufficient.

BTW, I emailed Dan about the first version of his DNS checker tool (see
http://www.doxpara.com) not accounting for cases where the targeted
nameserver is behind something like the SNAT --random feature.  The
source port appears to be predictable because of iptables state
tracking, but only if one testing server is used - Dan has since updated
the DNS checker to use five different testing servers, so the change in
the tuple means the different source ports are assigned and the checker
detects this.

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

> 
> 
> Thanks for any and all input. I am sure many people would like
> clarification on those points.
> 
> Richard
> 
> 
> [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html