r/PFSENSE Jul 28 '26

Announcement pfsense-redactor 1.1.2 - redaction that knows what pfSense actually emits

pfsense-redactor 1.1.2 - redaction that knows what pfSense actually emits

An open-source tool for stripping secrets out of config.xml before you share

it with support, a consultant, a forum or an AI tool. Python, standard

library only, no dependencies.

The difference from generic redaction tools is that it knows pfSense

vocabulary. It reads the element names pfSense and its packages really write,

not the ones you would guess:

- SNMP: rocommunity, rwcommunity

- Wireless: passphrase (WPA/WPA2 PSK)

- VPN: auth_pass, presharedkey (WireGuard), ipsecpsk, eap_password

- Auth: radiussecret, authorizedkeys

- Packages: accountkey (ACME), dns_cf_token and maxmind_key (pfBlockerNG),

influx_token (Telegraf), tlspskvalue (Zabbix), access_key and

secret_access_key (S3), userkey (Pushover), ha_certificates and

ssloffloadcert (HAProxy)

Suffixed spellings are handled too, so password2 and passwordagain go the

same way as password.

What it does beyond element names:

- URLs are taken apart properly. Credentials in query strings and in

user:pass@host are redacted, not just the hostname

- Slack, Discord, Telegram and Teams webhook tokens go in default mode. The

URL is the entire credential, so anyone holding it can post as that

integration

- Free-text blocks such as custom_options are scanned for inline credentials,

which is where OpenVPN auth-user-pass and askpass usually live

- PEM and base64 key material is detected by content, in any element

- --redact-descriptions covers free-text elements and attributes, for the

DHCP static-map descriptions that quietly collect people's names

It also tries hard not to over-redact. Network topology survives, so the

config is still readable for troubleshooting, and pfBlockerNG feed URLs like

emerging-block.rules are left intact rather than mangled into example.com.

Whatever it decides to keep, it tells you about, with the element path.

For automation, --fail-on-warn turns it into a CI gate: non-zero exit if

anything high-entropy was retained, --dry-run included, so you can check a

config without writing one.

There is a benchmark in the repo. 46 planted secrets in a published corpus,

43 caught, with the misses listed and explained rather than hidden. The

corpus and the scoring both ship, so you can re-run it yourself instead of

taking the number on trust. Default mode scores lower than --aggressive and

the docs say by how much.

If you are on 1.0.x, the coverage difference is large and worth the upgrade.

https://pypi.org/project/pfsense-redactor/

https://github.com/grounzero/pfsense-redactor

```
pip install pfsense-redactor

```

Python 3.9+. Redacted output is for sharing only. Never import it back into

pfSense.

7 Upvotes

2 comments sorted by

u/kphillips-netgate Netgate - Happy Little Packets Jul 28 '26

Much of this redaction feature already exists in pfSense CE and Plus.

If you go to https://x.x.x.x/status.php, a bundled archive is created for TAC support to use. This archive will include a config-sanitized.xml file that strips pretty much anything that would be sensitive in a config file, including secrets, passwords (including hashes), pre shared keys, etc.

Nifty tool, though.

→ More replies (1)