[ previous ] [ next ] [ threads ]
 From:  "Lee Sharp" <leesharp at hal dash pc dot org>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Re: per-interface rulebases: why?
 Date:  Thu, 1 Jun 2006 15:17:41 -0500
From: "Molle Bestefich" <molle dot bestefich at gmail dot com>
> Chris Buechler wrote:

>> Can you name a firewall vendor that doesn't do per-interface rulesets?

> I can name a dozen.

> Start in the big league with the mother of them all, Check Point
> Software Technologies Ltd.

Not sure if I would say this is the best commercial firewall... :-)  And it 
can get confusing when you are using it between many interfaces with rules 
between them.  Of course few Check Point firewalls get a lot of 
interfaces...  Usually more than 10 goes to a vendor with dark blue cases. 

>> Or one good reason it shouldn't be this way?

> If there's no real use cases (as I suspect), then adding complexity
> makes the rulebase harder to figure out.

It makes it much simpler if you think in a "spatial relations" sort of way. 
What is the flow of the traffic, and look at those interfaces.

> * It forces the administrator to think interfaces into every rule,
> even though they are completely irrelevant (please state use cases if
> you think this is wrong).

I can not think of a time when interfaces are irrelevant.  They are used 
every time you touch the firewall.  And thinking this way helps you 
visualize where the traffic is, and what could be breaking it.  Sometimes it 
is not the firewall.  (MTU issues spring to mind)

> * The administrator needs to look in a multitude of different sections
> for h(is/er) rules.

All firewalls break stuff into categories.  One page of rules can be 
terribly daunting.  However, if you wanted to, you could change the display 
easily by just changing a page.  I could see having the interfaces as 
collapsing/expanding entries as opposed to tabs.

> * You loose a lot of simplicity - it's no longer "rules mentioned
> first are acted upon first", "it's rules listed first are acted upon
> first, well, depending on how the traffic looks and on which interface
> it arrived or is going to, and depending on whether the packet in
> question is currently before or after the kernel IP router.." or some
> such..

This is how firewall work on the lowest level.  You come in on an interface. 
Does first rule apply? Next...  It is just grouped by interface to make it 
easier for US.  It also helps a lot in trouble shooting if you know how your 
traffic flows.

>> The vast majority of the time, it makes rulesets much cleaner and
>> easier to work with, and easier to read and comprehend.

> Ok, that's a real use case!
> Thanks!

> Can you elaborate?
> How is per-interface rulebases much cleaner compared to other ways of
> grouping rules?

How is a Ford better than a Chevy?  We had to pick one.  I prefer per 
interface rules.  However, it is trivial to change.  Just change the HTML 
code on the rules php page.

> (For example, you could maintain the simplicity and linearity of one
> rulebase if you allowed the user to group consecutive rules into a
> "group", which could be folded/unfolded by javascript with the click
> of a '+/-' button.)

This is a LOT harder to implement.  Dynamic pages to that level would 
require a lot more work, and an additional batch of entries in the config