Hi,
I use 'puppet' for this to manage over 20 OpenBSD firewalls now.
I don't know how I would manage without it to be honest ;)
Puppet manages all my pf's (by simply defining multiple files, each
containing different common parts for different zones/roles etc, and
then site specific files etc. Using puppet to 'include' each of the
different parts as necessary, I only have to maintain one code base in
git, make one change to just the one appropriate file, and then push
out that pf change to every single/or group of firewalls using puppet
to do the leg work.
This provides control and 'standardisation' across everything :)
I also use it to manage, and deploy many various different daemons
including Snort etc which signals alerts via syslog to a central OSSIM
server for event correlation.
Anyway, the main point I'm suggesting is it sounds like you need a
change control and deployment system like puppet if you have that many
and are growing.
It took me about 4 or 5 months to develop a complete puppet code base
which manages every aspect of our OpenbSD firewalls, and as a result I
can now keep up with change requests and deploy to the entire fleet in
a matter of minutes without getting myself in a tangle trying to
remember everything/special cases, and most importantly get close to
the holly grail of 'standardisation' and 'normalisation' ;)
https://puppetlabs.com/
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Books
Hope this helps, Andrew Lemin
On Thu 11 Jul 2013 12:18:13 BST, Jummo wrote:
Hi,
How do you manage your pf.conf?
My setup: I have 9 firewalls with carp and each with around 500 lines
of pf.conf, except one firewall, later more. I edit the pf.conf
manually. Every logical pf rule has a unique identifier (a number)
which I add manually and maps to the rule on a wiki page. The wiki
page has this format.
START WIKI PAGE
=== Firewall
This firewall is for ...
== ID
A ID identify one or more rules for a particular service. Please use the
next free ID.
Last used ID: 21
== Changelog
No | Date | Action | Executed by
== Tables
Table | Content
== NAT/Redirection
ID | Description | Source | Port | Destination | Port | NAT-To |
Redirect-To |
Protocol | Date
== Rules
ID | Description | Direction (outgoing/incoming/forwarded) | Source |
Port | Destination | Port | Protocol | Date
END WIKI PAGE
I use a script to manually copy the changed pf.conf to the
corresponding carp partner to keep the firewall pair in sync. Idea: To
check the sync state of pf.conf, Icinga cloud compare the file date of
the two pf.conf.
This works quiet good for me and my firewalls with one exception, my
big fat central router/firewall. This firewall has around 2000 lines
of pf.conf, is attached with 12 VLAN interfaces and get slowly
unmanageable with this concept.
How to you manage such big firewalls? Do you split the pf.conf into
logical parts? Do you use a base structure for every pf.conf? Do you
use a tool for automatic creation of pf.conf? How do you tests your
old rules after you changed something?
I'm happy about any feedback.
Best Regards,
Patrick
