Securing Cisco Device Management
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Overview
There are many things to consider and implement when building a secure management infrastructure for network devices. At the most basic level, one of the most important issues is how you will access and manage each device, including both console and virtual-terminal access methods. With this plan nailed down, you can begin implementing other common security features:
- Configuring the Simple Network Management Protocol (SNMP) for remote management access via the Internet Protocol (IP) and setting up remote alerting (via traps or informs)
- Configuring a central time-management solution, so that all network devices and their monitoring systems utilize the same clock to correlate events
- Implementing a file-transfer mechanism
This article focuses on these initial management steps, discussing the concepts behind setting up these elements of the management infrastructure and the protocols (and/or protocol versions) that are typically implemented to make the infrastructure as secure as possible.
Device Management: In-Band Versus Out-of-Band
There are two different ways of managing a device:
- In-band: When managing a device in-band, you use the same interfaces and media as normal data traffic.
- Out-of-band: When managing a device out-of-band, you use different traffic paths, including access via the console or auxiliary lines, or by using an interface that has been placed into a different VLAN and thus at least virtually separated from normal data traffic.
Out-of-band methods are the most secure, but they incur additional expense, and how they work depends greatly on the specific implementation. For example, service providers with multiple tenants are likely to implement completely out-of-band methods in order to ensure security, whereas enterprises with only a single tenant might not weigh the use of out-of-band management as highly.
Securing Device Access
There are a number of ways to configure secure device access. The simplest approach includes using a complex password as well as a secured enable password (using secret). This security method can also be configured in much more complex ways, allowing for both centralized and granular control. In most larger implementations (anything over a small business in size), one common technique is to implement an authentication, authorization, and accounting (AAA) solution using either Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Access-Control System Plus (TACACS+). Using either of these protocols offers a number of available solutions, including those directly from Cisco.
Whether the method is simple or complex, the configuration must be designed to take advantage of the selected features. Devices can be configured to utilize these features individually; the particular implementations in a specific environment are the choice of the network designers and management.
Regardless of the method used, it's important to configure the devices to use the most secure protocols supported by the operational teams. Since protocols like SSH, SNMP (version 3), NTP, and SCP are supported on most devices, they should be implemented whenever possible. The following sections discuss each of these basic protocols.
Secure Shell (SSH) Protocol
One of the most obvious security changes over the last decade is the implementation of a more secure method of performing command-line interface (CLI) configuration on Cisco devices. For a long time, Telnet was the protocol of choice because it requires less configuration than SSH, and it's generally easier to get up and working quickly for anyone unfamiliar with SSH. However, the configuration of SSH has been part of the CCNA curriculum for a few iterations now, making it more commonplace to see SSH used in production environments.
Simple Network Management Protocol (SNMP)
SNMP has been around for a long time and is widely used as a method of monitoring and/or managing devices, mainly because its operation is rather straightforward to understand. However, SNMP's older versions are inherently unsecured, relying on a simple community string for authentication. By learning a community string that was accepted by a device as having both read and write privileges, an attacker could alter the configuration or monitor the device.
This situation changed with the introduction of and wide-scale support for SNMP version 3, which provides a much higher level of security than offered by previous iterations. This version also supports the encryption of management traffic transmitted between a central network-management station and a device. The SNMP "users and groups" system granularly controls what is and isn't allowed, as well as controlling the address of the management station.
Network Time Protocol (NTP)
NTP is commonly implemented to ensure that the time on every device in an organization references the same source. Without this type of time synchronization, the devices in a network might have times set slightly off from each other. Even a few seconds' difference makes troubleshooting very challenging, as event correlation between devices is almost impossible. When all of the device clocks are in sync, troubles can be tracked from device to device through the network, making root causes much easier to track down.
NTP uses a clock hierarchy called stratum levels, in which the lower the number, the more accurate the clock. A stratum 0 clock source is not attached to the network, and is considered a reference clock; typically these references are atomic clocks whose accuracy is regulated by either cesium or rubidium. One step away from a stratum 0 clock is a stratum 1 clock source, typically the first network-attached device, which can be referenced directly on the network. One hop away from a stratum 1 source, the time reference becomes a stratum 2 source, two hops away is a stratum 3 source, and so on up to stratum 15. (Stratum 16 is considered invalid, or no longer a good source.)
The problem with NTP is that without adequate configuration it can become a large security risk. For example, what if an attacker gains control of your time reference and alters it to affect the accurate recording of an attack? This is where NTP authentication comes in: To prevent this type of attack, your configuration must ensure that NTP authentication is used on every device, and none of the devices allow their time to be altered by an unauthenticated source.
Secure Copy Protocol (SCP)
For a long time, files were commonly transferred to network devices by using the Trivial File Transfer Protocol (TFTP), which is both unsecured and unreliable. Used on SSH (and using the same keys as SSH when configured on a Cisco device), SCP is reliable and generally works better than TFTP, so there is no reason not to use it. It's easy to add support for SCP on Cisco devices, especially when SSH is already configured on the device.
Summary
This list of methods for securing management on a Cisco device is not exhaustive. Instead, we've focused on the most common methods that should be implemented to ensure the security of your network management. Many of these methods can be implemented without external servers, which makes their implementation much easier. (Though configuring a secure multilayer AAA solution requires an external server.) Using the available solutions discussed here is a good beginning for addressing your network's security concerns.