Network Device Hardening: Cisco Switch and Router Security Configuration Guide
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Network infrastructure devices — switches, routers, and firewalls — are the highest-privilege targets in most networks and among the least frequently hardened. A management plane compromise on a core switch provides the ability to monitor all traffic traversing that switch, modify VLAN configurations to reach otherwise segmented systems, and manipulate routing to redirect traffic. These capabilities are unavailable to an attacker who compromises a single server or endpoint.
Despite this, most vulnerability management programs do not scan network devices (credentialed network device scanning is operationally complex) and most penetration tests focus on servers and applications. The result is network infrastructure that has not been hardened since it was initially configured, running Telnet, default community strings, and shared enable passwords.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Management plane hardening: the highest-priority controls
The management plane encompasses every protocol and interface used to configure, monitor, and query network devices: SSH, SNMP, syslog, TACACS+, and the console port. Each of these is a potential entry point if left at default settings. Replacing Telnet with SSH version 2 eliminates plaintext credential exposure; migrating from SNMPv1/v2c community strings to SNMPv3 AuthPriv mode eliminates both plaintext secrets and unauthenticated MIB read access. TACACS+ replaces shared enable passwords with per-user authentication and command-level authorization, creating an audit trail of every command run on the device. Management ACLs restrict which source IPs can reach these interfaces at all, adding a network-layer control that backs up the protocol-layer controls. Applying all four changes in a consistent sequence across the fleet is the goal; testing each change on a non-production device first is the safeguard that keeps core infrastructure online.
Audit the current state before making changes
Before any configuration changes: capture the current running configuration of all network devices with show running-config and store it in version-controlled storage. Review each configuration for: any 'transport input telnet' or 'transport input all' on VTY lines, any 'snmp-server community' with RW access, any plaintext enable passwords (should use 'enable secret' not 'enable password'), any 'username' lines with password instead of secret. The audit provides a baseline for the changes and a rollback point if a hardening change causes connectivity issues. For a large fleet: use a network configuration management tool (Cisco DNA Center, Oxidized, RANCID) to collect configurations automatically.
Test each hardening change on a non-production device first
Network device configuration changes carry higher risk than server configuration changes because a misconfiguration can take the device offline entirely, requiring console access to recover. Test sequence: apply the SSH and AAA configuration to one non-critical switch (an access switch in a low-traffic area, not a core or distribution switch) first. Verify SSH access works, TACACS authentication works, and the fallback to local authentication works (test by temporarily making TACACS unavailable). Then apply to the rest of the fleet in risk order: access switches first, distribution switches second, core switches third. Never apply untested configuration changes to core infrastructure during business hours.
The bottom line
Network device hardening covers a set of configuration changes that collectively harden the management plane: SSH replaces Telnet, SNMPv3 replaces community strings, TACACS+ replaces shared enable passwords, management ACLs restrict which sources can reach management interfaces, and unused services and ports are disabled. STP security controls protect the control plane from topology manipulation attacks. The hardening configuration follows Cisco IOS commands that are consistent across most Catalyst switch models and ISR router models with minor variations. Audit current configurations before making changes, test on non-production devices first, and monitor syslog for authentication failures and configuration changes after hardening is applied.
Frequently asked questions
How do I configure SSH and disable Telnet on a Cisco switch or router?
SSH configuration on Cisco IOS: (1) Set the hostname and domain name (required for RSA key generation): hostname SWITCH-01; ip domain-name company.internal. (2) Generate the RSA key: crypto key generate rsa modulus 4096 (minimum 2048, recommend 4096). (3) Enable SSH version 2: ip ssh version 2; ip ssh time-out 60; ip ssh authentication-retries 3. (4) Configure VTY lines for SSH only: line vty 0 15; transport input ssh; login local. (5) Disable Telnet by removing 'transport input telnet' from all line configurations. (6) Create local user accounts (for fallback if TACACS is unavailable): username admin privilege 15 secret [strong-password]. (7) Verify: show ip ssh should show SSH enabled, version 2.0. Test SSH access from your management workstation before disconnecting the console. Note: if TACACS is not yet configured, the local user account is your only access method — do not proceed with step 4 without confirming local user authentication works first.
How do I configure SNMPv3 on Cisco devices and remove SNMPv1/v2c?
SNMPv3 configuration on Cisco IOS: (1) Create an SNMP view (limits what MIB data the monitoring system can access): snmp-server view READONLY iso included (grants access to all OIDs) or a more restrictive view. (2) Create an SNMP group with AuthPriv security: snmp-server group MONITORING-GROUP v3 priv. (3) Create an SNMP user: snmp-server user monitoring-user MONITORING-GROUP v3 auth sha [auth-password] priv aes 128 [priv-password]. Use SHA (not MD5) for authentication and AES-128 (not DES) for privacy — MD5 and DES are deprecated. (4) Remove all SNMPv1 and SNMPv2c community strings: no snmp-server community public. no snmp-server community private. Review show running-config for any remaining 'snmp-server community' lines and remove them. (5) Configure SNMP trap receiver (if applicable): snmp-server host SIEM-IP version 3 priv monitoring-user. (6) Verify: test SNMP access from your monitoring system using the v3 credentials. Confirm that snmpwalk using v1 or v2c community strings fails.
How do I configure TACACS+ authentication for network device access?
TACACS+ configuration on Cisco IOS: (1) Configure TACACS+ server: tacacs server PRIMARY; address ipv4 TACACS-SERVER-IP; key SHARED-SECRET. tacacs server SECONDARY; address ipv4 BACKUP-TACACS-IP; key SHARED-SECRET. (2) Configure AAA authentication: aaa new-model; aaa authentication login default group tacacs+ local. The 'local' fallback uses local user accounts if TACACS is unreachable — this is critical for break-glass access. (3) Configure AAA authorization (which commands each user can run): aaa authorization exec default group tacacs+ local; aaa authorization commands 15 default group tacacs+ local. (4) Configure AAA accounting (logs all commands): aaa accounting exec default start-stop group tacacs+; aaa accounting commands 15 default start-stop group tacacs+. (5) Apply AAA to VTY lines: line vty 0 15; login authentication default. (6) Test: log in via SSH using TACACS credentials before closing the console session. Verify authentication appears in TACACS server logs. TACACS+ server options: Cisco ISE (full-featured, expensive), Cisco DNA Center, or open source tac_plus (smaller environments).
What STP security features should I enable on access switch ports?
Spanning Tree Protocol security configuration: (1) BPDU Guard: enable on all access ports that should never become part of the spanning tree. BPDU Guard shuts down the port if a BPDU (Bridge Protocol Data Unit) is received, preventing an attacker from connecting a rogue switch and manipulating the spanning tree topology. Configuration: interface range FastEthernet 0/1-24; spanning-tree bpduguard enable. Or enable globally on all PortFast-enabled ports: spanning-tree portfast bpduguard default. (2) PortFast: enables access ports to immediately transition to forwarding state without going through listening and learning, which reduces connection time for end devices. Enable on access ports: interface FastEthernet 0/1; spanning-tree portfast. (3) Root Guard: prevents a downstream switch from becoming the STP root bridge by disabling ports that receive superior BPDUs. Enable on uplink ports facing access layer switches (not on ports facing the core): interface GigabitEthernet 0/1; spanning-tree guard root. (4) Loop Guard: detects loss of BPDUs on point-to-point links and prevents ports from transitioning to forwarding if BPDUs stop being received. Enable on inter-switch links: interface GigabitEthernet 0/1; spanning-tree guard loop.
How do I restrict management access to network devices using ACLs?
Management plane ACL configuration: restrict SSH, SNMP, and HTTPS management access to only the management team's IP addresses or management VLAN. (1) Create an access control list that permits management from authorized sources only: ip access-list standard MGMT-ACL; permit 10.10.10.0 0.0.0.255 (management workstation subnet); deny any log. (2) Apply the ACL to the VTY lines: line vty 0 15; access-class MGMT-ACL in. (3) Restrict SNMP access: snmp-server community SNMP-COMMUNITY RO MGMT-ACL (applies the ACL to SNMP v2c access — use per-user access for SNMPv3). (4) For router management interfaces: use a dedicated loopback interface as the management source IP, advertised only within the management network routing domain. (5) If the device has a dedicated out-of-band management port (console server access): ensure the management port is on the dedicated management VLAN and not on the production network. (6) Create a management ACL on all devices with identical permit statements so the management access policy is consistent across the fleet.
How do I disable unused services and ports on Cisco devices?
Unused service and port hardening: (1) Disable unnecessary global services: no service finger; no service udp-small-servers; no service tcp-small-servers; no ip bootp server; no ip http server (if HTTP management is not used — use HTTPS: ip http secure-server); no ip http server (disable unencrypted HTTP management). (2) Disable CDP (Cisco Discovery Protocol) on external-facing interfaces: CDP broadcasts device model, IOS version, and IP information to adjacent devices — disable on all interfaces facing external networks or end-user devices: interface range FastEthernet 0/1-24; no cdp enable. (3) Shut down all unused switch ports: interface range FastEthernet 0/[unused ports]; shutdown; switchport access vlan [unused-vlan]. Place unused ports in a dedicated 'black hole' VLAN. (4) Disable source routing: no ip source-route. (5) Disable proxy ARP on routed interfaces: interface GigabitEthernet 0/0; no ip proxy-arp. (6) Disable ICMP redirects on external-facing interfaces: no ip redirects; no ip unreachables (reduces information leakage from ICMP messages).
How do I configure network devices to send logs to a SIEM?
Network device syslog configuration for SIEM integration: (1) Enable logging to an external syslog server: logging host SIEM-IP; logging facility local7 (or local0-local7, matching your SIEM's expected facility); logging trap informational (sets the minimum severity level to log — informational captures login events, configuration changes, and STP topology changes; debugging generates excessive volume and is not appropriate for production SIEM forwarding). (2) Enable logging for security-relevant events: logging on; service timestamps log datetime msec localtime. (3) Enable logging of AAA events (login success/failure, command accounting): the TACACS+ accounting configuration sends command logs to the TACACS server, but authentication events also appear in syslog. (4) Enable logging of interface state changes and STP events: these appear at informational severity by default. (5) Configure NTP for consistent log timestamps: ntp server NTP-SERVER-IP; ntp authentication-key 1 md5 NTP-KEY; ntp authenticate. NTP synchronization ensures syslog timestamps are accurate for SIEM correlation. Without NTP, log timestamps may be hours off from your SIEM's system time, making log correlation impossible. (6) SIEM-side: configure a Syslog input on your SIEM to receive network device logs, and create detection rules for: configuration change syslog messages, multiple failed login events, STP topology changes outside maintenance windows.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.