Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Jun 2009 11:04:06 +0200
From:      Max Laier <max@love2party.net>
To:        freebsd-current@freebsd.org
Cc:        freebsd-ipfw@freebsd.org, Doug Barton <dougb@freebsd.org>, freebsd-pf@freebsd.org
Subject:   Re: pfsync rc script breaks pfsync on cloned interfaces
Message-ID:  <200906261104.07597.max@love2party.net>
In-Reply-To: <4A444BC2.4010606@FreeBSD.org>
References:  <E1MJoX9-000F3V-6z@clue.co.za> <4A444BC2.4010606@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 26 June 2009 06:17:06 Doug Barton wrote:
> I have reverted the change that caused pf and ipfw to appear before
> netif in the rcorder. While I still feel strongly that it is the
> "right thing" to configure the firewalls first, the changes caused too
> many problems for too many users, and it's too late in the release
> cycle to make a change like this that has significant side effects.
>
> I would like to strongly encourage those who use pf and ipfw to
> consider doing the work required to make this change possible. With
> ipfw it's not quite as urgent since by default it does not pass
> packets till it is configured. This is not the case with pf, as its
> default is wide open until it is configured.

It's not a simple problem and I'm not sure we can really come up with a 
"one-size-fits-all" solution.  That does not mean we shouldn't try, 
though.

My idea how this should work is something along the following lines:

1) Very early in the boot (just after the necessary firewall configuration 
tools are available [NFS-root might be a problem here!]) setup an "initial 
firewall" configuration.  For most users this could be a default (allow 
dhcp, outgoing DNS, maybe ssh in/out, NFS(???), ...).

2) After setting up the interfaces have the option to start a more 
involved firewall that is fully user supplied.  At this point we should be 
able to look up DNS (though this is clearly a bad idea from the security 
PoV unless you have DNSSEC), get interface configurations and maybe even 
routing information.  The latter could be another chicken-egg-problem as 
we might need a routing daemon active to get this.  However, people who 
really need that should be able to modify the early setup accordingly.

It is unclear to me where stage 2 should be located.  I would argue that 
with a reasonable default setup we can easily get away with putting stage 
2 at the very end of the start up procedure.  If people need early holes 
in the firewall (e.g. for smbfs, routing daemons, ...) they can place them 
in the early stage.

I would like input about how a very simple "save default" setup could look 
like.  A ruleset for pf or ipfw that allows most of the boot process to 
complete without opening the host to the outside world, yet.  For extra 
points this ruleset is aware of the rc.conf variables and adjusts 
accordingly (e.g. opening access to sshd iff it is configured).  In 
addition there might be *one or two* configuration variables for the early 
stage to open additional ports or to select a default interface.  However, 
the fewer the better.

Input greatly appreciated!

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906261104.07597.max>