Router Service Hardening: Turning Off What You Never Needed

Every service a router runs is a door, and most routers ship with doors open that you will never walk through. A legacy Telnet listener, an HTTP server nobody manages, CDP announcing your topology to anything on the wire, small services from the 1980s that exist only as attack surface. Hardening is the unglamorous work of closing those doors, and the only honest way to know you succeeded is to scan the box and watch the open ports disappear. This article, part of the infrastructure security cluster, does exactly that: a real Nmap scan of a router before hardening, the config that turns off what was never needed, and a re-scan proving the attack surface shrank to nothing. Then it covers the syslog design that makes the whole thing auditable.

Before: scan the router, find a door open

You cannot harden what you have not measured. So before touching the config, we scanned EDGE1 from the Debian attacker with Nmap, checking the twenty most common ports:

j@llmbits$ nmap -Pn -T4 --top-ports 20 192.168.99.1
23/tcp   open   telnet          <-- cleartext telnet is LISTENING
22/tcp   closed ssh
80/tcp   closed http
... (all others closed) ...
Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

There it is: 23/tcp open, Telnet listening. Cleartext management, credentials and session in the clear, on a port anyone who can reach the interface can connect to. The vty lines had transport input ssh telnet, so Telnet was live. This is precisely the kind of finding a scan surfaces that a config review might skim past. If you want the scanning technique itself, our Nmap cluster covers it in depth, and the before/after scan here is a natural bridge to it.

Harden: turn off what you never needed

The remediation is a checklist of services to disable and management to lock down. Every line has a reason:

no ip http server
no ip http secure-server
no cdp run
no lldp run
no service pad
no ip source-route
no ip bootp server
no ip finger
line vty 0 4
 transport input ssh            ! telnet gone, SSH only
 access-class PLZ-VTY-ACL in    ! and restrict WHO can even connect
ip access-list standard PLZ-VTY-ACL
 permit 192.168.99.0 0.0.0.255
 deny any log

Discovery protocols deserve a word. CDP and LLDP are genuinely useful inside your trusted network - they map neighbours and drive things like voice VLAN assignment. On an untrusted edge they are pure information leak, handing an attacker your platform, software version, and port layout for free. Disable them on edge-facing interfaces; keep them where they earn their keep. This service-plane work complements the management-plane lockdown in our companion article on hardening the management plane on IOS XE - together they cover both what the box offers and who is allowed to manage it.

Why an open service is worth closing even if "nothing uses it"

The pushback you will hear against hardening is "that service is not hurting anyone, leave it." It is worth answering directly, because the reasoning is the same for every door on the list. An unused listening service costs you in three ways regardless of whether anyone legitimately uses it. First, it is attack surface: every listener is code that parses attacker-controlled input, and every such codebase has a vulnerability history you are now exposed to. The IOS HTTP server is a classic example, with a long list of CVEs for something most operators never deliberately use. Second, it is reconnaissance value: a Telnet banner, a CDP announcement, or a finger response tells an attacker what you are running, which is the first step of any targeted attack. Third, it is a foothold: cleartext management like Telnet hands over credentials to anyone who can sniff the segment, turning a passive position into an active one. "Nothing uses it" is not a security argument - if nothing uses it, that is the strongest possible reason to turn it off, because you lose nothing and remove all three costs.

After: re-scan, and prove it

Here is the rule that separates hardening from wishful thinking: prove each step with a real re-scan, not a claim. So we scanned EDGE1 again from the same attacker:

j@llmbits$ nmap -Pn -T4 --top-ports 20 192.168.99.1
Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds    (NO open ports reported)

j@llmbits$ nmap -Pn -p22,23,80 192.168.99.1
22/tcp closed ssh
23/tcp closed telnet           <-- telnet is now CLOSED
80/tcp closed http

The top-20 scan reports no open ports. The targeted scan of 22, 23, and 80 confirms it: 23/tcp is now closed, the Telnet listener is gone. The attack surface that a scan could see went from "Telnet wide open" to "nothing," and we know that because a real tool measured it twice. That before/after is the entire credibility of hardening - a shrinking open-port list from an actual scan, not a config diff you hope had the intended effect.

Syslog design: hardening you can reconstruct afterward

Closing ports stops the easy attacks. When something does get through, the difference between a five-minute triage and a week of guessing is your logging. The lab already produces useful security events - recall the anti-spoofing capture, where the router logged the exact forged source:

%SEC-6-IPACCESSLOGDP: list PLZ-ANTISPOOF denied icmp 1.2.3.4 -> 10.255.0.2 (8/0), 1 packet

That message is only fully useful if the surrounding syslog design gives it three properties. Here is the minimum viable configuration:

service timestamps log datetime msec localtime show-timezone
service sequence-numbers
logging buffered 64000 informational
logging host 192.168.99.100          ! the Debian VM as the remote collector
logging trap informational

Put those together and you have a log an incident responder can actually work with: an accurate timestamp (so it lines up with every other device, which needs authenticated NTP to trust), a sequence number (so a cleared range is visible as a gap), and a remote copy on the collector (so the record outlives the compromised box). Msec plus timezone plus sequence numbers plus a remote collector is the minimum viable syslog design for an incident you can reconstruct afterward - and the accurate timestamp is why the NTP authentication work is a prerequisite, not a nicety. Time and logging are core network services, so pair this with the wider IP services cluster too.

Make it repeatable, not a one-off

A hardened box drifts. Someone enables the HTTP server to troubleshoot and forgets to disable it; a template rebuild reintroduces Telnet; a new interface comes up edge-facing with CDP still running. The way you keep hardening from decaying is to treat the scan as an ongoing control, not a one-time event. Bake the before/after Nmap into your change process: scan after any config change to a device's management or service configuration, and diff the open-port list against a known-good baseline. A port that appears where none should be is an alert, the same way a new deny-log hit is. This is the operational discipline that makes the difference between a device that was hardened once and a device that stays hardened - and it is why the scanning skill from the Nmap cluster is worth having in your own toolkit, pointed at your own gear.

What the scan does and does not tell you

One honest caveat about the before/after evidence. An external port scan measures reachable listening services from a given vantage point, which is exactly the attacker's view and precisely what you want for edge hardening. It does not, by itself, prove that a service is fully disabled everywhere - a listener could still be reachable from a different source that your vty access-class permits, or bound to a management interface the scanner cannot reach. That is a feature, not a gap: the access-class we applied means the vty is now reachable only from 192.168.99.0/24, so a scan from an unauthorized source seeing "closed" is the intended result. Combine the scan (the outside view) with a config audit (show running-config for the service lines) and the vty access-class deny-log hits (who tried and was refused). The scan proves the door is shut to outsiders; the access-class log proves someone rattled it; the config proves the service is off by policy. Together they give you defence you can demonstrate three different ways.

The hardening checklist, in order

Pulling it together into a repeatable process:

• Audit with a real scan first - Nmap the box and see what is actually listening, not what you assume.
• Kill cleartext management - Telnet to SSH only on the vty lines.
• Disable discovery on untrusted edges - CDP and LLDP off where they only leak information.
• Turn off legacy small services and source-routing - HTTP servers, PAD, BOOTP, finger, source-route.
• Restrict management with a vty access-class - only your management range can even reach the vty.
• Re-scan to prove each change - the open-port list must shrink for real.
• Design syslog for reconstruction - accurate time, sequence numbers, remote collector.

Key Takeaways

• Prove hardening with a scan, not a claim. A real Nmap before/after took EDGE1 from 23/tcp Telnet open to no open ports reported and Telnet closed.
• Kill cleartext management - transport input ssh plus a vty access-class so only your management range can connect at all.
• Turn off what you never needed - HTTP servers, CDP/LLDP on untrusted edges, PAD, BOOTP, finger, and source-routing are attack surface with no upside on an edge router.
• A log is only useful with three things - an accurate timestamp (hence authenticated NTP), a sequence number (to spot cleared logs), and a remote destination (to survive compromise).
• The before/after scan bridges to Nmap - measuring your own attack surface is the same skill as scanning anyone else's.

Service hardening is where device security becomes measurable. Work through the rest of the infrastructure security cluster to pair it with control-plane policing, anti-spoofing, and authenticated NTP for a device that is hard to reach, hard to spoof, and easy to audit.