Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ?

On Sun, Jul 16, 2006 at 11:44:56PM +0200, Daniel Hartmeier wrote:
On Sun, Jul 16, 2006 at 11:05:27PM +0200, Dag-Erling Smørgrav wrote:

That would then block all packets on all interfaces, until a ruleset is
loaded. If anything started through the startup scripts needs unblocked
packets (including the production ruleset loading requiring name
resolution over network), you'd need to first load a simpler temporary
ruleset to pass that, and finally replace it with the production

And, of course, if the boot sequence for any reason doesn't reach that
point, you can only fix stuff with local access... :)

I'm not sure the average user _really_ is worried enough about that
half a second period on boot. But I DO know there will be people locking
themselves out from far-away remote hosts (on updates, for instance) if
this becomes the default.

There are two completely different issues here. One is protecting the
machine itself, the other is to protect the complete network behind it
if this is a firewall. Having a firewall open for half a second (is it
really ONLY half a second in all cases?) is not acceptable if this is a

So if you build a pf based firewall:
- Include pf in your kernel ("device pf" in ${ARCH}/conf/KERNEL) or
load pf from BTX ("pf_load=YES" in /boot/loader.conf)
- Make sure you have console access before making changes to pf.conf
or make sure you can get back to the firewall even after a mistake
in pf.conf.

I've done quite a lot of remote ipfw.conf and ipf.rules maintenance on
remote, unattended firewalls and come up with several easy ways to
make sure the device reverts to the last known to work ruleset if I
get locked out during the process.

One way is to schedule a "pfctl -Fa -f /etc/pf.conf" or a reboot after
several minutes using at(1) and make changes to /etc/, load it
manually using pfctl and atrm(1) the scheduled job if you can still reach
the firewall. Finally when you are really sure about the changes working
correctly, move them to /etc/pf.conf.

If you are to protect your company network or your customers network,
maintaining access to the firewall is very important but exposing the
network behind it, even for a short time, is IMO not acceptable.

So I still believe in having some kind of PF_DEFAULT_BLOCK for those
caring about the protection of the network behind the firewall.

OTOH I see a good point in having the rc.d/pf_boot script the OP asked
for as well and install /etc/pf.boot.conf early giving applications DNS
(and access to i.e. a remote database needed to start up a certain app)
and give the sysadmin access until all required apps are loaded and maybe
even proven to work correctly.


Paul Schenkeveld
freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"