Em 08-04-2014 19:13, Andy Lemin escreveu:
> Hi Wiesław,
>
> Definitely support your desire to try to add more structure to your PF
> writing! :)
>
> We use git to version control PF and many other files (over 60 files across
> an OBSD system now come to think of it).
>
> For PF, I wouldn't recommend using anchors as I *think* their slower and
> restricted in terms of options. You also want to be using tables if you want
> performance.
>
> Anyway, we wanted to create some structure too but opted for, instead of
> being too clever just using care and attention, always using 2 firewalls
> (running carp), and following PF's own 'skip steps' to define how we break
> our rules into different well defined groups within the PF file.
> Of course within the skip step group ordering you can also add whatever other
> rules you like. E.g. We always say rules with the higher QoS go above other
> rules within the same rule group.
>
> Doesn't make a difference in terms of actual QoS performance, it's just makes
> it easier for someone to come along and see where their new rule needs to be
> inserted, if their is a clear guideline to follow (which we leave commented
> in the pf file for reminders).
>
> If anyone has a clever way of managing it I'd be interested but simple
> guidelines seem to work well enough.
>
> PS; cannot encourage enough the benefits of two firewalls, honestly (esp if
> your sharing the management). It makes it so much easier to make a change to
> a backup firewall, switch to it gracefully, and check all is ok. then git
> pull your new PF on the previous firewall once your happy you don't have to
> roll back quickly.
>
> You won't loose any states or break any connections created by a previous a
> ruleset as pfsync will keep you happy. If new connections are failing on the
> new ruleset just switch back. Barely anyone will notice a thing if your quick
> about spotting a fatfinger issue.
>
> Cheers, Andy
>
>
> Sent from my iPhone
>
>> On 8 Apr 2014, at 19:47, Wiesław Kielas <wieslaw.kie...@bluemedia.pl> wrote:
>>
>> Wiesław
Hi,
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.
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. 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.
Now, I believe that as many others pointed the combination of
rdomains with pf is the way to go. Not perfect but close to what you
want to accomplish.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
