>> As for the stateful packet filtering, I've always not understood that.
>> So long as you can specify IP flags within your filtering rules, it is
>> technically a stateful firewall. You just need to specify the SYN and
>> FIN flags.
>
> here I have to insist (if you don't mind).
Feel free. This was an open mailing list, last I checked.. :)
> IMHO it is a difference if I allow all packets to high ports that have not
> the SYN (SYN/ACK) Flag(s) or if I only allow the answers of former
> connections. Imagine a sophisticated portscanner like nmap, which plays with
> the flags. Stateful filtering is not so important as often said but this is
> a clear advantage.
My point was that you can "imitate" a stateful filter by specifying
flags. Stateful filtering right in the code makes life a bit easier.
Instead of specifying answers to former connections, you can just
specify that the ACK bit is set. And voila, you've got a "stateful"
firewall. You can still specify ports and such. It's just that the
stateful-ness is being done manually, instead of automagically.
As for nmap, it's now got an option to play with the protocols. So
this should make for some interesting logs in the coming weeks.
> I think, session hijacking is also a bit more difficult through a stateful
> packet filter, but I'm not sure about that.
Again, I'm not too clear on session hijacking, but from all the
theories behind it, I'd say not. All you're doing is sending a few
messages to redirect the source or dest IP (whichever you're taking
over). You don't interrupt the protocol flow. Yes, there is a problem
sending the redirects if a MASQ'ed firewall is being used, but you can
do it without a problem if you've got a copy of an original packet.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
