Hi, No we don't use the puppet firewall module as it doesn't support PF properly. We don't use any 'software' to manage PF rules, but we do still have rules sets with thousands of lines.
I have never found any PF configuration software that comes anywhere near what can be done with a carefully designed and hand written PF file structure, using Vim (with a modified bashrc and filetypes), reading the Book of PF and following the OpenBSD change logs to keep up with new features/changes and knowing the PF flow diagram by heart ( http://notamentaldowu.files.wordpress.com/2009/08/flow.png?w=700). Their just simply isn't a magic bullet if you want to achieve the full power of PF.. There are many great pieces PF software out there which are good for people who are learning, but none which can ever fully support the extremely wide features and packet mangling capabilities of PF (which is continually growing and changing), or can correctly parse all of our rules. Things especially get more complicated for parsing when you have multiple 'related' rules attached to different physical interfaces, but where all are needed to pass and queue a desired flow. I believe that a well structured PF file which is built up using several includes etc with a strong consistent structure is the best way to have access to /all/ the latest features and functions whilst maintaining visibility and ease of management. To make PF super friendly in Vim, set-up your PF syntax highlighting; /root/.vimrc; so /root/.vim/filetypes.vim set guifont=9x15bold set ruler syntax on set tabstop=4 set shiftwidth=4 filetype on /root/.vim/filetypes.vim; augroup filetype au! au BufRead,BufNewFile *.c set filetype=c au BufRead,BufNewFile pf.* set filetype=pf au BufRead,BufNewFile pf.conf set filetype=pf au BufRead,BufNewFile pf.conf.* set filetype=pf au BufRead,BufNewFile snort.conf set filetype=hog au BufRead,BufNewFile snort.conf.* set filetype=hog augroup END Not wanting to waffle as this is already long, but seeing as people seem interested (tell me to shut up if I am just generating noise ;) we structure our PF's roughly as follows; Global common; 'pc.conf.internalnetworks' - Defines common macro names for /all/ of the different subnets we have globally; E.g. int_net_hbase="10.0.50.0/24", int_net_solr="10.0.51.0/24", int_net_stage="10.0.52.0/24" ..... 'pf.conf.hosts' - This is a dynamic file. We have a script on each firewall which connects to the 'local' LDAP server, downloads every host macro for that zone and prints the int_ip_<cn name>=<IP> macros into pf.conf.hosts 'pf.conf.publicips' - defines common macro names for /all/ of our public IP addresses to the roles they provide access to (multiple roles means multiple macros with the same IP etc) 'pf.conf.tables' - defines common tables like <blacklist_hosts>, <snort2pf>, <ossec_fwtable>, <trusted_networks> etc.... 'pf.conf.options' - defines all our non-default firewall options including 'states', 'table-entries' .... and all of our 'Stateful Tracking Option' macros 'pf.conf.portgroups' - defines common service groups. E.g. 'office_mail_protos="smtp, 465, submission, imaps, pop3s"', 'office_chat_tcpports="5190, 5222, 5223, 5269, 5349"' etc.... Per environment common (DC, Office etc); 'pf.conf.queues.office' - defines all our HFSC queues (NB; the bandwidth values are $variables which are defined in the site specific includes allowing for a generic queue structure for all offices). 'pf.conf.queues.livedc' - defines all our HFSC queues (NB; the bandwidth values are $variables which are defined in the site specific includes allowing for a generic queue structure for all offices). 'pf.conf.rules.common.office' - The common office rules 'pf.conf.rules.common.dc' - The common DC rules 'pf.conf.scrub' -antispoof, urpf-failed, non_routable drops, packet scrubbing and tagging etc Site Specific; 'pf.conf.interfaces.berlin' - Defines common macro names mapping to all the physical interface names; E.g. if_ext="em0", if_lan="em1", if_dmz="em2" ..... 'pf.conf.interfaces.newyork' - Defines common macro names mapping to all the physical interface names; E.g. if_ext="em0", if_lan="em1", if_dmz="em2" ..... 'pf.conf.rules.berlin' - rdr-to, binat-to, nat-to, block, pass etc.. These bespoke per site rule files are now small and easy to manage :) 'pf.conf.rules.newyork' - rdr-to, binat-to, nat-to, block, pass etc.. . etc Puppet then pushes out the appropriate files to the appropriate firewalls using simple manifests. Hope this makes sense.. By grouping and standardising common things, the final site specific rules become very small and easy to read, and making wider global/environment changes are a one file change :) NB; When writing filter rules try to continue to be consistent and maintain structure remembering the 'PF skip steps' (PF optimises rule inspection by grouping rules (skip steps) skipping by; interface, protocol, source, destination, and finally by dest port). # EXT Interface, WAN Transit Egress Rules (post NAT) # EXT Interface, WAN Transit Ingress Rules (post NAT) # LAN Interface (Interzone), ZONE->ZONE Rules (Internal bandwidth queues) # LAN Interface (Outbound), LAN->WAN Rules (WAN bandwidth queues) # LAN Interface (Inbound), WAN->LAN Rules # DMZ Interface (Interzone), ZONE->ZONE Rules # DMZ Interface (Outbound), DMZ->WAN Rules # DMZ Interface (Inbound), WAN->DMZ Rules . . . We are only just starting to build out IPv6 support and so this will need adjustments to support that properly as in our case it triplicates the rule sets (filtering IPv4, IPv6 and IPv4 embedded in IPv6 (0064:ff9b::<v4>/96 - RFC6052)). And we also want to move away from rule based filtering to policy based filtering which should reduce the rule set sizes but requires a deeper knowledge and a rule clean up ;) This is just how we are doing it, it is not neccesserily correct or the best way. So please don't shot or flame if you disagree, constructive criticism please becuase I am certain this can be improved on many times over and I'm only offering this in the hope it helps someone. There is sooooo much more I am yet to learn.. PS; Like Patrick, I'm also after a policy management system still for the level 2 support guys??? Tracking temporary rules etc. Andrew Lemin On 12/07/13 07:07, C. L. Martinez wrote: > On Thu, Jul 11, 2013 at 8:51 PM, Patrick Lamaiziere > <patf...@davenulle.org> wrote: >> Le Thu, 11 Jul 2013 13:18:13 +0200 (CEST), >> Jummo <jum...@yahoo.de> a écrit : >> >>> 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? >> We have a large set of rules at work on several routers/firewalls and we >> use a tool 'list firewall (lsfw)' to help to manage the rules set. The >> goal is to display the rules applied between a source address and a >> destination, on several equipments, doing routing and firewalling. >> See: https://groupes.renater.fr/wiki/jtacl/index >> >> It has some other features, ip cross references by example which is >> cool to know where an address is used directly or indirectly (in >> table/group) or to extract the addresses from the configurations and to >> automate tests on them. >> >> That works fine at work (PF + cisco + checkpoint), but there are some >> limitations (see the doc...) >> >> My next step is a tool to managed security policies. I mean if someone >> asks to open a port, we should be able to track this policy (who, why, >> which rules are used) and to check it. This is work in (slow) progress. >> If someone already has such tool please let me know :) >> >> If you want more precisions ask me, this is a bit out of topic here. >> >> Regards. >> > > A really, really interesting topic. I have the same problem with my > CARP firewalls (20 in total), but I think the best option is the one > that says Andy: fast, reliable and "secure" (if you know what are you > doing) ... > > Andy, do you use the firewall module that comes with puppet to > accomplish this task?? [demime 1.01d removed an attachment of type image/png which had a name of OpenBSD_PF_flow.png]
