Date: Mon, 01 Jun 2009 15:57:10 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: bzeeb-lists@lists.zabbadoz.net, Gert Doering <gert@greenie.muc.de>, freebsd-pf@freebsd.org Subject: Re: Moving the pf rc.d scripts to run before netif Message-ID: <4A245CC6.7010901@FreeBSD.org> In-Reply-To: <200906012145.17315.max@love2party.net> References: <4A242035.8010101@FreeBSD.org> <200906012145.17315.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote: > 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. That's what I was afraid of. Traditionally this has been viewed as a Bad Thing(TM) and I'm surprised that it was ever set up that way to start with. >> 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". Ok. > 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. Well the previous order had pf starting before routing anyway (and therefore also starting before IPv6, nsswitch, resolv, named, etc.) so I don't think this would have worked in any case. >> 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. I would definitely be supportive of a pf-late script that runs after the network is up. I'll even write the thing if someone can tell me what it needs to have. Would calling "/etc/rc.d/pf reload" do the right thing? And if this is the best way to handle the problem, how late should it start? (IOW, what should it REQUIRE to make sure it will have everything it needs when it is run, and what would it need to run BEFORE to make sure the system is still as secure as possible?) > 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. Thanks for the well-informed response, and the note of support. :) Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A245CC6.7010901>