[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pf with many interfaces?



Hi,


some comments ...


Adam Morley wrote:
My pf firewall has about 18 or so interfaces (10 physical interfaces,
and a bucket of VLANs).   It is layer 3, and routes packets.   This,
combined with my previous experience not requiring interface names in
rules makes me want to do:
em0: 10.1.0.0/24
em1: 10.1.1.0/24
em2: 10.1.2.0/24
em3: internet connected, say, 65.1.1.0/24 for the purposes of this
example.

First of all, you might want to set up macros - I like the idea of being able to reconfigure my pf configuration by editing it in as few places as possible and do whatever I want by making minor changes to my macros on top of pf.conf.


The next nice thing is to start with a

block log

and then block quick those packets that you know you never want to let through. This simplifies the following pass rules, because you don't have to care about certain things anymore. For example

block in log quick on em0 from ! (em0:network)

This syntax in parentheses also happens to represent what you appear to be used to, like "I only want to see packets from the proper network on that interface." A prerequesite for this to work properly is a correctly configured em0 interface with the appropriate netmask.

With this sanitization in place, you get some nice benefits - you can use the fewer/shorter rules that you want to use, you can decide whether you forgot about a certain group of packets when they get caught by the first block log rule, etc.

table <outsideworld> { *, !<internal_subnets>, !<rfc1918>, !<classD>, !<classE> } (can I use * or should it be 0.0.0.0/0?)
table <notoutside> { <internal_subnets>, <rfc1918>, <classD>, <classE> }

(Nested tables don't work.)


Outside is everywhere that isn't inside. Don't use two tables when you can do it with only one. You can look at this by checking outgoing packets on the interface pointing to the 'net from certain addresses/networks, or by using a macro or table for everything inside and negating it.

How about adding a layer of abstraction that allows you to work with group interfaces and/or networks into entities that are allowed to do certain things instead of grouping them as what they are or where they point to? With so many interfaces, maintainablility should be your main concern (if your actual ruleset gets too complex for the hardware, upgrade the hardware - it'll be cheaper than the time you have to spend on possibly optimized-for-speed but complicated and hard to understand rules), and changing permissions by adding or removing networks/IPs/interfaces/etc from macros or tables is better than digging through the filter every time.

(obviously, I would implement this using tags and more lists to make
it cleaner, but i didn't want to get it too confusing as a first pass)

Well, you could still tag each and every packet at this stage and see whether you can use 'em or not lateron, and remove those you don't need after you figured out where you want to go with this in the end. As I said above, your goal (apart from the obviously required functionality) should be to have some hooks where you can adjust your rules with as little effort as possible later when the whole thing goes live. Concerning tags, I personally used them on a bridge, for sortof application level filtering (ftpsesame can tag packets) as well as making it easier for me to logically separate one network into a privileged and an unprivileged part. I do not use them when I can do things simpler or equally simple without them.


Pf allows you to solve problems any way you like - you can write rules that make it behave just as awkward as iptables, and you can do it simpler, too. :) Another advice would be that you get a pen and a paper and take a fresh look at your situation with pf in mind. Getting used to its simplicity may take a while, but once you're used to it that some or all of the cruft you are used to is not required, the solution might look as easy as it can get with 21 interfaces ...

I also found it useful to abuse labels as rule comments. With labels and pftop from ports, debugging rulesets gets a lot easier. Also, remember that you can put almost anything in macros. Things that are repeated often, like "flags S/SA keep state" could go into a macro $SK, to make rules appear shorter and easier to read.


Moritz



A. Lester Burke Network Analyst Arlington Public School Arlington VA E [email protected] V 703-228-6057

The wise man can learn from the fool but the fool cannot learn from the wise man.

Dad