Re: Any ongoing effort to port /etc/rc.d/pf_boot,

On Fri, Jul 14, 2006 at 08:47:36PM +0300, Ari Suutari wrote:

> There has been discussion about this before. I know that perfect
> solution would be PF_DEFAULT_BLOCK, but while waiting for that
> I wonder why we cannot have pf_boot, which closes the
> boot hole (at least when run with proper filter rules).

That is certainly not a perfect solution, as it misses the point,
mostly.

The "hole" being discussed is the time, during boot, before pf is fully
functional with the production ruleset. For a comparatively long time,
the pf module isn't even loaded yet. The time after module load and
enabling pf with the production ruleset is much smaller.

So, you first need to check the boot sequence for

  - interfaces being brought up before pf is loaded
  - addresses assigned to those interfaces
  - daemons starting and listening on those addresses
  - route table getting set up
  - IP forwarding getting enabled
  - etc.

And to get rid of the "hole", you need to get the order right so there
is nothing being exposed before the pf module is loaded. Once you have
ensured that nothing gets exposed before rc.d/pf is started, it's
trivial to make sure that that script only exits after pf has been
enabled and the production ruleset is in place.

Hence, a "default block" switch or compile time option _within_ pf is
not going to make any difference. The problem lies mostly outside of pf,
and the boot order needs to be carefully examined and adjusted, if
needed.

I think the chronological placement of rc.d/pf is already meant to
achieve precisely that, have you actually checked the rc.d scripts and
found some order that needs to be adjusted?

Daniel
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"