Bugtraq mailing list archives
Re: ipfilter denial of service problem
From: Russ Dill <Russ.Dill () asu edu>
Date: 06 Jan 2003 12:08:19 -0700
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/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 () asu edu>
Current thread:
- ipfilter denial of service problem Yiming Gong (Jan 21)
- Re: ipfilter denial of service problem Russ Dill (Jan 06)
- Re: ipfilter denial of service problem Darren Reed (Jan 06)