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.
* Marc Heuse wrote on Fri, Mar 02, 2001 at 01:05 +0100:
Think of all those bloody bastards trying to penetrate your filter by using source ports like 20, 53, 80, and the like.
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 ...)
Could you explain the idea? Autoprotecting sounds... well... insecure? But I have no idea what this could be.
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.
Usually the real important machines/subnets are blocked from such things anyway, or should be ;)
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
I recommend to use kernel 2.2 for first and 2.4 for second packet filter. If a attacker could use a kernel bug to bypass the firewall, the other kernel release usually should not have the same bug (or combine linux and BSD or so).
an additional problem with stateful filters is that people think they have no a magic bullet for security
Well, but that's the same with simple firewalls and virus scanner ("I can open all attachments, I have a virus scanner!").
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>------------------<DMZ> | <internal-router-with-static-ACLs>
Well, but in practise there're still a lot of protocols without good and secure proxies, ain't? HTTP, Mail, DNS and others are no problem, but maybe SMB or NFS (yep, I know VPN :)).
lessons learned: time changes technology. it does not change concepts.
We'll see :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Quoting Steffen Dettmer (steffen@dett.de) on Fri, Mar 02, 2001 at 10:55:53AM +0100:
I recommend to use kernel 2.2 for first and 2.4 for second packet filter. If a attacker could use a kernel bug to bypass the firewall, the other kernel release usually should not have the same bug (or combine linux and BSD or so).
Using two different technologies is theoretically quite a bit better. I would use it on my own systems any time. But only if you can get admins that are proficient in both. Unfortunatley, thare are not enough of those. At most customer sites I see, I start cheering if I see someone competent in at least on technology :-((
an additional problem with stateful filters is that people think they have no a magic bullet for security
Well, but that's the same with simple firewalls and virus scanner ("I can open all attachments, I have a virus scanner!").
Yup! So let's reduce the number of magic bullets and try to educate as many as possible.
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>------------------<DMZ> | <internal-router-with-static-ACLs>
Well, but in practise there're still a lot of protocols without good and secure proxies, ain't? HTTP, Mail, DNS and others are no problem, but maybe SMB or NFS (yep, I know VPN :)).
Hmm, then rething the companies overall policies. Either they do want security or not. SMB or NFS or any oth the other totally uncontrollable protocols with an external network is just no good security practice.
lessons learned: time changes technology. it does not change concepts. Worked for me for the last 10 years
afx -- atsec information security GmbH Phone: +49-89-44249830 Steinstrasse 68 Fax: +49-89-44249831 D-81667 Muenchen, Germany WWW: www.atsec.com May the Source be with you!
participants (3)
-
Andreas Siegert
-
marc@suse.de
-
Steffen Dettmer