..and a way to have it revert in 2 minutes unless the operator does <something>, for the times when you cut off the branch you are sitting on.
2014-04-09 23:55 GMT+02:00 Adam Thompson <[email protected]>: > 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. > > -- May the most significant bit of your life be positive.
