Strip the secrets before you upload
Your config backup contains admin passwords, VPN pre-shared keys, and private keys. Our parser never reads them — but you shouldn't have to take our word for it. Run this sanitizer locally and nothing sensitive ever leaves your machine.
Prefer zero effort? It's built into the upload box.
Every CRWLR upload form sanitizes FortiGate configs in your browser, before the upload (on by default — you'll see exactly how many secret values were redacted). Same engine-parity guarantee. The downloads below are for running and verifying it yourself, offline, or in automation.
Downloads
FortiGate sanitizer
v1.0 · 12 KBStrips every secret from a FortiOS .conf backup (tested on 7.2/7.4/7.6 exports). Engine-aware: audit results on the sanitized file are identical to the original — pinned by our regression suite on real-world configs. Refuses to run on non-FortiGate input.
Palo Alto sanitizer
15 KBStrips secrets from a PAN-OS XML config and additionally anonymizes IPs, hostnames, and serials (full topology rewrite). Writes a local mapping file so you can reverse the placeholders.
Upload script (bash)
4 KBSanitize-then-upload in one cron-able command. Uses a revocable CRWLR API key from an environment variable, polls until your posture score is ready.
Upload script (PowerShell)
4 KBSame flow for Windows Task Scheduler. Works on stock Windows PowerShell 5.1+ (uses the curl.exe that ships with Windows 10+).
Single files, zero dependencies, MIT-licensed. No npm install, no network access — open them in any editor and read every line before you run them.
Supported vendors & firmware
| Vendor | Input format | Firmware coverage | Status |
|---|---|---|---|
| FortiGate | FortiOS backup (.conf) | Tested on real FortiOS 7.2 / 7.4 / 7.6 exports; format stable since 6.x | Available |
| Palo Alto | PAN-OS running-config XML | Tag-level redaction — works across PAN-OS versions | Available |
| Sophos XG/XGS | Entities.xml / pgdump backup | — | In progress |
| Check Point | R80+ JSON / Gaia clish | — | In progress |
| Cisco ASA | show running-config | — | In progress |
No sanitizer for your vendor yet? You're still covered: our parser never extracts secrets from any format — its data types have no fields for them. See exactly what we read and skip →
Why one script per vendor instead of one tool for everything?
Auditability. A ~250-line single-purpose file is something you can actually read, line by line, before pointing it at your firewall config. A multi-vendor bundle would triple the size and the review burden. Each script also refuses to run on a config it doesn't recognize and tells you which script to use instead — you can't accidentally half-sanitize the wrong format.
How to run it
# 1. Sanitize locally (needs only Node.js)
node sanitize-fortigate-config.js fw-backup.conf
# 2. Verify — every secret now reads REDACTED. The script
# prints a summary and flags anything left for your review.
# See the exact changes yourself:
diff fw-backup.conf fw-backup.sanitized.conf
# (on Windows: fc fw-backup.conf fw-backup.sanitized.conf)
# 3. Upload the .sanitized.conf file — that's it.
What it removes
- ✕Every
ENC-encrypted secret blob — admin passwords, VPN pre-shared keys, RADIUS/LDAP secrets, HA keys - ✕Cleartext passwords, passphrases, and keys (older exports and lab configs)
- ✕PEM bodies — private keys, certificates, CSRs
- ✕Custom SNMP community strings (renamed to neutral placeholders)
What it preserves
- ✓All policies, interfaces, zones, addresses, services, NAT
- ✓VPN phase 1/2 crypto parameters — the audit needs these, the secrets it doesn't
- ✓Firmware version and model (CVE matching), hostname and serial (re-scan matching)
- ✓Secret presence — lines are replaced, never deleted, so checks like "BGP neighbor has no password" still work
Audit results stay identical
The FortiGate sanitizer is engine-aware: it knows exactly which fields our analysis reads and never touches them. We pin this with a regression suite — on every real config in our test corpus, the findings before and after sanitization are identical, down to the severity. The one deliberate exception: well-known default SNMP communities (public, private) are kept verbatim, because flagging them is the point of the audit.
What it protects against — and what it doesn't
A security tool that overclaims is worse than none. Here is the honest scope:
It protects against
- ✓Accidental credential disclosure when a config is shared — with us, vendor support, a consultant, or a teammate
- ✓Credential harvesting if the sanitized copy ever leaks — there are no passwords, keys, or PSKs left in it to harvest
- ✓Wrong-file mistakes — it refuses other vendors' formats outright instead of half-sanitizing them
It does not
- ✕Make the file safe to publish. Network structure stays by design — policy logic, addressing, hostnames, firmware version — because the audit needs it. A sanitized config still shows how your network is built. Keep treating it as confidential.
- ✕Guarantee 100% removal. It is careful pattern matching, not magic — a vendor can add a new secret field tomorrow, or an exotic setup can carry a secret somewhere we don't recognize. That is why the script prints a review list and why step 2 is "diff it and look."
- ✕Replace credential rotation. If a raw, un-sanitized config has already leaked somewhere, rotate the credentials in it — don't just sanitize the next export.
Think of it as one layer of two: you strip the credentials before the file leaves your machine; our architecture never stores the raw file and never parses secrets on our side. The scripts are MIT-licensed and provided as-is, without warranty; use is subject to our Terms of Service.
Automate recurring scans
Already exporting nightly FortiGate backups — to a file share, GitHub, or via Ansible? The upload scripts above chain straight onto that: sanitize locally, push to the CRWLR API with a revocable write-scoped API key, and your fleet re-scores itself on schedule. Create a key under Account → API keys after you sign up.
- ✓API key shown once, stored only as a hash, revocable any time
- ✓Config parsed in memory, never stored — see the full data-handling policy
- ✓Cron / Task Scheduler examples included in the script headers
Frequently asked questions
Will sanitizing my firewall config change the audit results?
No. The FortiGate sanitizer replaces secret values without deleting lines, so every structural detail the analysis engine reads is untouched. We pin this with a regression suite: on every real config in our test corpus, the findings before and after sanitization are identical, down to the severity.
What does the sanitizer remove from my config?
All FortiOS ENC-encrypted secret blobs (admin passwords, VPN pre-shared keys, RADIUS/LDAP secrets), cleartext passwords and keys, PEM private-key and certificate bodies, and non-default SNMP community strings. Replaced values read REDACTED so you can verify the output in any text editor.
Which vendors and firmware versions are supported?
FortiGate today: FortiOS backup files, regression-tested against real 7.2, 7.4, and 7.6 exports — the text format has been stable since FortiOS 6.x, so older backups work too. Palo Alto today: PAN-OS running-config XML, where tag-level redaction works across PAN-OS versions. Sophos, Check Point, and Cisco ASA sanitizers are in progress. Even without a sanitizer, our parser never extracts secrets from any format.
What happens if I run it on the wrong vendor's config?
It refuses and tells you which script to use. Each sanitizer checks that the input actually looks like its vendor’s format before touching anything — a FortiGate script fed a PAN-OS XML exits with an error and writes nothing, so you can never accidentally upload a half-sanitized file.
How can I verify what was actually changed?
Diff the two files: "diff fw-backup.conf fw-backup.sanitized.conf" on Linux/macOS or "fc" on Windows. Every replaced value reads REDACTED, the script prints a count of each category it replaced, and it flags any suspicious-looking lines it deliberately left for your review.
Does sanitizing make my config safe to share publicly?
No — and we want to be straight about that. The sanitizer removes credentials, not structure. Policy logic, addressing, hostnames, and firmware version remain in the file because the audit needs them, and they still describe how your network is built. Sanitizing protects you from accidental credential exposure when sharing a config with a specific party; it does not turn the file into something you can post on a forum. Keep treating sanitized configs as confidential.
Why does it keep default SNMP communities like "public"?
Default community strings are well-known words, not secrets — and using one is a high-severity security finding. Redacting them would hide that finding from your audit. Custom community strings ARE secrets and get renamed to neutral placeholders.
Do I need to install anything to run it?
Just Node.js (any recent version). The sanitizer is a single file with zero dependencies — no npm install, no network access, works completely offline. You can read every line of it before running.
Sanitized and ready?
Upload the .sanitized.conf file and get your posture score in about a minute.
Run your first scan free2 free scans · no credit card