On Fri, Jul 12, 2013 at 11:12 AM, Andy <[email protected]> wrote: > 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 > > >
Yep, fantastic explanation Andrew ... Many thanks.
