Config Compliance Checker

Someone hands you a hardening standard and forty switch configs. Paste one in, choose a rule pack, and the checker scores it out of 100, groups what failed by severity, quotes the offending line with its line number, explains in plain English why the rule exists, and gives you the configuration commands that fix it. Six packs ship with the tool — security hardening, logging and NTP, AAA, SNMP, the management plane, and banners — and you can write your own as JSON.

What it does

• Six built-in rule packs covering 91 checks
• Severity-weighted score from 0 to 100, with the weights shown
• Required lines, forbidden lines, and required config sections
• Exact-match or regular-expression rules
• Every finding carries the line number, the reason, and the fix
• Custom rule packs as JSON: import, edit, export
• Pro: up to 50 configs per run, fleet table, CSV and XLSX export, saved packs

The rule packs that ship with it

• Security hardening — enable secret over enable password, service password-encryption, the legacy services (source routing, PAD, BOOTP, finger, service config), login throttling and logging, console timeout, and SSH-only vty stanzas.
• Logging and NTP — syslog collector, trap and buffer levels, a pinned source interface, configuration change archiving, and an authenticated time source.
• AAA and access control — aaa new-model, authentication, authorization and accounting method lists against a server group with local fallback, a break-glass local account, and the TACACS+ server and group blocks.
• SNMP — no default or read-write communities, no v1 or v2c trap destinations, SNMPv3 with SHA authentication and AES privacy, a restricted MIB view.
• Management plane — SSH version 2 and its timeouts, a management ACL bound to every vty stanza, session timeouts, and no cleartext management listener.
• Banners and legal notice — the MOTD, login and EXEC banners, the wording an unauthorised-access case needs, and what a pre-auth banner must not disclose.

How the score is worked out

Findings are weighted by severity: CRITICAL 10, HIGH 6, MEDIUM 3, LOW 1, INFO 0. The score is 100 multiplied by the weight of the rules that passed, divided by the weight of every rule that applied, rounded to one decimal. INFO rules are reported but never move the score. A rule that does not apply to the device — a rule about the AUX port on a platform with no AUX port — is left out of both sides of the fraction rather than counted as a failure.

Writing your own rule pack

A rule pack is one JSON object with an id, a name and a list of rules. A rule is required (a line that must be present), forbidden (a line that must be absent), or section (a parent line whose indented block must contain every listed child). Each rule matches exactly or by regular expression and carries a severity, a plain-English reason, and the config lines that fix it. Export a built-in pack, edit it, and paste it back. Pro accounts can save packs to the account with a lifetime of 30, 90 or 365 days.

Nothing you paste is stored. The configuration is read into memory, scored, and dropped with the response. It is never written to a database and never logged. A pasted configuration never leaves memory; an uploaded file over about a megabyte is spooled by the web server into an unnamed temporary file that is deleted when the request ends, which is the framework's own upload handling and not something this tool keeps. Either way nothing is retained after the response. This tool does not connect to a device, does not ask for a credential, and does not proxy a session: it reads text you give it. The one thing that can be stored is a Pro account's custom rule pack — rules only, never a configuration — saved as an explicit action, with a lifetime you pick and a delete control on every pack. Rule packs are free text in their notes fields, so do not paste a configuration into one.