Just under contruction, version 0.1, last update 2002/11/25

How to write good firewall rules?

This paper is an attempt to write a concept of how to write good firewall rules. Writing good rules means, that other people can follow and understand them, that rules are consistent in their structure, that you can build on them, that they are easily extensible. It is not a paper on firewall rules themself.

Objects and name conventions

In a firewall ruleset you normally work with objects like servers, workstations, services etc. It is not good to give them ad hoc names. In order to make objects understandable it is important to use a consistent and structured convention for names. An object's name should consist of several parts that give an unique description of that object. The different parts of a name of an object should describe it from the more general to the more specific.

For example, you can use the following elements:

1. Quality:
• WKS: Workstation
• SRV: Server
• SVE: Service
• RGL: Rule
• TME: Time
2. Quantity:
• INV: single (individual) Component
• GRP: Group of Components
• MTA: Meta Group (group of groups)
3. Name: an individual and unique name

The schema can be expanded as needed. For example you can use extra elements of quality of your components are localy seperated, network components like router, switches, firewalls etc.

Then you have the following possibilities to build your objects:

• WKS-INV-NAME: a single workstation
• WKS-GRP-NAME: a group workstations
• WKS-MTA-NAME: a meta group of workstations
• SRV-INV-NAME: a single server
• SRV-GRP-NAME: a group of servers
• SRV-MTA-NAME: a meta group of servers
• SVE-INV-NAME: a single service
• SVE-GRP-NAME: a group of services
• SVE-MTA-NAME: a meta group of services (do not use it)
• TME-INV-NAME: a single time range
• TME-GRP-NAME: a group of time ranges
• TME-MTA-NAME: a meta group of time ranges
• RGL-INV-NAME: a single rule
• RGL-GRP-NAME: a group of rules
• RGL-MTA-NAME: a metagroup of rules (do not use it, but can make sense if you use chains)

Group of rules and metagroup of rules are only of theoretical interest and only usable for documentation. But it also depends on the point of view, how abstract you want to see rules. For example some rules can be seperated into subrules.

Ruledesign

The problem of every system is, that an extension of the system can be easily done and understood only if the concept of the system is well developed so that you can say that it has a good basis. If you have a good concept, then you also need the discipline to use this concept all the time. It is not good if exceptions are the rule. The rule must be the rule!

Transfered to firewall rules this means that a bad concept results over time and with a high probability in bad firewall rulesets. With bad rulesets I mean rulesets that are hard to understand. This gives misconfiguration a chance. And then it might be possible that services become unavailable or the firewall unsecure.

Therefore a good concept is necessary. It can help to avoid bad rulesets. It should not be the reality that exceptions dominate a ruleset. Whenever exceptions are necessary (because of time constrains), they should be temporary. After an evaluation by qualified individuals, it has to be decided to delete the rule or to integrate it in a consistent manner into the ruleset. Consistent means not violating the concept. But the rule should be: Exceptions are an exception, and we should avoid them.

Here is a first concept, 10 rules, on how to build a ruleset:

1. Every rule should be considered as a metaobject, which defines, who has access to what service.
2. A service should be considered as one ressource that is offered by one or more servers on one or more different ports.
3. Every single rule that is needed to allow access to a service contains the source- and destination adress(es), the protocol used, the related port and additional information like state, TCP-flags etc.
4. Every single rule is assigned to only one service (implicit, normally the case).
5. To a single service a service user group is assigned, who can use this service. It is not allowed to assign single componets to a service.
6. A user group always consists out of one or more assigned groups or single components.
7. Every single group consists exclusively out of single components or exclusively out of other groups (then it is a meta group).
8. Every single group, that contains no other groups, consists exclusively out of single components, that are grouped in a meaningful way.
9. Single components can be member of more than one group.
10. Groups can be members of more than one meta group.

Documentation

In order to be able to understand a firewall ruleset later and even after more or less changes, you need sufficient documentation, especially on the changes. First you should use all documentation options your firewall configuration program is offering. This should be done using a concept, so that the documentation follows always the same rules and thus is understandable.

All changes should be saved as a document in structural way. There are always people that have to be informed about changes. Rules should have an unique number. To this number a directory on a fileserver with limited access is assigned. In the directory authorized individuals can find all relevant information about this rule. Additionally all documentation should be printed out and stored in a save location.

What information has to be documented in case of a change in the ruleset?

1. The date of change.
2. Who has done the cahnges?
3. Is it a new rule or has an existing one changed?
4. The current number of the rule.
5. Who has asked for the rule change? (name, position, contact)
6. Why was the change in the ruleset necessary?
7. What are the changes?
8. Is the change temporary and if so, when does the rule expire?
9. Is it an ad hoc rule and has it still to be integrated consistently into the ruleset?

back to top