Verify if a firewall stealth rule exists

[Danny]

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?

[the_rock]

Maybe this?

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

[Bob_Zimmerman]

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:

1. 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.
2. 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.

[the_rock]

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

Andy

[Bob_Zimmerman]

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.

[the_rock]

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

Andy

[Bob_Zimmerman]

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.

[the_rock]

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

Andy

[Danny]

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

[Henrik_Noerr1]

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 

[the_rock]

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]#

[the_rock]

@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