iptables, NAT, DNS & Dan Kaminsky - Kernel

This is a discussion on iptables, NAT, DNS & Dan Kaminsky - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: iptables, NAT, DNS & Dan Kaminsky

  1. 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/kerne...494a302b6b9a30
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: iptables, NAT, DNS & Dan Kaminsky

    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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: iptables, NAT, DNS & Dan Kaminsky

    Hi Willy,


    On Wed, Jul 30, 2008 at 21:55, Willy Tarreau 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: iptables, NAT, DNS & Dan Kaminsky

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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: iptables, NAT, DNS & Dan Kaminsky

    On Thu, Jul 31, 2008 at 2:14 PM, Willy Tarreau 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: iptables, NAT, DNS & Dan Kaminsky

    We are drifting from the initial topic, but oh well..

    On Thu, Jul 31, 2008 at 23:36, Ray Lee 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread