Check Point Rulebase Explained – Creating Effective Security Policies

Prerequisites: Basic Networking, TCP/IP, Firewall Fundamentals and Security Zones

Imagine a company with several network security requirements.

Employees need access to approved websites.

Administrators need SSH access to certain network devices.

Guest users must not access internal company servers.

How does a firewall decide which connections to permit and which to block?

It uses a Security Policy Rule Base.

In Check Point, a Rule Base contains rules describing which network connections are allowed, denied or subjected to additional security processing.

However, modern Check Point policies can contain multiple layers.

This introduces an important concept:

The first matching rule determines the decision within its current policy layer, but it does not always determine the final decision for the entire connection.

In this article, you will learn:

• What a Check Point Rule Base is
• How Security Policy rules are structured
• What first-match processing means
• Why an Accept rule may not be the final decision
• How Ordered Layers and Inline Layers work
• How cleanup and implied rules affect matching
• How to create, verify and troubleshoot Access Control rules

What Is a Check Point Rule Base?

A Rule Base, also called a Rulebase, is an organized collection of rules within a security policy.

Administrators use SmartConsole to create and maintain these rules.

The Security Management Server stores the policy configuration.

The Security Gateway enforces the installed policy.

Rule Base, Policy and Layer

A modern Check Point Access Control Policy can contain one or more Ordered Layers and may include Inline Layers.

Important Rule Base Columns

Not every column is shown by default.

Available features depend on the enabled Software Blades and policy configuration.

Action vs Track

These fields must not be confused.

Action determines how the firewall handles matching traffic.

Common actions include:

• Accept
• Drop
• Reject
• Inline Layer
• Other supported actions such as Ask or Inform

Track determines how the event is recorded or reported.

Examples include:

• None
• Log
• Accounting
• Supported alerts

A rule with Action: Drop and Track: Log blocks matching traffic and creates the configured log information.

Are Rule Numbers Permanent?

No.

A rule number represents the rule’s current position in its layer.

Adding, moving or deleting rules can change their displayed numbers.

Use descriptive names and appropriate documentation rather than relying only on a rule number.

How First-Match Rule Processing Works

What Does First Match Mean?

In a simple Check Point Access Control layer, rules are evaluated in their configured order.

For a new connection, the firewall checks the conditions of the first applicable rule.

If those conditions do not match, it continues to the next rule.

When a rule matches, the firewall applies the action associated with that rule.

It does not continue searching for a more specific rule farther down the same normal rule sequence simply because that lower rule would be more restrictive.

This is the essential meaning of first-match processing.

Example — Single-Layer Rule Base

Consider this simplified Firewall/Network layer:

Scenario 1 — Administrator SSH

An administrator starts an authorized SSH connection to a gateway.

Rule 1 matches.

The firewall applies Accept for the current layer.

Rules 2, 3 and 4 are not evaluated for this connection within that layer’s normal rule sequence.

If this is the only Access Control layer, the connection has satisfied that layer.

Other applicable security and system controls may still apply.

Scenario 2 — Guest Access to Internal Server

A guest computer attempts to reach an internal server.

• Rule 1 does not match.
• Rule 2 matches.
• Action is Drop.

Result: The connection is blocked.

Rules 3 and 4 are not evaluated.

Scenario 3 — Employee HTTPS Access

An employee attempts an HTTPS connection to the approved DMZ web server.

• Rule 1 does not match.
• Rule 2 does not match.
• Rule 3 matches.
• Action is Accept.

Result: The connection is accepted by the current layer.

If another Ordered Layer follows, matching continues in that next layer.

Scenario 4 — No Business Rule Matches

Suppose a guest attempts to connect to an unrelated destination using an unauthorized service.

None of the first three rules match.

Rule 4 is an explicit cleanup rule with:

Source: Any

Destination: Any

Service: Any

Action: Drop

The cleanup rule matches and blocks the connection.

First-Match Decision Summary

Important — Accept Does Not Always Mean Final Allow

This is the most important distinction in modern Check Point Rule Base processing.

Example: Two Ordered Layers

An organization has:

Layer 1 — Firewall/Network

A rule permits employees to connect to the internet using HTTPS.

Layer 2 — Application Control

A rule blocks an unauthorized web application.

Now an employee attempts to access that application through HTTPS.

Although Layer 1 accepted the connection, Layer 2 denied it.

Final Access Control result: Drop.

The connection must satisfy each applicable Ordered Layer.

For this reason, first-match means first matching rule within the current layer, not always first matching rule across the entire policy.

Two-Layer Example with Three Connections

The table demonstrates how the same connection can be accepted at one stage but blocked at another.

Does Every Packet Repeat the Rule Search?

No.

Check Point is a stateful firewall.

It maintains connection-state information and supports acceleration technologies.

After a connection is established, subsequent packets do not necessarily repeat a complete new-connection Rule Base search.

Application-aware rules may also require additional connection data before an application can be identified.

The examples above describe the logical policy decision, not a guaranteed sequence of internal packet-processing operations.

Ordered Layers, Inline Layers and Cleanup Rules

1. Ordered Layers

Ordered Layers divide Access Control into separate policy evaluations.

For example:

• Layer 1 — Firewall/Network
• Layer 2 — Application Control
• Layer 3 — Content Awareness

Each layer contains its own rules.

The firewall evaluates the applicable layers in order.

Within each layer, the first matching rule determines that layer’s action.

A matching Drop ends Access Control processing.

A matching Accept can continue to the next Ordered Layer.

2. Inline Layers

An Inline Layer works differently.

It is a sub-policy connected to a parent rule within an Ordered Layer.

For example:

In this example:

If Rule 2 does not match:

The firewall continues to Rule 3 in the parent Ordered Layer.

If Rule 2 matches:

The firewall enters the Finance_Access Inline Layer.

It evaluates Rule 2.1, then Rule 2.2 if necessary.

If Rule 2.1 matches:

The Inline Layer applies Accept.

No additional sibling rules in the parent Ordered Layer are evaluated for that matched parent-rule path.

If another Ordered Layer follows, its checks can still apply.

If Rule 2.1 does not match:

The Inline Layer continues to Rule 2.2.

Rule 2.2 is the cleanup rule and drops the connection.

The firewall does not return to Rule 3 in the parent Ordered Layer.

Inline Layer Decision Summary

This last point is important.

An Inline Layer is not simply a temporary detour that automatically returns to the next parent-level rule.

3. Explicit Rules

An explicit rule is created and configured by an administrator.

Examples include:

• Allow approved HTTPS traffic
• Block guest access to internal networks
• Restrict administrative SSH
• Drop unmatched traffic

4. Implied Rules

Check Point also provides implied rules controlled through supported Global Properties settings.

They support certain management and infrastructure communication requirements.

Their configured positions can include:

• First
• Before Last
• Last

Implied rules are separate from ordinary explicit rules.

Therefore, the statement “Rule 1 is always the first rule evaluated” is not universally accurate without considering applicable implied rules.

5. Explicit Cleanup Rules

An explicit cleanup rule is a visible rule that handles otherwise unmatched traffic.

Example for a Firewall/Network layer:

Check Point recommends an explicit cleanup rule at the end of each Access Control Layer.

For some Application Control layer designs, a cleanup Accept is appropriate to allow traffic not otherwise blocked by that application layer.

The cleanup action should reflect the intended purpose of the layer.

6. Implicit Cleanup Rules

Each layer also has an implicit cleanup rule.

It provides a fallback when no other applicable rule matches.

The implicit cleanup action can be configured as Accept or Drop in the layer settings.

An explicit cleanup rule should be consistent with the intended implicit cleanup behavior.

Cleanup Rule Comparison

These are illustrative designs, not mandatory cleanup actions for every environment.

[/SG-VISUAL]

Configuring, Verifying and Troubleshooting Rules

Step 1 — Open the Rule Base

1. Open SmartConsole.
2. Connect to the Security Management Server.
3. Select Security Policies.
4. Open the appropriate policy package.
5. Navigate to Access Control → Policy.
6. Select the required Ordered Layer.

Step 2 — Create Network Objects

For this example, assume the following objects are available:

Step 3 — Add an Access Control Rule

Select the intended position in the Rule Base.

Choose New Rule Above or New Rule Below.

Configure:

Review the rules above it.

An earlier matching Drop rule could prevent the new Accept rule from being reached.

Step 4 — Review Policy Layers

Before publishing:

1. Confirm the intended rule belongs to the correct Ordered Layer.
2. Check whether the rule invokes an Inline Layer.
3. Review relevant cleanup behavior.
4. Check whether later Ordered Layers could restrict the connection.
5. Confirm that implied rules and rule order are understood.

Step 5 — Publish and Install Policy

Click Publish to save the management changes.

Then:

1. Select Install Policy.
2. Confirm the required policy package.
3. Select the intended Security Gateway or Cluster.
4. Install the appropriate Access Control Policy.
5. Confirm successful installation.

Publishing alone does not update the installed policy on the gateway.

Step 6 — Verify the Installed Policy

On a supported Security Gateway, enter Expert mode.

Run:

cpstat -f policy fw

This command displays information about the installed firewall policy.

Review the policy name and relevant installation information.

It does not show every individual rule match.

Step 7 — Test a Permitted Connection

From an authorized Linux client with Netcat installed:

nc -vz -w 3 10.20.30.10 443

The destination must have a working HTTPS service on TCP port 443.

If the route and applicable security policies permit communication, the connection should succeed.

Illustrative expected output:

Connection to 10.20.30.10 443 port [tcp/https] succeeded!

Step 8 — Test a Blocked Connection

From an authorized guest test client, attempt to connect to an internal test server:

nc -vz -w 3 192.168.10.50 443

If a matching Drop rule applies, the TCP connection should not succeed.

Possible illustrative output:

nc: connect to 192.168.10.50 port 443 (tcp) timed out

A timeout alone does not prove that a Check Point rule blocked the connection.

Routing, the target service or another security control may also cause the failure.

Step 9 — Review Logs and Rule Matches

In SmartConsole:

1. Open Logs & Events.
2. Search for the source and destination IP addresses.
3. Review the connection’s action.
4. Identify the matching rule and applicable policy layer.
5. Check whether any later Ordered Layer blocked the connection.

For example, a connection may pass the Firewall/Network layer but be blocked in the Application Control layer.

The relevant log information should be interpreted with this layered behavior in mind.

Step 10 — Review Hit Count

In the Access Control Rule Base:

1. Display the Hits column.
2. Right-click the relevant rule number.
3. Select Hit Count → Display.
4. Select the required display method.
5. Review the available timeframe.
6. Refresh the Hit Count when needed.

Hit Count measures matching connections collected from supported gateways with Hit Count enabled.

It works independently of the rule’s Track setting.

Hit Count vs Logging

Common First-Match Troubleshooting Problems

Best Practices

• Use descriptive rule names.
• Keep restrictive network rules clear and easy to locate.
• Review all relevant Ordered Layers before treating an Accept as final.
• Use Inline Layers for logical organization when appropriate.
• Add an explicit cleanup rule to each layer.
• Keep cleanup actions consistent with the intended layer behavior.
• Check matching logs before changing rule order.
• Avoid broad Any → Any → Accept rules without a specific approved purpose.
• Verify successful policy installation after changes.
• Document changes and maintain an approved rollback procedure.

Key Takeaways

First-Match Logic

• Rules are checked in order within the current Access Control layer.
• The first matching rule determines that layer’s decision.
• A matching Drop blocks the connection.
• A matching Accept stops normal rule matching within that layer.
• An Accept may continue into the next Ordered Layer.

Policy Layers

• Ordered Layers apply separate policy checks in sequence.
• Inline Layers are evaluated when their parent rule matches.
• Once an Inline Layer handles a matched parent rule, evaluation does not resume at the next sibling rule in that parent layer.
• Each layer has its own cleanup behavior.
• Implied rules may affect the effective order of rule evaluation.

Configuration and Verification

• SmartConsole manages the Rule Base.
• Publish saves changes to management.
• Install Policy deploys changes to the gateway.
• cpstat -f policy fw verifies installed policy information.
• Logs help identify matching rules and actions.
• Hit Count shows collected connection matches, not the total packet count.

The Check Point Rule Base controls how Security Gateways evaluate network communication.

The first-match principle is fundamental, but it must be understood within the context of modern layered policies.

In a single-layer Rule Base, the first matching rule determines the Access Control action for that layer.

When multiple Ordered Layers exist, a connection accepted in one layer can still be blocked by another.

Inline Layers introduce additional sub-rule evaluation through matching parent rules, and cleanup rules determine what happens when no other applicable rule matches.

Understanding these differences makes firewall policies easier to design, verify and troubleshoot.

Next Article: Check Point Firewall Policy Layers Explained — Ordered Layers, Inline Layers, Implied Rules and Cleanup Rules.

Useful Links and References

SanchitGurukul Static Resources

Official External References