|
||||||||
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 file. Lee |