Hardening edge routers and firewalls: a practical checklist

Edge routers and firewalls sit between your network and everyone else, so a weak default or a forgotten service there has an outsized effect. This checklist covers the areas worth reviewing on every edge device, from management access to BGP session protection and configuration backups.

Lock down management access

Most compromises of network devices start with management access that is more exposed than it needs to be. Treat management as its own network with its own rules.

The management plane

• Put management interfaces in a dedicated out-of-band network or management VRF, never reachable from the internet.
• Use SSH version 2 only; disable Telnet, plain HTTP and any web interface you do not use.
• Apply access lists to VTY lines, SNMP and APIs, permitting only management subnets and jump hosts.
• Use SNMPv3 with authentication and encryption, or restrict older SNMP versions to read-only access from named collectors.
• Disable what you do not need: discovery protocols on external interfaces, IP source routing, proxy ARP and directed broadcasts.
• Synchronise time with several NTP sources, authenticated where supported. Every log you read later depends on accurate timestamps.
• Keep firmware on a supported release and track vendor security advisories for each platform.

Authentication, authorisation and accounting

Shared local accounts make it impossible to tell who changed what. Move to central AAA with personal accounts.

• Authenticate administrators through TACACS+ or RADIUS backed by your identity system, with multi-factor authentication where possible.
• Define roles: read-only for monitoring and junior staff, full privileges only where needed.
• Enable command authorisation and accounting so every configuration command is logged against a user.
• Keep one local break-glass account per device, with a long unique password held in a vault, for use when AAA servers are unreachable. Alert whenever it is used.
• Remove accounts promptly when staff or contractors leave.

Protect the control plane

The route processor has limited capacity. Control-plane policing (CoPP), or an equivalent filter protecting the device itself, stops a flood of traffic aimed at the router from starving routing protocols or locking out administrators.

• Classify traffic destined to the device: routing protocols, management, monitoring, ICMP and everything else.
• Permit BGP only from configured neighbour addresses, and OSPF or IS-IS only on interfaces where they run.
• Rate-limit ICMP and other permitted classes, and police the default class hard.
• Use TTL security (GTSM, RFC 5082) on directly connected eBGP sessions where both sides support it.
• Watch drop counters per class, so you notice when a limit is too tight before it causes a session to drop.

Secure every BGP session

A BGP misconfiguration at your end or a neighbour’s can affect far more than your own network. RFC 7454 is a good reference for BGP operations and security; the essentials are below.

• Session authentication: configure TCP MD5 (RFC 2385) or, where both ends support it, TCP-AO (RFC 5925). Agree key rotation with each peer and store keys in your vault.
• Max-prefix limits: set a limit on every eBGP session, based on what the peer should send plus headroom, with a warning threshold below it. Decide whether the session restarts automatically or waits for an engineer.
• Inbound filters: reject bogons, your own prefixes, default routes unless requested, and prefixes more specific than /24 for IPv4 or /48 for IPv6. Filter customers strictly against prefix lists built from IRR data and their registered resources.
• Route origin validation: validate routes against RPKI and drop invalids. Monitor your validators so a failure does not go unnoticed.
• Outbound filters: announce only your own prefixes and those of your customers. On platforms that do not deny eBGP routes by default when no policy is set (see RFC 8212), add an explicit deny.
• Source address validation: apply uRPF or equivalent filters on customer-facing interfaces, in line with BCP 38.

Keep firewall rules clean

On a firewall, the rule base itself is the attack surface. Start from default deny in both directions and make every permit traceable to a service and an owner.

• Remove any-to-any rules and broad ranges left over from troubleshooting.
• Give IPv6 equivalent policy. A firewall that filters IPv4 carefully but passes IPv6 freely is a common gap.
• Record a ticket reference and review date in each rule’s comment.
• Log denied traffic at the edge and permitted traffic into sensitive zones.
• Review the rule base at least once a year and remove rules with no hits that nobody can justify.

Logging and configuration backups

Logs and backups are what let you investigate an incident and recover from one.

• Send syslog to at least one central collector, with timestamps that include the time zone, and retain it for a period that fits your obligations.
• Alert on repeated login failures, configuration changes outside change windows, BGP session resets and break-glass logins.
• Back up configurations automatically after every change and on a schedule, with a tool such as Oxidized or RANCID, and keep them in version control so changes can be compared.
• Treat backups as sensitive: they contain keys and password hashes, so encrypt them and restrict access.
• Restore a backup onto spare hardware or a lab image from time to time, to confirm it is complete.

How TACS can help

TACS can review your edge configuration against this checklist as part of our Development & security reviews, and keep it maintained through Infrastructure management. For routing changes involving your own address space, our LIR services team can align route objects and ROAs with what you announce.