On 2014-04-08, Giancarlo Razzolini <[email protected]> wrote: > I find it very useful using a very simple script I created that: > 1) Opens up /etc/pf.conf using whatever editor is in $EDITOR > 2) After you save it, it uses pfctl -nf to check pf.conf syntax > 3) If you made a mistake, it warns you and re-opens the file for > editing. If everything is ok it exits cleanly.
If you're going to script this, you could have it make a copy of the file and work on that, so an unexpected reboot won't leave you with a pf.conf that may have errors. For even more safety, you could reload the ruleset using a copy of the file, leaving /etc/pf.conf with the old rules so that the most you need to do to recover from fat-finger accidents is reboot (and then you can copy the new file back out to pf.conf after it's been proven). I take a different approach and make sure I have out-of-band console access :) I would strongly encourage keeping pf.conf in source control though. Something as simple as rcs on the box itself is a huge step up from just editing the file directly, though I prefer to have them on a separate machine (I use svn for that). > Of course the script above won't help with rules that are right in > its syntax, but are passing or blocking traffic they were not meant to. > I found empirically that the majority of the mistakes are in pf's > syntax. When you make a wrong rule you'll either detect it right away, > for instance, a block rule that blocks the wrong traffic or you will not > detect it for a long time. Hmm.. It is often fairly quick to pick up rules which over-block (though problems with jobs which only occur weekly or monthly can take a while to track down, and also there are situations where you won't notice a problem until all firewall states are flushed and all tables flushed and reloaded). But it's a lot harder to pick up rules which are too open. > Also, even when detecting an unexpected > behavior, it might be hard to pinpoint where it is in you pf > configuration. I had to use tags many times to discover that the > combination of 3 or more rules was causing the unexpected behavior. match log(matches) is extremely useful here.
