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
