How to Secure Cisco Routers and Switches

Routers and switches make up the bulk of network infrastructure and are vulnerable to attack. We hear about mass Denial of Service (DOS) attacks or Distributed Denial of Service (DDOS), but the network itself is as big a risk because if it is taken out, there is no path for the data to flow. Although network infrastructure is vital, we also need to protect the networking devices themselves from attack; this protection is known as hardening. Firewalls will help along with Intrusion Prevention Systems (IPS), but there are additional steps we can take to harden the routers and switches within our network.

The National Security Agency (NSA) has guidelines for hardening devices for use with the U.S. federal government. Those guidelines are a bit extreme, but we can use it as a foundation and pick and choose the parts that make sense with an enterprise network. Risks to a network are not limited to those attempting malicious activity; the people working on networks pose an inherent risk as well. There needs to be policy for change control and security; more importantly, they need to be followed, but that’s something for another article.

Today, I want to focus on the routers and switches themselves. There are three main functions within networking devices that need to be protected: the management plane, the control plane, and the data plane as seen in Figure 1. Let’s take a look at a few options to secure them.

Figure 1. Management, Control and Data Planes

Management Plane

The management plane manages traffic sent to the router or switch itself and is made up of applications and protocols for the function of managing the devices. As illustrated in Figure 2, some of those application or protocols are telnet, Secure Shell (SSH), Simple Network Management Protocol (SNMP), Trivial File Transfer Protocol (TFTP), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP) and HTTP Secure (HTTPS).

Figure 2. Management Plane

Since the management plane is used to access and control the networking device, it is a prime candidate for attack. User access and control is key to hardening the management plane although there are other features, protocols and applications that could be fortified as well.

Using some method to authenticate and authorize a user is a must. Password control, for example, is a minimum requirement. Setting policy for frequency of password changes and complex passwords (minimum length, use of mixed characters, numbers and special characters) is recommended while managing passwords through an access control server using TACACS+, Radius or LDAP is highly recommended. There would still need to be local authentication for at least the console access if reachability to the servers is disrupted. Remote access should not have a local option for authentication.

Authorization can also be configured through an access control server detailing what the authorized user is allowed to do on the router or switch. Local privilege level password (also known as the “enable” password) should be configured with the enable secret command rather than the enable password command. The enable secret uses a Message Digest 5 (MD5) hashing algorithm to encrypt the password in the configuration; the enable password does not. If the service password encryption command is used, the enable password and the line level password will be encrypted but with a much more simplistic method. Configuring a local username/password database for local authentication should use the Enhanced Password Security feature, which is using the username <name> secret<password> rather than username <name> password <password> option.

Using the Login Password Retry Lockout feature is also recommended. This allows you to lock out a local user account after a specific number of failed attempts to log into the system. Use the aaa local authentication attempts max-fail <max-attempts> command to enable this feature. Note that users that are configured for level 15 privilege are not affected by this feature.

Remote access should use the more secure option for remote access: SSHv2 over Telnet; SCP (Secure Copy Protocol) over FTP or TFTP; HTTPS over HTTP. The foundational security for each is based on the configuration for SSHv2. A hostname has to be configured as well as a domain name. Use the hostname and ip domain-name commands to configure these options. Note that the domain name does not have to be a real domain but instead needs to be in the format of a domain name. Then you need to generate a key; the minimum key size for SSHv2 is 768 bits, but bigger is stronger. Use the crypto key generate rsa command to generate the key, and once the key has been generated, enable SSHv2 with the ssh version 2 command. The line level access (for remote access) should be configured for only SSH, but the default supports all access methods. Go to the lines using line vty 0 4 or higher depending on the version and type of platform (most IOS switches support 16 virtual terminal lines, so that would be line vty 0 15). Then modify the allowed remote access application to be SSH using the transport input ssh command. Secure Copy (SCP) is also now available for file transfer, which is based on SSH and therefore more secure. To enable the HTTPS server, use the ip http secure-server command, confirm that no ip http server is configured to disable the non-secure version.

SNMP is another method of remote access; it can be used to pull or push information to or from the networking devices. You need to secure SNMP as well. By default, SNMP is disabled, but it is highly used for management of network devices. SNMPv3 provides secure access to devices because it authenticates and optionally encrypts packets over the network.

Use Access Control Lists (ACLs) to limit who can access the device remotely. ACLs can be applied to the VTYs, HTTPS server and SNMP configurations to limit who is allowed to access through those remote methods.

Control Plane

The control plane of network devices process traffic that is adding to the functionality of the network infrastructure. The control plane consists of applications and protocols between network devices including Spanning Tree Protocol (STP) (for layer 2) and the Border Gateway Protocol (BGP), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), Intermediate System to Intermediate System (IS-IS) and Open Shortest Path First (OSPF) for layer three. This is illustrated in Figure 3.

Figure 3. Control Plane

There are other control plane protocols or applications that could be secured. In general, anything going to or from the router or switching that makes networking work is probably related to the control plane.

Control Plan Policing (CoPP) allows us to control those applications and others that are potentially disruptive to the control plane. (Even the lowly echo can be disruptive if there are too many being sent to the router or switch.) We use Modular QoS Command Line Interface (MQC) to configure a policy that would police traffic destined to the router or switch itself. Use the class maps to define the different types of traffic heading to the router or switch; next, in the policy map, define policers to limit how much can be sent and apply to the control plane under the global control-plane command to get to the control plane sub-configuration mode. Finally, apply the service policy to the control at that point.

The main functions of a layer 2 switch are to build a layer 2 forwarding table and forward traffic based on that table and loop prevention. Once the forwarding table is built, it’s used in the data plane. Let’s look at our loop prevention: Spanning Tree Protocol (STP). To help protect the STP, you can use spanning-tree guard root interface level command to protect against other switches trying to take over as the root of the topology. If a port never has a switch connected to it, you can use the spanning-tree bpduguard enable command.

Since the routing protocols are the bread and butter of a router’s control plane, securing them is a must. Border Gateway Protocol (BGP) is a robust, complex routing protocol that can scale to large numbers and has to be to make the Internet work. It is the routing protocol that makes it possible to have the number of networks attached to the Internet that we do today. However, that also means it is a main target for disruption or redirection to an unintended target. Some of the security features available for BGP are authentication, Time to Live (TTL) security, maximum prefix received and route filtering. BGP authentication is based on MD5, but depending on version of code, Secure Hash Algorithm (SHA) could be used. The authentication method used will be dependent on what is available to the peers that BGP is neighboring up to. (SHA for different routing protocols will be covered in another article.) To configure MD5, simply use a neighbor statement with the keyword password followed by the password. (Example: neighbor 192.168.5.1 password cisco.)

TTL security was introduced to pick up on spoofed updates. Normally, BGP will accept an update from its neighbor as long as it’s coming from the correct IP address. The router doesn’t look to see what the TTL value is. If the neighbor is an external peer (eBGP), the TTL is typically 1 (but could be more). If the neighbor is an internal peer (iBGP), the TTL could be anything from 255 to 1. With TTL security, the TTL has to be predictable. When enabled, the TTL for BGP will be set to 255 (eBGP defaults to 1), and it’s necessary to identify how many hops away the neighbor is. If the neighbor is directly connected, then the hop count is 1. If there are others between the peers, then you have to count the number of hops. The router will then check the TTL on receipt, and if the TTL is between 255 and 225 minus the hop count, then the packet is acceptable. If the TTL is less than the predicted minimum, then the packet is dropped. Use the neighbor <ip-address> ttl-security hops <hop-count> command to configure TTL security.

The maximum prefixes received will protect the router from being overwhelmed by too many routers being advertised to it from a given neighbor. It’s critical to estimate the number of prefixes a router will receive. Typically, we use a multiple of that value to allow for growth, and most service providers will double the value of the number of prefixes. Use the neighbor <ip-address> maximum-prefix <warning-threshold-percentage> command to configure the maximum prefixes a neighbor can send.

Route filtering with BGP has the most options compared to other routing protocols. You can filter based on the prefixes themselves using a prefix list or an access list (IPv4 only) or filter based on the AS path, standard or extended community strings or combine them together (and more) in a route map applied against the neighbor.