RE: Security flaw in Stateful filtering ??????

[Sneppe Filip]

Title: RE: Security flaw in Stateful filtering ??????

Yes, it's that time of the month again :-)

Emmanuel Fleury [mailto:[EMAIL PROTECTED]] wrote:
>
>Patrick Schaaf wrote:
>
>> The behaviour is intentional. The reason is "connection pickup". Imagine
>> a situation where the firewall reboots. All active conntracking information
>> will be lost. With the observed behaviour, connections are "relearned"
>> on the fly as they create new traffic.
>
>I simply disagree with you on this point (sorry :-/).
>
>I wouldn't accept to have such a flaw in my firewall just because of
>an hypothetic reboot of one of my gateway !!!!
>
>Of course, I could be wrong, but in this case this 'feature' should be
>highly documented and be disabled as default. IMHO.

Hi Emmanuel,

Please note that connection tracking doesn't just pick up connections
based on ACK packets willy-nilly after hypothetical reboots. So there
really is no security problem whatsoever.

It's all a matter of the policy set by the admin. If you have rules
that say to accept ESTABLISHED packets, and to accept tcp connections
to port 25 of your mailserver's IP address, and if your firewall reboots,
it's not like all of a sudden other ports to the mailserver will open
automagically!

If the mailserver sends a packet with sourceip=it's IP, source port=25,
destip=remote IP, destport= > 1023, it will get dropped, and if
the other end sends a non-SYN packet to port 25, it goes through and the
connection picks up, just like you specified in the rules.

It's a feature I want, and I assume a lot of people want it, since
Checkpoint has been behaving exactly like this for many years.

If you're worried about weird scans, just specify tighter rules
and combine the ESTABLISHED and NEW states with additional checking
of TCP flags.

iptables offers flexibility, not a policy, and one should tailor
netfilter/iptables to one's needs/policy.

Regards,
Filip