From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 1 11:01:58 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 9973716A429 for ; Mon, 1 Aug 2005 11:01:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 442E943D45 for ; Mon, 1 Aug 2005 11:01:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j71B1w36017177 for ; Mon, 1 Aug 2005 11:01:58 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j71B1vUw017171 for freebsd-ipfw@freebsd.org; Mon, 1 Aug 2005 11:01:57 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Aug 2005 11:01:57 GMT Message-Id: <200508011101.j71B1vUw017171@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 11:01:58 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/05/11] bin/80913 ipfw /sbin/ipfw2 silently discards MAC addr ar 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/29] kern/73276 ipfw ipfw2 vulnerability (parser error) o [2005/02/01] kern/76971 ipfw ipfw antispoof incorrectly blocks broadca o [2005/05/05] kern/80642 ipfw [patch] IPFW small patch - new RULE OPTIO o [2005/06/28] kern/82724 ipfw [patch] Add setnexthop and defaultroute f 4 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 1 11:02:56 2005 Return-Path: X-Original-To: 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 9AE6916A41F for ; Mon, 1 Aug 2005 11:02:56 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE8C543D5D for ; Mon, 1 Aug 2005 11:02:45 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j71B2jsS017739 for ; Mon, 1 Aug 2005 11:02:45 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j71B2if7017733 for ipfw@freebsd.org; Mon, 1 Aug 2005 11:02:44 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Aug 2005 11:02:44 GMT Message-Id: <200508011102.j71B2if7017733@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 11:02:56 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp o [2003/12/11] kern/60154 ipfw ipfw core (crash) o [2004/03/03] kern/63724 ipfw IPFW2 Queues dont t work o [2004/11/13] kern/73910 ipfw [ipfw] serious bug on forwarding of packe o [2004/11/19] kern/74104 ipfw ipfw2/1 conflict not detected or reported f [2004/12/25] i386/75483 ipfw ipfw count does not count 7 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/26] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/30] kern/60719 ipfw ipfw: Headerless fragments generate cryp o [2004/08/03] kern/69963 ipfw ipfw: install_state warning about already o [2004/09/04] kern/71366 ipfw "ipfw fwd" sometimes rewrites destination 9 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 2 16:47:53 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 9BB1616A41F for ; Tue, 2 Aug 2005 16:47:53 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from mail.spaingsm.com (llwb135.servidoresdns.net [217.76.137.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F3743D45 for ; Tue, 2 Aug 2005 16:47:52 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from SERVEREL (unknown [85.120.13.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.spaingsm.com (Postfix) with ESMTP id C561C24C899 for ; Tue, 2 Aug 2005 18:35:54 +0200 (CEST) Date: Tue, 2 Aug 2005 19:48:26 +0300 From: vladone X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1881102745.20050802194826@spaingsm.com> To: Oliver Fromme In-Reply-To: <200507281659.j6SGxkXx059613@lurza.secnetix.de> References: <200507281659.j6SGxkXx059613@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 16:47:53 -0000 Please, explain more clearly, what u want to do? P.S. looks very strange "out not recv any xmit" From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 2 17:46:09 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 B5B5C16A41F for ; Tue, 2 Aug 2005 17:46:09 +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 202F443D55 for ; Tue, 2 Aug 2005 17:46:08 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (stojuz@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j72Hk6BM006761; Tue, 2 Aug 2005 19:46:07 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j72Hk6Wq006760; Tue, 2 Aug 2005 19:46:06 +0200 (CEST) (envelope-from olli) Date: Tue, 2 Aug 2005 19:46:06 +0200 (CEST) Message-Id: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG, vladone In-Reply-To: <1881102745.20050802194826@spaingsm.com> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-ipfw@FreeBSD.ORG, vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:46:09 -0000 vladone wrote: > Please, explain more clearly, what u want to do? What exactly was unclear in my description? > P.S. looks very strange "out not recv any xmit" It's perfectly valid syntax according to ipfw(8). "out not recv any xmit dc0" consists of three options (i.e. match patterns): 1. "out" --> match only outgoing packets. 2. "not recv any" --> match packets that haven't been received through any interface (i.e. which originate from the local host). It's simply a negation of "recv any", see the ipfw(8) manpage. 3. "xmit dc0" --> match packets which are going to be transmitted through the dc0 interface. However, the problem is that the second option is being ignored, and I would like to know why, and how to work- around the bug. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 2 18:35:36 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 250C016A41F for ; Tue, 2 Aug 2005 18:35:36 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C84543D69 for ; Tue, 2 Aug 2005 18:35:31 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j72IZUPd026531 for ; Tue, 2 Aug 2005 20:35:30 +0200 Message-ID: <42EFBCDC.6090900@wm-access.no> Date: Tue, 02 Aug 2005 20:35:08 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> In-Reply-To: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=AE7F1636 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 18:35:36 -0000 Oliver Fromme wrote: > However, the problem is that the second option is being > ignored, and I would like to know why, and how to work- > around the bug. > Would this work?: # ipfw add pass ip from me to $N out xmit xl0 -- Sten Daniel Sørsdal From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 2 21:32:16 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 422DC16A41F for ; Tue, 2 Aug 2005 21:32:16 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D671943D68 for ; Tue, 2 Aug 2005 21:32:13 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j72LWCix074139; Tue, 2 Aug 2005 14:32:12 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j72LWBN7074138; Tue, 2 Aug 2005 14:32:11 -0700 (PDT) (envelope-from rizzo) Date: Tue, 2 Aug 2005 14:32:11 -0700 From: Luigi Rizzo To: freebsd-ipfw@freebsd.org, vladone Message-ID: <20050802143211.A74003@xorpc.icir.org> References: <1881102745.20050802194826@spaingsm.com> <200508021746.j72Hk6Wq006760@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508021746.j72Hk6Wq006760@lurza.secnetix.de>; from olli@lurza.secnetix.de on Tue, Aug 02, 2005 at 07:46:06PM +0200 Cc: Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 21:32:16 -0000 ok, so the problem is the following: when i implemented ipfw2 i thought that 'recv any' or 'xmit any' were effectively NOPs so the parser erroneously removes them, together with any 'not' prefix (which is processed before). To fix this one should - patch the function ipfw2.c:fill_iface() so that an argument of 'any' puts some special pattern in the ipfw_insn_if (e.g. an * in the first char of name[] should suffice as i doubt it is a legal interface name). cmd->o.len |= F_INSN_SIZE(ipfw_insn_if); /* Parse the interface or address */ if (!strcmp(arg, "any")) - cmd->o.len = 0; /* effectively ignore this command */ + cmd->name[0] = '*'; /* any interface */ else if (!isdigit(*arg)) { - patch the O_XMIT... case in ipfw2.c:show_ipfw() to print the special value above as 'any'; else /* if (cmd->opcode == O_VIA) */ s = "via"; if (cmdif->name[0] == '\0') printf(" %s %s", s, inet_ntoa(cmdif->p.ip)); + else if (cmdif->name[0] == '*') + printf(" %s any", s); else if (cmdif->p.unit == -1) printf(" %s %s*", s, cmdif->name); - patch sys/netinet/ip_fw2.c:iface_match() so that a '*' in the first char of name[] and a non-null ifp returns 1; if (ifp == NULL) /* no iface with this packet, match fails */ return 0; /* Check by name or by IP address */ if (cmd->name[0] != '\0') { /* match by name */ + if (cmd->name[0] == '*') + return 1; /* Check unit number (-1 is wildcard) */ if (cmd->p.unit != -1 && cmd->p.unit != ifp->if_unit) return(0); if you want to try, this should be all cheers luigi On Tue, Aug 02, 2005 at 07:46:06PM +0200, Oliver Fromme wrote: > vladone wrote: > > Please, explain more clearly, what u want to do? > > What exactly was unclear in my description? > > > P.S. looks very strange "out not recv any xmit" > > It's perfectly valid syntax according to ipfw(8). > > "out not recv any xmit dc0" consists of three options > (i.e. match patterns): > > 1. "out" --> match only outgoing packets. > > 2. "not recv any" --> match packets that haven't been > received through any interface (i.e. which originate > from the local host). It's simply a negation of > "recv any", see the ipfw(8) manpage. > > 3. "xmit dc0" --> match packets which are going to be > transmitted through the dc0 interface. > > However, the problem is that the second option is being > ignored, and I would like to know why, and how to work- > around the bug. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > > (On the statement print "42 monkeys" + "1 snake":) By the way, > both perl and Python get this wrong. Perl gives 43 and Python > gives "42 monkeys1 snake", when the answer is clearly "41 monkeys > and 1 fat snake". -- Jim Fulton > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 2 22:20:34 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 BA9F016A41F for ; Tue, 2 Aug 2005 22:20:34 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from mail.spaingsm.com (llwb135.servidoresdns.net [217.76.137.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FC6D43D45 for ; Tue, 2 Aug 2005 22:20:34 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from SERVEREL (unknown [85.120.13.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.spaingsm.com (Postfix) with ESMTP id EDCE624C8A3 for ; Wed, 3 Aug 2005 00:08:34 +0200 (CEST) Date: Wed, 3 Aug 2005 01:20:52 +0300 From: vladone X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1931204423.20050803012052@spaingsm.com> To: Oliver Fromme In-Reply-To: <200507281659.j6SGxkXx059613@lurza.secnetix.de> References: <200507281659.j6SGxkXx059613@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 22:20:34 -0000 I dont understand u! If have an rule for filter traffic incoming to server, why put options for "incoming" and "not outgoing"? From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 00:51:57 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 CE2AA16A41F for ; Wed, 3 Aug 2005 00:51:57 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1790B43D46 for ; Wed, 3 Aug 2005 00:51:56 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from [200.152.82.190] (nbr.matik.com.br [200.152.82.190]) by msrv.matik.com.br (8.13.1/8.13.1) with ESMTP id j730pvYt013182 for ; Tue, 2 Aug 2005 21:51:57 -0300 (BRST) (envelope-from asstec@matik.com.br) From: AT Matik To: freebsd-ipfw@freebsd.org Date: Tue, 2 Aug 2005 21:51:45 -0300 User-Agent: KMail/1.8.1 References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> In-Reply-To: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508022151.45925.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 00:51:57 -0000 On Tuesday 02 August 2005 14:46, Oliver Fromme wrote: > > P.S. looks very strange "out not recv any xmit" > > It's perfectly valid syntax according to ipfw(8). (1+1-1)/1 also ... ;) > > 1. "out" --> match only outgoing packets. > > 2. "not recv any" --> match packets that haven't been > received through any interface (i.e. which originate > from the local host). It's simply a negation of > "recv any", see the ipfw(8) manpage. > > 3. "xmit dc0" --> match packets which are going to be > transmitted through the dc0 interface. > even if I agree to your logic aspect in general I thought out and xmit is probably exactly the same still especially as you set src-ip and dst-ip so the interface where this packages are xmit is defined by the routes localhost normally runs on lo0 which is an interface as any other so which ghost packages you try to catch here? probably this rule you try is a deny all rule since any package is beeing received by some IF before it can go out or xmit Hans A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 08:25:18 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 8BEEC16A41F for ; Wed, 3 Aug 2005 08:25:18 +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 E6F9443D46 for ; Wed, 3 Aug 2005 08:25:17 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dapatm@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j738PFr7008845 for ; Wed, 3 Aug 2005 10:25:16 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j738PFg7008844; Wed, 3 Aug 2005 10:25:15 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Aug 2005 10:25:15 +0200 (CEST) Message-Id: <200508030825.j738PFg7008844@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <42EFBCDC.6090900@wm-access.no> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Another bug in IPFW@ ...? 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: Wed, 03 Aug 2005 08:25:18 -0000 Sten Daniel Sørsdal wrote: > Oliver Fromme wrote: > > However, the problem is that the second option is being > > ignored, and I would like to know why, and how to work- > > around the bug. > > Would this work?: > > # ipfw add pass ip from me to $N out xmit xl0 No. It wouldn't check the (non-existing) incoming interface. The "from me" pattern does not check any interfaces. It only checks that the source IP in the packet is one of the locally configured IP addresses. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 08:30:45 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 1ADB216A41F for ; Wed, 3 Aug 2005 08:30:45 +0000 (GMT) (envelope-from nicolas@i.0x5.de) Received: from pc5.i.0x5.de (n.0x5.de [217.197.85.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E13343D48 for ; Wed, 3 Aug 2005 08:30:43 +0000 (GMT) (envelope-from nicolas@i.0x5.de) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 117CE81C2A; Wed, 3 Aug 2005 10:30:41 +0200 (CEST) Date: Wed, 3 Aug 2005 10:30:41 +0200 From: Nicolas Rachinsky To: freebsd-ipfw@FreeBSD.ORG Message-ID: <20050803083040.GB89059@pc5.i.0x5.de> Mail-Followup-To: freebsd-ipfw@FreeBSD.ORG References: <42EFBCDC.6090900@wm-access.no> <200508030825.j738PFg7008844@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200508030825.j738PFg7008844@lurza.secnetix.de> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: A32C2932 (Communication) and F66AFAF2 (Certification) X-PGP-Fingerprint1: 97EB FA8B 4C8F A54B D89A 697E A6BC AF72 A32C 2932 (Comm.) X-PGP-Fingerprint2: 1DE8 DF23 56F0 3E14 238D 740C E598 C87E F66A FAF2 (Cert.) X-PGP-Keys: http://www.rachinsky.de/nicolas/pgp/nicolas_rachinsky.asc User-Agent: Mutt/1.5.9i Cc: Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 08:30:45 -0000 * Oliver Fromme [2005-08-03 10:25 +0200]: > Sten Daniel Sørsdal wrote: > > Oliver Fromme wrote: > > > However, the problem is that the second option is being > > > ignored, and I would like to know why, and how to work- > > > around the bug. > > > > Would this work?: > > > > # ipfw add pass ip from me to $N out xmit xl0 > > No. It wouldn't check the (non-existing) incoming interface. > The "from me" pattern does not check any interfaces. It only > checks that the source IP in the packet is one of the locally > configured IP addresses. ipfw add deny ip from me to any in ipfw add pass ip from me to $N out xmit xl0 But I would like the 'not recv any' feature, too. At the moment I use a static list. Nicolas From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 08:35:40 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 2C23016A41F for ; Wed, 3 Aug 2005 08:35:40 +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 085DC43D53 for ; Wed, 3 Aug 2005 08:35:38 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (nefezk@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j738Zb79009263 for ; Wed, 3 Aug 2005 10:35:38 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j738Zb1q009262; Wed, 3 Aug 2005 10:35:37 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Aug 2005 10:35:37 +0200 (CEST) Message-Id: <200508030835.j738Zb1q009262@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <20050802143211.A74003@xorpc.icir.org> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: Another bug in IPFW@ ...? 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: Wed, 03 Aug 2005 08:35:40 -0000 Luigi Rizzo wrote: > ok, so the problem is the following: when i implemented ipfw2 > i thought that 'recv any' or 'xmit any' were effectively NOPs > so the parser erroneously removes them, together with any 'not' prefix > (which is processed before). That explains it. I was a little confused by the ipfw(8) manpage: It says: "recv any [...] matches packets received [...] through some interface", and two paragraphs later: "A packet may not have a receive [...] interface: packets originating from the local host have no receive interface". That clearly implies that "recv any" shouldn't be a NOP. :-) > To fix this one should > [...] > if you want to try, this should be all Thank you very much! I will give it a try, but it will take a little while, because I cannot reboot this router any time (ipfw is configured statically in the kernel). Thanks again, Luigi, I appreciate your assistance! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 09:12:04 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 08DC416A41F for ; Wed, 3 Aug 2005 09:12:04 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C375943D49 for ; Wed, 3 Aug 2005 09:12:03 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j739Br8B080897; Wed, 3 Aug 2005 02:11:53 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j739Bp8U080896; Wed, 3 Aug 2005 02:11:51 -0700 (PDT) (envelope-from rizzo) Date: Wed, 3 Aug 2005 02:11:51 -0700 From: Luigi Rizzo To: AT Matik Message-ID: <20050803021151.B80694@xorpc.icir.org> References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> <200508022151.45925.asstec@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508022151.45925.asstec@matik.com.br>; from asstec@matik.com.br on Tue, Aug 02, 2005 at 09:51:45PM -0300 Cc: freebsd-ipfw@freebsd.org Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 09:12:04 -0000 On Tue, Aug 02, 2005 at 09:51:45PM -0300, AT Matik wrote: ... > even if I agree to your logic aspect in general I thought > > out and xmit is probably exactly the same still especially as you set > src-ip and dst-ip so the interface where this packages are xmit is > defined by the routes > > localhost normally runs on lo0 which is an interface as any other > > so which ghost packages you try to catch here? there are internally generated packets which do not have a rcvif (which is what really 'recv' means); and any packet in the input path does not have an output-if (which is wht really 'xmit' means). so "out" and "xmit any" are the same thing (and "in" is "not out" so the same as "not xmit any"), assuming there is a route for the destination (but otherwise i believe the packet is dropped before reaching the firewall), but i cannot find a synonim for "recv any" cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 09:19:27 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 AC7D516A420 for ; Wed, 3 Aug 2005 09:19:27 +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 E898B43D4C for ; Wed, 3 Aug 2005 09:19:26 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (bczgzu@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j739JP6G010572 for ; Wed, 3 Aug 2005 11:19:25 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j739JPAL010571; Wed, 3 Aug 2005 11:19:25 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Aug 2005 11:19:25 +0200 (CEST) Message-Id: <200508030919.j739JPAL010571@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <200508022151.45925.asstec@matik.com.br> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: Another bug in IPFW@ ...? 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: Wed, 03 Aug 2005 09:19:27 -0000 AT Matik wrote: > On Tuesday 02 August 2005 14:46, Oliver Fromme wrote: > > > P.S. looks very strange "out not recv any xmit" > > > > It's perfectly valid syntax according to ipfw(8). > > (1+1-1)/1 also ... ;) I should have added: "perfectly valid syntax _and_ it makes sense". > > 1. "out" --> match only outgoing packets. > > > > 2. "not recv any" --> match packets that haven't been > > received through any interface (i.e. which originate > > from the local host). It's simply a negation of > > "recv any", see the ipfw(8) manpage. > > > > 3. "xmit dc0" --> match packets which are going to be > > transmitted through the dc0 interface. > > even if I agree to your logic aspect in general I thought The ipfw(8) manpage certainly agrees with my logic. I suggest you have a look at it, it's quite well written. > out and xmit is probably exactly the same No, it's not. "out" just says that this rule matches only outgoing packets. It doesn't specify anything about inter- faces or addresses. > still especially as you set > src-ip and dst-ip so the interface where this packages are xmit is > defined by the routes src-ip and dst-ip can be both faked and need not have anything to do with the interfaces on which a packet is received or transmitted. Sure, for "normal" packets, the routes specify the transmit interface, but a malicous program can just circumvent that and send packets with arbitrary content out through any interface. Therefore it is always a good idea to check _both_ (i.e. addresses _and_ interfaces). If you don't check interfaces, you might open holes for spoofed packets. > localhost normally runs on lo0 which is an interface as any other That's an entirely different thing. I was not talking about packets going through lo0 -- those don't leave the local host anyway, and are handled by rules earlier in the rule set. I was rather talking about packets generated by the local host, destined for a remote host, for example someone is using ping(1) or telnet(1) on the machine. Packets generated that way do not have a receive interface (neither a physical interface nor lo0 or some- thing else). > so which ghost packages you try to catch here? *sigh* The rule should allow packets going out through dc0 which have not been received through any interface. (Furthermore, the rule verifies that the source IP is the address configured on dc0, and that the destination I is OK for the LAN connected to dc0, but these checks are not the problem.) I didn't imagine that it could be _that_ difficult to understand. :-) > probably this rule you try is a deny all rule since any package is > beeing received by some IF before it can go out or xmit No. See above. If you type "ping remotehost", the ICMP ECHO request packets that your machines is going to send do not have a receive interface. (And in the same way, the ECHO REPLY packets that it's going to receive won't have a transmit interface, of course.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 09:30:36 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 DEABF16A41F for ; Wed, 3 Aug 2005 09:30:36 +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 4EA7443D48 for ; Wed, 3 Aug 2005 09:30:36 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (kdapat@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j739UYdQ011089 for ; Wed, 3 Aug 2005 11:30:35 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j739UYAU011088; Wed, 3 Aug 2005 11:30:34 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Aug 2005 11:30:34 +0200 (CEST) Message-Id: <200508030930.j739UYAU011088@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <20050803083040.GB89059@pc5.i.0x5.de> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: Another bug in IPFW@ ...? 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: Wed, 03 Aug 2005 09:30:37 -0000 Nicolas Rachinsky wrote: > ipfw add deny ip from me to any in > ipfw add pass ip from me to $N out xmit xl0 Yes, I also have a work-around with two rules, but I would prefer an independend check within the "out" rule. > But I would like the 'not recv any' feature, too. At the moment I use > a static list. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Perl is worse than Python because people wanted it worse. -- Larry Wall From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 10:56:47 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 8ECF916A41F for ; Wed, 3 Aug 2005 10:56:47 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF7EF43D49 for ; Wed, 3 Aug 2005 10:56:46 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from [200.152.82.190] (nbr.matik.com.br [200.152.82.190]) by msrv.matik.com.br (8.13.1/8.13.1) with ESMTP id j73Auirb036894 for ; Wed, 3 Aug 2005 07:56:45 -0300 (BRST) (envelope-from asstec@matik.com.br) From: AT Matik To: freebsd-ipfw@freebsd.org Date: Wed, 3 Aug 2005 07:56:40 -0300 User-Agent: KMail/1.8.1 References: <200508030919.j739JPAL010571@lurza.secnetix.de> In-Reply-To: <200508030919.j739JPAL010571@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508030756.41257.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 10:56:47 -0000 On Wednesday 03 August 2005 06:19, Oliver Fromme wrote: > > > out and xmit is probably exactly the same > > No, it's not. "out" just says that this rule matches only > outgoing packets. It doesn't specify anything about inter- > faces or addresses. > packages catched by xmit IF are catched with out as well "xmit any" probably is another expression for "out" I do not see your point here > > still especially as you set > > src-ip and dst-ip so the interface where this packages are xmit > > is defined by the routes > > src-ip and dst-ip can be both faked and need not have good, then you do not catch them anyway by src|dst[-ip] unless you deny all but the src-ip you want to pass and a fake dst-ip don't know who would do that but certainly an interesting idea ... Hans A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 11:20:26 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 49C3416A41F for ; Wed, 3 Aug 2005 11:20:26 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A4C743D45 for ; Wed, 3 Aug 2005 11:20:25 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from [200.152.82.190] (nbr.matik.com.br [200.152.82.190]) by msrv.matik.com.br (8.13.1/8.13.1) with ESMTP id j73BKPCi037843 for ; Wed, 3 Aug 2005 08:20:25 -0300 (BRST) (envelope-from asstec@matik.com.br) From: AT Matik To: freebsd-ipfw@freebsd.org Date: Wed, 3 Aug 2005 08:20:17 -0300 User-Agent: KMail/1.8.1 References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> <200508022151.45925.asstec@matik.com.br> <20050803021151.B80694@xorpc.icir.org> In-Reply-To: <20050803021151.B80694@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508030820.18304.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 11:20:26 -0000 On Wednesday 03 August 2005 06:11, Luigi Rizzo wrote: > there are internally generated packets which do not have > a rcvif (which is what really 'recv' means); > and any packet in the input path does not have an output-if > (which is wht really 'xmit' means). > well, means that any rule using IF here is not catching anything and you get them as with src-ip and dst-ip only, unless you really can say "not recv any" or isn't this "not in"? nb# ipfw add pass proto ip not in 65500 allow ip from any to any out practically correct? or only logical? anyway, looking at the initial rule and what you said a msg before: # ipfw add pass ip from $A to $N out not recv any xmit xl0 00900 allow ip from $A to $N out xmit xl0 "out xmit IF" isn't this kind of unecessary double-check and ipfw should not accept it? what match first here, ou or xmit? And look what I get: nb# ipfw add pass proto ip src-ip $A dst-ip $N out not in xmit dc0 65500 allow ip from any to any src-ip $A dst-ip $N out out xmit dc0 Hans A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 11:37:36 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 E7ECB16A41F for ; Wed, 3 Aug 2005 11:37:36 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9111E43D48 for ; Wed, 3 Aug 2005 11:37:36 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j73BbaEq082624; Wed, 3 Aug 2005 04:37:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j73Bba1I082623; Wed, 3 Aug 2005 04:37:36 -0700 (PDT) (envelope-from rizzo) Date: Wed, 3 Aug 2005 04:37:36 -0700 From: Luigi Rizzo To: AT Matik Message-ID: <20050803043736.A82515@xorpc.icir.org> References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> <200508022151.45925.asstec@matik.com.br> <20050803021151.B80694@xorpc.icir.org> <200508030820.18304.asstec@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508030820.18304.asstec@matik.com.br>; from asstec@matik.com.br on Wed, Aug 03, 2005 at 08:20:17AM -0300 Cc: freebsd-ipfw@freebsd.org Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 11:37:37 -0000 the question is simple: i made a mistake in implementing recv|xmit any, Oliver spotted it, i posted a fix. Whether his example was a good one or not is rather irrelevant. Hopefully the discussion has clarified that some checks are redundant, but the compiler cannot possibly spot all useless sequences, and i'd rather not put in useless complexity. The reason "out not in" is printed as "out out" is because "in" is implemented as "not out" and ipfw stores the 'compiled' version in the kernel. cheers luigi On Wed, Aug 03, 2005 at 08:20:17AM -0300, AT Matik wrote: > On Wednesday 03 August 2005 06:11, Luigi Rizzo wrote: > > > there are internally generated packets which do not have > > a rcvif (which is what really 'recv' means); > > and any packet in the input path does not have an output-if > > (which is wht really 'xmit' means). > > > > well, means that any rule using IF here is not catching anything and > you get them as with src-ip and dst-ip only, unless you really can > say "not recv any" or isn't this "not in"? > > nb# ipfw add pass proto ip not in > 65500 allow ip from any to any out > > practically correct? or only logical? > > anyway, looking at the initial rule and what you said a msg before: > > # ipfw add pass ip from $A to $N out not recv any xmit xl0 > 00900 allow ip from $A to $N out xmit xl0 > > "out xmit IF" isn't this kind of unecessary double-check and ipfw > should not accept it? what match first here, ou or xmit? And look > what I get: > > nb# ipfw add pass proto ip src-ip $A dst-ip $N out not in xmit dc0 > 65500 allow ip from any to any src-ip $A dst-ip $N out out xmit dc0 > > > > Hans > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 12:13:16 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 ADAAE16A425 for ; Wed, 3 Aug 2005 12:13:16 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1142843D46 for ; Wed, 3 Aug 2005 12:13:15 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from [200.152.83.36] (nbc.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.1/8.13.1) with ESMTP id j73CDFOI039929 for ; Wed, 3 Aug 2005 09:13:16 -0300 (BRST) (envelope-from asstec@matik.com.br) From: AT Matik To: freebsd-ipfw@freebsd.org Date: Wed, 3 Aug 2005 09:13:09 -0300 User-Agent: KMail/1.8.1 References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> <200508030820.18304.asstec@matik.com.br> <20050803043736.A82515@xorpc.icir.org> In-Reply-To: <20050803043736.A82515@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508030913.10213.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 12:13:16 -0000 On Wednesday 03 August 2005 08:37, Luigi Rizzo wrote: > the question is simple: i made a mistake in implementing > recv|xmit any, Oliver spotted it, i posted a fix. > Whether his example was a good one or not is rather irrelevant. > Hopefully the discussion has clarified that some checks > are redundant, but the compiler cannot possibly spot all useless > sequences, and i'd rather not put in useless complexity. Sorry if my input was misunderstood, it was not meant to you personal specially because ipfw attends my needs very well thank's to your work Hans A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 13:51:21 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 4C23E16A41F for ; Wed, 3 Aug 2005 13:51:21 +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 87D3043D46 for ; Wed, 3 Aug 2005 13:51:20 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (qxabuf@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j73DpInt019944 for ; Wed, 3 Aug 2005 15:51:19 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j73DpIA8019943; Wed, 3 Aug 2005 15:51:18 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Aug 2005 15:51:18 +0200 (CEST) Message-Id: <200508031351.j73DpIA8019943@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <200508030756.41257.asstec@matik.com.br> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: Another bug in IPFW@ ...? 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: Wed, 03 Aug 2005 13:51:21 -0000 AT Matik wrote: > On Wednesday 03 August 2005 06:19, Oliver Fromme wrote: > > > > > out and xmit is probably exactly the same > > > > No, it's not. "out" just says that this rule matches only > > outgoing packets. It doesn't specify anything about inter- > > faces or addresses. > > packages catched by xmit IF are catched with out as well > "xmit any" probably is another expression for "out" Ah, now I understand you. You wrote "out and xmit is the same", but what you really meant was "out and xmit any is the same". The latter is right, of course, because only packets that leave the local host have a transmit interface. This could be regarded as a semantical coincidence. :-) However, due to the asymmetry of the filtering, the analogy does _not_ work for the receive interface (so "in" is not the same as "recv any"). And this is precicesly the thing which exhibited the bug for me; see my very first posting in this thread. > > > still especially as you set > > > src-ip and dst-ip so the interface where this packages are xmit > > > is defined by the routes > > > > src-ip and dst-ip can be both faked and need not have > > good, then you do not catch them anyway by src|dst[-ip] unless you > deny all but the src-ip you want to pass I'm sorry, but I do not understand that sentence. What's wrong with trying to make sure that packets which claim to be from this host must be really generated on this host, i.e. have no receive inetrface? > and a fake dst-ip don't know who would do that Someone who wants to circument routing policies by sending a packet through an interface different from the one the routing tables specify. Besides, I don't ask "who would do that". Hackers sometimes find creative ways to abuse possibilities that nobody has thought of before. Rather than denying specific known bad packats (and allowing everything else), I want to allow only certain known good packets (and deny everything else). Making sure that outgoing packets with a local source IP have no receive interface is certainly a very valid thing to do. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 4 18:38:42 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 5A65216A41F for ; Thu, 4 Aug 2005 18:38:42 +0000 (GMT) (envelope-from jstarng@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D297543D49 for ; Thu, 4 Aug 2005 18:38:41 +0000 (GMT) (envelope-from jstarng@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so189543wra for ; Thu, 04 Aug 2005 11:38:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K7eoYARoUESJWmWeOdIOokpUmx/kgsmXWyn7koIRhDsP5FOLIDQSz6bqLe9A6T4PCmtpszF3gVdQQFevprtw7KFW3kdOG/NeAosvK2zzszjskGLnBbqO/wJ/AZFNSbivyJW06VAe9A4dXiIxcDRCuCsNyrqq7nYkIJSe+Ubn6ag= Received: by 10.54.53.62 with SMTP id b62mr1822758wra; Thu, 04 Aug 2005 11:38:40 -0700 (PDT) Received: by 10.54.147.8 with HTTP; Thu, 4 Aug 2005 11:38:40 -0700 (PDT) Message-ID: <2d3ab026050804113845d75cad@mail.gmail.com> Date: Thu, 4 Aug 2005 14:38:40 -0400 From: jstarng To: freebsd-ipfw@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: IPFW ip masking and stateful connections X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jstarng List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 18:38:42 -0000 two questions: 1. I'm having some trouble setting up a some rules. i have two networks one: 192.0.0.1-192.0.0.255 and the other 192.168.1.1-192.168.1.255 I want to prevent anyone from using services (like sharing folders) from one network to the other i tried a line: $c 00450 deny UDP from 192.0.0.0/16 to 192.168.1.1/16 but i think that's wrong because when i do an IPFW show it lists it as: 00450 deny udp from 192.0.0.0/16 to 192.168.0.0/16 I guess i'm not really understanding how bit masks work on ip ranges. what's the correct range i should use 2. Also whenever i try to use stateful connections it seems that my setup keep-state rules are ignored. The packet will be denied even though it matches one of the "allow" rules... additionally i never see any packet counts by the check-state rule. here's my current ruleset #!/bin/sh c=3D"ipfw add" skip=3D"skipto 60000" skiplog=3D"skipto 60002" denylog=3D"skipto 59999" #Legitemate External IP's ############################# $iDNS =3D "24.95.80.45,24.95.80.41" #Legitemate Internal IP's ############################# iClark=3D"192.0.0.201" iJoe=3D"192.0.0.36" iMikeG=3D"192.0.0.200" iTim=3D"192.0.0.223" iTroy=3D"192.0.0.231" iInternet=3D"192.0.0.201,192.0.0.231" iMe=3D"192.168.1.212" iMe2=3D"192.0.0.111" #Flush ############################# ipfw -f -q flush #flush existing rules #Divert ############################# $c 00001 divert natd all from any to any $c 00002 check-state #Redirect traffic based on direction #ed0 is the network with the internet connection $c 00003 skipto 100 all from any to any in via ed0 $c 00004 skipto 200 all from any to any in via vr0 $c 00005 skipto 398 all from any to any out via ed0 $c 00006 skipto 400 all from any to any out via vr0 #In via lo0 50 ############################# $c 00007 $skip TCP from 127.0.0.1 25 to 127.0.0.1 in via lo0 #In via ed0 100 ############################# $c 00100 $skip UDP from any to 255.255.255.255 in via ed0 #Broadcast $c 00102 $skip UDP from any 137 to 192.168.1.255 137 in via ed0 #shares $c 00103 $skip UDP from any 138 to 192.168.1.255 138 in via ed0 #shares $c 00104 $skip UDP from $iDNS 53 to $iInternet in via ed0 #DNS $c 00110 $skip TCP from 192.168.1.235 to $iMe 22 in via ed0 #SSH from me $c 00111 $skip TCP from any to $iInternet in via ed0 $c 00112 $skip TCP from any to $iMe 139 in via ed0 $c 00199 $skiplog all from any to any in via ed0 #In via vr0 200 ############################# $c 00200 $skip all from $iInternet to any in via vr0 $c 00295 $skip UDP from any to 255.255.255.255 60001 in via vr0 #Broadcast $c 00296 $skip TCP from any to $iMe2 139 in via vr0 $c 00297 $skip UDP from any 137 to 192.0.0.255 137 in via vr0 $c 00298 $skip UDP from any 138 to 192.0.0.255 138 in via vr0 $c 00299 $skiplog all from any to any in via vr0 #out via ed0 300 ############################# $c 00398 $skip all from $iMe to any out via ed0 $c 00399 $skiplog all from any to any out via ed0 #out via vr0 400 ############################# $c 00400 $skip all from any to $iInternet out via vr0 $c 00498 $skip TCP from $iMe2 139 to any out via vr0 $c 00499 $skiplog all from any to any out via vr0 #Deny and log $c 59999 deny log logamount 1000 all from any to any $c 60000 allow TCP from any to any setup keep-state $c 60001 allow UDP from any to any keep-state $c 60002 allow log logamount 1000 TCP from any to any setup keep-state $c 60003 allow log logamount 1000 UDP from any to any keep-state $c 60004 deny log logamount 1000 all from any to any ipfw zero #eof any help would be appreciated. From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 5 07:31:05 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 9539516A41F for ; Fri, 5 Aug 2005 07:31:05 +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 F3DA643D46 for ; Fri, 5 Aug 2005 07:31:02 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ylqnun@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j757V0S3094474; Fri, 5 Aug 2005 09:31:00 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j757UxWb094473; Fri, 5 Aug 2005 09:30:59 +0200 (CEST) (envelope-from olli) Date: Fri, 5 Aug 2005 09:30:59 +0200 (CEST) Message-Id: <200508050730.j757UxWb094473@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG, jstarng In-Reply-To: <2d3ab026050804113845d75cad@mail.gmail.com> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: IPFW ip masking and stateful connections X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-ipfw@FreeBSD.ORG, jstarng List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 07:31:05 -0000 jstarng wrote: > i have two networks one: 192.0.0.1-192.0.0.255 and the other > 192.168.1.1-192.168.1.255 So that be 192.0.0.0/24 and 192.168.1/24. BTW, are you aware that the former is reserverd to the IANA ("ROOT-NS-LAB") and is _not_ available for use? So, unless you are working for them, you should better use a different subnet. > I want to prevent anyone from using services (like sharing folders) > from one network to the other > > i tried a line: > $c 00450 deny UDP from 192.0.0.0/16 to 192.168.1.1/16 That should be: from 192.0.0.0/24 to 192.168.1.0/24 Since the last byte is masked out, it doesn't really matter what you specify, but it's convention to specify the net- work address (base address), which would be .0 in this case. NB: Some software allows ommitting the insignificant bytes entirely, so you could write 192.0.0/24 and 192.168.1/24, respectively. However, the ipfw(8) parser doesn't seem to like that, so you have to fill with trailing zeros so there are always 4 bytes. > I guess i'm not really understanding how bit masks work on ip ranges. > what's the correct range i should use The number after the slash specifies the number of the leftmost significant bits of the address. A complete IP (v4) address has 4 bytes which is 32 bits. So if you want to specify a (sub-) network by the left 3 bytes, that's 24 bits. (Historically those are sometimes called "class-C nets", but that's not entirely correct nowadays.) > #Divert > ############################# > $c 00001 divert natd all from any to any So NAT is involved. That complicates things somewhat, because all following rules work on the rewritten addresses, not on the original ones. Keep that in mind. You should specify an interface on the "divert natd" rule, e.g. "via fxp0". Otherwise, _all_ packets will go through natd, even lo0 packets, which is unnecessary overhead and might even have adverse side effects. > $c 00002 check-state A general advise: When numbering your rules, make the spacing between the numbers larger than 1, otherwise you cannot insert rules later (e.g. for testing or debugging) without flushing and reloading the whole set. I'd recommend a spacing of 10, at least. The default spacing of ipfw (when no numbers are given explicitly) is even 100. Consider that the numbers can go as high as 65534, so there's plenty of space. > $c 00007 $skip TCP from 127.0.0.1 25 to 127.0.0.1 in via lo0 I don't understand the purpose of that rule. Usually you want to allow all traffic on the lo0 interface while denying the 127/8 network everywhere else. These rules will do that: pass all from any to any via lo0 deny all from any to 127.0.0.0/8 deny all from 127.0.0.0/8 to any > #In via ed0 100 > ############################# > $c 00100 $skip UDP from any to 255.255.255.255 in via ed0 #Broadcast Uhm. The broadcast addresses of your interfaces are 192.0.0.255 and 192.168.1.255, respectively. Normally you don't need to handle broadcasted packets in a special way in your rule set. > $c 00102 $skip UDP from any 137 to 192.168.1.255 137 in via ed0 #shares > $c 00103 $skip UDP from any 138 to 192.168.1.255 138 in via ed0 #shares I'm not 100% familiar with those protocols, but I very much doubt that they use the same number for the source _and_ destination port. > $c 00104 $skip UDP from $iDNS 53 to $iInternet in via ed0 #DNS That rule would match only DNS reply packets from your internal DNS servers to the internet (if I understand your variables correctly). Doesn't seem to make sense, because I don't see any rules for matching appropriate request packets. > $c 00110 $skip TCP from 192.168.1.235 to $iMe 22 in via ed0 #SSH from me Either the rule is wrong, or the comment. :-) The rule matches SSH _to_ the host. I don't see a rule which allows outgoing SSH connections. > $c 00199 $skiplog all from any to any in via ed0 You can omit the "in via ed0", saving a few cycles. The check isn't necessary at this point. But where's your $denylog rule? You're basically allowing all remaining packets. > $c 00295 $skip UDP from any to 255.255.255.255 60001 in via vr0 #Broadcast Please excuse my, but your rules keep confusing me more and more. :-) So you're allowing broadcasts on 255.255.255.255 port 60001. The only thing using that port (AFAICT) is a trojan called Trinity. So is it your intention to broadcast that trojan to the whole internet? :-) The following rules have similar issues as those already mentioned above, so I won't repeat it. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie