From owner-freebsd-stable Mon May 6 6:11: 3 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.liwing.de (mail.liwing.de [213.70.188.162]) by hub.freebsd.org (Postfix) with ESMTP id DAB1037B404 for ; Mon, 6 May 2002 06:10:54 -0700 (PDT) Received: (qmail 6544 invoked from network); 6 May 2002 13:20:19 -0000 Received: from stingray.liwing.de (HELO liwing.de) ([213.70.188.164]) (envelope-sender ) by mail.liwing.de (qmail-ldap-1.03) with SMTP for ; 6 May 2002 13:20:19 -0000 Message-ID: <3CD67F4E.E7A27EEE@liwing.de> Date: Mon, 06 May 2002 15:04:14 +0200 From: Jens Rehsack Organization: LiWing IT-Services X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Karsten W. Rohrbach" Cc: Michael Riexinger , freebsd-stable@freebsd.org Subject: Re: ipfilter problem 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> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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: 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