Worldwide Locations
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.
The Interior Gateway Protocols (IGPs) can be protected through authentication and route filter like BGP. The configuration for authentication depends on the protocol and version of code. EIGRP, for instance, using a keychain to configure the key string for the authentication is then applied to the interfaces. The mode of authentication for EIGRP is MD5. (SHA is an option to the other protocols.) RIPv2 also uses a keychain, but the mode of authentication can be clear text or MD5. OSPFv2 can be configured for area level or link level authentication. The password is defined at the link level. OSPFv2 supports clear text or MD5 authentication (later version of code supports using a keychain and SHA). OSPFv3 using IP Security (IPsec) to protect the protocol. Whatever crypto capability is available in the code is available to authenticate and/or encrypt the OSPF packets. IS-IS uses two levels to apply authentication: process level or link level. IS-IS can be configured using clear text or MD5 and has the option to use a keychain or apply the password directly. The process level application then includes all interfaces on which IS-IS is configured, but unlike OSPFv2, the password or keychain is configured under the process. The following are examples of configuring authentication for the IGPs:
EIGRP:
key chain Fred key 1 key-string cisco ! interface fastethernet0/1 ip authentication mode eigrp 35 md5 ip authentication key-chain eigrp 35 Fred
RIPv2:
key chain Fred key 1 key-string cisco ! interface fastethernet0/1 ip rip authentication mode md5 ip rip authentication key-chain Fred
OSPFv2:
interface fastethernet0/1 ip address 10.1.1.1 255.255.255.0 ip ospf message-digest-key 1 md5 cisco ! router ospf 1 network 10.0.0.0 0.255.255.255 area 0 area 0 authentication message-digest ! or interface fastethernet0/1 ip address 10.1.1.1 255.255.255.0 ip ospf message-digest-key 1 md5 cisco ip ospf authentication message-digest
OSPFv3:
interface fastethernet1/0 ipv6 enable ipv6 ospf 1 area 0 ipv6 ospf authentication ipsec spi 500 md5 1234567890ABCDEF1234567890ABCDEF or ipv6 router ospf 1 router-id 10.11.11.1 area 0 authentication ipsec spi 1000 md5 1234567890ABCDEF1234567890ABCDEF
IS-IS:
interface fastethernet1/0 ip router isis isis password cisco or key chain Fred key 1 key-string cisco ! interface fastethernet0/1 ip router isis isis authentication mode md5 isis authentication key-chain Fred or router isis authentication mode md5 authentication key-chain Fred
Data Plane
The data plane forwards data through a network device and does not include traffic sent to the local router or switch. Figure 4 provides examples of what might be found at the data plane.
Figure 4. Data Plane
The data plane for a switch must be protected against bogus Media Access Control (MAC) addresses, rogue devices attaching themselves to the switch and those trying to spoof addressing across the switch. One potential attack is to fill the layer 2 forwarding table with bogus MAC addresses. To help protect the forwarding table from bogus source MAC addresses, use port security, which locks down the ports to a specific number of source MAC addresses that can be seen on a port as well as which address are legal on a given port. If there are too many source MAC addresses or the wrong MAC addresses as sources, port security registers a violation. The default table size for a port that has port security enabled on it is one (one MAC address only), and the default violation is shutdown, which actually puts the port into an errdisabled state.
Other features to protect the switch or switched environment are DHCP snooping (which is configured protect against bogus DHCP servers and builds a binding table of the assignments of IPv4 address to the MAC addresses of the clients); Dynamic ARP Inspection (DAI) (which uses the binding table built by DHCP snooping to protect users from devices trying to falsely respond to an ARP request with their own MAC address or a device trying to take over ownership of an IPv4 address using a gratuitous arp); and IP Source Guard (which uses the binding table from DHCP snooping to compare the source IPv4 address to source MAC addresses to confirm that no other devices are spoofing another’s IPv4 address). Use the ip dhcp snooping and then ip dhcp snooping vlan <number> commands to enable DHCP snooping. The ip arp inspection vlan {vlan_ID | vlan_range} command enables DAI. To enable IP Source Guard, use the ip verify source vlan dhcp-snooping interface level command.
On the routers, we have to be concerned with features like IP options, fragmentations and spoofed addressing. The biggest IP options threat is IP Source Routing. The routers are there to determine the path traffic should take through the network. The Source Routing IP option, if enabled, will allow a source device to direct the forwarding path traffic takes either through different devices, possibly bypassing secure appliances, or toward the wrong destination to possibly cause a denial of service attack. To ensure that IP Source Routing is disabled, use the no ip source-route command.
Another possible attack is to cause a router undue load if the destination address is known to be through a different router on the same ingress interface. The router would then send an IP ICMP redirect to sending device to use a different router. Under attack, the source sends a large number of packets known to be going the wrong direction, which causes the router to send a large number of redirects. To disable ICMP redirects, use the no ip redirects interface level command. IP fragments can be a normal part of the network traffic, and they’re caused by packets that exceed the Maximum Transmission Unit (MTU) of an egress interface. The routers will then fragment the larger packet into sizes that are allowed to transmit assuming that the do not fragment bit is not set in the IPv4 header.
The concern is that some firewalls and routers have issue with fragments since only the first of the fragment would have the original TCP or UDP header information. There is a flag in the first fragment to indicate it is the first. Subsequent fragments would have a replicated IPv4 header but have a fragment offset and flags set to indicate that they are not the first fragment. The target devices then use the fragment offset to reassemble the packet and don’t actually look at the flags. Since the access control lists would typically look at the TCP or UDP header information for permit or deny, they don’t know what to do with the fragments that are not the first.
Most routers will then forward the fragments without looking deeper into the packet structure. Attackers have taken advantage of this behavior and flipped the flag that indicates that the first fragment is, in fact, first. The router then thinks it’s a fragment beyond the first and allows the packet to go through. When that fragment arrives at the target device, it doesn’t look at the flags but at the offset, which would be 0 (zero). The device would then reassemble the packet, which could be carrying something malicious like a virus or Trojan. To stop fragments from being forwarded, you can add to your ACLs:
deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments
Don’t forget to have a permit statement in your ACL, or you’ll disable IPv4 on the interface this is applied to! This will stop any fragments from being forwarded, but this is considered to be more desirable to the alternative.
Routers and switches make up the bulk of network infrastructure and are vulnerable to attack. As you can see, there are a lot of options to help protect our infrastructure from attack. These are but a few of the options available. For more options and details, see http://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html#anc95. Remember, one size does not fit all in networking! Use the options that best meet the needs of your network and know that some protection is better than none.
Learn More
Cisco Routing and Switching Training Options
Johnny Bass has been in the networking industry since the late 1980s. He has specialized in Cisco System products since 1990 and has provided network design, education and technical support expertise in the aerospace, health care, and service provider industries. Holding both CCIE and CCSI credentials, Johnny has a proven record of teaching and consulting on Cisco Routing, Switching, Data Center, Design, Implementation, and Support. During his tenure as a Senior Instructor with Global Knowledge, Johnny has developed extensive experience teaching CCNP-R&S/CCNP-SP/CCNP-Collaboration/CCNP-DC and CCIE R&S courses. This experience has also allowed him to excel in the role of Course Director and Subject Matter Expert with technical responsibility for Global Knowledge North American CCIE R&S curriculum and CCNA and CCNP level courses for Routing & Switching and Service Provider Technical Segment. Johnny is a Cisco 360 R&S Master instructor for the Cisco Expert-Level Training for CCIE Routing and Switching and is the first to achieve this level outside of the organization that created the program. In addition to his teaching engagements, Johnny is the owner and President of Bass Consulting Services, Inc., and lives in Gig Harbor Washington with his wife (Tiffany) and children (Sean and Cayman).
Recommended Courses:
