[lug] ipfilter DOS

[jd]

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 at 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/documentation/tutorials/blueflux/iptables-tutorial.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 at asu.edu>
> 
> 

Hello, 
  after reading this I would like to apply the "new not SYN" rule. One 
question...if a connection makes it into the connection table, are
anymore packets checked from that connection after the initial matches
that allowed the connections first packet. And it seems that it would
continue to match following packets against the state table when using
-m --state RELATED,ESTABLISHED. So if i logged all "new not SYN" would
this log every packet after the handshake? Should i put
the RELATED,ESTABLISHED before "new not SYN". Just wondering the best
way to apply "new not SYN" and if there is anything I should be aware
of.

thanks allot
jd
jd at taproot.bz

fun: http://www.devnull.bz