Hi,
many thanks. Is version 4.3 based on the IPtables?....and you mean SuSE 7.1?
SuSEfirewall is solely based on ipchains (which also works with the 2.4 kernel). SuSEfirewall2 will solely be based on iptables (first alpha end of this week on my homepage [www.suse.de/~marc]
(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.....?)
you have the option to keep track of connection states. this is an improvement, yes, however not a big one in my opinion
Is the any more description for v.2.6 to learn aboat the possibilities? Or should I dig into the script SuSEfirewall to discover the "variables"?
if you want to learn about tcp/ip kernel functions and weird for() loops for ipchain rules generation, go for it (/sbin/SuSEfirwall) :-) but susefirewall2 will be nicer :)
How does SuSE react to the emerging security issues, namely does there is a internal patch development, or do you rely on the public resources?
SuSE was the first linux vendor with an own security team for auditing and research, and still has got the biggest team. Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
On Tue, Feb 27, 2001 at 18:03 +0100, Marc Heuse wrote:
(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.....?)
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 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. Think of the "symmetric" and "unconditional" rulesets we see here on a regular basis to "let anything out and let anything in" no matter if it's some request or some response. I have yet to see an ipchains ruleset to "let me do anything I want while nobody can get in" ... I feel it to be a *huge* improvement to have the notion of "let the answer in if and _only_ if I asked _this_ machine before to send me an answer". 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? Once more I point the gentle reader to the www.ipfilter.org site and especially to the HowTo. It's of interest not only to ipf users. And now that Linux has a stateful filter, too, it's not only about "look what you're missing" but "look what you can make use of, too". :> It definitely gives me much more warm fuzzies to have a *very* selective filter in place. Of course it cannot solve all my problems, but it's better than anything I could have done by 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? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Quoting Gerhard Sittig (Gerhard.Sittig@gmx.net) on Wed, Feb 28, 2001 at 04:20:54AM +0100:
On Tue, Feb 27, 2001 at 18:03 +0100, Marc Heuse wrote:
(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.....?)
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 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.
So what. Use proxies and that doesn't bother you. Thinking of a firewall as packet filtering only is the wrong way to go.
Think of the "symmetric" and "unconditional" rulesets we see here on a regular basis to "let anything out and let anything in" no matter if it's some request or some response. I have yet to see an ipchains ruleset to "let me do anything I want while nobody can get in" ...
I feel it to be a *huge* improvement to have the notion of "let the answer in if and _only_ if I asked _this_ machine before to send me an answer".
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.
It definitely gives me much more warm fuzzies to have a *very* selective filter in place. Of course it cannot solve all my problems, but it's better than anything I could have done by 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. Knowing Marc and his experince, 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. cheers 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 -
Gerhard Sittig -
marc＠suse.de