In the Checkpoint manual, the Rule Name is described as the:

Name used to indicate the significance of the specific rule. Rule Name appears throughout all the applications (for example, SmartView Tracker, SmartReporter, and so on), and offers a clue as to why it is being used.

During our firewall rule reviews, we see different usage of the Rule Name field: the most used value is “” (none, null, void …), then a plethora of strings ranging from “Test” to the lapalissian “Allow rule” (sometime in conjunction with a drop action). Is the Rule Name really useless?

A reasonable case

Basically a rulebase consist of a set of rules used to partition the traffic between two areas in as small as possible channels to monitor/allow/block the traffic flow. Normally a rulebase may have hundreds of rules, grouped – or not – in higher level logical blocks reflecting some administrative properties not strictly related to the technical implementation (example inbound/outbound smtp traffic is usually placed nearby even if not technically necessary). Typically an organisation uses a management process, with some word/web/paper forms, to justify/document/monitor/create/remove the technical implementation of a rule:

1. an application requires communications paths
2. a programmer fills out an order describing the action (add/change/remove) and the src/dst/svc
3. an engineer designs a possible solution
4. a revisor accepts/rejects the request
5. an operator technically implements the rule

Keeping the process synchronized (all parties refer to the same rule), a necessary step to assure a high quality level of the rulebase, is a challenge and a common source of security issues.

A possible structure of the Rule Name

Use the Rule Name field to map the technical and the management level, creating a bijection between the rules described in the management process and the technical implementation. The requirements for the structured Rule Name are:

1. must be bijective: give an exact pairing of the elements of order and rulebase
2. must be readable: each rule already has a UUID but, even if unique, something like 99cffc66-0660-1001-abcd-00aa11bb22cc is “hard to remember”
3. must be simple enough to maintain

Based on the requirements, we could form our Rule Name considering the Enforcement Point where the rule would be installed, the order – or the application – needing the communication and the position of the rule in the order. A possible structure of our Rule Name field could be:

1. EP identification
2. order identification
3. line in the order

<fw-id>.<order-id>.<order-line>

This format is a little bit redundant in favor of readability, but visually clear and effective. It is possible to quickly identify the EP and the order which normally identify an application. In case of troubleshooting or revision every rule it is easier to classify and relate to an application (area), refer to a management order and/or a responsible person.

Using numerical or text identifier does not really matter, the important thing is to use normalized identifiers:

ext.mail.1, int.mail.1, ...
ext.av.1, int.av.1, ...
1.101.1, 2.202.2, ...

Based on the number of orders and how the internal process is organized, it may be more confortable to use numbers instead of strings.

The side effects

A really nice side effect of structuring the Rule Name is the new filtering possibilities of the logfile. Basically, we assigned some new management properties to each rule, so we can now use these properties to get some management results. Even in the simple case of a single firewall

Client(s)->FW01->Server(s)

naming each rule with format <fw-id>.<order-id>.<order-line> can help filtering all logs related to a specific order-nr or application without using complex src/dst filter. Consider now the common case of a connection traversing multiple EPs with complications like proxies/gateways/NATs and so on.

Client(s)->FW01->DMZ-Server(s)->FW02->Internet

In this case it would be very difficult, or impossible, to filter the logfile via src/dst/svc, but a childs play using the Rule Name: just track logs containing ".<order-nr>." and follow how an internal client causes a new connection originating from a server in a DMZ. This method has proven to be very usefull in troubleshooting cases.

An example

Consider the case of allowing mail traffic from internet to intranet and vice versa. A normal configuration has a DMZ mail server accepting and controlling all incoming/outgoing mails; if mail passes all checks (antispam, virus, …), it is forwarded to the final destination. On the firewalls we need to allow the communication between internet<->DMZ<->intranet.

The SmartDashboard configuration:

on fw-ext, the firewall placed between DMZ and Internet:

on fw-int, the firewall placed between DMZ and Intranet:

the SmartTracker with a filter [ Rule Name – Contains – .ap101. ], will show:

With a single simple filter it is possible to also track DMZ gateway activities.

Summary

Structuring the Rule Name has some costs related to the manual maintenance of referential integrity; on the other side, we obtain a cheap and efficient tool that helps to synchronize the “should” with the “is” state and new tracking filter, which could help a lot in case of troubleshooting.

{$t:Structuring the Rule Name in Checkpoint Firewall,$a:rcc,$v:1}

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.