Network Device Hardening Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Hardening is a smaller management plane

Hardening a network device means fewer ways to manage it, stronger ways for the people who should, logs you can trust, and a configuration you can restore. It does not mean collecting exploit notes. This page does not describe attacks. It describes the shape of a device you are willing to leave running. It is a planning aid. It is not a CIS benchmark and it is not the vendor's hardening guide. Those documents have owners. Use them when your policy says to, and use this page to see whether the basics are even in the ticket.

The management plane is SSH or the vendor's equivalent, from a prefix you named, with a person who is accountable. Telnet, a shared admin password, and a web interface open to the whole company are the things this guide wants gone. SNMP, if you poll, follows the monitoring guide: a secret, a source prefix, and not the word public.

The control plane is the routing and switching the device does with its neighbours. Protect it by knowing who the neighbours are. A new neighbour you did not add is a change, not a feature. Authentication of the protocol, where you have it, is part of the design and not a later project. The routing and switching guides are the companions.

The data plane is what users' traffic does. Hardening it is policy: default deny where a firewall is the job, and no accidental trunk of every VLAN where a switch is the job. The VPN and switching guides hold those details. A hardened management plane on a switch that trunks every VLAN everywhere is half a job.

Who can log in, and from where

Named people, not a shared account called admin, wherever the platform allows it. A shared account means you cannot say who changed the trunk. If the platform forces a shared account, compensate with the change ticket and with physical control of the password store, and plan the replacement. The password is not in the ticket and not in this page.

Source restriction is the other half. SSH from the management prefix only. If the management prefix is the whole user LAN, you do not have a management prefix. Carve one out, even a small one, and put the jump host there. The jump host is then the thing you harden as a server. The network device only has to trust that prefix.

Turn off what you do not use. An unused HTTP server, an unused Telnet listener, and an unused discovery protocol on a user port are extra surfaces. Discovery between switches can be useful. Discovery toward a user port tells the user things they do not need. Know the difference on your platform. The vendor guide is the dialect.

Authentication against a directory is better than a local password, until the directory is down. Keep one local break-glass account, stored the way you store break-glass accounts, tested on a schedule, and not used for daily work. A break-glass account that is used daily is just the shared admin password again.

Logs and time

Send logs to a server that is not the device. A device that only logs to itself loses the log in the reboot you are investigating. The monitoring guide covers the path. Use it. Include configuration changes if the platform can log them. The question you will be asked is who changed the trunk. The log is the answer, or the ticket is.

Time has to be right. Logs from devices that disagree by minutes cannot be lined up with a capture or with a directory failure. NTP from a source you trust, and a check that the clock is actually synced, is part of hardening. A device that thinks it is 2019 will also fail certificates and confuse you.

Keep the log server on the management prefix. If user traffic can rewrite your logs, you do not have logs. Restrict who can read them. They contain the shape of the network.

Alert on the events you will act on: a new login failure storm, a configuration change outside a window, a neighbour appearing. An alert on every informational line will be muted. The monitoring guide's rule about pages applies here word for word.

A configuration you can put back

Back up the configuration on a timer to a place that survives the device. Test a restore in a lab. A backup you have never restored is a hope. The migration guide says the same about the night you replace the device. Hardening includes the boring restore test.

Store the backup with the same care as a password if it contains secrets. Many do. Access to the backup store is access to the network. Treat it that way. Do not keep the only copy on a laptop.

A change that cannot be rolled back is a change that waits. Hardening work itself must be reversible. If you lock SSH to the wrong prefix, you need the console. Know where the console is before you restrict the prefix. Out-of-band access is a hardening tool. Without it, people leave management open because they are afraid, and they are right to be afraid.

Version the configuration if you can, and keep secrets out of the repository, as the automation guide insists. A diff of yesterday against today is how you notice a change nobody ticketed. That diff is a control. Run it.

A first hardening pass that does not lock you out

On one lab device, restrict management, turn off the unused listeners, set the clock, send a log, and take a backup. Then restore the backup onto a second lab device or the same one after a wipe you intended. If you locked yourself out, the console was the lesson. Do not start on the core.

Then one production closet, in a window, with the console path tested that morning. Then the rest, in batches. The automation guide's small batch applies. A hardening script aimed at every device on the first day is how a bad prefix becomes a network-wide lockout.

Write the exceptions. A device that cannot do SNMPv3 yet, a device that still needs a local account, a trunk that still allows an old VLAN. Exceptions have expiry dates. An exception without an expiry is the permanent design, and it should be chosen on purpose if so.

Revisit the pass when a device is replaced. New devices arrive with defaults. The migration checklist includes the hardening checklist, or the new device is the soft one. Defaults are not a personality. They are a backlog.

Name the management prefix and the jump host.
Confirm a console or out-of-band path.
Restrict management and remove unused listeners on a lab device.
Send logs off the device and check the clock.
Back up and restore once in the lab.
Do one production device in a window.
Batch the rest.
Give every exception an expiry.

Mistakes that harden you out of the network

Restricting SSH to the wrong prefix with no console.

A shared admin password in a ticket.

Leaving Telnet because the new path was not tested.

SNMP community public.

Logs that exist only on the device.

A backup that has never been restored.

A hardening script aimed at every device on day one.

Calling this page a compliance certificate. It is not.

Hardening checks before a device is called done

Confirm this before you call the change done: Management comes from a named prefix, not from the whole user LAN. A console path was tested the same day the restriction was applied. Logins are named people, or the shared-account exception has an expiry. Break-glass is not the daily account. Telnet and unused web services are off. SNMP follows the monitoring guide and the secret is not in the ticket. The clock is synced and a log line arrived off-box. A backup was restored in a lab. The configuration diff against yesterday has an owner. The first production device was one closet, not the core. Exceptions have expiry dates. New devices inherit this list during migration. This page was not filed as a CIS benchmark or a certification. No exploit notes were required to do any of the checks. The management prefix is smaller than the user LAN. Out-of-band access was tested before SSH was restricted. A lab restore of a backup succeeded. The hardening batch size is one device, then a few, not the whole fleet. Directory login has a tested break-glass account that is not used daily. And yesterday's configuration diff has a person responsible for reading it. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: CIS Benchmarks Overview.