From owner-freebsd-stable Tue Jan 29 11:48:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 58EC437B402 for ; Tue, 29 Jan 2002 11:48:44 -0800 (PST) Received: (qmail 14920 invoked by uid 0); 29 Jan 2002 19:47:44 -0000 Received: from pd9508836.dip.t-dialin.net (HELO mail.gsinet.sittig.org) (217.80.136.54) by mail.gmx.net (mp008-rz3) with SMTP; 29 Jan 2002 19:47:44 -0000 Received: (qmail 48614 invoked from network); 29 Jan 2002 19:33:58 -0000 Received: from shell.gsinet.sittig.org (192.168.11.153) by mail.gsinet.sittig.org with SMTP; 29 Jan 2002 19:33:58 -0000 Received: (from sittig@localhost) by shell.gsinet.sittig.org (8.11.3/8.11.3) id g0TJXnI48599 for stable@FreeBSD.ORG; Tue, 29 Jan 2002 20:33:49 +0100 (CET) (envelope-from sittig) Date: Tue, 29 Jan 2002 20:33:49 +0100 From: Gerhard Sittig To: stable@FreeBSD.ORG Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020129203349.G1494@shell.gsinet.sittig.org> Mail-Followup-To: stable@FreeBSD.ORG References: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org> <15445.48617.802871.870971@caddis.yogotech.com> <20020128.151138.115627568.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020128.151138.115627568.imp@village.org>; from imp@village.org on Mon, Jan 28, 2002 at 03:11:38PM -0700 Organization: System Defenestrators Inc. 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 On Mon, Jan 28, 2002 at 15:11 -0700, M. Warner Losh wrote: > > Loading ipfw is less secure than having it in the kernel, since > there's a window at boot that packets can pass. The problem with ipfw > now is that if you don't have the default deny rule, there's a small > window where you have packets passed. ipfilter is done much sooner in > the boot process, so doesn't appear to suffer from this > vulnerability. If possible, we should move ipfw to the same location > as ipfilter (I suspect that it isn't there for some reason). The only reason I can come up with is the "ppp/nat" catchword. Loading ipfw this late might be what saved ipfw users from suffering from the "problem" in PR conf/22859. The issue seem to be "suddenly appearing" or reconfigured interfaces (drivers loaded on demand, ppp creating tun(4)s, and the like). Should ipfw be loaded earlier it might need a method of synching or reloading its ruleset very much like the "ipf -y" feature. Or to do what I've seen in Linux land: run the firewall boot scripts in ip-up and ip-down once more (/etc/ppp/ppp.link{up,down} in FreeBSD speak), maybe passing a few parameters to restrict work a little (only adjusting the PPP interface or something). That's when default policies of accepting traffic might harm you when the ruleset gets build multiple times while the machine is already connected ... > We'd also need to change ipfilter rules as well. It doesn't defaults > to blocking everything and if you set ipfilter_enable to NO, you get > that same behavior. Regarding the default to block everything: it might not be the default behaviour when only enabling the ipf kernel code or ipl module. But there's a kernel option IPFILTER_DEFAULT_BLOCK available and rc.network as well as rc.conf(5) even recommend its use. (guess who wrote these comments :>) > The ipfilter stuff also will blindly try to load the ipfilter rules, > even if ipfilter isn't in the kernel and can't be loaded. I just had a look at rev 1.119 of rc.network (-CURRENT). It tries to activate ipfilter as soon as the admin wants ipf or ipnat functionality. Then it checks for ipf code in the kernel and (should the querying sysctl fail) tries to load ipl.ko. Should this module loading fail, the admin's wishes are overridden and no further ipf/ipnat/ipfs/ipmon command gets issued. This should be safe. I read it that the ipf subsystem only is used / configured if it is statically linked into the kernel or could be loaded on demand. I don't see a problem here, unless I missed something. A quick look at rev 1.74.2.28 (-STABLE) makes me assume that the logic is identical here, at least in the ipf respect. Last "cvs up" in the above sandboxes was done last Thursday, but I haven't noticed commit logs in cvs-all. So things should be fine in ipf land. :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message