I should add that once using source control abs a script to manage edits to pf.conf, it is easy to use at(1) to simulate Juniper's "commit confirmed" feature, adding another level of safety. -Adam
On April 9, 2014 7:50:14 AM CDT, Giancarlo Razzolini <[email protected]> wrote: >Em 09-04-2014 06:31, Stuart Henderson escreveu: >> On 2014-04-08, Giancarlo Razzolini <[email protected]> wrote: >> 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). >I use git and my script edit the source control version, not /etc one. >So if the syntax check passes, my script automatically copies the >pf.conf to /etc and asks if I want to commit and push the new version. >> >>> 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. >Exactly. That's why I use policy (tags) based firewalling. I makes a >little easier to pick up on such errors. >> >>> 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. >> >Exactly. Matching and logging is very nice, because it is sticky and >you >can log the entire flow of a packet with it. Speaking of flows, I use >pflow with nfsense and it helps a lot in detecting these "too open" >rules. Because there are these weekly or daily jobs that sometimes >can't >be run ahead of time and you won't need to wait until they run again, >just take a look at the flows in nfsen. > >Cheers, > >-- >Giancarlo Razzolini >GPG: 4096R/77B981BC -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
