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
On Wed, Jul 30, 2008 at 04:53:57PM +0200, 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?
>
>
> 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,
you should re-post your question to relevant lists. I think that
the netfilter ML would be more appropriate. The list you posted to
is about Linux kernel development, which has nothing to do with
how to setup iptables rules, so I don't think you'll find useful
answers here, if any. And BTW I don't think that many of the people
reading LKML care a dime about the "exploit" for poorly configured
DNS servers.
Regards,
Willy
Hi Willy,
On Wed, Jul 30, 2008 at 21:55, Willy Tarreau <[email protected]> wrote:
> you should re-post your question to relevant lists. I think that
> the netfilter ML would be more appropriate. The list you posted to
> is about Linux kernel development, which has nothing to do with
> how to setup iptables rules, so I don't think you'll find useful
> answers here, if any.
I also asked said list, but as I am especially concerned about
what kernels versions act in which way, I thought I would try
my luck here, as well.
> And BTW I don't think that many of the people
> reading LKML care a dime about the "exploit" for poorly configured
> DNS servers.
It is an exploit that is being abused as we speak and, unless you
mean source address filtering or the like, has nothing to do with
how the servers are configured (well, unless they are authorative
nameservers, but..).
Thanks,
Richard
Hi Richard,
On Thu, Jul 31, 2008 at 04:59:24PM +0200, Richard Hartmann wrote:
> On Wed, Jul 30, 2008 at 21:55, Willy Tarreau <[email protected]> wrote:
>
> > you should re-post your question to relevant lists. I think that
> > the netfilter ML would be more appropriate. The list you posted to
> > is about Linux kernel development, which has nothing to do with
> > how to setup iptables rules, so I don't think you'll find useful
> > answers here, if any.
>
> I also asked said list, but as I am especially concerned about
> what kernels versions act in which way, I thought I would try
> my luck here, as well.
Then you should wait a bit, there may be a lot of people in holidays.
> > And BTW I don't think that many of the people
> > reading LKML care a dime about the "exploit" for poorly configured
> > DNS servers.
>
> It is an exploit that is being abused as we speak and,
That does not mean that abused servers were properly set up.
> unless you
> mean source address filtering or the like, has nothing to do with
> how the servers are configured
Yes it has. I don't want to enter a DNS debate and I'm not even qualified
for that. But I can't find any reason why you would let your servers offer
public resolving service for outsiders. They must resolve hosted zones for
outsiders, hosted+outside zones for insiders and that's all. So that *should*
be either a non-issue, or a valid reason to fix the issue.
Regards,
Willy
On Thu, Jul 31, 2008 at 2:14 PM, Willy Tarreau <[email protected]> wrote:
>> > And BTW I don't think that many of the people
>> > reading LKML care a dime about the "exploit" for poorly configured
>> > DNS servers.
>>
>> It is an exploit that is being abused as we speak and,
>
> That does not mean that abused servers were properly set up.
Properly configured servers are vulnerable, that's why this is such a
big deal. This a problem with the design of the DNS protocol (&
associated behaviors) itself -- the only mitigation strategy sysadmins
have right now is forcing a randomization of the source port (outside
of the DNS resolver itself), or placing the DNS resolver behind a NAT
masquerading firewall that does strict response dropping if a response
comes from the wrong host. (There used to be an option in the kernel
to deal with that -- loose source routing or somesuch, but I think
that's a by-gone from the 2.4 era.)
So, to answer Richard, yes something like that should work. I'm not an
iptables guru by any means, but what you should do is set up a machine
with that, and sniff the output of the DNS server before and after
enabling that line to verify that it works.
The better solution, of course, is to update your DNS server to allow
it to do the source port randomization itself.
We are drifting from the initial topic, but oh well.. :)
On Thu, Jul 31, 2008 at 23:36, Ray Lee <[email protected]> wrote:
> or placing the DNS resolver behind a NAT
> masquerading firewall that does strict response dropping if a response
> comes from the wrong host. (There used to be an option in the kernel
> to deal with that -- loose source routing or somesuch, but I think
> that's a by-gone from the 2.4 era.)
You do not need a NAT to do this, you simply need to block packets
with a source address that does not match the routes your router has
in his routing table. Other than ISP end-costumers and a few other
very clearly defined situations, this is highly non-trivial, though. Some
people still do this, but in most cases, it has proved impractical and
a source of many 'strange' errors.
> So, to answer Richard, yes something like that should work. I'm not an
> iptables guru by any means, but what you should do is set up a machine
> with that, and sniff the output of the DNS server before and after
> enabling that line to verify that it works.
I know that this is possible.
What I wanted to know is what kernel versions do what [automagically]
and in what way.
> The better solution, of course, is to update your DNS server to allow
> it to do the source port randomization itself.
Of course. But I want to fully understand all cases and this is the last
area I still lack information on.
Thanks,
Richard