Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    Russ Dill
    Re: ipfilter  denial of service problem
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: ipfilter denial of service problem

    On Sun, 2003-01-05 at 20:15, Yiming Gong wrote:
    > Below is an ipfilter security issue, and my previous mail to author
    > Darren was bounced back, so I think maybe I should mail it to this
    > mailing list.
    >
    > Overview
    > --
    > Anytime ipfilter see a packet with ACK bit set without the previous SYN,
    > it will marked it as TCPS_ESTABLISHED in it's state table, and for
    > ipfilter will soon notice the RESET packet send back by the system
    > application, it will then change it's ttl in state table to 1 minute,OK,
    > it's good.
    >
    > But If an attact send packet with ACK bit set and bad checksum, ipfilter
    > will happily add an "ESTABLISHED" session into it's state table which
    > will wait 120 hours to timeout instead of the normal 1 minutes!
    >
    > So using this way an evil guy can easily destroy the network
    > connection of any system with ipfilter installed in a few minutes!
    >
    >
    > proof of concept
    > --
    > [yiming@security.zz.ha.cn]#hping -s ip.of.spoofedandtrusted.box -A
    > ip.of.target.box -p 22 -c 1 -b
    >
    > you will immediately see a a long wait ttl of 120 hours, like this
    >
    > security.zz.ha.cn,1235 server,22 4/0 tcp 1 40
    > 119:59:48
    >
    > Affected Versions:
    > --
    > I've test the following version of ipfilter
    >
    > IP Filter: v3.4.30
    >
    > IP Filter: v3.4.29 (400)
    >
    >
    > a chinese vesion of these security issue is at
    >
    > http://security.zz.ha.cn
    >
    > Best wishes!


    I'm fairly certain this is a know issue, and a simple "workaround"
    preventing the behavior you describe is possible, the following rule can
    be put in for inbound connections, and then again for outbound
    connections (possibly with a rate limit to allow some such connections,
    but not too many). note that these need to be applied to not just the
    INPUT chain, but also the FORWARD and OUTPUT chains

    http://www.netfilter.org/documentati...html#NEWNOTSYN


    $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
    --log-prefix "New not syn:" $IPTABLES -A INPUT -p tcp ! --syn -m state
    --state NEW -j DROP



    Caution
    The above rules will take care of
    this problem. This is a badly
    documented behaviour of the
    netfilter/iptables project and
    should definitely be more
    highlighted. In other words, a huge
    warning is in it's place for this
    kind of behaviour on your firewall.



    --
    Russ Dill <Russ.Dill@asu.edu>


  2. #2
    Darren Reed
    Re: ipfilter  denial of service problem
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: ipfilter denial of service problem

    In some mail from Yiming Gong, sie said:
    >
    > Below is an ipfilter security issue, and my previous mail to author
    > Darren was bounced back, so I think maybe I should mail it to this
    > mailing list.


    Actually, you consistently sent email to the wrong place, in the wrong
    manner. There's an email address posted on IPFilter's web page, along
    with in the distribution that you could of (and did not) send email to
    about this.

    > Overview
    > --
    > Anytime ipfilter see a packet with ACK bit set without the previous SYN,
    > it will marked it as TCPS_ESTABLISHED in it's state table,


    This only happens if you are using "keep state" rules without "flags S"
    and that is something that I (and others) actively discourage people
    from doing, in general unless they are doing it for a specific reason.

    > and for
    > ipfilter will soon notice the RESET packet send back by the system
    > application, it will then change it's ttl in state table to 1 minute,OK,
    > it's good.
    >
    > But If an attact send packet with ACK bit set and bad checksum, ipfilter
    > will happily add an "ESTABLISHED" session into it's state table which
    > will wait 120 hours to timeout instead of the normal 1 minutes!
    >
    > So using this way an evil guy can easily destroy the network
    > connection of any system with ipfilter installed in a few minutes!


    This is not an IPFilter problem, per se, but a known limitation of
    using any limited resource to allocate state table sessions and is
    not anything new to me (at least). In fact you don't even need to
    use that particular packet sequence to do it. This is being more
    properly addressed in upcoming versions of IPFilter.

    Presently, in order to combat this, IPFilter will goto more effort
    to free up state table entries if it detects the table is full.

    Darren

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics