freebsd security - Jul 2006 - Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ?

Hi,

[I have added freebsd-security to recipient list as I consider
  this issue a security risk]

Paul Schenkeveld wrote:
> Hello,
> 
> On Fri, Jul 14, 2006 at 01:26:38PM +0300, Ari Suutari wrote:
>> Hi,
>>
>> Does anyone know if there are any plans to bring
>> pf boot-time protection (ie. /etc/rc.d/pf_boot and
>> related config files) from NetBSD to FreeBSD ?
>>
>> This would close small (but as far as I understand existing)
>> window during boot where firewall is fully open (if using only
>> pf).
> 
> I'd prefer to have PF_DEFAULT_BLOCK analogous to IPFILTER_DEFAULT_BLOCK
> instead of some magic script closing the hole between driver init and
> configuration.  Always wondered how the OpenBSD -securety minded- people
> have come up with a packet filter that's open by default.
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).

I would suggest:

- first port pf_boot which brings us to same level of security
   as OpenBSD & NetBSD.
- then, work with PF authors to get PF_DEFAULT_BLOCK if it still
   seems necessary.

As pf becomes more and more popular on FreeBSD I see current state
of system as security risk (ie. I won't use pf + FreeBSD on
company firewalls although I would otherwise like to).

	Ari S.

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