Part of why managing firewalls is hard

December 21, 2008

Let me say it up front: managing a firewall of any decent complexity is hard. Sooner or later you start losing track of rules and what's actually going on, writing half-redundant rules, and so on; in short, your firewall ruleset descends into sysadmin superstition. I've recently realized that part of why this happens is that there are three views of your firewall's behavior that you need, and you can't get all of them just from reading your firewall rules; at most you can get one. (Often you don't get any.)

Firewalls are about certain sorts of sources being allowed to do certain sorts of traffic to certain destinations; in the abstract you say 'NFS clients are allowed to do NFS to NFS servers, and no one else is allowed to do NFS to anywhere'. You can want to look at your firewall from the perspective of any of those three things:

  • what traffic is allowed to this machine (or group thereof)?
  • what can this source of traffic do and reach?
  • what are all of the rules for NFS?

(It is tempting to think that you only have one source of traffic, that being the outside world, but I think this is wrong twice over. First, internal machines making outgoing connections are also a source, and you probably have them, and second sooner or later you are going to be treating some outside machines specially.)

You can write a firewall rule system that makes any one of these three the central focus (and you can of course write rule systems that make none of them the central focus, because the rules are expressed at a lower level). But you cannot write a rule system that makes all of them the focus simultaneously, and so you are always going to have to slice up and analyze your firewall rules to get two out of these three views. Even if you can do this, it is quite difficult for people to keep track of all three views at once and synthesize an overall picture from the combination (and thus you get fragile complexity).

This insight makes me vaguely depressed because it means that I can't solve my firewall problems by coming up with the right clever way and the right high level language to specify the firewall rules in. No matter how clever I get, no single thing can give me the overall view of what's going on; it's always going to be hard to get that.

(In my opinion, common OS level firewall rule systems are best viewed as a kind of firewall assembly language (Linux more than OpenBSD); by themselves they are too low level to give you any of these views. You can no more easily understand your firewall by reading PF or iptables rules than you can easily understand anything but a tiny and trivial program by reading its assembly.)

Comments on this page:

From at 2008-12-22 11:55:30:

Have you looked at a Checkpoint policy manager GUI lately? While not perfect, it makes firewall management very easy. The object grouping, targets (specify which firewall(s) the rule applies to) and rule groups make for a very tidy policy. This is important when you're asked to make routine change requests because you need to know where to insert new rules. These changes are usually as simple as adding a host or service to an existing group.

I compare this to PIX/ASA and various open source firewalls, many of which will not allow the grouping of heterogeneous objects. I'm not trying to pimp CheckPoint or anything (performance wise, I've always preferred PIX/ASA) but I have always found their management tools/structure to be top notch.


By cks at 2008-12-23 02:13:39:

I've never had the chance to play around with any of the commercial firewalls; given that the free alternatives work well enough, university budgets basically mean that commercial firewalls are completely off limits.

From at 2008-12-23 08:34:10:

Maybe look at general higher-level management tools like Puppet ( )? This will allow you to specify things in terms of services and hosts, and I believe (but I'm not 100% sure) that there is a query interface so you'd be able to see what NFS rules are being applied to the various hosts, say.

Written on 21 December 2008.
« The role of superstition and folklore in system administration
You need major advantages to really move issues »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Dec 21 23:15:45 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.