From owner-freebsd-pf@FreeBSD.ORG Mon Jul 17 08:11:41 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4324B16A4DA; Mon, 17 Jul 2006 08:11:41 +0000 (UTC) (envelope-from fb-security@psconsult.nl) Received: from ps226.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB59643D53; Mon, 17 Jul 2006 08:11:39 +0000 (GMT) (envelope-from fb-security@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.13.1/8.13.1) with ESMTP id k6H8ACbp072309; Mon, 17 Jul 2006 10:10:12 +0200 (CEST) (envelope-from fb-security@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.13.1/8.13.1/Submit) id k6H8ACgc072308; Mon, 17 Jul 2006 10:10:12 +0200 (CEST) (envelope-from fb-security@psconsult.nl) Date: Mon, 17 Jul 2006 10:10:12 +0200 From: Paul Schenkeveld To: freebsd-security@freebsd.org, freebsd-pf@freebsd.org Message-ID: <20060717081012.GA71385@psconsult.nl> Mail-Followup-To: freebsd-security@freebsd.org, freebsd-pf@freebsd.org References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi> <20060716182315.GC3240@insomnia.benzedrine.cx> <86y7utgt0o.fsf@xps.des.no> <20060716214456.GE3240@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060716214456.GE3240@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.6i Cc: Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 08:11:41 -0000 On Sun, Jul 16, 2006 at 11:44:56PM +0200, Daniel Hartmeier wrote: > On Sun, Jul 16, 2006 at 11:05:27PM +0200, Dag-Erling Smørgrav wrote: > > That would then block all packets on all interfaces, until a ruleset is > loaded. If anything started through the startup scripts needs unblocked > packets (including the production ruleset loading requiring name > resolution over network), you'd need to first load a simpler temporary > ruleset to pass that, and finally replace it with the production > ruleset. > > And, of course, if the boot sequence for any reason doesn't reach that > point, you can only fix stuff with local access... :) > > I'm not sure the average user _really_ is worried enough about that > half a second period on boot. But I DO know there will be people locking > themselves out from far-away remote hosts (on updates, for instance) if > this becomes the default. There are two completely different issues here. One is protecting the machine itself, the other is to protect the complete network behind it if this is a firewall. Having a firewall open for half a second (is it really ONLY half a second in all cases?) is not acceptable if this is a firewall. So if you build a pf based firewall: - Include pf in your kernel ("device pf" in ${ARCH}/conf/KERNEL) or load pf from BTX ("pf_load=YES" in /boot/loader.conf) - Make sure you have console access before making changes to pf.conf or make sure you can get back to the firewall even after a mistake in pf.conf. I've done quite a lot of remote ipfw.conf and ipf.rules maintenance on remote, unattended firewalls and come up with several easy ways to make sure the device reverts to the last known to work ruleset if I get locked out during the process. One way is to schedule a "pfctl -Fa -f /etc/pf.conf" or a reboot after several minutes using at(1) and make changes to /etc/pf.conf.new, load it manually using pfctl and atrm(1) the scheduled job if you can still reach the firewall. Finally when you are really sure about the changes working correctly, move them to /etc/pf.conf. If you are to protect your company network or your customers network, maintaining access to the firewall is very important but exposing the network behind it, even for a short time, is IMO not acceptable. So I still believe in having some kind of PF_DEFAULT_BLOCK for those caring about the protection of the network behind the firewall. OTOH I see a good point in having the rc.d/pf_boot script the OP asked for as well and install /etc/pf.boot.conf early giving applications DNS (and access to i.e. a remote database needed to start up a certain app) and give the sysadmin access until all required apps are loaded and maybe even proven to work correctly. Regards, Paul Schenkeveld