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>