Stealth Rule best practices

[Cypress]

Have a question:  In the guide 'Creating a basic access control policy,' it is recommended to create a Stealth Rule which restricts management access to the firewall gateways themselves.  I believe most, if not all, customers of Check Point thusly have some version of this rule in their policy.  But it seems like there are many different ways to go about actually writing the rule.

From the guide, the two basic rules they suggest:

1. Source: Admins (Access Role); Destination: Group of Security Gateways; Services: Any; Accept
2. Source: Any; Destination: Group of Security Gateways; Services: Any; Drop

But when researching this topic, searching these forums, etc, I am seeing several different way that customers have set these rules up, in regards to what object they are using in the 'Destination' column.  Some different designs I've seen talked about:

- Reference the actual Cluster Object and/or Gateway Objects in the rule

- Creating Host Objects representing the IP Addresses of the Gateway Interfaces

- Using Dynamic Objects i.e. LocalGatewayExternal, LocalMachine, LocalMachine_All_Interfaces, etc.

In addition to that, in Gateways & Servers under Cluster Properties there is 'Platform Portal Accessibility' feature which can be toggled to 'Through all interfaces," "Through internal interfaces," or "According to the Firewall policy."

I know the answer is usually "it depends on what your intention is," but it's not exactly clear how these different options affect how matching works, i.e. does using the Cluster Object match on any IP Address of the cluster interfaces, or does it only match on the management address?  Are the Dynamic objects like LocalGatewayExternal better?  Stealth rule applies only if you have "According to the Firewall Policy" toggled for Platform Portal?

I am just wondering, if you are ATAM and setting up a brand new gateway for a brand new customer, policy being built totally from scratch, how are you building the Stealth Rules?  is the best practice differ between R81.10/20, R82, etc.  Thanks for any discussions you can bring!

[AkosBakos]

Hi @Cypress 

What was the sk what you read?

Here are two:

https://support.checkpoint.com/results/sk/sk106597

https://support.checkpoint.com/results/sk/sk102812

• 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.

Akos

[the_rock]

Both great references @AkosBakos 

[PhoneBoy]

One thing to be careful of regarding the use of Dynamic Objects (eg LocalMachine) is they require an explicit “Install-On” field (ie cannot be Any).
It’s not something I see for a stealth rule, usually.

The stealth rule is also complicated by how the Implied Rules work, particularly for http/https to the gateway itself.
This will likely help that: https://support.checkpoint.com/results/sk/sk180808

[AkosBakos]

@PhoneBoy this kind of  Dynamic Objects (eg LocalMachine) not related to only SMB appliances?

[PhoneBoy]

dynamic_objects -l from expert on my locally managed SMB appliance includes LocalGateway plus several others.
I've also used them in centrally managed policies previously.
There is just no mechanism in local management to create/refer to these objects beyond the objects that already exist (e.g. "This Gateway").

[the_rock]

I would say this is PERFECT  explanation...courtesy of AI copilot 🙂

Andy

**********************************

This is Check Point AI Assistant.

Configuring a stealth rule is a best practice to prevent direct access to the Security Gateway. Here are the steps to configure a stealth rule in Check Point:

Steps to Configure a Stealth Rule

1. Open SmartConsole:

   • Launch the SmartConsole application and log in with your administrator credentials.

2. Navigate to the Security Policies:

   • Go to the "Security Policies" tab.

3. Create a New Rule:

   • Click on the "+" button to add a new rule at the top of the rule base.

4. Define the Rule Properties:

   • Name: Give the rule a meaningful name, such as "Stealth Rule".
   • Source: Set the source to "Any" or specify the networks that should be restricted.
   • Destination: Set the destination to the group of Security Gateways.
   • Services & Applications: Set this to "Any".
   • Action: Set the action to "Drop".
   • Track: Set the tracking option to "Alert" to receive notifications when this rule is matched.

5. Position the Rule:

   • Ensure that the stealth rule is placed at the top of the rule base, just below any necessary administrative access rules.

6. Install the Policy:

   • After configuring the rule, click on "Install Policy" to apply the changes to the Security Gateways.

Example of a Stealth Rule Configuration

No	Name	Source	Destination	Services & Applications	Action	Track	Install On
1	Stealth Rule	Any	Group of Gateways	Any	Drop	Alert	Policy Targets

Best Practices

• Admin Access Rule: Ensure you have an admin access rule above the stealth rule to allow administrators to connect to the Security Gateways.
• Cleanup Rule: Place a cleanup rule at the bottom of the rule base to drop all traffic that is not explicitly allowed by earlier rules.

By following these steps, you can effectively configure a stealth rule to enhance the security of your Check Point environment.

Learn more:

1. R81 Quantum Security Management Administration Guide - Creating-a-Basic-Access-Control-Policy
2. R80.40 Security Management Administration Guide - Creating-a-Basic-Access-Control-Policy
3. R82 Security Management Administration Guide - Best-Practices-for-Access-Control-Rules
4. R80.40 Security Management Administration Guide - Best-Practices-for-Access-Control-Rules

[Timothy_Hall]

To further expand upon what "Admin Access" rules need to be placed in front of the Stealth Rule, there are generally 4 categories of these rules:

1) General Admin Access - SSH, HTTPS, 4434 access to Gaia OS from a trusted IP/network

2) Ping/traceroute - Do you want the gateway to respond to ping requests to its own interfaces and also show up in traceroute?  Generally if the request is coming from the inside or DMZ I'd say allow this.  Coming from the Internet or other untrusted networks? Nope.

3) NMS SNMP - If you have some kind of network monitoring system doing SNMP GETs to the firewall for pulling statistics, you'll need a rule allowing this.  Netflow statistics are connections initiated by the gateway to the collector, so no need for explicit rules allowing Netflow usually.

4) DHCP - If the firewall's Gaia OS is acting as a DHCP Server (not likely) or performing DHCP Relay/Helper (more likely), the DHCP broadcasts will need to be allowed.

There are a few other random corner cases involving legacy identity/authentication features and such, but these 4 categories should about cover it.