2.7 Stealth and Cleanup Rules: Placement and Best Practice

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

2.7 Stealth and Cleanup Rules: Placement and Best Practice

Key Takeaways Explain This Topic AI

The stealth rule blocks direct access to the Security Gateway itself and is placed near the top of the Network layer

The cleanup rule is the last rule in the layer and drops all traffic that did not match any earlier rule

Stealth rule source is typically Any and destination is the gateway object with services like ssh, https, and SmartConsole ports

Cleanup rule should Log or Alert so denied traffic is visible

Correct placement of stealth and cleanup rules is a frequent CCSA scenario
Last updated: July 2026

The Stealth Rule

The stealth rule is an explicit Access Control rule that blocks direct access to the Security Gateway itself. Without it, the gateway's own IP addresses would be reachable by any source that the explicit rulebase allows, exposing the management interfaces and services (SSH, HTTPS, SmartConsole ports, ClusterXL control) to scans and attacks. The stealth rule is the rulebase's first line of defense for the gateway as a host , as opposed to the gateway as a forwarder of traffic.

A typical stealth rule looks like:

Source Destination Service Action Track
Any Gateway-Object ssh, https, fw1, tcp18211, etc. Drop Log

Some organizations write the stealth rule more broadly: Any source, Gateway-Object destination, Any service, Drop. This drops all direct access to the gateway, including the management protocols, and relies on implied rules (SIC, ClusterXL CCP) for control traffic. The broad version is more secure but requires confidence in the implied rules; the narrow version is more selective but requires knowing which services to list.

Why the Stealth Rule Sits Near the Top

The stealth rule is placed near the top of the Network layer — usually as rule 1 or just below any explicit management-access rules — because rules below it could match traffic destined to the gateway and accept it before the stealth rule runs. If a broad Accept rule like Any source to Any destination on Any service sat above the stealth rule, the stealth rule would never evaluate and the gateway would be fully exposed.

The conventional ordering of the top of the Network layer is:

Explicit management access rules (for example, allow SmartConsole only from the management subnet).

Stealth rule — drop direct access to the gateway from anywhere else.

Business allow rules — traffic to and from protected networks.

This order ensures that authorized management traffic is allowed, all other direct gateway access is dropped, and then business traffic is evaluated.

The Cleanup Rule

The cleanup rule is the last rule in the Access Control Network layer. It matches any traffic that did not match any earlier rule and drops it. The cleanup rule implements the default-deny posture that every firewall should enforce: anything not explicitly allowed is denied.

A typical cleanup rule:

Source Destination Service Action Track
Any Any Any Drop Log

The cleanup rule must be the last rule in the layer because any rule placed below it can never match — the cleanup rule, with its Any/Any/Any match, matches everything. Some administrators are tempted to add rules below the cleanup 'just in case,' but those rules are dead rules and signal that the rulebase is mismanaged.

The cleanup rule's Track field should be Log at minimum, and often Alert so denied traffic is visible. The log entries from the cleanup rule are the primary way to detect scans, misconfigurations, and policy gaps: a flood of cleanup-rule drops on a specific service suggests a user or application trying to reach a service that the rulebase does not allow.

Why Both Bookends Are Mandatory

The stealth and cleanup rules together close the two open ends of the rulebase:

Stealth closes the top end: traffic to the gateway itself is denied unless explicitly allowed.

Cleanup closes the bottom end: traffic not matching any explicit rule is denied.

Without a stealth rule, the gateway is exposed. Without a cleanup rule, the layer's default action takes effect — and if the default is anything other than Drop, the firewall is leaking. Even if the layer default is Drop, the explicit cleanup rule is best practice because it is visible, auditable, and configurable for logging and alerting in a way the layer default action is not.

Common Placement Mistakes

CCSA exam scenarios often test these mistakes:

Stealth rule placed below a broad Accept rule. A broad Accept above the stealth rule shadows the stealth rule — the gateway is exposed.

Cleanup rule placed above business rules. A cleanup rule placed too high drops traffic that should have been allowed by lower rules; the lower rules never fire.

No cleanup rule, relying on the layer default. If the layer default is Drop, the firewall still drops unmatched traffic, but there is no visible rule for auditors and no easy way to set Track to Log or Alert specifically for unmatched traffic.

Cleanup rule with Track set to None. A cleanup rule that drops without logging hides the very traffic an administrator most needs to see — denied attempts.

Stealth rule missing entirely. The gateway's own IP addresses are reachable through any rule that allows traffic to the gateway's networks.

A Worked Placement Example

A well-ordered top of a Network layer:

# Source Destination Service Action Track
1 Mgmt-Subnet Gateway-Object fw1, https, ssh Accept Log
2 Any Gateway-Object Any Drop Log (stealth)
3 Net-Internal Net-DMZ http, https Accept Log
4 Net-Internal Net-Internet http, https, dns Accept Log
… … … … … …
N Any Any Any Drop Log (cleanup)

Rule 1 allows administrators from the management subnet to reach the gateway's management services. Rule 2 (stealth) drops all other direct access. Rules 3 and 4 allow business traffic. Rule N (cleanup) drops anything else.

Stealth and Cleanup in Inline Layers

Inline layers also benefit from cleanup rules. An inline layer should end with a cleanup rule that drops traffic that entered the inline layer but matched no specific rule. Without an inline cleanup rule, the inline layer's default action applies — which is often Drop but should be explicit for auditability.

A stealth rule is not typically placed inside an inline layer because the parent rule's match (for example, source = partner subnet) usually does not include the gateway as a destination. The stealth rule belongs at the top of the main Network ordered layer, where the gateway as a destination is a meaningful match.

Best Practices Summary

Place the stealth rule at the top of the Network layer , below only the explicit management-access rules.

Place the cleanup rule last in every ordered layer and every inline layer.

Log the cleanup rule — Track should be Log or Alert, never None.

Document both rules in Comments with the rationale and any change-control reference.

Audit periodically — review cleanup-rule logs to identify traffic that the rulebase does not explicitly allow but that users are attempting.

Why This Matters for the Exam

CCSA R82 tests the placement of stealth and cleanup rules, their function, and the consequences of misplacing them. Expect scenarios where a broad Accept is placed above a stealth rule (gateway exposed), a cleanup rule is placed above a business rule (business traffic dropped), or the cleanup rule is missing (the layer default applies). Recognize the conventional top-and-bottom placement and the rationale for each.