how to manage big pf-rulesets in a comfortable way

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

how to manage big pf-rulesets in a comfortable way

Joerg Streckfuss-2
Hi list,

i need some hints to manage a pf ruleset of about more than 150 rules.

In my company we want to design a firewall-cluster with about
10 interfaces. We plan to use two dell 1850 with two DFE-580TX
quad port NIC's.
Each interface points to a separate subnet. The cluster should use carp
for redundancy.

The problem is to manage the hole ruleset in a comfortable way. One of
my ideas is to put the ruleset of each subnet into an extra file and
load it into pf with anchors. This will reduce the main ruleset
extremely.
The disadvantage is that all macros listed in the main ruleset have to
be listed in the subnet ruleset too - this is a little bit error-prone.
In my opinion bandwith managment with separate files is not an elegant
way as well.
Interface groups are not the solution, because the subnet rulesets are
too different.
At the end, i have to put all rules into a single file.

So is there a better way to handle big rulesets?

Cheers Joerg.

--
Joerg Streckfuss, DFN-CERT Services GmbH
PGP RSA/2048, E0D4BD3F, 90 C3 FB 4A CB D3 20 70  6B 04 47 84 B5 3C 28 8C

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: how to manage big pf-rulesets in a comfortable way

Joachim Schipper
On Wed, Feb 01, 2006 at 12:28:33PM +0100, Joerg Streckfuss wrote:

> Hi list,
>
> i need some hints to manage a pf ruleset of about more than 150 rules.
>
> In my company we want to design a firewall-cluster with about
> 10 interfaces. We plan to use two dell 1850 with two DFE-580TX
> quad port NIC's.
> Each interface points to a separate subnet. The cluster should use carp
> for redundancy.
>
> The problem is to manage the hole ruleset in a comfortable way. One of
> my ideas is to put the ruleset of each subnet into an extra file and
> load it into pf with anchors. This will reduce the main ruleset
> extremely.
> The disadvantage is that all macros listed in the main ruleset have to
> be listed in the subnet ruleset too - this is a little bit error-prone.
> In my opinion bandwith managment with separate files is not an elegant
> way as well.
> Interface groups are not the solution, because the subnet rulesets are
> too different.
> At the end, i have to put all rules into a single file.
>
> So is there a better way to handle big rulesets?

From what I hear, you'd be pretty happy with the following Makefile:

.PHONY: all

PF_OBJS=/etc/pf.d/hosts /etc/pf.d/server_rules /etc/pf.d/client_rules \
        /etc/pf.d/bandwidth
all: /etc/pf.conf

/etc/pf.conf: $(PF_OBJS)
        umask 077 && cat $(PF_OBJS) > /etc/pf.conf.new
        mv /etc/pf.conf.new /etc/pf.conf

Makefiles are very useful for system administration. I always have a
couple lying around in strategic places.

For an even more convenient solution, put this in a distfile (see
rdist(1)):

# Please note the Makefile is under /etc/pf.d!
F_PF = ( /etc/pf.d )
H_PF = ( [hidden email] [hidden email] )

update-fws: ${F_PF} -> ${H_PF}
        install -o younger,remove / ;
        cmdspecial "cd /etc/pf.d && make" ;

The only real disadvantage is the required root access. It can be
curtailed a bit, but not much - rdist requires write access to quite a
few critical files, usually.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: how to manage big pf-rulesets in a comfortable way

Joerg Streckfuss-2
In reply to this post by Joerg Streckfuss-2
Hi Marc,

Thanks for your advice but i have already tested fwbuilder.
The builder is nice to edit a big ruleset, but i dislike the
concept of global- and interface-policy. In global policy-section
i missed the direction for packets. An example:
If you want to edit some antispoof rules, you have to use the interface
policies because of the direction and so you have to write more rules
than only say "antispoof for $ext_if inet" in pf.conf.
Futhermore i missed some features like synproxy, statefull tracking
options an bandwith management.

cheers Joerg.


Am Donnerstag, den 02.02.2006, 14:17 +0100 schrieb Marc Peters:
> hi joerg,
>
> you may want to have a look at firewall builder (www.fwbuilder.org). it
> can produce rulesets for pf, but you should have a look at the conf
> later on and check the ruleset if it fits your needs.
>
> hth,
> marc
--
Joerg Streckfuss, DFN-CERT Services GmbH
PGP RSA/2048, E0D4BD3F, 90 C3 FB 4A CB D3 20 70  6B 04 47 84 B5 3C 28 8C

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: how to manage big pf-rulesets in a comfortable way

tony sarendal
In reply to this post by Joerg Streckfuss-2
On 01/02/06, Joerg Streckfuss <[hidden email]> wrote:

>
> Hi list,
>
> i need some hints to manage a pf ruleset of about more than 150 rules.
>
> In my company we want to design a firewall-cluster with about
> 10 interfaces. We plan to use two dell 1850 with two DFE-580TX
> quad port NIC's.
> Each interface points to a separate subnet. The cluster should use carp
> for redundancy.
>
> The problem is to manage the hole ruleset in a comfortable way. One of
> my ideas is to put the ruleset of each subnet into an extra file and
> load it into pf with anchors. This will reduce the main ruleset
> extremely.
> The disadvantage is that all macros listed in the main ruleset have to
> be listed in the subnet ruleset too - this is a little bit error-prone.
> In my opinion bandwith managment with separate files is not an elegant
> way as well.
> Interface groups are not the solution, because the subnet rulesets are
> too different.
> At the end, i have to put all rules into a single file.
>
> So is there a better way to handle big rulesets?



Being able to manage large firewalls with pf (and others) is about ruleset
design.
Make a design where you know where the rule is(or should be) by just knowing
the rule.

Splitting it into multiple files will not help you much if the design to
start with is
inconsistent. I use external files to store the tables in so we can add
remove stuff like
syslog clients without poking around in the rules.

I have managed many boxes with lots of interfaces and rules, and I found pf
to be the easiest to work with once I understood how states actually were
handled
and could make a design for it. My vlan firewalls are a breeze to manage,
especially
with excellent tools like CVS/RCS.

/Tony

--
Tony Sarendal - [hidden email]
IP/Unix
       -= The scorpion replied,
               "I couldn't help it, it's my nature" =-