Best Practices - Rulebase Construction and Optimization for R77.30 and Lower

Support Center > Search Results > SecureKnowledge Details

Technical Level

Solution ID	sk106597
Technical Level
Product	Quantum Security Management, Multi-Domain Security Management, Quantum Security Gateways, ClusterXL, Cluster - 3rd-party, VSX, SecureXL
Version	R77.20 (EOL), R77.30 (EOL)
Platform / Model	All
Date Created	13-Jul-2015
Last Modified	30-Jan-2023

Solution

For R80 and higher, refer to the Security Management Administration Guide and Logging and Monitoring Administration Guide for your version.

This article provides best practice guidelines for Check Point rulebase construction and optimization.

Rulebase Overview

The Check Point rulebase contains the policy rules that govern what connections are permitted through the firewall. When the firewall receives the first packet of a new connection it inspects the packet and checks the rulebase to see if the connection is allowed or if it should be either rejected or dropped.

The rulebase is checked top-down meaning the firewall checks the rulebase by looking for a match in the first rule and if the connection is not matched the firewall then works its way down through the rulebase until it eventually finds a match.

Rule order is a critical aspect of an effective rulebase because it can affect both the operational performance of the firewall and the operative accuracy of the policy. Having the same rules, but putting them in a different order, can radically alter the effectiveness of the firewall. Always place more specific rules first and the more general rules last to prevent a general rule from being applied before a more specific rule.

General Rulebase Layout

The rules within the rulebase are generally arranged as shown below:

The Business related rules section contains the rules that regulate your business traffic.
Business related rules should be grouped together in logical sub-sections to make the format of the rulebase easy to understand. The sub-sections that are most heavily used should be placed highest in the rulebase (so long as doing this does not compromise SecureXL tuning).

The blue coded rules are the Implied Rules (Policy > Global Properties > Firewall Implied Rules).
The enabled default Implied rules can be selectively turned off if not required or if the administrator has created specific rules to replace them. This is often done to harden or 'nail-down' the rulebase.

The green coded rules are VPN, management and noise rules.
The admin and management rules control access to the firewall e.g. SSH, HTTPS etc. If the implied rules have been disabled then specific rules to permit all required connections to and from the firewalls will be required.

The purpose of the Noise rule is to drop unwanted traffic such as NetBIOS traffic as high up in the rulebase as possible.
The use of a Noise rule helps to make the firewall more efficient by dropping unwanted traffic high up in the rulebase instead of at the bottom of the rulebase (clean-up rule).
If the 'noise' traffic is mixed with 'useful' traffic then additional noise rules can be placed within the Business related rules section to drop the unwanted noise traffic once the useful traffic has been matched.

The Stealth rule should be located as early as possible in the policy, typically placed immediately after the management rules.
The purpose of the Stealth rule is to drop unauthorized connections destined to the firewall; protecting the firewall from being scanned and attacked.
The rulebase is likely to be constantly evolving so the effectiveness of the Stealth rule should be periodically tested; it may need to be re-positioned to maintain effectiveness.

The clean-up rule is the last rule in the rulebase and is used to drop and log explicitly unmatched traffic.
To improve the rulebase performance, noise traffic that is logged in the Clean-up rule should be included in the Noise rule so it is matched and dropped higher up in the rulebase.

Rulebase Best Practices

As the rulebase grows in length and complexity it becomes harder to understand and maintain. If several firewalls are managed by the same rulebase the complexity of the rulebase is further increased. Creating a single policy per firewall or firewall cluster can help to simplify the rulebase and make the policy easier to maintain.

Section Titles
Use section titles to identify and group similar rules together; makes the rulebase easier to understand and maintain. Section titling helps administrators to place additional rules in the right place within the policy.
Name Field
Use the Name field to create a name for the rule that describes the purpose of the rule. The name will appear in the logs and can help in troubleshooting sessions.
Comment Field
Use this field to further describe the rule and other pertinent information such as change request numbers.

Rulebase Optimization

The rulebase efficiency is optimized by moving the most hit rules towards the top of the rulebase. Identifying the most hit rules can be achieved by using either the SmartReporter Rulebase Analysis report; the rulebase Hits count or by monitoring the Top Security rules in SmartView Monitor.

Some services and rulebase objects disable SecureXL or stop connection rate templating which will have a negative impact on the firewall's performance. It is important to check moving a rule does not have a detrimental impact on SecureXL otherwise the benefit of moving the rule can be easily out-weighed by the impact on SecureXL.

Refer to sk32578 (SecureXL Mechanism) to allow more connections to be accelerated by SecureXL.

Identifying the Most Hit Rules:

SmartReporter - Rulebase Analysis:
SmartReporter can provide a Rulebase Analysis report for individual firewalls based on logged traffic

An extract from the Rulebase Analysis report:
Hits Counter:
The Check Point rulebase Hits counter (introduced in R75.40) shows the accumulated hits a rule has received in the rulebase. The rulebase hit count can be reset using the procedure in the following Secure knowledge article:

sk72860 (How to reset the 'Hit Count' in SmartDashboard)

Hit counter in the rulebase:
SmartView Monitor - Top Security rules:
If the firewall's monitoring blade is active then SmartView Monitor can be used to monitor the most hit firewall rules.

Monitoring blade option on Firewall object (license required):

SmartView Monitor - Top Security rules:

SecureXL and Rule Placement

Some factors, such as certain operations and IPS defenses may decrease SecureXL performance, resulting in loss of traffic acceleration, disabled templates and a decreased session rate. Optimizing the rulebase for SecureXL will help to optimize the performance of the firewall.

Refer to sk32578 (SecureXL Mechanism).

Rulebase Installation Performance

Unused objects and duplicate objects will increase the policy verification time. Avoid creating duplicate objects and delete unnecessary objects. Cleaning up these objects can greatly improve the overall policy installation time.