Re: /etc/rc.d/pf reload doesn't lose tables
Alfred Perlstein <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.general |
|---|---|
| Message-ID | <[email protected]> |
* Jeremy C. Reed <[email protected]> [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 -