Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Danny
Champion Champion
Champion

Verify if a firewall stealth rule exists

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?

0 Kudos
11 Replies
the_rock
Legend
Legend

Maybe this?

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

0 Kudos
Bob_Zimmerman
Authority
Authority

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
Legend
Legend

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

Andy

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
the_rock
Legend
Legend

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

Andy

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
the_rock
Legend
Legend

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

Andy

0 Kudos
Danny
Champion Champion
Champion

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

0 Kudos
Henrik_Noerr1
Advisor

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
Legend
Legend

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

0 Kudos
the_rock
Legend
Legend

@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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events