From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 4 00:22:45 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E34616A406; Wed, 4 Apr 2007 00:22:45 +0000 (UTC) (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 83FC313C45A; Wed, 4 Apr 2007 00:22:44 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l340MgQl029431; Tue, 3 Apr 2007 21:22:42 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Tue, 3 Apr 2007 21:11:49 -0300 User-Agent: KMail/1.9.5 References: <200704021540.l32FerX8074400@freefall.freebsd.org> <20070 4030804.31819.asstec@matik.com.br> <20070403154054.GA1468@rogue.navcom.lan> In-Reply-To: <20070403154054.GA1468@rogue.navcom.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704032111.50041.asstec@matik.com.br> X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,AWL, J_CHICKENPOX_21,MR_DIFF_MID,SMILEY,TW_PF,USER_IN_WHITELIST autolearn=unavailable version=3.1.8 X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: jonw@whoweb.com, Mike Makonnen Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $fire wall_script not read it 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, 04 Apr 2007 00:22:45 -0000 On Tuesday 03 April 2007 12:40, Mike Makonnen wrote: > On Tue, Apr 03, 2007 at 08:04:31AM -0300, AT Matik wrote: > > I see your point > > but first tell me, how do you know that the rules are *successfully* > > loaded? > > Sorry, I wrote that email from memory and thought that was how it operate= d. > However, what it does is output a warning if the last rule is to deny all > packets (btw, is that correct? I thought ipfw operated on a "first-match" > basis, so there could be rules before that one to allow certain packets. > The more I look at it, the more bogus it looks to me, but I'm not > an ipfw user so... ). > instead of discussing, here is my actual version of /etc/rc.d/ipfw. I inver= ted=20 my personal choice of enabling ipfw before running the script into after. A= t=20 the end it doesn't matter because the outcome is the same. Also I think natd should not be run from ipfw script since there is=20 a /etc/rc.d/natd which in my opinion should have REQUIRE ipfw but not be=20 called by another rc.d script. So I do natd by it's own script only ipfw_start () { [ -z "${firewall_script}" ] && firewall_script=3D/etc/rc.firewall if [ -r "${firewall_script}" ]; then (sh - ${firewall_script}) echo -n 'firewall configured as type $firewall_type, rules= =20 loaded' else echo 'ERROR: firewall script not found!' echo 'You might have lost all Internet connections!' fi echo '.' if checkyesno firewall_logging; then if [ `sysctl -n net.inet.ip.fw.verbose` =3D "0" ]; then ${SYSCTL} net.inet.ip.fw.verbose=3D1 >/dev/null echo 'Firewall logging enabled' fi fi if [ `sysctl -n net.inet.ip.fw.enable` =3D "0" ]; then ${SYSCTL} net.inet.ip.fw.enable=3D1 >/dev/null fi } Jo=E3o > Anyways, I believe your original comment had to do with enabling the > firewall in a precmd() subroutine. I suppose in the end it comes down to > personal preference. It just seems "more correct" to me that the rules > are loaded first and then the firewall is turned on, but I can see how > someone else might disagree. I just thought > of something else as well: Enabling the firewall and then loading the > rules may introduce a brief window of vulnerablity where the firewall is > enabled (default to allow) but no rules are loaded. Off course, enabling > the firewall regardless of the outcome of the firewall script would > probably introduce a much bigger window of vulnerability :-). > > In any case, since I'm not a regular ipfw user I don't feel comfortable > making any more changes that might have unintended consequences. I'll > leave it to someone more familiar with ipfw to comment on and commit any > further changes. > > Cheers. =2D-=20 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br