On Tue, Apr 08, 2014 at 03:39:54PM -0600, Daniel Melameth wrote: > On Tue, Apr 8, 2014 at 12:47 PM, Wies??aw Kielas > <[email protected]> wrote: > > I'm trying to achieve something similar to Cisco's firewall contexts or > > Juniper's virtual systems with PF and OpenBSD. > > > > Currently I run an OpenBSD box as a firewalling device for multiple > > environments, most of them independent of each other. My main problem > > with this arrangement is that when I make a mistake modifying the > > ruleset, all of the environments are affected. > > > > Mistakes I've made include: > > - Fatfingering and disabling PF completely on a machine > > - Fatfingering and loading an empty ruleset > > - Creating block rules that catch legitimate traffic > > - Putting rules in wrong order completely changing their behavior > > > > I'd love to be in a situation when I (or any of my colleagues for that > > matter) make any of the mistakes mentioned above the impact for other > > environments (those which rules weren't modified) is minimal. > > > > The best I've came up with so far is using anchors with matching, > > keeping all rules for environments separate, for example: > >> anchor ENV_APP1 on $app1_if from $app1_net > >> anchor ENV_APP2 on $app2_if from $app2_net > > and modifying the rules per anchor at a time. > > > > This brings the problem of restricting access to things like "pfctl -d". > > First I've thought about using securelevel=2, hoping that you can > > manipulate anchors when it's active, but unfortunately it doesn't work > > that way. > > > > Another idea is to forfeit using the root account and work entirely > > though sudo, giving my account access to "pfctl -a" and "pfctl -sr" only. > > > > The obvious thing to do, meaning splitting the firewall into separate > > physical/virtual machines isn't something I'd want to consider for > > multiple reasons, including the actual cost of buying new hardware. > > > > Do you have any ideas on how to approach the problem of logical > > separation of rules? I'd greatly appreciate any help and tips ;-) > > While I don't have this requirement now, I might have in the future so > I'm interested in hearing what others are doing here. That said, the > only thing I have to add is you might want investigate the use of > rdomains and/or rtlabels. >
I think you may want to use anchors with rdomain. Then you can map one rdomain to one anchor and doing so the rule files in the anchors are no longer influencing each other. Using rdomains will have other side-effects (you may need to set rtable in a match or pass rule). I think there are still ways how one anchor could cause issues in another one. You may need to limit the available commands per anchor but this is outside of the scope of pf. -- :wq Claudio
