Date: Mon, 06 May 2002 15:04:14 +0200 From: Jens Rehsack <rehsack@liwing.de> To: "Karsten W. Rohrbach" <karsten@rohrbach.de> Cc: Michael Riexinger <mailinglists@grindking.de>, freebsd-stable@freebsd.org Subject: Re: ipfilter problem Message-ID: <3CD67F4E.E7A27EEE@liwing.de> References: <20020504223450.GA1025@grind.grind.dom> <20020505152314.B73550@mail.webmonster.de> <20020505133204.GA667@grind.grind.dom> <20020505184630.A76286@mail.webmonster.de> <3CD5B662.26298116@liwing.de> <20020506020820.A82377@mail.webmonster.de> <3CD64534.672CD6A7@liwing.de> <20020506114555.C91849@mail.webmonster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
"Karsten W. Rohrbach" wrote: [...] skipping indoctrination > Jens Rehsack(rehsack@liwing.de)@2002.05.06 10:56:20 +0000: > > Because of the position of the dynamic added rule there seems sometimes problems... > > huh? on ipfilter dynamic rules are always processed before the actual > rule set you supply. the definition of "dynamic rules" for ipf is > "state". see http://coombs.anu.edu.au/~avalon/ipfil-flow.html > it is a matter of _how_ you add state, please read on. I read it. As I already said: I detected some problems not make it clean. And I do not know want you want to say with this... > > block in all > > block in on isp0 all # if you just want to block incoming traffic > # from the isdn interface I like default block. So I deny all by default and allow by rule. > > pass in quick on isp0 proto tcp from any to any port = 80 keep state > > pass in quick on isp0 proto tcp from any to any port = 80 flags S/SA keep state > # we want state added when establishing a > # session, not for every tcp packet that passes > # this rule If you read your own statement above you can cut the flags, because all dynamic rules added "quick" before this rule/line, so this rule is never parsed for any already matched ... [...] > > Does the same as above, but it's really more intuitive (for me): > > block in all except to (port 80/tcp [, ...]), they are ok. > > adding tcp packet state without matching tcp flags causes that you add a > state for every subsequent packet in a session. this doesn't really make > sense. don't try your rules on a live firewall with a heavily loaded web > server behind it - your state table will fill up quite fast ;-) s.o. > > > the main problem here might be that he just had _one_ line for _both_ > > > protocols, tcp and udp, which might lead to trouble in several points. > > > that's a totally different thing. > > I have this too, and there is no problem anywhere. Of course, it could be. > > from my experiences (with firewall code different to ipfilter), it often > is a problem if you combine protocols in one rule. think about how tcp > and udp state is kept; it's a totally different story for both > protocols. Recognized. But it seems to work like C preprocessing to me. The rule with /udp/tcp is expanded to 2 rules with one protocol in one rule. > > But I got the idea of changed position of dynamic rules inserting (could > > be speed up permormance, AFAIK, depending on internal structures). > > yup, but you need quite some throughput to really notice a difference... > on an isdn router you will hardly notice a difference, it's limited to > one or some channels of 64kbit/s which is a piece of cake for nearly > every modern firewall implementation out there. > > > Reading is ok, understanding is ok (as long I can identify the letters :-)), but > > nevertheless I will not write a ruleset to late and use without checking it > > next morning. > > heh, yep... > > also, as a sidenote, ipftest(1) is your friend, regardless of the level > of intoxication ;-) I know, but a good advice in this discussion. > -- > > Microsoft isn't the answer. Microsoft is the question, and the answer is no. Every time a different saying, huh? kind regards Jens -- L i W W W i Jens Rehsack L W W W L i W W W W i nnn gggg LiWing IT-Services L i W W W W i n n g g LLLL i W W i n n g g Friesenstraße 2 gggg 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91 ggg e-Mail: <rehsack@liwing.de> Fax: +49 - 3 45 - 5 17 05 92 http://www.liwing.de/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD67F4E.E7A27EEE>