From owner-freebsd-ipfw@FreeBSD.ORG Fri May 7 04:19:09 2004 Return-Path: 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 9BAC816A4CE for ; Fri, 7 May 2004 04:19:09 -0700 (PDT) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C86B443D58 for ; Fri, 7 May 2004 04:19:08 -0700 (PDT) (envelope-from oleg@rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.12.11/8.12.11) with ESMTP id i47BJ7Ts005490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 15:19:07 +0400 (MSD) (envelope-from oleg@rinet.ru) Received: from localhost (oleg@localhost)i47BJ6MU005487; Fri, 7 May 2004 15:19:07 +0400 (MSD) (envelope-from oleg@rinet.ru) Date: Fri, 7 May 2004 15:19:06 +0400 (MSD) From: Oleg Bulyzhin To: Luigi Rizzo In-Reply-To: <20040507024206.B61144@xorpc.icir.org> Message-ID: <20040507150212.P5201@lath.rinet.ru> References: <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <20040506153815.A75812@xorpc.icir.org> <20040507024206.B61144@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw: ouch!, skip past end of rules, denying packet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 11:19:09 -0000 On Fri, 7 May 2004, Luigi Rizzo wrote: > On Fri, May 07, 2004 at 01:17:22PM +0400, Oleg Bulyzhin wrote: > ... > > > Your patch replaces the matching rule with the next one, > > > which however might still end up being the default rule; > > > so it does not fix the proble, plus, it might completely > > > subvert the packet's flow. > > > > I've used dn_pkt.rule cause dn_pkt structure has no separate pointer for > > 'next rule', perhaps we should add it? > > the problem is that there is a race here -- you start processing > the packet, suspend, change the ruleset, then if one_pass=0 restart. > When you restart, > the ruleset might have little or nothing in common with the previous > one, so there isn't really any assumption you can make that doesn't > open holes in your firewall. > So i really believe the only sensible choice in the above case > is either drop the packet, or restart its processing from the > beginning (but that might have annoying side effects). > > Dropping a packet (or a few) during a reconfiguration is not dramatic, > it might have got lost anyways -- and note, this case is very > different from reconfiguring a pipe's bandwidth, where you _know_ > what to do with the packet (and still you cannot guarantee > if it will come out at the desired rate). You have almost convinced me. Perhaps it would be better to apply default policy to such packets. Thanks for explanation! > > cheers > luigii > P.S. about your suggestion how to fix it: maybe instead of special check in ipfw_chk() would be better to change lookup_next_rule() behaviour in order to lookup_next_rule(default_rule) == default_rule? (anyway this function is not used for traversing list of rules); -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================