Date: Mon, 17 Jul 2006 10:10:12 +0200 From: Paul Schenkeveld <fb-security@psconsult.nl> To: 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: <20060717081012.GA71385@psconsult.nl> In-Reply-To: <20060716214456.GE3240@insomnia.benzedrine.cx> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi> <20060716182315.GC3240@insomnia.benzedrine.cx> <86y7utgt0o.fsf@xps.des.no> <20060716214456.GE3240@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> ruleset.
>
> 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
firewall.
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/pf.conf.new, 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.
Regards,
Paul Schenkeveld
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060717081012.GA71385>