How to audit a Cisco router configuration: a step-by-step checklist

Auditing a Cisco router doesn't start with a scanner. It starts with one text file — the running configuration — and a clear list of what to look for. Here is the checklist we use, in the order that finds the most serious problems first.

Step 0: get the right file

Everything below works from the device's configuration, so start by exporting it. On the router run show running-config (or show running-config all if you also want default values) and save the output to a text file. Grab show version too — the software version decides which known vulnerabilities (CVEs) apply.

Work from a copy. Never paste a live config with real passwords into an online tool; secrets like enable secret hashes and SNMP communities are in that file.

Step 1: management access — who can log in, and how

This is where most real compromises begin, so check it first.

• No Telnet. Every line vty block should say transport input ssh. transport input telnet or transport input all sends credentials in clear text.
• SSH version 2 only. Look for ip ssh version 2. Version 1 has known weaknesses.
• Restrict where logins come from. VTY lines should have an access-class that only allows the management network.
• Idle timeout. exec-timeout on VTY and console/AUX lines — 10 minutes or less is typical.
• No web management in clear text. no ip http server; if the web UI is needed at all, use ip http secure-server with an access list.

Step 2: authentication and passwords

• enable secret, never enable password. The old enable password is stored reversibly. Prefer a strong hash (algorithm-type scrypt on current IOS).
• Central AAA. aaa new-model with TACACS+ or RADIUS for login and exec authorization, so every admin has their own account and actions are traceable.
• Local fallback account with a hashed secret, for when the AAA server is unreachable.
• service password-encryption — worth enabling, but know that it only hides type 7 passwords from shoulder-surfing; type 7 is trivially reversible.
• Login brute-force protection. login block-for slows down password guessing.

Step 3: SNMP

• No public or private community strings — ever.
• Any remaining community must have an access list limiting which hosts can use it.
• Prefer SNMPv3 with authentication and privacy, and remove v1/v2c once v3 works.
• Read-write (RW) communities are rarely needed; each one is a remote configuration change waiting to happen.

Step 4: logging and time

• Remote syslog with logging host. A local buffer alone is lost on reboot and easy to overwrite.
• Timestamps with service timestamps log datetime msec so events can be correlated.
• Authenticated NTP. Correct time matters for logs and certificates; ntp authenticate with a trusted key stops time spoofing.

Step 5: services nobody remembers enabling

Older defaults and copied configs leave features on that no one uses: CDP on internet-facing interfaces, IP source routing, directed broadcast, the small TCP/UDP servers, BOOTP, and Smart Install (vstack), which has a long history of abuse. Turn off anything without a clear purpose.

Step 6: match the version against known vulnerabilities

Take the version from show version and check Cisco's security advisories and the NVD for CVEs affecting it — especially anything on CISA's Known Exploited Vulnerabilities list. A perfectly hardened config on a version with an actively exploited flaw is still exposed.

Step 7: map findings to the standard you report against

Most audits have to answer to something: CIS Benchmarks, DISA STIG, NIST 800-53, ISO 27001 or PCI-DSS. Record which control each finding breaks, the exact line as evidence, and the change that fixes it. That turns a list of problems into a report someone can act on.