From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 28 17:59:31 2005 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.ORG Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C253116A41F for ; Mon, 28 Nov 2005 17:59:31 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id D96C843D45 for ; Mon, 28 Nov 2005 17:59:30 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (fezkly@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id jASHxRNN093198 for ; Mon, 28 Nov 2005 18:59:28 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id jASHxR3q093197; Mon, 28 Nov 2005 18:59:27 +0100 (CET) (envelope-from olli) Date: Mon, 28 Nov 2005 18:59:27 +0100 (CET) Message-Id: <200511281759.jASHxR3q093197@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <43833270.8060502@freebsdbrasil.com.br> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Features enhacement: AND-block and "me" expression on a table... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-ipfw@FreeBSD.ORG List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2005 17:59:32 -0000 Patrick Tracanelli wrote: > Would it be hard to make ipfw processing "and" blocks, just like "or" > blocks? I mean, in the following situation: > > ipfw add deny log tcp from { not 10.10.10.10/32 or not 10.10.10.20/32 } > to any dst-port 22 out via fxp0 setup keep-state > > On my understanding, this rule will *always* match, because the OR block > makes the source always be true, because it *won't* be a orign OR won't > the other be. What if we could have: > > ipfw add deny log tcp from { not 10.10.10.10/32 and not 10.10.10.20/32 } > to any dst-port 22 out via fxp0 setup keep-state First, some small notes: 1. It usually doesn't make much sense to use "keep-state" with deny rules. I suggest you omit it. 2. You can also savely omit the "setup" option. 3. You can omit the /32 bitmask (it's the default). 4. I'm not sure whether you really mean "via". It seems that "xmit" is intended in this case, not "via". 5. And finally, you don't have to write "dst-port" (it doesn't hurt, but I prefer to write rules in a compact way because I think it's more readable when the lines don't have to wrap on a standard 80-columns terminal). Now to your question about an "and" operator. There are several possibilities to do what you want. For example, you could use a byte list: deny log tcp from not 10.10.10.0/24 to any 22 out xmit fxp0 deny log tcp from 10.10.10.0/24{0-9,11-19,21-255} to any 22 out xmit fxp0 Or slightly different (negated byte list): deny log tcp from not 10.10.10.0/24 to any 22 out xmit fxp0 deny log tcp from not 10.10.10.0/24{10,20} to any 22 out xmit fxp0 Or you could use a skipto rule: 100 skipto 300 all from { 10.10.10.10 or 10.10.10.20 } 200 deny log tcp from any to any 22 out xmit fxp0 300 ... Personally I like the latter best, because it's the most flexible solution. It's also easy to read and understand. You can easily place more rules in the range which is skipped over for the two priviledged IP addresses, and you don't have to mention those IP addresses again in every such rule. With careful use of "skipto" rules, it is easy to make very well-structured rule sets. Using "skipto" also often improves performance of the rule set, because fewer rules have to be analyzed for every packet. If you have a lot of rules, it is almost always a good idea to group them into logical units and then use "skipto" to jump into the appropriate groups. Doing that can improve performance by a big factor. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll." -- Frank Klemm, de.comp.os.unix.discussion