Check Point Firewall Configuration Audit

Audit your Check Point config
in 60 seconds.

Upload your Check Point export — mgmt_cli JSON from R80+ or `show configuration` from Gaia clish. Get a posture score, prioritized risks, Threat Prevention coverage analysis, Stealth Rule review, and ready-to-paste fixes — without installing an agent or handing over SMS API credentials.

Start Free ScanSee Demo

No agent, no SMS API key, no SmartConsole automation. R80+ JSON and Gaia clish both handled. Raw export parsed in memory and discarded.

⚡

Two formats, one minute

mgmt_cli JSON or Gaia clish `show configuration` — both parsed by the same scanner. Centrally-managed and standalone gateways both work. Full posture report in under 60 seconds.

🎯

Threat Prevention coverage, scored

The engine inventories which gateways actually have IPS, Anti-Bot, Anti-Virus, URL Filtering, App Control, and Threat Emulation assigned — not just licensed. The classic Check Point gap: blades licensed, profiles defined, never bound to the gateway that needs them.

🛡

Security Advisory CVEs tied to your version

Gateway and management firmware are matched against Check Point Security Advisories, CISA KEV, and NVD. CVEs are only surfaced if the affected feature (Mobile Access, SSL Inspection, IPSec, Quantum SD-WAN) is actually enabled.

What CRWLR finds in a Check Point config

✓Access Policy rules with any source, any destination, any service — including rules that survived multiple admins and a policy-merge or two
✓Stealth Rule missing or positioned below an Any-Accept — gateway management is reachable from anywhere it shouldn't be
✓Cleanup Rule with Track set to None — every denied attempt is invisible to audit, IR, and compliance
✓Threat Prevention blades licensed but the profile is unassigned to one or more gateways (the spend-without-protection failure mode)
✓Inline Layer sprawl — sub-rules that override parent intent, default-actions that undermine the parent rule, layers with the same rule duplicated across siblings
✓SSL Inspection coverage — outbound HTTPS not categorized, exclusion lists swallowing risk classes, certificate-pinning bypass rules that became permanent
✓Identity Awareness gaps — rules that should be user/group-based still keyed on IP, AD groups defined but not used in policy
✓Mobile Access and Remote Access VPN — single-factor authentication, weak IKEv1/IKEv2 crypto, expired Mobile Access certificates, portal accessible from any source
✓NAT layer hygiene — hide-NAT overlaps, manual NAT rules that bypass the policy, static NAT exposing risky services (RDP, SMB, Telnet) without compensating controls
✓Gaia OS hardening — admin sources unrestricted, SSH/HTTPS exposed on data interfaces, weak password policy, NTP unset or pointing at a public pool, logging not forwarded
✓Firmware CVE exposure — gateway and SMS versions cross-referenced with Check Point Security Advisories; safe upgrade JHF / take recommended deterministically from vendor data, not guessed
✓Multi-hop attack paths — compound risk chains across Access Control + NAT + Threat Prevention layers with pivot awareness and service scoring
Sample finding— what you get per issue
HIGH

Threat Prevention profile defined but not assigned to gateway gw-edge-01

Threat Prevention profile Strict exists with IPS, Anti-Bot, Anti-Virus, and Threat Emulation enabled — but no Threat Prevention rule has gw-edge-01 in the install-on list. The blades are licensed and configured; no traffic on that gateway is actually being inspected.

# From the SMS, via mgmt_cli:
mgmt_cli add threat-rule \
  layer "Standard Threat Prevention" \
  name "Inspect edge traffic" \
  source.1 Any \
  destination.1 Any \
  protected-scope.1 Any \
  service.1 Any \
  install-on.1 gw-edge-01 \
  action Strict \
  track Log \
  -u admin -p <password>

mgmt_cli publish -u admin -p <password>

# Then push policy:
mgmt_cli install-policy \
  policy-package "Standard" \
  access true \
  threat-prevention true \
  targets.1 gw-edge-01 \
  -u admin -p <password>

Every finding ships with the exact mgmt_cli block above (or SmartConsole navigation path when CLI is awkward), the rule or object that triggered it, the Security Advisory reference, and a plain-English explanation of why it matters and what changes after you publish + install.

Frequently asked

Which Check Point platforms and versions are supported?

Any Check Point gateway managed by an R80+ Security Management Server — R80, R80.10, R80.20, R80.30, R80.40, R81, R81.10, R81.20, R82. Both Quantum appliances (3000/6000/7000/16000/26000 series) and CloudGuard virtual gateways are handled. Gateway-only audits via Gaia clish output also work for shops that do not centrally manage via mgmt_cli.

How do I export my Check Point configuration?

Two paths. Centralized (preferred): from the SMS run `mgmt_cli show package name "<your-policy>" --format json -u admin -p <pass> > export.json` then upload export.json. Standalone or gateway-only: from the Gaia clish shell run `show configuration` and save the output to a text file. Both formats are handled by the same scanner.

What does CRWLR actually check in a Check Point config?

140 checks spanning Access Policy hygiene, Inline Layer sprawl, Threat Prevention assignment (IPS / Anti-Virus / Anti-Bot / URL Filtering / Application Control / Threat Emulation), Stealth Rule presence and position, Cleanup Rule logging, SSL Inspection coverage, Identity Awareness usage, Mobile Access / Remote Access VPN crypto and authentication, NAT hygiene, Gaia OS hardening, and Check Point firmware CVE exposure. Full list at /security.

Is my Check Point configuration stored anywhere?

No. The export is parsed in memory and discarded at the end of the scan. Only the normalized findings, scores, and per-rule analysis are persisted to your tenant. mgmt_cli JSON exports can include object metadata that hints at internal addressing — the parser drops fields that are not needed for analysis before any normalized data is written.

Does CRWLR check Check Point firmware CVEs?

Yes. Gateway and management firmware versions are matched against CISA KEV, NVD, and the Check Point Security Advisories feed, deduplicated across sources. CVEs are filtered to only those that affect features actually enabled — a Mobile Access Portal vulnerability is only flagged if Mobile Access is configured, an SSL Inspection vulnerability only if SSL Inspection is on.

Does CRWLR understand Inline Layers and Threat Prevention layers separately?

Yes. Check Point policies are not flat — Access Control rules, NAT rules, Threat Prevention rules, and per-rule Inline Layers each get their own analysis pass. The scoring engine knows that a clean Access Control layer means nothing if the Threat Prevention layer is not assigned to a gateway, and that an inline layer with a permissive default-action undermines the parent rule.

Can I use this across dozens of Check Point gateways for MSP work?

Yes. CRWLR supports bulk import (drop a ZIP of mgmt_cli JSON exports or Gaia clish dumps), scheduled re-scans, per-gateway finding acknowledgements, and a fleet dashboard that rolls firmware risk, configuration risk, and external exposure into one composite score across your whole estate.

Do I get CLI fixes or SmartConsole guidance?

Both, depending on the finding. Where mgmt_cli can apply the change non-interactively, you get the exact `mgmt_cli set …` command. Where the change is more naturally made in SmartConsole (e.g. inline-layer restructuring), you get the SmartConsole navigation path. Paste-ready either way.

Upload your Check Point export. See the gaps in 60 seconds.

No credit card. No agent to install. The raw export never touches our storage.

Start Free Scan →
HomeFortiGate auditPalo Alto auditSophos auditCisco ASA auditCheck coverageHow we handle your datavs. SkyboxBlog
Check Point Firewall Configuration Audit — 60 Seconds | CRWLR