Date: Sun, 16 Jul 2006 20:23:15 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Ari Suutari <ari@suutari.iki.fi> Cc: freebsd-security@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? Message-ID: <20060716182315.GC3240@insomnia.benzedrine.cx> In-Reply-To: <44B7D8B8.3090403@suutari.iki.fi> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 14, 2006 at 08:47:36PM +0300, Ari Suutari wrote: > There has been discussion about this before. I know that perfect > solution would be PF_DEFAULT_BLOCK, but while waiting for that > I wonder why we cannot have pf_boot, which closes the > boot hole (at least when run with proper filter rules). That is certainly not a perfect solution, as it misses the point, mostly. The "hole" being discussed is the time, during boot, before pf is fully functional with the production ruleset. For a comparatively long time, the pf module isn't even loaded yet. The time after module load and enabling pf with the production ruleset is much smaller. So, you first need to check the boot sequence for - interfaces being brought up before pf is loaded - addresses assigned to those interfaces - daemons starting and listening on those addresses - route table getting set up - IP forwarding getting enabled - etc. And to get rid of the "hole", you need to get the order right so there is nothing being exposed before the pf module is loaded. Once you have ensured that nothing gets exposed before rc.d/pf is started, it's trivial to make sure that that script only exits after pf has been enabled and the production ruleset is in place. Hence, a "default block" switch or compile time option _within_ pf is not going to make any difference. The problem lies mostly outside of pf, and the boot order needs to be carefully examined and adjusted, if needed. I think the chronological placement of rc.d/pf is already meant to achieve precisely that, have you actually checked the rc.d scripts and found some order that needs to be adjusted? Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060716182315.GC3240>