Date: Sun, 16 Jul 2006 21:17:32 +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: <20060716191732.GD3240@insomnia.benzedrine.cx> In-Reply-To: <44BA8A95.10300@suutari.iki.fi> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi> <20060716182315.GC3240@insomnia.benzedrine.cx> <44BA8A95.10300@suutari.iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 16, 2006 at 09:51:01PM +0300, Ari Suutari wrote:
> I could of course adjust my rc.d scripts, but I would very much
> appreciate that security-related things are there correctly in
> standard setup.
>
> I'll try to port pf_boot myself if nobody else volunteers.
> (I don't think there is much porting to do, however).
The point of OpenBSD's "boot-time" (preliminary) ruleset is that pf can
be activated earlier, before the production ruleset can be loaded.
The production ruleset can usually not be loaded very early on in the
boot sequence, because it can contain constructs that rely on interfaces
having been created, IP addresses assigned, or host name resolution
working.
At the point in time where all these things work, other things are
already exposed (briefly).
So what OpenBSD does (and I guess what that pf_boot script does on
NetBSD) is enable pf with a short hard-coded preliminary ruleset very
early on in the boot sequence, which only allows traffic which is needed
by the boot process itself subsequently. This protects the things
exposed afterwards, but before the production ruleset can be loaded. It
also remains effective should the production ruleset fail to load (hence
it usually allows ssh access to the firewall itself).
So first you need to identify whether FreeBSD's boot sequence suffers
the same issue (things are being exposed prior to the point where you
can load the production ruleset). Then you need to find the proper time
to load the kernel module and activate a preliminary ruleset. And of
course the preliminary ruleset needs to account for all legitimate
traffic that can subsequently occur during boot on various kinds of
setups. One word of warning, the OpenBSD preliminary ruleset had to be
revised many times when people found it broke things that the boot
sequence needs in non-default setups. You'll likely go through several
revisions on FreeBSD as well.
You claimed there was a hole. If you can't explain what it consists of
("thing X might get exposed prior to rc.d/pf due to the following
sequence of events..."), blindly sticking in pf_boot at some convenient
place in the boot order is not guaranteed to solve more than it can
break. Whoever is going to do this, will NEED to carefully go through
the rc.d sequence with regards to networking.
Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060716191732.GD3240>