topic Re: Verify if a firewall stealth rule exists in API / CLI Discussion

Verify if a firewall stealth rule exists

Danny — Sun, 24 Aug 2025 19:06:12 GMT

I'm working on a firewall audit script and I'm looking for a way to verify if a firewall stealth rule (Src: Any, Dst: Firewall Gateway, Service: Any, Action: Drop or Reject) exists.

The check should work on:

on SmartCenter Servers via mgmt_cli on all configured security policies
on Firewall Gateways via grep $FWDIR/state/local/FW1 as db_tool isn't supported anymore

Any ideas?

Re: Verify if a firewall stealth rule exists

the_rock — Sun, 24 Aug 2025 20:49:43 GMT

Maybe this?

clish -c "show access-rulebase name <policy-package> details-level full" | grep <gateway_name>

Re: Verify if a firewall stealth rule exists

Bob_Zimmerman — Sun, 24 Aug 2025 21:11:04 GMT

This gets complicated if you potentially have multiple access layers in a policy package. I guess you could check each access layer one by one to see if at least one has such a rule.

It would likely be in the first 500, so you can probably get away with only fetching the one page.

It also gets complicated if you use a different form of stealth rule: an inner layer. Say the outer layer has "Any source to firewall object, send to firewall management layer". As long as the firewall management layer ends in drop or reject, that functions as a stealth rule, though it doesn't obviously look like one at first glance. The advantage of this pattern is you can manage all administrative access to all of your firewalls in the firewall management layer, regardless of which policy package they run. Add a new SNMP client? You just need to stick it into a rule in one place.

I would probably do something like this:

Get a list of all domains. If this is a SmartCenter rather than an MDS (no domain), treat it like an MDS with only the one domain to scrub.
For each domain, get a list of all policy packages. For each policy package:
1. Record the policy package's installation targets.
2. For each access layer in the policy package, get a list of the first 500 rules (
  .rulebase[]|if has("rulebase") then .rulebase[] else . end| ... can help here).
  1. For each installation target, select all the rules with a source of "97aeb369-9aea-11d5-bd16-0090272ccb30" (UUID for Any), a destination of that target, and an action of "Drop", "Reject", or "Inner Layer".
  2. If the action is "Inner Layer", dump the access layer in the rule's "inline-layer" key and check to be sure either the last rule's action is Drop or Reject, or the layer's "implicit-cleanup-action" is "drop".
3. As long as at least one layer in the policy package has at least one matching rule for every installation target, you're good.

Re: Verify if a firewall stealth rule exists

Henrik_Noerr1 — Mon, 25 Aug 2025 07:13:21 GMT

Also, What I often see is we have a stealth rule in the top ten rules, but over time this rule gets pushed down due to inexperienced admins, rushed projects or just because, basically making the drop useless because the packet was accepted above.

Of course also be aware of implicit rules like remote vpn ports being opened by default on VPN gateways if not unselected.

Just something to keep in mind, when evaluating the value of the output of a simple grep.

/Henrik

Re: Verify if a firewall stealth rule exists

the_rock — Mon, 25 Aug 2025 12:41:05 GMT

Is there a way to say search for rule where fw is dst itself and action is drop?

Andy

Re: Verify if a firewall stealth rule exists

Bob_Zimmerman — Mon, 25 Aug 2025 14:20:32 GMT

Yes, but that doesn't tell you if the policy runs on the firewall in the destination of the rule. That's the difficult part.

Re: Verify if a firewall stealth rule exists

the_rock — Mon, 25 Aug 2025 14:31:41 GMT

Would you mind put the command? I would still like to test it in the lab.

Andy

Re: Verify if a firewall stealth rule exists

Bob_Zimmerman — Mon, 25 Aug 2025 14:50:53 GMT

I haven't written one. It would be a non-trivial amount of work, and isn't adjacent to anything I'm currently doing, so I can't really spend the time.

Re: Verify if a firewall stealth rule exists

the_rock — Mon, 25 Aug 2025 14:52:14 GMT

K, no worries, let me play around with it in the lab, see how far I get.

Andy

Re: Verify if a firewall stealth rule exists

the_rock — Mon, 25 Aug 2025 15:20:50 GMT

Not sure if this may suffice, but seems like a aomewhat okay option to me. I just tried it in the lab.

Andy

[Expert@CP-MANAGEMENT:0]# mgmt_cli show access-rulebase name "network" filter "stealth"
Username: admin
Password:
uid: "38271c2f-ab44-4e25-9aa4-e219cb6e12cf"
name: "network"
rulebase: []
total: 0

[Expert@CP-MANAGEMENT:0]#

Re: Verify if a firewall stealth rule exists

the_rock — Mon, 25 Aug 2025 15:41:19 GMT

@Danny

AFTER creating stealth rule. I just named it stealth rule.

Andy

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

[Expert@CP-MANAGEMENT:0]# mgmt_cli show access-rulebase name "network" filter "stealth"
Username: admin
Password:
uid: "38271c2f-ab44-4e25-9aa4-e219cb6e12cf"
name: "network"
rulebase:
- uid: "1061f0d8-516f-4af3-b388-74ba735f5e44"
name: "stealth rule"
type: "access-rule"
domain:
uid: "41e821a0-3720-11e3-aa6e-0800200c9fde"
name: "SMC User"
domain-type: "domain"
rule-number: 12
filter-match-details:
- column: "name"
track:
type: "598ead32-aa42-4615-90ed-f51a5928d41d"
per-session: false
per-connection: true
accounting: false
enable-firewall-session: false
alert: "none"
source:
- "97aeb369-9aea-11d5-bd16-0090272ccb30"
source-negate: false
destination:
- "1d825439-7eff-42ff-bee2-f091dad7aa83"
destination-negate: false
service:
- "97aeb369-9aea-11d5-bd16-0090272ccb30"
service-negate: false
service-resource: ""
vpn:
- "97aeb369-9aea-11d5-bd16-0090272ccb30"
action: "6c488338-8eec-4103-ad21-cd461ac2c473"
action-settings: {}
content:
- "97aeb369-9aea-11d5-bd16-0090272ccb30"
content-negate: false
content-direction: "any"
time:
- "97aeb369-9aea-11d5-bd16-0090272ccb30"
custom-fields:
field-1: ""
field-2: ""
field-3: ""
meta-info:
lock: "unlocked"
validation-state: "ok"
last-modify-time:
posix: 1756135560299
iso-8601: "2025-08-25T11:26-0400"
last-modifier: "admin"
creation-time:
posix: 1756135534952
iso-8601: "2025-08-25T11:25-0400"
creator: "admin"
comments: ""
enabled: true
install-on:
- "6c488338-8eec-4103-ad21-cd461ac2c476"
available-actions:
edit: "true"
delete: "true"
clone: "not_supported"
tags: []
objects-dictionary:
- uid: "97aeb369-9aea-11d5-bd16-0090272ccb30"
name: "Any"
type: "CpmiAnyObject"
domain:
uid: "a0bbbc99-adef-4ef8-bb6d-defdefdefdef"
name: "Check Point Data"
domain-type: "data domain"
icon: "General/globalsAny"
color: "black"
- uid: "1d825439-7eff-42ff-bee2-f091dad7aa83"
name: "CP-FW-CLUSTER"
type: "simple-cluster"
domain:
uid: "41e821a0-3720-11e3-aa6e-0800200c9fde"
name: "SMC User"
domain-type: "domain"
icon: "NetworkObjects/cluster"
color: "sea green"
- uid: "6c488338-8eec-4103-ad21-cd461ac2c473"
name: "Drop"
type: "RulebaseAction"
domain:
uid: "a0bbbc99-adef-4ef8-bb6d-defdefdefdef"
name: "Check Point Data"
domain-type: "data domain"
icon: "Actions/actionsDrop"
color: "none"
- uid: "598ead32-aa42-4615-90ed-f51a5928d41d"
name: "Log"
type: "Track"
domain:
uid: "a0bbbc99-adef-4ef8-bb6d-defdefdefdef"
name: "Check Point Data"
domain-type: "data domain"
icon: "Track/tracksLog"
color: "none"
- uid: "6c488338-8eec-4103-ad21-cd461ac2c476"
name: "Policy Targets"
type: "Global"
domain:
uid: "a0bbbc99-adef-4ef8-bb6d-defdefdefdef"
name: "Check Point Data"
domain-type: "data domain"
icon: "General/globalsAny"
color: "none"
from: 1
to: 1
total: 1

Re: Verify if a firewall stealth rule exists

Danny — Mon, 01 Sep 2025 08:51:53 GMT

@Bob_Zimmerman : That's my current code to quickly identify all types of stealth rules on a security management:

psql_client cpm postgres -c " SELECT COUNT(*) FROM accessctrlrule_data WHERE deleted = false AND srcs LIKE '%97aeb369-9aea-11d5-bd16-0090272ccb30%' AND dsts NOT LIKE '%97aeb369-9aea-11d5-bd16-0090272ccb30%' AND svcs LIKE '%97aeb369-9aea-11d5-bd16-0090272ccb30%' AND src_negated = false AND dst_negated = false AND svc_negated = false AND ruleactionsetting_action IN (SELECT objid FROM rulebaseaction_data WHERE name IN ('Drop','Reject') AND deleted = false); "

I'm currently trying (i.e. struggling) to verify whether the destinations (dsts) defined in the identified rules match the installation target of the security policy they belong to. This would finally let me drill down to firewall stealth rules only.