Router Audit Tool — Complete Guide to Cisco IOS & IOS-XE Security Hardening

The average enterprise router has 23 security misconfigurations. Most take less than five minutes to fix once you know they exist. The one that doesn’t get fixed is the one an attacker uses to pivot into your network, establish persistence, and spend 87 days — the median dwell time for router compromises — reading your traffic undetected.

A router security audit is the process of comparing a device’s running configuration against a known-good baseline of security controls — things like enforcing SSH-only access, disabling cleartext SNMP community strings, requiring authenticated NTP, and ensuring every routing protocol session has MD5 or SHA authentication. Done manually, it takes a checklist, 30 minutes per device, and a spreadsheet. Done with this tool, it takes five seconds and zero file uploads.

Paste your show running-config output into the tool below. The hierarchical block parser evaluates your configuration against 60 security controls drawn from the CIS Benchmark for Cisco IOS, DISA STIG for IOS XE, and the NSA Router Security Configuration Guide — entirely within your browser. Nothing is transmitted to any server.

The rest of this guide explains exactly what each check means — why it matters, what the real-world attack looks like, and the precise IOS commands that fix it. Whether you’re preparing for a CCNP Security exam, hardening a production edge router, or satisfying a PCI DSS audit, every section below is written to be immediately actionable.

Why This Matters — By The Numbers

What Is a Router Security Audit? History & Context

Definition and Purpose

A router audit checks a device’s running or startup configuration against a set of known security requirements. The output is a list of controls that pass, controls that fail, and the exact commands needed to remediate each failure. The goal is to close the gap between a factory-default Cisco router — which is configured for maximum compatibility, not maximum security — and a hardened device suitable for an enterprise perimeter or carrier edge.

Manual audits involve a network engineer reading a configuration printout and checking each line against a spreadsheet of requirements. This works, but it’s slow, error-prone, and impossible to scale across dozens or hundreds of devices. Automated router audit tools like this one parse the configuration programmatically, apply every check in under a second, and produce structured output that can be exported to CSV, Markdown, JSON, or PDF for compliance documentation.

Who needs a Cisco router security audit: network engineers before any device goes live in production, security teams conducting quarterly compliance reviews, MSPs managing client infrastructure, and penetration testers verifying whether a client’s perimeter devices are hardened before they start looking for deeper vulnerabilities.

The NSA Router Security Configuration Guide (RSCG)

The authoritative starting point for Cisco IOS security is the NSA’s Router Security Configuration Guide (RSCG), first published in 2001 at 248 pages. It covered four broad areas: disabling unnecessary services, controlling management access, filtering routing traffic, and implementing logging and monitoring. For 2001, it was comprehensive. Cisco configuration syntax has not changed dramatically at the command level, so the NSA RSCG remains largely valid.

What the RSCG cannot cover: SSH v2 cipher restriction (SSHv2 wasn’t widely deployed until IOS 12.1), SNMPv3 (still a draft standard in 2001), Type 8 and Type 9 password hashing (introduced in IOS 15.3 and 15.4 respectively), Control Plane Policing (introduced in IOS 12.3(4)T in 2003), or any IOS-XE-specific syntax. The RSCG is a foundation, not a complete modern standard.

CIS Benchmark for Cisco IOS

The Center for Internet Security publishes regularly updated benchmarks for Cisco IOS and IOS-XE, available at cisecurity.org. The benchmarks are organized into two levels. Level 1 consists of foundational controls that are safe to apply on any production router without operational risk — things like disabling CDP globally, enabling AAA, requiring SSH v2, and removing default SNMP community strings. Level 1 has over 35 rules. Level 2 adds advanced controls that may have operational trade-offs, such as strict Control Plane Policing rate limits and RPKI for BGP route origin validation.

This router audit tool implements all CIS Level 1 controls plus a significant subset of Level 2, augmented with DISA STIG requirements and NSA RSCG recommendations that the CIS Benchmark does not duplicate.

Why Router Auditing Matters More Than Ever

Threat actors in 2023 and 2024 specifically targeted misconfigured network infrastructure. The Volt Typhoon APT group, attributed to Chinese state-sponsored actors, compromised Cisco routers at critical infrastructure organizations across the United States. Their method in most reported cases was not a software zero-day — it was exploiting weak or default credentials on unaudited management interfaces. The NSA and CISA issued a joint advisory in 2023 explicitly calling out router misconfigurations as the primary initial access vector.

The BGP hijacking incidents that have made headlines — Pakistan Telecom taking YouTube offline in 2008, Rostelecom redirecting Apple and Google traffic in 2022 — all exploited the absence of BGP authentication and route origin validation. These are configuration failures, not software vulnerabilities. They are detectable in 30 seconds by a router audit tool. They are fixable in under 10 minutes.

According to Mandiant’s M-Trends 2023 report, the median attacker dwell time across all breach types is 16 days. For infrastructure device compromises — routers, switches, VPN concentrators — the median dwell time is 87 days. Attackers stay undetected longer on network devices because most organizations lack logging and monitoring for configuration changes. The archive log config feature in IOS, which this tool checks for, produces a complete record of every configuration command entered with timestamp and username. Most routers don’t have it enabled.

The Original SANS RAT vs. Modern Requirements

What the 2002 SANS/CIS RAT Checked

The 2002 CIS Router Audit Tool — still ranking in the top results for “router audit tool” more than two decades after publication — checked 37 rules across six categories. For its time it was excellent work. Here is the full original rule set:

What Has Changed Since 2002

SSH v2 and cipher restriction: SSH version 1 support in IOS 12.1 was a security milestone in 2001, but SSHv1 has known protocol-level vulnerabilities including session injection attacks. The command ip ssh version 2 disables SSHv1 negotiation entirely. More critically, the 2002 RAT had no concept of cipher suite restriction — AES in CTR mode was not widely available in IOS hardware acceleration. Modern audits must restrict SSH to CTR-mode ciphers only, rejecting CBC-mode ciphers vulnerable to the BEAST attack.

SNMPv3 with encryption: The 2002 RAT’s only SNMP checks were “don’t use ‘public'” and “don’t use ‘private’.” SNMPv3, which provides both authentication (HMAC-SHA) and payload encryption (AES), was in draft status in 2002 but is now a 20-year-old standard. The correct modern check is: eliminate all SNMPv1 and v2c community strings entirely, and verify SNMPv3 is configured with priv mode (authentication and encryption).

AAA framework: The 2002 RAT did not check for AAA at all. The aaa new-model command and associated method lists for authentication, authorization, and accounting are now foundational requirements under PCI DSS 8.2, NIST SP 800-53 IA-2, and HIPAA §164.312(d). Without AAA, there is no per-user audit trail, no login lockout mechanism, and no centralized credential management.

Type 8 and Type 9 password hashing: The 2002 standard considered MD5 hashing (Type 5, enable secret) secure. In 2025, MD5-based password hashes are crackable by commodity GPU hardware running Hashcat in minutes on common passwords. Type 8 (SHA-256 with PBKDF2) and Type 9 (scrypt, memory-hard) are the current standards. The 2002 RAT cannot detect the difference.

Control Plane Policing: Not introduced until IOS 12.3(4)T in 2003, CoPP has no analog in the original RAT. It protects the router’s software-based control plane from being overwhelmed by crafted packets, which causes routing protocol session failures and network outages without any software vulnerability being exploited.

IOS Classic vs. IOS-XE: 20 Years of Security Architecture Changes

Classic IOS Architecture

Classic Cisco IOS, running on platforms like the ISR G1/G2, 7200, and 7600 series, is a monolithic operating system. All processes — routing, forwarding, management, crypto — run within a single shared memory space. The version numbering follows the 12.x train (e.g., 12.4(24)T, 12.2(33)SXI). Configuration is stored in NVRAM as startup-config and loaded into RAM as running-config. The security feature set is extensive but the platform architecture means that a crashing process can bring down the entire system.

From an auditing perspective, classic IOS uses numbered ACLs (1–99 for standard, 100–199 for extended), classic EIGRP autonomous-system syntax, crypto ca for PKI (later renamed crypto pki), and SNMP v1/v2c community-based access. The security configuration language is stable and well-documented.

IOS-XE Architecture

IOS-XE, running on the ASR 1000, ISR 4000, CSR 1000v, and Catalyst 9000 series, separates the IOS software layer from the underlying operating system. On ASR 1000 platforms, the underlying OS is QNX. On CSR 1000v and Catalyst 9000, it is Linux. This separation provides process isolation — a crashing IOS-XE process does not crash the entire platform. Version numbering follows the 16.x and 17.x trains (e.g., 16.12.8, 17.9.4a for the Catalyst 9000).

The configuration language is largely the same as classic IOS, which is why most configuration audit tools work across both platforms. However, IOS-XE introduces features with different or additional syntax: named EIGRP replaces classic EIGRP for most modern deployments, Zone-Based Firewall (ZBFW) uses a policy-map structure rather than classic ACL-based firewalling, and the platform resource commands exist only on IOS-XE for CPU and memory management.

Configuration Differences That Affect Auditing

A router audit tool that does not distinguish between IOS classic and IOS-XE syntax will produce false positives and false negatives. Key differences:

• PKI syntax: Classic IOS uses crypto ca identity; IOS-XE uses crypto pki trustpoint. Both may coexist in older migrated configs.
• Named EIGRP: Classic EIGRP uses router eigrp <asn> with per-interface commands. Named EIGRP (IOS-XE preferred) uses router eigrp <name> with an address-family block and af-interface sub-commands for authentication — a completely different syntax tree.
• HTTPS server: Classic IOS enables HTTPS with ip http secure-server. IOS-XE 17.x adds ip http secure-active-session-modules for module-level control.
• SSH algorithm restriction: The ip ssh server algorithm encryption and ip ssh server algorithm mac commands are available from IOS 15.2(2) onward and are present in all current IOS-XE releases.

This tool’s hierarchical block parser handles both syntaxes. Interface blocks, line blocks, router protocol blocks (including named EIGRP address-family sub-blocks), archive blocks, and control-plane blocks are all parsed in correct structural context — not via flat line-by-line regex matching that produces false results when the same command appears in different configuration contexts.

IOS-XE Version-Specific Security Defaults

IOS-XE 17.3 and later disable 3DES by default on new key generation, and many platforms no longer accept 3DES-CBC for SSH negotiation. This is progress, but it does not eliminate the need for explicit cipher restriction — a device upgraded to 17.3 from 16.x may retain legacy SSH configuration. The only reliable check is explicit algorithm configuration, which is what this tool verifies.

The no service pad command has been the default in IOS since 12.3, but it remains a best practice to configure it explicitly so the intention is visible in the configuration and audit trail. Likewise, no ip directed-broadcast has been default-off since IOS 12.0, but explicit configuration is required by the CIS Benchmark and DISA STIG.

Authentication & AAA — The Complete IOS Deep Dive

Why AAA Is the Foundation of Router Security

Without the AAA framework, Cisco IOS authentication is line-level. A line password on the VTY lines is a single shared credential — every administrator who SSH’s into the device uses the same password, there is no per-user logging, there is no lockout mechanism, and removing access requires changing the shared password and distributing the new one. In a real incident response scenario, line-level authentication makes it impossible to determine which of your ten network engineers made a specific configuration change at 2:47 AM.

AAA (Authentication, Authorization, Accounting) is the framework that changes this. Authentication answers “who are you?” — and supports TACACS+ or RADIUS server-based verification with a local fallback. Authorization answers “what are you allowed to do?” — controlling which users can enter privileged EXEC mode and which commands they can run. Accounting answers “what did you do?” — generating per-session and per-command records sent to the TACACS+ server with timestamp and username.

AAA is required by PCI DSS v4.0 Requirement 8.2 (unique IDs for all admin access), NIST SP 800-53 Rev 5 IA-2 (identification and authentication for privileged users), HIPAA §164.312(d) (person or entity authentication), and is the first check in the DISA STIG for Cisco IOS XE Router at category CAT I.

The aaa new-model Command

The aaa new-model command is the master switch for the entire AAA framework. Entering it immediately changes how all authentication works — line passwords are overridden, and any undefined method list falls back to local authentication. This is where administrators make a critical mistake: enabling aaa new-model without first creating a local fallback user.

The safe AAA enable sequence:

! Step 1: Create a local fallback user FIRST
username admin privilege 15 algorithm-type scrypt secret MyStrongPass123!

! Step 2: Enable the AAA framework
aaa new-model

! Step 3: Define authentication — TACACS+ first, local fallback
aaa authentication login default group tacacs+ local

! Step 4: Define authorization — who gets an EXEC shell
aaa authorization exec default group tacacs+ local if-authenticated

! Step 5: Define accounting — what they do
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

Method Lists: Authentication, Authorization, Accounting

The aaa authentication login default group tacacs+ local command creates a method list named “default” that tries TACACS+ first. If the TACACS+ server is unreachable (not if authentication fails — reachability is the trigger), IOS falls back to local authentication. This prevents lockout during a TACACS+ server outage while maintaining centralized authentication during normal operations.

aaa authorization exec default group tacacs+ local if-authenticated controls who gets an EXEC session. The if-authenticated keyword means that if TACACS+ is unreachable, any locally authenticated user gets an EXEC session. Without this, a TACACS+ outage could prevent authorized administrators from accessing devices during an incident.

aaa accounting commands 15 default start-stop group tacacs+ records every privilege-level-15 command to the TACACS+ server. This is the forensic backbone of your security operations: when investigating a configuration change, you retrieve the TACACS+ accounting records and see exactly which administrator ran which commands, at what time, from which source IP.

tacacs server TACACS-PRIMARY
 address ipv4 10.0.100.10
 key TacacsKey123!
 timeout 5

tacacs server TACACS-SECONDARY
 address ipv4 10.0.100.11
 key TacacsKey123!
 timeout 5

aaa group server tacacs+ TACACS-GROUP
 server name TACACS-PRIMARY
 server name TACACS-SECONDARY

Login Brute-Force Protection

The login block-for command is one of the most impactful single-line security improvements available in IOS and one of the most commonly absent. It implements an automatic lockout: if authentication fails more than a specified number of times within a defined window, the router blocks all login attempts for a defined period.

! Block all logins for 60s if 5 failures within 30s
login block-for 60 attempts 5 within 30

! During lockout period, allow only management IPs
login quiet-mode access-class MGMT-ONLY

! Log every third failure (reduce log noise)
login on-failure log every 3

! Log every success
login on-success log

When brute-force protection is active, IOS generates syslog messages that appear like this in your SIEM:

%SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: admin] [Source: 10.0.0.5] [localport: 22] at 14:22:11 UTC Mon Jun 02 2025
%SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: admin] [Source: 203.0.113.44] [localport: 22] at 14:22:09 UTC Mon Jun 02 2025
%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 25 secs, [user: admin] [Source: 203.0.113.44]

These messages, combined with AAA accounting records, give you complete visibility into authentication events across your router fleet. Without login block-for, a credential-stuffing attack against SSH can run at full network speed with no consequence.

IOS Privilege Levels

IOS supports 16 privilege levels, numbered 0 through 15. Most deployments only use level 1 (user EXEC, limited read-only commands) and level 15 (privileged EXEC, full access). The principle of least privilege suggests that not all network engineers need level 15. An NOC operator who needs to check interface status and routing tables does not need the ability to change BGP configurations or overwrite the startup config.

Custom privilege levels allow fine-grained control:

! Allow "show running-config" at privilege level 7
privilege exec level 7 show running-config

! Allow interface configuration at level 10
privilege configure level 10 interface

! Assign a user to a specific privilege level
username netops privilege 7 algorithm-type scrypt secret NOCpass!

! The TACACS+ server can also return the privilege level
! via the "priv-lvl" attribute in the authorization response

SSH v2 Hardening — Ciphers, MACs, Key Exchange

SSH Is a Protocol Family, Not a Specific Algorithm

Enabling SSH on a Cisco router does not mean your management access is secure. SSH is a protocol framework that negotiates algorithms at connection time — and the algorithms IOS accepts by default include several that have been deprecated, attacked, or broken. A router running SSH with weak defaults is better than Telnet, but it is not hardened.

Default IOS SSH accepts: 3DES-CBC (64-bit block cipher, Sweet32 attack), AES-128-CBC and AES-256-CBC (CBC mode, vulnerable to the BEAST attack in certain configurations), HMAC-MD5 and HMAC-SHA1 (both deprecated by NIST SP 800-131A Rev 2 effective January 2014), and potentially Diffie-Hellman group1 (768-bit, factored by the Logjam attack published at USENIX Security 2015).

Enforcing Strong Ciphers — CTR Mode Only

AES in CBC (Cipher Block Chaining) mode encrypts each block by XORing it with the previous ciphertext block before encrypting. This creates a dependency chain that, under the BEAST attack, allows an adversary who can manipulate plaintext to decrypt chosen blocks. AES in CTR (Counter) mode encrypts each block independently using a counter value — there is no dependency chain and BEAST does not apply.

ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr

! Verify with:
show ip ssh
! Output should show:
! Encryption Algorithms: aes128-ctr aes192-ctr aes256-ctr

Enforcing SHA-2 MAC Algorithms

Message Authentication Codes verify the integrity of each SSH packet. HMAC-MD5 is deprecated — while no practical key-recovery attack against HMAC-MD5 exists, its underlying hash function is broken and it no longer meets NIST requirements. HMAC-SHA1 provides a 80-bit security level against collision attacks, below the NIST SP 800-57 Part 1 minimum of 112 bits required through 2030. Only HMAC-SHA2-256 and HMAC-SHA2-512 meet current NIST standards.

ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512

Key Exchange and RSA Key Size

Diffie-Hellman group1 uses a 768-bit prime. The Logjam attack demonstrated that 768-bit discrete logarithm problems are solvable by a nation-state adversary in real time, and by academic researchers in about a week. Diffie-Hellman group14 uses a 2048-bit prime and is the minimum acceptable for key exchange through 2030 per NIST SP 800-57. For RSA host keys, the NSA’s CNSA (Commercial National Security Algorithm) Suite 2.0 requires 3072 bits minimum, with 4096 bits preferred.

! Minimum DH group size for SSH
ip ssh server algorithm kex diffie-hellman-group14-sha1
ip ssh dh-min-size 2048

! Generate a 4096-bit RSA key pair
crypto key zeroize rsa
crypto key generate rsa modulus 4096

! Set session limits
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3

Password Hashing Types 0, 5, 7, 8, and 9 — Explained

Cisco IOS stores passwords using a type prefix in the configuration. That single digit before the hash string tells you everything about whether the credential is recoverable. Misconfiguring this — or failing to audit it — means an attacker who obtains a config backup has cleartext or near-cleartext credentials.

Detecting Each Type in a Running Config

The type number appears literally in the configuration:

! Type 0 — plaintext (never acceptable)
enable password cisco

! Type 5 — MD5, crackable in minutes on GPU
enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0

! Type 7 — XOR cipher, instantly reversible
username admin password 7 0822455D0A16544541B

! Type 8 — SHA-256 + PBKDF2 (acceptable)
enable secret 8 $8$dsYGNam3K1SIJO$7nI/NbmKbBBQV0fGRgS...

! Type 9 — scrypt (preferred)
enable secret 9 $9$nhEmQVczB7dqsO$X.HsgL3x1VxeLeL...
username admin privilege 15 algorithm-type scrypt secret MyStr0ngPass!

This tool flags Type 0, Type 4, Type 5, and Type 7 credentials as failures and reports their location in the config. Type 8 is flagged as a warning (acceptable but not optimal). Type 9 or algorithm-type scrypt passes.

Upgrading Password Hashes

! Step 1: Remove legacy enable secret/password
no enable secret
no enable password

! Step 2: Set Type 9 enable secret
enable algorithm-type scrypt secret MyNewStrongPass123!

! Step 3: Update local users (one at a time to avoid lockout)
no username admin
username admin privilege 15 algorithm-type scrypt secret MyNewStrongPass123!

! Verify hashes are Type 9:
show running-config | include secret
! Should show: secret 9 $9$...

Type 6 — Master Key Encryption

Type 6 uses AES to encrypt passwords at rest using a master key that is not stored in the configuration. It is the only mechanism that protects RADIUS and TACACS+ keys from being read in cleartext from show running-config output. When configured, those keys are replaced with key 6 <encrypted-string> in the config. The master key must be backed up separately; losing it means the device cannot decrypt its own RADIUS/TACACS+ keys after a reload.

! Configure master key (stored in secure storage, not in config)
key config-key password-encrypt MasterKey123!

! Enable Type 6 encryption globally
password encryption aes

! All RADIUS/TACACS+ keys in config now stored as Type 6

SNMP Security — From Community Strings to SNMPv3

The SNMP Attack Surface

SNMP (Simple Network Management Protocol) is the most dangerous service on most network devices. SNMPv1 and v2c authenticate via community strings — short text passwords embedded in cleartext UDP packets. There is no encryption, no replay protection, and no lockout mechanism. A brute-force attack against SNMP v2c proceeds at wire speed: UDP has no handshake overhead, and IOS has no rate limiting for SNMP authentication failures by default.

What SNMP read access reveals: the complete routing table, every interface and its IP address, the ARP cache (which maps IP addresses to MAC addresses, revealing connected hosts), CDP neighbor information (which reveals adjacent device types and IP addresses), and the full MIB-II tree including device uptime, hardware model, and IOS version. Every piece of information needed to plan a network attack is available via SNMP read access.

SNMP write access is functionally equivalent to console access. An attacker with read-write SNMP access can shut down interfaces, manipulate routing tables, change ACL configurations, and — on some platforms — overwrite the startup configuration. The 2002 CERT advisory CA-2002-03 on SNMP vulnerabilities affected virtually every major network vendor, and the fundamental authentication weakness has not changed for SNMPv1 and v2c.

Why Changing Community Strings Is Not Sufficient

The original SANS RAT checked only whether the community strings were literally “public” or “private.” This is the minimum possible check — removing the two most obvious defaults. The actual problem is that any SNMPv1 or v2c community string is vulnerable: brute-force attacks against SNMP community strings are trivial, operate at line rate, and produce no log entries on default IOS configurations.

A realistic attack: an adversary on the same network segment (achieved via a compromised workstation, a rogue wireless device, or ARP poisoning) runs a community string dictionary attack. Common community strings like “internal”, “network”, “mgmt”, “cisco”, “admin” appear in every SNMP brute-force wordlist. The scan takes seconds and leaves no trace. The solution is not a stronger community string — it is eliminating SNMPv1 and v2c entirely.

Complete SNMPv3 Configuration

! Step 1: Remove ALL community strings (eliminates v1/v2c)
no snmp-server community public
no snmp-server community private
! (remove all others as well)

! Step 2: Create MIB views
snmp-server view FULL-VIEW iso included
snmp-server view LIMIT-VIEW system included
snmp-server view LIMIT-VIEW interfaces included

! Step 3: Create groups with auth + priv (encryption mandatory)
snmp-server group NETMGMT v3 priv read FULL-VIEW write FULL-VIEW
snmp-server group READONLY v3 priv read LIMIT-VIEW

! Step 4: Create user (auth SHA, encryption AES-128)
snmp-server user NETOPS NETMGMT v3 auth sha AuthPass123! priv aes 128 PrivPass123!

! Step 5: Restrict by ACL
ip access-list standard SNMP-ACL
 permit 10.0.100.0 0.0.0.255
 deny any log
snmp-server group NETMGMT v3 priv access SNMP-ACL

! Step 6: Asset tracking metadata (required by CIS Level 2)
snmp-server contact noc@company.com
snmp-server location "DC1 Row3 Rack12 U14"

! Step 7: Traps for change notification
snmp-server enable traps config
snmp-server enable traps snmp linkdown linkup coldstart
snmp-server host 10.0.100.50 version 3 priv NETOPS

The difference between SNMPv3 authNoPriv and priv: with authNoPriv, the SNMP authentication header is HMAC-SHA signed (so tampering is detectable) but the payload — the actual SNMP data — travels in cleartext UDP. A passive network tap captures all MIB data. With priv, the entire payload is AES-128 encrypted. Only the SNMP source and destination are visible to a passive observer. Always use priv mode.

SNMP and NMS Integration

Major network management platforms — SolarWinds NPM, PRTG, Auvik, Zabbix, LibreNMS — all support SNMPv3 with authentication and privacy. The migration from v2c to v3 is a configuration change in both the router and the NMS, not a platform replacement. If your NMS vendor claims SNMPv3 priv is not supported, it is time to evaluate alternative NMS platforms. SNMPv3 RFC 3414 was published in 2002 — it is not new.

Interface Hardening — The Per-Interface Security Checklist

Why Interface-Level Checks Are Different

Global IOS security commands protect the control plane — the software processes that handle routing, authentication, and management traffic. Interface-level commands protect the data plane — the forwarding path for traffic flowing through the router between subnets and networks. Both are essential. A router with perfect global hardening but no interface-level controls is still vulnerable to topology disclosure, traffic redirection, and source address spoofing attacks.

The 2002 SANS RAT checked proxy-ARP as a global check. Modern auditing checks every active interface individually because a router with proxy-ARP disabled globally but active on one specific interface is still vulnerable on that segment. This tool’s hierarchical parser evaluates each interface block separately and reports per-interface findings.

The Six Per-Interface Security Commands

no ip redirects

ICMP redirect messages tell a host to use a different next-hop router for a specific destination. In a legitimate network, this handles suboptimal routing paths. In an attack, a threat actor who gains access to the network segment sends crafted ICMP redirect messages to hosts, redirecting their traffic through an attacker-controlled device — enabling a man-in-the-middle interception without any software vulnerability. Disable on all interfaces.

no ip unreachables

ICMP “destination unreachable” messages reveal network topology. When a host probes an IP address that has no route, the router responds with an ICMP unreachable. This response confirms the router is up, reveals which destinations are routable, and enables ICMP-based host and port mapping. Disable on all interfaces, particularly on external-facing interfaces. This makes the router’s unroutable space completely dark to external probes.

no ip mask-reply

ICMP address mask replies (type 17/18) respond to ICMP address mask requests with the subnet mask of the interface. This tells an attacker exactly what subnets are behind each router interface, enabling precise network mapping. There is no legitimate use case for ICMP mask replies in a modern network. Disable on all interfaces.

no ip proxy-arp

Proxy-ARP causes a router to respond to ARP requests on behalf of hosts in other subnets, effectively acting as a transparent ARP proxy. Attackers exploit proxy-ARP to conduct ARP spoofing attacks across subnet boundaries, intercepting traffic intended for hosts they would otherwise have no visibility into. Disable on all interfaces that do not explicitly require proxy-ARP for a specific, documented network design requirement.

no ip directed-broadcast

A directed broadcast is a packet sent to the broadcast address of a specific subnet. In the Smurf DDoS attack, an attacker spoofs the victim’s IP address and sends ICMP echo requests to the directed broadcast address of a large network. Every host on that network responds to the victim’s IP, amplifying the attack traffic by a factor of the number of hosts. Directed broadcasts have been disabled by default since IOS 12.0, but explicit configuration is required by CIS Benchmark and DISA STIG.

Shut Down Unused Interfaces

An interface with no IP address that is in the up/up state is an active attack surface. Any device physically connected to that port joins the broadcast domain and gains link-layer adjacency with other devices on the segment. In a data center or wiring closet environment with physical security, unused router ports should be administratively shut down with a descriptive label.

interface GigabitEthernet0/0
 description *** UPLINK ISP-PRIMARY ***
 ip address 203.0.113.2 255.255.255.252
 no ip redirects
 no ip unreachables
 no ip mask-reply
 no ip proxy-arp
 no ip directed-broadcast
 no cdp enable
 ip access-group INGRESS-FILTER in
 ip access-group EGRESS-FILTER out
 ip verify unicast source reachable-via rx
 carrier-delay msec 500

! Unused interface template
interface GigabitEthernet0/3
 description UNUSED - SHUTDOWN
 no ip address
 shutdown

Routing Protocol Security — OSPF, EIGRP, BGP

The Real-World Cost of Unauthenticated Routing

February 2008: Pakistan Telecom Authority ordered Pakistan Telecom to block YouTube within Pakistan. Pakistan Telecom implemented the block by announcing a more-specific BGP route for YouTube’s prefix (208.65.153.0/24) — and accidentally leaked that route to PCCW, their upstream provider, which propagated it globally. YouTube was offline worldwide for approximately two hours. The vulnerability: no BGP route origin validation, no authentication on the peer session that accepted the announcement.

April 2010: China Telecom announced 37,000 BGP prefixes belonging to organizations including the US military, government agencies, and major corporations. For 18 minutes, approximately 15% of global internet traffic was routed through China Telecom’s network. Again: no origin validation, no authentication on the accepting peer sessions.

April 2022: Rostelecom hijacked BGP prefixes belonging to Apple, Google, Meta, Twitter, and Akamai. Traffic was briefly redirected through Russian infrastructure. No software vulnerabilities were exploited — only misconfigured or absent BGP authentication and route filtering.

None of these incidents required a software vulnerability. They required only an absent or weak BGP peer configuration. A 10-minute configuration change — adding MD5 authentication to BGP peer sessions and basic prefix filtering — would have prevented all of them.

OSPF Authentication

Unauthenticated OSPF accepts Link State Advertisements (LSAs) from any device on the network segment that speaks OSPF. An attacker who gains access to the segment can inject false LSAs, advertising fake routes that redirect traffic through an attacker-controlled device for man-in-the-middle interception. The Loki routing protocol attack framework makes this trivial — it ships with OSPF injection as a first-class feature.

! Process-level authentication (all interfaces in area)
router ospf 1
 area 0 authentication message-digest

! Per-interface configuration
interface GigabitEthernet0/1
 ip ospf message-digest-key 1 md5 OSPFKey123!
 ip ospf authentication message-digest

! IOS-XE 15.3(3)M+ supports SHA via key chain
key chain OSPF-SHA
 key 1
  key-string OSPFsha123!
  cryptographic-algorithm hmac-sha-256

router ospf 1
 area 0 authentication key-chain OSPF-SHA

EIGRP Authentication

! Classic EIGRP — key chain MD5
key chain EIGRP-KEYS
 key 1
  key-string EIGRPkey!

interface GigabitEthernet0/1
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 EIGRP-KEYS

! Named EIGRP (IOS-XE preferred) — HMAC-SHA-256
router eigrp ENTERPRISE
 address-family ipv4 unicast autonomous-system 100
  af-interface GigabitEthernet0/1
   authentication mode hmac-sha-256 EIGRPsha256key!

BGP Authentication and GTSM

router bgp 65001
 neighbor 203.0.113.1 remote-as 65002
 ! MD5 session authentication
 neighbor 203.0.113.1 password BGPsecret!
 ! GTSM — Generalized TTL Security Mechanism (RFC 5082)
 ! Drops BGP packets not from a directly connected peer
 neighbor 203.0.113.1 ttl-security hops 1
 ! Peer session template for consistency
 template peer-session ISP-TEMPLATE
  password BGPsecret!
  ttl-security hops 1
  description *** ISP PEERING ***

GTSM (Generalized TTL Security Mechanism, RFC 5082) is one of the highest-impact, lowest-effort BGP security improvements available. By requiring that BGP TCP packets arrive with a TTL of 254 (set by the sender as 255, decremented once in transit), it ensures that only directly connected peers can establish BGP sessions. A remote attacker cannot spoof a BGP TCP packet with TTL=254 that arrives with TTL=254 — each network hop decrements the TTL. GTSM prevents remote BGP session attacks without cryptographic authentication overhead.

RPKI (Resource Public Key Infrastructure) is the modern solution to BGP prefix hijacking. Route Origin Authorizations (ROAs) cryptographically bind a prefix to the AS that is authorized to originate it. A BGP speaker with an RPKI-validating router origin validator drops or de-prefers announcements that contradict the ROA database. Configuration of an RPKI validator is beyond the scope of a running-config audit, but this tool checks for BGP peer authentication as the baseline requirement.

Control Plane Policing (CoPP)

The Data Plane vs. the Control Plane

Every router has two fundamentally different packet processing systems. The data plane forwards packets between interfaces at line rate using dedicated hardware (ASICs on the ASR 1000, the Quantum Flow Processor on the ISR 4000). A correctly configured data plane can forward millions of packets per second without involving the main CPU at all. The control plane runs routing protocols (BGP, OSPF, EIGRP), responds to ICMP pings, processes SSH sessions, handles SNMP polls, and manages every function that keeps the router operating. The control plane runs on the main CPU in software.

This architectural split is the router’s Achilles’ heel: an attacker who floods the control plane with crafted packets — OSPF hellos, BGP OPEN messages, SSH connection attempts, ICMP pings — can overwhelm the CPU and cause routing protocol adjacencies to drop. The result is a network outage. The data plane hardware may be idle; the router’s software brain is too busy handling the attack to do anything useful. This attack requires no software vulnerability — only the ability to send packets to the router’s interfaces.

CoPP Architecture

Control Plane Policing applies a QoS policy map to the control-plane interface, which represents all traffic destined for the router’s CPU. The policy map assigns traffic to class maps (OSPF traffic, BGP traffic, SSH traffic, ICMP, SNMP, everything else) and applies a police rate to each class. Traffic exceeding the rate is dropped before it reaches the CPU, protecting the control plane from overload while allowing legitimate traffic within the configured rate.

! ACLs to classify control plane traffic
ip access-list extended COPP-OSPF
 permit ospf any any
ip access-list extended COPP-BGP
 permit tcp any any eq 179
 permit tcp any eq 179 any
ip access-list extended COPP-SSH
 permit tcp 10.0.100.0 0.0.0.255 any eq 22
ip access-list extended COPP-SNMP
 permit udp 10.0.100.0 0.0.0.255 any eq 161
ip access-list extended COPP-ICMP
 permit icmp any any

! Class maps
class-map match-any COPP-ROUTING-CRITICAL
 match access-group name COPP-OSPF
 match access-group name COPP-BGP
class-map match-any COPP-MANAGEMENT
 match access-group name COPP-SSH
 match access-group name COPP-SNMP
class-map match-any COPP-ICMP
 match access-group name COPP-ICMP

! Policy map with rate limits
policy-map COPP-POLICY
 class COPP-ROUTING-CRITICAL
  police rate 512000 bps burst 32000 byte
   conform-action transmit
   exceed-action transmit
 class COPP-MANAGEMENT
  police rate 1000000 bps burst 128000 byte
   conform-action transmit
   exceed-action drop
 class COPP-ICMP
  police rate 256000 bps burst 16000 byte
   conform-action transmit
   exceed-action drop
 class class-default
  police rate 128000 bps burst 8000 byte
   conform-action transmit
   exceed-action drop

! Apply to control plane
control-plane
 service-policy input COPP-POLICY

! Monitor CoPP performance
! show policy-map control-plane
! show policy-map control-plane input class COPP-MANAGEMENT

Logging, NTP & Timestamps

Why Timestamps Are a Security Control

Consider a security incident where an attacker SSH’d into a router and modified an ACL. Your SIEM receives two log events: an SSH authentication success and a configuration change notification. If your router’s syslog timestamps have one-second resolution, these two events appear at the same timestamp and look like a single event. If they have millisecond resolution, you can see that the authentication happened 1,340 milliseconds before the configuration change — a clear attack sequence. More critically, if you need to correlate these events with firewall logs, endpoint logs, and SIEM alerts from other systems, millisecond timestamps are the common language that makes correlation possible.

PCI DSS v4.0 Requirement 10.3.3 explicitly requires time synchronization with millisecond precision across all in-scope systems. SOC 2 CC7.2 requires that security events be recorded with sufficient detail for investigation. Without msec in your timestamp configuration, you are non-compliant with both.

! Timestamps with milliseconds and timezone (mandatory)
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec localtime show-timezone

! Local buffer (fallback if syslog unreachable)
logging buffered 65536 informational

! Fixed source IP for SIEM correlation
logging source-interface Loopback0

! Remote syslog servers (minimum two for redundancy)
logging host 10.0.100.50 transport udp port 514
logging host 10.0.100.51 transport tcp port 6514

! Minimum severity to forward remotely
logging trap informational

! Syslog facility (matches SIEM parsing rules)
logging facility local7

! Include username in syslog messages
logging userinfo

! Log authentication events
login on-failure log every 3
login on-success log

Configuration Change Logging via Archive

The archive log config feature is one of the most impactful forensic capabilities available in IOS and one of the most rarely configured. When enabled, every command entered in configuration mode is logged to syslog with the administrator’s username, the exact command, and a millisecond timestamp. This is a complete configuration change audit trail — not just “a config change happened” (which is all that snmp-server enable traps config gives you), but “admin user jsmith entered ‘no ip access-list extended BLOCK-INTERNET’ at 2025-03-14 03:14:15.926 UTC.”

archive
 log config
  logging enable
  logging size 500
  notify syslog contenttype plaintext
  hidekeys

! Syslog output example:
! %PARSER-5-CFGLOG_LOGGEDCMD: User: jsmith  logged command: no ip access-list extended BLOCK-INTERNET

NTP Authentication

An attacker with access to the local network segment can send crafted NTP packets that shift the router’s clock. A clock shift of 12 hours causes TLS certificate validity checks to fail (most certificates have validity windows that don’t span 12 hours of offset). A shift of a few minutes corrupts SIEM log timestamp correlation. A shift forward in time can invalidate Kerberos tickets and RADIUS authentication sessions. NTP authentication using HMAC-MD5 keyed messages prevents unauthorized time sources from being accepted.

! Enable NTP authentication
ntp authenticate

! Define authentication key
ntp authentication-key 1 md5 NTPkey123!

! Mark the key as trusted
ntp trusted-key 1

! Associate key with specific server (minimum two for redundancy)
ntp server 216.239.35.0 key 1 prefer    ! time.google.com
ntp server 216.239.35.4 key 1            ! time2.google.com

! Fixed source IP so NTP traffic is auditable
ntp source Loopback0

! Verify: show ntp associations detail

Management Plane Hardening

The Management Plane Defined

The management plane comprises all traffic destined for the router itself for administrative purposes: SSH sessions, SNMP polls, HTTP/HTTPS web management, NETCONF/RESTCONF API calls, and ICMP pings to the router’s own interfaces. Unlike the control plane (which includes routing protocol traffic) and the data plane (transit traffic), the management plane is purely the human and machine administrative interface to the device. Proper management plane hardening means ensuring that only authorized systems from authorized network segments can reach these services, via secure protocols, with strong authentication.

The gold standard for management plane isolation is a dedicated management VRF (Virtual Routing and Forwarding instance) with a separate out-of-band management interface that is physically disconnected from the production network. This ensures that a production network compromise does not automatically grant management access. Most enterprise deployments do not have OOB management, but a VRF for management traffic plus strict ACLs on the VTY lines achieves meaningful isolation within the production network.

HTTP Server and HTTPS Restriction

! Disable plaintext HTTP (mandatory)
no ip http server

! HTTPS only if web management is required
ip http secure-server
ip http secure-port 8443

! Restrict to management IP range
ip access-list standard HTTPS-MGMT
 permit 10.0.100.0 0.0.0.255
 deny any log
ip http access-class HTTPS-MGMT

! Session timeout
ip http timeout-policy idle 30 life 60 requests 100

Disabling Unnecessary Services

NETCONF and RESTCONF

IOS-XE 16.3 introduced YANG-based programmability via NETCONF (RFC 6241) and RESTCONF (RFC 8040). These APIs provide programmatic access to router configuration and operational state with the same power as the CLI. If enabled, they must be subject to the same access controls as SSH: restricted to management subnet ACLs, authenticated via AAA, and logged.

! Only enable if required for automation
netconf-yang
restconf

! Apply management ACL (same as VTY/HTTPS restriction)
ip http access-class HTTPS-MGMT   ! covers RESTCONF (uses HTTP server)

! AAA applies automatically — netconf uses SSH transport
! Verify: show netconf-yang sessions

Ingress/Egress ACLs & Anti-Spoofing with uRPF

Why IP Source Address Spoofing Matters

IP source address spoofing — sending packets with a forged source IP — enables several attack categories that cannot be executed with a real source address: DDoS reflection attacks (where the victim receives amplified responses to queries sent with the victim’s IP as the source), bypassing IP-based access control lists (an attacker masquerades as a trusted management host), and evading network forensics (log entries show the spoofed address, not the attacker’s real IP).

The classic mitigation is a static ACL that denies RFC 1918 private addresses on external interfaces. This works, but it requires manual updates as the bogon list changes, must be replicated consistently across all external interfaces, and still allows spoofed public addresses. Unicast Reverse Path Forwarding (uRPF) provides dynamic, routing-table-based anti-spoofing that handles all cases automatically.

uRPF — Strict vs. Loose Mode

uRPF checks the source IP address of each arriving packet against the Forwarding Information Base (FIB). In strict mode, the source IP must be reachable via the same interface the packet arrived on — if routing says “to reach 10.0.1.0/24, go out GigabitEthernet0/1” but a packet from 10.0.1.5 arrives on GigabitEthernet0/0, it is dropped. This is the correct mode for single-homed links where asymmetric routing does not occur.

In loose mode, the source IP only needs a route in the FIB via any interface. This handles multi-homed links with asymmetric routing but provides weaker protection — it only drops packets from completely unrouted sources (true bogons and unallocated space), not all spoofed addresses. Use loose mode on links where legitimate asymmetric routing is expected; use strict mode everywhere else.

! CEF must be enabled (prerequisite for uRPF)
ip cef

! Strict mode — for single-homed external links
interface GigabitEthernet0/0
 ip verify unicast source reachable-via rx

! Loose mode — for multi-homed links with asymmetric routing
interface GigabitEthernet0/1
 ip verify unicast source reachable-via any

! Monitor drops:
show ip interface GigabitEthernet0/0 | include verify

Complete Ingress ACL Template

uRPF handles dynamic source spoofing. A static ingress ACL provides defense-in-depth by explicitly logging and dropping known-bogon traffic, providing visible evidence of spoofing attempts in your syslog that uRPF drops silently:

ip access-list extended INGRESS-FILTER
 ! RFC 5735 and RFC 1918 reserved ranges — should never arrive from internet
 deny ip 0.0.0.0 0.255.255.255 any log         ! This network (RFC 1122)
 deny ip 127.0.0.0 0.255.255.255 any log        ! Loopback (RFC 1122)
 deny ip 10.0.0.0 0.255.255.255 any log         ! RFC 1918 private
 deny ip 172.16.0.0 0.15.255.255 any log        ! RFC 1918 private
 deny ip 192.168.0.0 0.0.255.255 any log        ! RFC 1918 private
 deny ip 169.254.0.0 0.0.255.255 any log        ! Link-local (RFC 3927)
 deny ip 192.0.2.0 0.0.0.255 any log            ! TEST-NET-1 (RFC 5737)
 deny ip 198.51.100.0 0.0.0.255 any log         ! TEST-NET-2 (RFC 5737)
 deny ip 203.0.113.0 0.0.0.255 any log          ! TEST-NET-3 (RFC 5737)
 deny ip 224.0.0.0 15.255.255.255 any log       ! Multicast + Class E
 ! Permit all other traffic
 permit ip any any

! Apply to external interface
interface GigabitEthernet0/0
 ip access-group INGRESS-FILTER in

DISA STIG & CIS Benchmark Compliance Mapping

The Major Frameworks and Their Scope

The DISA STIG for Cisco IOS XE Router RTR (current version: V3R1) contains approximately 200 individual checks, mandatory for all Department of Defense contractors and federal agencies. STIG findings are categorized by severity: CAT I (critical — immediate risk of mission-critical failure), CAT II (serious — non-compliance creates significant risk), and CAT III (minor — information or configuration that could degrade security). Our tool covers all CAT I and the most impactful CAT II controls.

The CIS Benchmark for Cisco IOS 15 and the separate CIS Benchmark for Cisco IOS XE are the civilian equivalents — industry consensus documents updated approximately annually. Level 1 is safe for all production environments. Level 2 requires operational trade-off evaluation but is recommended for any router handling sensitive data or facing the public internet.

NIST SP 800-53 Rev 5 provides the control catalog that underpins most U.S. federal security requirements. The AC (Access Control), IA (Identification and Authentication), AU (Audit and Accountability), SC (System and Communications Protection), and CM (Configuration Management) control families all have direct IOS configuration implementations.

Interactive Audit Walkthrough — Before and After

The “Before” Configuration

This is a realistic configuration for a newly deployed Cisco ISR 4000 running IOS-XE 17.3 — straight from the VAR, with minimal post-deployment hardening. This exact configuration pattern is common in small-to-medium enterprise deployments:

version 17.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
enable password cisco
!
interface GigabitEthernet0/0/0
 description WAN
 ip address 203.0.113.2 255.255.255.252
!
interface GigabitEthernet0/0/1
 description LAN
 ip address 10.0.0.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 203.0.113.1
ip http server
ip http secure-server
!
snmp-server community public RO
snmp-server community private RW
snmp-server community internal RO
!
line vty 0 4
 password cisco
 login
 transport input all
!
end

What the Audit Engine Finds

Paste this configuration into the tool at the top of this page and click “Run Security Audit.” Here is what you will see:

Score: approximately 6/100 — Risk Level: CRITICAL. This router, if placed on the internet today, would be enumerated via SNMP within minutes, scanned for SSH (and would accept Telnet), and has credentials that are trivially recoverable from any config backup.

The “After” Configuration

After applying the remediation commands generated by the tool, the same audit produces a score of approximately 78/100 — Risk Level: LOW. The remaining failures are typically CoPP (requires a full policy-map design) and uRPF (requires CEF confirmation and interface-specific application), plus any routing protocol authentication rules that require TACACS+ server configuration. The critical and high findings are all resolved.

Remediation Command Reference

Copy-paste IOS/IOS-XE hardening blocks. Each block is independently applicable — apply in the order shown to avoid lockout risk. Review every command in a lab environment before production deployment.

! ── PREREQUISITE: Create local fallback user BEFORE enabling AAA ──
username admin privilege 15 algorithm-type scrypt secret CHANGE_ME_NOW!

! ── Enable AAA framework ──
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

! ── TACACS+ server ──
tacacs server PRIMARY
 address ipv4 10.0.100.10
 key CHANGE_TACACS_KEY!
 timeout 5

! ── Brute-force protection ──
security passwords min-length 12
login block-for 60 attempts 5 within 30
login quiet-mode access-class MGMT-ONLY
login on-failure log every 3
login on-success log

! ── Generate strong RSA key ──
crypto key zeroize rsa
crypto key generate rsa modulus 4096

! ── SSH version and algorithm restriction ──
ip ssh version 2
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512
ip ssh server algorithm kex diffie-hellman-group14-sha1
ip ssh dh-min-size 2048
ip ssh time-out 60
ip ssh authentication-retries 3

! ── VTY lines: SSH only, timeout, ACL, AAA ──
ip access-list standard VTY-MGMT
 permit 10.0.100.0 0.0.0.255
 deny any log

line vty 0 15
 transport input ssh
 exec-timeout 5 0
 access-class VTY-MGMT in
 login authentication default

! ── Remove legacy enable password ──
no enable password

! ── Set Type 9 (scrypt) enable secret ──
enable algorithm-type scrypt secret CHANGE_ME_NOW!

! ── Enable service password-encryption (for line passwords) ──
service password-encryption

! ── Console line: timeout and authentication ──
line con 0
 exec-timeout 5 0
 login authentication default

! ── AUX line: disable completely ──
line aux 0
 transport input none
 no exec

! ── Remove ALL community strings ──
no snmp-server community public
no snmp-server community private
! (repeat for any other communities)

! ── SNMPv3 with authentication + encryption ──
ip access-list standard SNMP-ACL
 permit 10.0.100.0 0.0.0.255
 deny any log

snmp-server view FULL-VIEW iso included
snmp-server group NETMGMT v3 priv read FULL-VIEW write FULL-VIEW access SNMP-ACL
snmp-server user NETOPS NETMGMT v3 auth sha AuthPass123! priv aes 128 PrivPass123!
snmp-server contact noc@company.com
snmp-server location "DC1 Row3 Rack12"

! ── Traps ──
snmp-server enable traps config
snmp-server enable traps snmp linkdown linkup
snmp-server host 10.0.100.50 version 3 priv NETOPS

! ── Millisecond timestamps ──
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec localtime show-timezone

! ── Syslog ──
logging source-interface Loopback0
logging buffered 65536 informational
logging host 10.0.100.50
logging trap informational
logging facility local7
logging userinfo

! ── Configuration change logging ──
archive
 log config
  logging enable
  logging size 500
  notify syslog contenttype plaintext
  hidekeys

! ── Authenticated NTP ──
ntp authenticate
ntp authentication-key 1 md5 NTPkey123!
ntp trusted-key 1
ntp server 216.239.35.0 key 1 prefer
ntp server 216.239.35.4 key 1
ntp source Loopback0

no service pad
no service config
no service tcp-small-servers
no service udp-small-servers
no ip finger
no ip bootp server
no ip source-route
no ip domain-lookup
no cdp run
ip cef

! ── Disable HTTP (enable HTTPS only if required) ──
no ip http server
! ip http secure-server          ! Uncomment only if web management needed
! ip http access-class HTTPS-MGMT

! ── Legal banner ──
banner motd ^
=========================================================
AUTHORIZED ACCESS ONLY
This system is for authorized users only.
Unauthorized access is prohibited and monitored.
All activities are logged and may be audited.
=========================================================
^

! Paste this block into each active interface, then customize
interface GigabitEthernet0/0
 no ip redirects
 no ip unreachables
 no ip mask-reply
 no ip proxy-arp
 no ip directed-broadcast
 no cdp enable

! Shutdown unused interfaces
interface GigabitEthernet0/3
 description UNUSED
 no ip address
 shutdown

! Anti-spoofing on external interface (requires ip cef)
interface GigabitEthernet0/0
 ip verify unicast source reachable-via rx

Frequently Asked Questions

Conclusion & Next Steps

Router security is not complex. It is a checklist — a well-defined set of configuration controls that have been known and documented since the NSA published its Router Security Configuration Guide in 2001. What has been missing is a tool that applies all of those controls, plus two decades of additional requirements from CIS, DISA, and NIST, against an actual configuration in seconds, with zero friction and zero privacy risk.

The 2002 SANS RAT paper that still dominates search results for “router audit tool” checks 37 rules, has no interactive element, cannot parse IOS-XE syntax, and misses entire categories of modern attack surface. A network engineer using only that paper as a hardening guide in 2025 leaves their BGP sessions unauthenticated, their SSH sessions open to weak ciphers, their SNMP in v2c mode, and their privilege-level-15 passwords in MD5. This tool closes all of those gaps.

Your Three Next Steps

• Run your first audit now: Paste a show running-config from any router you manage into the tool at the top of this page. Even if you think it’s already hardened, the results are usually surprising.
• Bookmark the Remediation Command Reference: Section 17 is structured as a runbook. Each block is independently applicable with comments explaining every command. Add it to your team’s network engineering wiki.
• Download the CIS Benchmark: The full CIS Benchmark for Cisco IOS is available free with registration. It provides the detailed rationale, audit procedures, and remediation guidance for every control, and is the authoritative reference for compliance evidence.

Twenty years after the original router audit tool was published as a static PDF, network security has evolved, attack techniques have matured, and the configuration requirements have grown more precise. The router on your network perimeter deserves an audit tool that has kept pace.