you have the option to keep track of connection states. this is an improvement, yes, however not a big one in my opinion Really? Linux users might not be that aware (yet). I myself only learned about the benefits _because_ I did run a stateful
(As I understand then IPtables make an improvement in the "memory" when compared with the stateless IPchains. Is this a good reason for skipping IPchains and start IPtables.....?) packet filter (most things I stumble upon pass by unnoticed by Linux friends). Think of all those bloody bastards trying to penetrate your filter by using source ports like 20, 53, 80, and the like.
thats why I say it's a small improvement. you prevent that people scan ports they should not. but where else is the added security? they can't connect to the services they cleverly found by their stealth scan ... (talking about simple "protection" by source port filtering - this is just stupid to rely on :-) Thats exactly the reason why the AUTOPROTECTING feature exists in SuSEfirewall (which is sadly something no other firewalling script has got ... I can only encourage people to cut'n paste ...)
And no, the "established" keyword cannot really count as an answer. What's the point in passing packets based on a flag the outside(!) sets? You don't believe in sources you want to protect yourself against in the first place, do you? Again, waht happens with packets without a SYN flag where there is no connection for them? Yes they can be used for scanning, but if you have a problem beeing scanned, then you have too many exposed systems anyway.
yep Andi - I'm of the same opinion ...
means of Linux and ipchains. I never would like to go back to stateless filters (read: I *gladly* spend the memory and cpu cycles on the functionality). And yes, it's just one aspect and has to be seen in combination with *all* the other possible hurdles and obstacles one sets up for the bad guys. But why not use the possibilities given? Well, all the stateful systems I have seen so far had interesting bugs (check for PIX and FW-1 state engine bugs in the bugtraq archives). This is an added complexity in the code, which increases the chance for implementation bugs.
hmm why am I replying to andi's mail? I can only 100% agree. I think there was only one bug in the ipfwadm code, and I can not remember a bug in the cisco ACL code, and there was none in the AIX filtering code. However, ip_filter had one or two bugs as well (agreed, not much) and commercial ones much much more - just because complexity is bad for security. this is proven since the 1970s, so keep security always as simple as possible. better chain several simple security mechanisms - thats the best solution. ipfwadm and ipchains were simple. iptables is not simple at all - hell when I wrote SuSEfirewall2, I had to test stuff how iptables/kernel actually work because the documentation is incomplete. Therefore I recommend not to use iptables until we can call 2.4 stable and tested. not before 2.4.10 or something. but that depends on the security level you want to have
Knowing Marc and his experience, I guess he can confirm that from real life audits... Although I think the functionality of stateful filters can be very useful, I am not rushing out to replace prooven systems with it.
an additional problem with stateful filters is that people think they have no a magic bullet for security and then rely on stateful firewalls as a single line of defense. The best firewall setup is still and will still be in 5 years from now: <external-router-with-static-ACLs>--<Application-Gateway-Firewall>--<internal-router-with-static-ACLs> | DMZ-1 (more interfaces for more DMZ's) and putting your e-commerce systems into different security layers in the DMZs. lessons learned: time changes technology. it does not change concepts.