From owner-freebsd-stable Mon May 6 2: 3:25 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 6253637B405 for ; Mon, 6 May 2002 02:03:02 -0700 (PDT) Received: (qmail 47101 invoked from network); 6 May 2002 09:12:23 -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 09:12:23 -0000 Message-ID: <3CD64534.672CD6A7@liwing.de> Date: Mon, 06 May 2002 10:56:20 +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> 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 > > I do following: I write all global rules at the top of the file/section, > > in this case the 3 lines with "return-unr". Then I specialize in the next > > lines using "quick" rules. > > that's a matter of style, not functionality. i can hardly see the > improvements for a 10 line ruleset here. all entries are "quick", so I do not use more rules as required. Usually I use as less as possible, but sometimes it's better to duplicate sth. to improve readability. > they get matched from top to bottom. the order of processing for > non-quick rules is somewhat different (and affects processing speed, > but that's not the issue here). having a flat matching strategy in a > "personal firewall" style rule set is pretty intuitive, compared to > "global"/"quick" mix'n'match or grouped sub rule sets, but hey, it's his > dsl/isdn router and no rocket science... I have several ethernet/DSL-routers and a ethernet / dedicated line firewall. They all work fine, but I detected some problems with "keep state" when I write some oppositional rules after another, f.e. pass in quick on isp0 proto tcp from any to any port = 80 keep state block in quick all Because of the position of the dynamic added rule there seems sometimes problems... I do not know exactly, I didn't wrote the ipfilter code, cause I'm not darren. I can only tell, what expiriences I made. block in all pass in quick on isp0 proto tcp from any to any port = 80 keep state Does the same as above, but it's really more intuitive (for me): block in all except to (port 80/tcp [, ...]), they are ok. > opposing to your apparent ideas, i implement firewall policies the > following way: > - as simple as possible We all have our own way to understand, to write and to do. > - documented Me too. > - structured by access groups/protocols/services, or both, or all three As required if any changes should be made later ... > - optimized for performance by rule groups, if applicable I hope in that order! > 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. But I got the idea of changed position of dynamic rules inserting (could be speed up permormance, AFAIK, depending on internal structures). > > This works, if I do not write it after the 4th beer. But sometimes even then ;-) > > ...and makes things more complicated by sticking to different rule > matching strategies in a set of 10 or some rules. i can see your point > with the beer, but what do you do after the 8th one, being confronted > with your own rulesets? 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. 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