Subject: Re: /etc/rc.d/pf reload doesn't lose tables
To: Jeremy C. Reed <reed@reedmedia.net>
From: Alfred Perlstein <bright@mu.org>
List: tech-misc
Date: 02/22/2007 17:16:30
* Jeremy C. Reed <reed@reedmedia.net> [070222 17:07] wrote:
> I changed my /etc/pf.conf and did "/etc/rc.d/pf reload" and a table I had
> removed from my configuration still existed.
>
> The rc.d script has:
>
> echo "Reloading pf rules."
> if [ -f ${pf_rules} ]; then
> /sbin/pfctl -q -f ${pf_rules}
> else
> warn "${pf_rules} not found; no pf rules loaded."
> fi
>
> FreeBSD does:
>
> echo "Reloading pf rules."
> $pf_program -n -f "$pf_rules" || return 1
> # Flush everything but existing state entries that way when
> # rules are read in, it doesn't break established connections.
> $pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables -Fosfp > /dev/null 2>&1
> $pf_program -f "$pf_rules" $pf_flags
>
> So it checks first if rules can be parsed with -n.
>
> Then it flushes everything except "state".
>
> And then it loads rules (without -q).
>
> FreeBSD also does a flush of everything with "-F all" before it loads
> rules and enables pf during a "start".
>
> Any thoughts on any of this?
>
> I can make patch, test and commit if okay.
>
> Jeremy C. Reed
>
> p.s. What list for this discussion? tech-security is documented for
> "security issues".
I really don't think firewall rules should be flushed unless
explicitly asked by the user. Perhaps having a knob to ask that
the system do it for you would be nice, but otherwise you're potentially
opening up something that shouldn't be opened by default in a "default
allow" setup.
that said, security minded people will use a "default deny" policy.
and.. that said your choices are:
default allow: suddenly box is open to attack.
default deny: suddenly you lose all flows.
this makes the scripts a little bit more "helpful" than one would
care for, right?
--
- Alfred Perlstein
- coder / sysadmin / FreeBSD Hacker / All that jazz -