Re: [Bastille-linux-discuss] iptables and --syn

[Michael R. <mb...@ci...>]

On Jul 31, 2001, Peter W wrote:

> On Tue, Jul 31, 2001 at 11:15:49AM -0400, Michael Rash wrote:
> > bastille-netfilter sets up the stateful stuff like this:
> > 
> > ${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > 
> > ....and accepts traffic to tcp ports like this:
> > 
> > ${IPTABLES} -A INT_IN -p tcp --dport ${serv} -j ACCEPT
> > 
> > Suppose we are running the firewall on a webserver, so we will allow anyone
> > to "connect" to port 80.  What happens if someone sends, say, a syn/fin 
> > packet to port 80?  The stateful rule will not match it since this packet 
> > cannot be recognized as part of an existing session tcp session and hence
> > will pass it down to the "${IPTABLES} -A INT_IN -p tcp --dport 80 -j ACCEPT"
> > rule, which will happily accept it. 
> 
> So what? The attacker learns what they could have learned from a normal TCP 
> connect scan: there's something on port 80.
> 
> > How about including the --syn option in
> > "${IPTABLES} -A INT_IN -p tcp --dport ${serv} -j ACCEPT" line?  If a proper
> > syn packet is received, this will rule accept it and all subsequent packets
> > of a proper session will be matched on the stateful rule.  Any other suspect
> > traffic will be caught by the deny rule.
> 
> Please check the list archives (and the netfilter users & dev archives) for 
> more discussion of this, but the basic problem is this:
>  - the conntrack state table is limited
>  - if it fills and we rely on the -m state rule for subsequent packets,
>    then the conntrack table filling results in your public services being
>    *needlessly* blocked.[0]

Ok, I went through a good portion of the netfilter archives and understand
the issue a little better and I see your point about services being blocked 
if we only allow incoming packets that match --syn after the state table is
maxed out.

> In my mind, having the service reliably available is more important than 
> denying stealthy/suspect packets destined for those open services. Though 
> we'll catch some of those once we add the PURGATORY table where we can spike 
> things like XMAS/NULL scans.

Here is a possible alternative (this is really messy, but it has a couple of
advantages):

Write a separate daemon that 1) counts the number of connections in
/proc/net/ip_conntrack and compares this value against the maximum total
connections allowed in /proc/sys/net/ipv4/ip_conntrack_max and if the 
difference is smaller than some threshold 2) kill the state rule, reload
the ipt_state and ip_conntrack modules, and reload the state rule.  (I 
could not find a reference in the archives as to how to clear the state
table but reloading the module certainly works... is there a better way?)

This approach would have the advantages of 1) making it easier to write 
iptables rules that catch bad packets since then we would not need to 
anticipate all of the possible combinations of the tcp flags that could be 
bad with the PURGATORY table, and 2) administrators that really want
all packets to be included within the state table at the expense of the 
sessions that will be dropped/rejected as the modules/rules are reloaded
will have a piece of code available.  Also, for most home users it will 
probably be generally fairly difficult to max out the state table...

--Mike

Michael B. Rash
http://www.cipherdyne.com