Übergang zu OpenSearch
Rocco Gagliardi
In the Checkpoint manual, the erule Name_ is described as the:
Name used to indicate the significance of the specific rule. erule 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 erule 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 erule Name_ really useless?
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/createeremove the technical implementation of a 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.
Use the erule 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 erule Name_ are:
Based on the requirements, we could form our erule 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 erule Name_ field could be:
<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.
A really nice side effect of structuring the erule 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 erule 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.
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:
Nr. | Name | Source | Destination | VPN | Service | Action | Track | Install On | Time | Comment |
---|---|---|---|---|---|---|---|---|---|---|
56 | 3.ap101.1 | Any | dmz_mail | Any Traffic | smtp | accept | Log | Policy Targets | Any | created, 20060103, rcc |
57 | 3.ap101.2 | dmz_mail | Any | Any Traffic | smtp | accept | Log | Policy Targets | Any | created, 20060103, rcc |
on fw-int
, the firewall placed between DMZ and Intranet:
Nr. | Name | Source | Destination | VPN | Service | Action | Track | Install On | Time | Comment |
---|---|---|---|---|---|---|---|---|---|---|
63 | 2.ap101.1 | dmz_mail | int_mail | Any Traffic | smtp | accept | Log | Policy Targets | Any | created, 20060103, rcc |
64 | 2.ap101.2 | int_mail | dmz_mail | Any Traffic | smtp | accept | Log | Policy Targets | Any | created, 20060103, rcc |
the SmartTracker with a filter [ erule Name_ – Contains – .ap101. ], will show:
Nr. | Date | Time | Origin | Source | Destination | Svc. | Action | Rule | Rule Name |
---|---|---|---|---|---|---|---|---|---|
11 | 27Apr12 | 10:11:12 | fw-ext | mx.google.com | ap101_dmz_mail | smtp | accept | 56 | 3.ap101.1 |
22 | 27Apr12 | 10:11:12 | fw-int | ap101_dmz_mail | ap101t_mail | smtp | accept | 63 | 2.ap101.1 |
33 | 27Apr12 | 11:12:13 | fw-int | ap101t_mail | ap101_dmz_mail | smtp | accept | 57 | 3.ap101.2 |
44 | 27Apr12 | 11:12:13 | fw-ext | ap101_dmz_mail | mail.yahoo.com | smtp | accept | 64 | 2.ap101.2 |
With a single simple filter it is possible to also track DMZ gateway activities.
Structuring the erule 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,$aercc,$v:1}
Unsere Spezialisten kontaktieren Sie gern!
Rocco Gagliardi
Rocco Gagliardi
Rocco Gagliardi
Rocco Gagliardi
Unsere Spezialisten kontaktieren Sie gern!