[ale] iptables issue

[Jason Lunz]

jimpop at yahoo.com said:
> Just to avoid some further confusion on my part, are these valid
> or not, and what can I add that will stop the block on the occasional 
> outbound FIN:
>
> iptables -A INPUT -p tcp -d WW.XX.YY.ZZ --dport http
>        -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
> iptables -A OUTPUT -p tcp -s WW.XX.YY.ZZ --sport http
>        -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> Thanks, seriously. I'm learning something new here today.

It would be clearer to write these equivalent rules:

iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -d WW.XX.YY.ZZ --dport http
       -m state --state NEW -j ACCEPT

The reason you don't have to mirror the http port match on output is
that it's implied by connection tracking. When you're using stateful
firewalling, the general strategy is to a) only allow new connections
for the services you choose, and b) pass through all packets that are
part of an established connection.

I don't see why you'd need to block any outbound FIN. The purpose of the
FIN packets is for one host to tell the other that it's closed the
session. The FIN sender waits for the FIN packet to be ACKnowledged. If
for whatever reason the other end doesn't ACK (maybe the other end
crashed or went off the net), the FINs will be resent just in case
until some timer expires. If this timer is longer than the timer the
iptables code uses to decide whether to keep tracking the session, it
will think the next FIN isn't part of any session (even though it is).

It's harmless. I'd just ignore them.

Jason