[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is a 'PF default to block' setting outside pf.conf a desirable feature?

On Wed, Nov 09, 2005 at 09:57:08AM +0100, Peter N. M. Hansteen wrote:
> Over in the comp.unix.bsd.freebsd.misc news group, there's a
> discussion about what happens when PF loads, specifically a perceived
> 'window of opportunity' for an attacker in the interval between PF
> getting enabled and the rule set loading, and what happens if the rule
> set you load at boot time is an empty or invalid rule set.
> On FreeBSD, it is possible to compile your kernel with options to make
> 'block all' the default in absence of a rule set. This apparently works
> for all the other firewall systems supported by FreeBSD, but not PF.
> You should not be surprised to learn that there are people who feel that
> this feature, described as 'booting to a safe state regardless of
> failure or success of ruleset load' is a necessary feature of 'any
> firewall worthy of the name'.  I'm trying to make up my mind whether
> some way to set PF to 'block all' default outside of the rule set itself
> is a desirable feature.  For a bit of context, the thread in question
> starts at <[email protected]>
Unless I'm being completely mislead, this feature is already in place
with OpenBSD.  See /etc/rc.  If pf is set to anything but "NO" in
/etc/rc.conf, two things happen.  First, a minimal set of rules is
devised that:
   * blocks everything
   * Allows ssh in
   * Allows pings and DNS requests out
   * Allows specific IPv6 icmp packets in/out
   * Allows pfsync/carp packets in/out
   * Allows NFS/portmap packets if necessary
pf is enabled and this minimal ruleset is loaded.  Normal system startup
continues -- /etc/sysctl.conf and /etc/mixerctl.conf are parsed,
/etc/resolv.conf is tweaked if needed and then the network is started.
Once this is done, your ruleset is loaded.
One might argue that the default ssh rule could use some tightening.
This default ruleset will help the case where your /etc/pf.conf is
invalid unless you are doing something whacky like 'pfctl -e -F all -f
/etc/pf.conf', in which case the default rules setup by /etc/rc are now
irrelevant.  For the case where your /etc/pf.conf is empty, well, I'm
not sure.  *Maybe* a test like what is done for /etc/sysctl.conf is in
order -- strip out all comments.  If there is something left that isn't
whitespace, pipe it to pfctl, otherwise stick with the default rules?
I'm not sure.  Something about this logic doesn't seem right.