Re: iptables 'syn but not new' packets

[Blue Boar <BlueBoar () thievco com>]

> .html#AEN1632 ). It explains that iptables CAN recognize packets that
> have the syn bit OFF as state NEW. The author of the document recomends:
<snip>
>      That makes completly sense. NEW packets with syn bit turned off
> should never exists in real world.

A packet with only SYN is the definition of a new connection.  The NEW
here must refer to the iptables state table, i.e. it's new to ipfilter.

>      Questions are: Do somebody here have ever studied about this
> 'feature' of iptables ?? Can you imagine some problem generated by this
> rule ??

Note: I haven't used ipfilter yet, so I'm speculating.  However, I think
I have a pretty good idea of what's going on.

If you've got load-balancing firewalls (like in the example you gave), or
if you happen to reload iptables in the middle of the day... what happens
to your connections?  What if you were in the middle of downloading a
650MB ISO image?  If you restart the firewall, when it comes back
with an empty table, no SYN packet would have been seen, and the connection
will be blocked.

However, if you add a feature like the above, it can then add an entry
to the table, and permit the rest of the connection.  The obvious
question is: how does the firewall know that this is the continuation
of a previous connection, or if it's an attacker trying to play games?

One way it can do so is to allow a packet, or form of a packet into
the inside machine.  If the inside machine sends an ACK that matches,
then it was previously having that conversation.  If it sends a RST, then
someone is trying to spoof.

Firewall-1 has had this feature for some time.  I read recently that 
OpenBSD's new PF firewall can do this.  This is why I allowed the post..
I suspect there is some fun to be had with this feature, in various
implementations.

                                        BB