Writing

Cisco IOS hardening: a small guide

Published · Updated
cisco hardening ios operations

Following the IOS vulnerabilities last year, I have been refining a small hardening guide for Cisco IOS routers. The guide is for friends and small-organisation contacts running modest Cisco infrastructure. Worth writing up the substance.

This is not a comprehensive guide; it is the small set of changes that produce the most defensive value.

The basics

Disable services you do not use. Most Cisco routers ship with several services enabled by default. The ones to think about:

  • service tcp-small-servers and service udp-small-servers — echo, chargen, daytime, discard. Useless on modern networks. Disable: no service tcp-small-servers, no service udp-small-servers.
  • ip http server — the web-based configuration interface. Subject to the vulnerabilities I wrote about last year. If you do not use it, disable: no ip http server. If you do use it, restrict by ACL: ip http access-class [number].
  • cdp — Cisco Discovery Protocol. Useful for managing Cisco environments; leaks information to anyone on the same segment. Disable on external interfaces: no cdp enable.
  • ip source-route — old IP option for source routing. Almost never legitimately used. Disable: no ip source-route.

Restrict management access. Console, vty, and SNMP access should all be restricted by ACL. Specifically:

access-list 10 permit [your-management-ip]
access-list 10 deny any log
line vty 0 4
  access-class 10 in

This restricts vty access to a specific source. The log keyword on the deny line means refused attempts are logged.

Use SSH for management, not telnet. Cisco IOS supports SSH from version 12.1 onwards. Configure the router with an RSA keypair, configure vty to require SSH (transport input ssh), and disable telnet (transport input none followed by transport input ssh).

Use AAA for authentication. Local username/password is fine for small deployments; for anything larger, integrate with an authentication server (RADIUS or TACACS+) so credentials are centrally managed.

The router-as-target hardening

A few additional changes for routers that are themselves likely to be probed.

Filter at the perimeter. Inbound from the internet, drop:

  • Source addresses from RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Source 127.0.0.0/8 (loopback).
  • Source 0.0.0.0/8.
  • Multicast and broadcast destinations.
  • Source addresses that match your own network range (anti-spoofing).

Apply BCP 38 egress filtering. Outbound, only permit traffic with source addresses from your own range.

Rate-limit ICMP. A rate-limit directive on the input interface caps the rate at which ICMP can flood the router itself, defeating the simplest router-targeted DoS attempts.

The logging discipline

Log everything to a central syslog server. logging [server-ip] directs logs to an external machine. The router's own log buffer is small and rotates quickly; the central server is the source of truth.

Increase the logging level for security events. logging trap warnings captures the security-relevant events without flooding with informational messages.

Monitor the central log. Structured-log analysis on the syslog server should be looking for unusual patterns — repeated authentication failures, unexpected configuration changes, ACL deny-rate spikes.

What I have not included

A few things I deliberately leave out:

VPN configuration. Out of scope. If you need VPN, the configuration is non-trivial and depends on what you are connecting to.

Routing protocol authentication. OSPF, BGP authentication is important if you are running these protocols. Most small deployments do not.

Specific IDS integration. Cisco's NetFlow can feed network analysis but the integration is non-trivial.

For friends running modest Cisco infrastructure, the basics above produce the bulk of the defensive value. More sophisticated deployments need more sophisticated hardening; the guide is for the modest case.

A note on the broader industry

The state of router-hardening guidance in 2001 is, in my view, inadequate. Cisco's official documentation describes the configuration directives but is light on which ones to use and why. Third-party guides exist but are uneven in quality.

The gap is similar to the TLS-audit gap — the tools exist, the configuration is documented, but the opinionated guidance about what to actually do is patchy. Operators end up either following an old written-down checklist (some of which are out of date) or making it up.

For my own contribution: this post and the small expanded guide I am writing for friends.

More as the year develops.

Back to all writing