Moving the pf rc.d scripts to run before netif

[Max Laier]

On Monday 01 June 2009 20:38:45 Doug Barton wrote:
> Howdy,
>
> As you can see below, I've made a change to the order of execution of
> the rc.d scripts in 8-current (soon to be 8-release) to run all of the
> firewalls, including pf, before the network is up. However the
> following PR gives an example of why this might be bad:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=130381
>
> This leaves me with a few questions.
>
> 1. When the _kernel_ first starts, what is the condition of the pf
> firewall? In other words, you have pf in the kernel, and let's pretend
> that there is no rc.d/pf initialization script. What's going to happen
> to the packets when the network comes up?

The default behavior is to pass everything unconditionally.

> 2. The previous rcorder for the pf script was right after netif (the
> network coming up) and before routing .... why? Is this related to how
> pf does its work? The reason I ask this question is that in order to
> fix the IPv6 rcorder problem in the pr the way that Gert is suggesting
> the "BEFORE: routing" would have to be removed because our IPv6
> startup depends on RA which depends on routing being up. (Side note,
> in the long term I'd like to revise this so that an IPv6-only host
> and/or a host with statically assigned IPv6 addresses can easily be
> configured within rc.d, but that's another thing altogether.)
>
> 3. Is the need to be able to use $ext_if after the network is up so
> overwhelmingly important that it justifies running pf after netif? Or
> is using ($ext_if) a reasonable solution?

Traditionally pf has had some issues with startup before netif.  e.g. it 
was not possible to configure ALTQ on interfaces before they are created.  
Over the years most of these restrictions have been fixed (though you 
still need to specify an absolute bandwidth for ALTQ if you want to 
configure non-existing interfaces).  The last remaining issue with non-
existing interfaces is the "set loginterface".

In addition people seem to like to use symbolic hostnames in their pf.conf 
for some reason.  It's a bad idea from the security perspective, but who 
am I to decide how one shoots oneself?  Symbolic hostnames, as well as 
non-dynamic interface statements are evaluated at ruleset load-time in pf.  
Thus the resolver must work when we load a ruleset with rules like that.

> Anything else y'all would like to add is welcome at this point.

It might make sense to have the ability for two points to configure the 
firewall.  One "firewall_early" to setup a minimal "block all/allow 
dhcp/RA/DNS/..." and "firewall_late" to setup the final thing.

In any case setting up the firewall is a non-trivial task and I doubt that 
there really is a good "one size fits all" solution.  I'd prefer your 
version over the previous incarnation - as it is secure by default.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News