linux-kernel - iptables, NAT, DNS & Dan Kaminsky

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Jul 2008 16:53:57 +0200
From:	"Richard Hartmann" <richih.mailinglist@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: iptables, NAT, DNS & Dan Kaminsky

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?

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?

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/