Any function related to management of a device resides in the management plane. The primary means of managing Cisco routers and switches are the console and the vty. Both of these provide access to the command-line interface (CLI). In most cases, even when a GUI interface for management is available, it uses the CLI to issue commands to the device. Apart from direct access to the CLI, SNMP can be used for information gathering and change configuration.
Other noteworthy functions that reside in this plane relate to logging and time management. In this section, we discuss security of the CLI and SNMP. Before we discuss the specific topics, some of the general security practices associated with the management plane should be understood:
- Zero trust and minimum required access: Network devices are the backbone of your information technology infrastructure and should have very strict and restrictive access control applied. Few selected and trained individuals should have access to network devices, and their activities on devices should be authorized and logged. Centralized access control using an authentication, authorization, and accounting (AAA) server along with command authorization are highly recommended. This blog briefly discusses AAA.
- Central monitoring and log collection: Logs from network devices provide important event and performance data. They should be collected, analyzed, and correlated in a central location for preventive measures as well as incidence response. Similarly, monitoring the network devices using SNMP provides a constant view of the network security and performance while reducing the need for logging in to the device directly.
- Secure communication: Multiple protocols can be used to access network devices for management. The devices should be configured to use only secure protocols. For example, SSH, HTTPS, and SFTP provide encrypted transfer, whereas Telnet, HTTP, and FTP do not. Similarly, SNMP Version 3 (SNMPv3) should be used instead of earlier versions to provide secure and authenticated access.
- Central configuration management: Using centralized configuration management provides change versioning and archiving while also keeping your policies consistent across the network.
- Disabling unnecessary services: Routers and switches contain many services that listen for packets. Services that are not required on your network should be disabled to prevent the chance that they will be used to launch an attack on the device. Special attention should be paid to what Cisco calls small servers. These are disabled by default but can be enabled by using the service tcp-small-servers and service udp-small-servers commands.
Securing the Command Line
The Cisco IOS CLI is divided into 16 privilege levels, each of which defines what commands are available to a user. The privilege levels are divided into four categories:
- Privilege level 0: Includes the disable, enable, exit, help, and logout commands.
- User EXEC mode: Also called privilege level 1. By default, users log in to this mode, and it is denoted by a greater-than sign (
>) at the end of the prompt. Commands available in this level cannot affect the device configuration. - Privileged EXEC mode: Also called privilege level 15. This level can be entered by using the
enablecommand in the user EXEC mode and is denoted by the hash sign (#) at the end of the prompt. All commands are available at this level. - Custom privileged modes: Whereas level 1 provides no access to configuration, level 15 provides full access to it. In some cases, neither of these levels can fulfill the requirements of access control policies. To provide tailored access control, IOS has privilege levels 2 to 14. By default, these levels do not provide any more access than level 1 but can be configured to provide access to required commands.
Each of these privilege levels can be protected by passwords. The first level is protected by the passwords configured in the terminal lines. Different devices have different numbers of lines that can be ascertained with the show line command. Typically, Cisco switches and routers have 1 console line and 16 vty lines. You can configure a password to protect the lines by using the password command on the terminal lines as shown in Example 1.
Example 1 Configuring Passwords on Terminal Lines
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#line vty 0 15
R1(config-line)#password L3tm31n!
R1(config-line)#exit
R1(config)#line console 0
R1(config-line)#password L3tm31n!
R1(config-line)#In addition to the password, the vty lines should be configured to use SSH instead of Telnet to allow for encrypted communication with the device. Before SSH can be enabled on the vty lines, an SSH key must be generated on the device, as shown in Example 2.
Example 2 Generating an SSH Key
R1(config)#ip domain-name cisco.com
R1(config)#crypto key generate rsa modulus 2048After the SSH key is generated, the vty lines can be configured to use SSH only. To do this, use the transport input command, as shown in Example 3.
Example 3 Changing the Transport Protocols on vty Lines
R1(config)#line vty 0 15
R1(config-line)#transport input ssh
R1(config-line)#exitvty lines can be further secured by applying an access list such that SSH sessions are accepted only from certain IP addresses or ranges. This requires an access list that contains the allowed IP addresses. That access list can be applied to vty lines using the access-class command, as shown in Example 4.
Example 4 Using an ACL to Restrict Access to vty Lines
R1(config)#access-list 1 permit host 192.168.1.10
R1(config)#access-list 1 permit host 192.168.1.15
R1(config)#line vty 0 15
R1(config-line)#access-class 1 in- autocommand: This command is used to configure the lines to execute a specific command when a remote access session is established and authenticated. The session disconnects after execution is completed. The command to be executed is specified as the argument in this case. In Example 5, the lines are configured to execute
show running-configas soon as the SSH session is established. The SSH session is disconnected after the configuration is displayed.
Example 2-5 Executing a Command on Session Establishment
R1(config)#line vty 0 15
R1(config-line)#privilege level 15
R1(config-line)#autocommand show running-config- exec-timeout: This command configures the duration, in minutes, for which an idle session will be kept alive. It is important to configure a short duration to safeguard against unauthorized access as well as to prevent all vty lines from being used up by idle sessions. Example 6 shows how this is configured.
Example 6 Configuring the Idle Timeout
R1(config)#line vty 0 15
R1(config-line)#exec-timeout 5- privilege level: This command configures the default privilege level that the user lands into after an access session is established on the terminal lines. By default, a user starts at privilege level 1, but that can be changed to any level, including 15. In Example 7, the default privilege level for the console line is configured to be 15. After this, when a user connects to the console and authenticates successfully, she starts in privilege level 15 instead of 1.
Example 7 Configuring the Default Privilege Level
R1(config)#line con 0
R1(config-line)#privilege level 15Privilege Levels
After successful authentication using the line password, a user enters privilege level 1 by default. If the user needs to access a higher level, he needs to use the enable [level] command and enter the enable password associated with that level. This password is configured using the enable secret [level] command. If a level is not specified with either of the commands, level 15 is assumed. Example 8 shows how the secrets for different levels are configured. The first example does not specify a level; hence, it is assumed to be for level 15. Example 9 shows how the enable command is used to enter different levels. Note the use of the show privilege command to show the level that the user is in and the disable [level] command to go back to a previous level. The default level for the disable command is 1.
Example 8 Configuring enable secret
R1(config)#enable secret cisco123!
R1(config)#enable secret level 5 l3v3l5!
R1(config)#enable secret level 10 l3v3l10!Example 9 Changing IOS Levels
R1>enable
Password:
R1#show privilege
Current privilege level is 15
R1#disable
R1>show privilege
Current privilege level is 1
R1>enable 5
Password:
R1#show privilege
Current privilege level is 5
R1#disable
R1>enable
Password:
R1#show privilege
Current privilege level is 15
R1#disable 10
R1#show privilege
Current privilege level is 10All custom levels from 2 to 14 are no different from level 1 to start with. All configuration commands and most verification commands have a default level of 15. To populate the custom levels, you need to reduce the level of required commands from 15 to the desired level. This can be done with the privilege command, which has the following syntax:
privilege mode level level command-stringThe mode string denotes the mode in which the command is available—such as configuration, interface, or exec. IOS has hundreds of modes. Usually the name of the mode is reflected in the command used to enter that mode.
The level string denotes the new level of the command. This is the custom level in which you want the command to be available.
The command-string option specifies the actual command that is subject to privilege level change.
As an example, if you want the show running-config command to be available at level 5, you need to reduce the privilege level of that command to 5, as shown in Example 10.
Example 10 Changing Privilege Levels of Commands
R1#show privilege
Current privilege level is 5
R1#show run?
% Unrecognized command
R1#enable
Password:
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#privilege exec level 5 show running-config
R1(config)#exit
R1#disable 5
R1#show privilege
Current privilege level is 5
R1#show running-config
Building configuration…sing custom privilege levels is an easy way to provide differentiated access based on job roles. This is particularly useful in allowing help-desk members to perform basic maintenance functions on a network device while preventing them from making changes to the overall configuration of the device. Example 2-11 shows how privilege level 10 is given the ability to shut down an interface or bring one up without allowing users in that level to make any other changes. Note the use of the mode names—exec, configure, and interface—with the privilege command. The mode name denotes the mode in which the subject command is available.
Example 11 Changing Privilege Levels of Configuration Commands
R1#show privilege
Current privilege level is 10
R1#configure terminal
^
% Invalid input detected at ‘^’ marker.
R1#enable
Password:
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#privilege exec level 10 configure terminal
R1(config)#privilege configure level 10 interface
R1(config)#privilege interface level 10 shutdown
R1(config)#exit
R1#disable 10
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface Gi0/1
R1(config-if)#shut?
shutdownWhile using local passwords and privilege levels on the device provides the required security, it can be cumbersome to manage these on each device, and inconsistent configuration across the network is very likely. To simplify device configuration and maintain consistency, it is recommended that you use an AAA server such as Cisco Identity Services Engine (ISE). The network devices can use the Terminal Access Controller Access Control System Plus (TACACS+) protocol to authenticate users and authorize commands. Since the authorization configuration is centralized on the AAA server, policies are applied consistently across all network devices.
Management Plane Protection
Earlier in this blog, we discussed the use of an access list to limit the source addresses from which remote access sessions are accepted on vty lines. While the ACL limits the source addresses, recommended best practice is to limit remote management sessions to specific trusted interfaces only.
The Management Plane Protection (MPP) feature can be used to limit remote management sessions to specific trusted interfaces only. This is very useful when a router connects a trusted network to an untrusted network such as the Internet. MPP applies to all management protocols, such as SSH, HTTPS, and SNMP. This feature is configured using the management-interface command in the control pane. This command can be repeated to enable the same or a different set of protocols on other interfaces. One key restriction of this feature is that it cannot be applied to an out-of-band management interface (also called a dedicated management interface), if the device has one. Example 12 shows the usage of this command.
Example 12 Management Plane Protection
R1(config)#control-plane host
R1(config-cp-host)#management-interface Gi0/0 allow ssh snmp httpsCPU and Memory Thresholding
When a network device is under a denial-of-service (DoS) attack, its resources such as CPU and memory start to deplete quickly. Hence, it is important to monitor the resources on your network devices. While regular polling of devices using SNMP helps, configuring a device to send an SNMP trap when certain CPU and memory utilization thresholds have been reached is better. The CPU and Memory Threshold notification features provide this functionality.
The CPU Thresholding Notification feature can alert when CPU utilization exceeds a configured level and when the utilization drops below a configured level. The former is called a rising notification, and the latter is called a falling notification.
The syntax for the command to enable CPU thresholding notification is as follows:
process cpu threshold type {total|process|interrupt} rising percentage interval seconds [falling percentage interval seconds]
In addition to this command, SNMP traps for CPU threshold must be enabled. Example 13 shows the configuration required to enable CPU thresholding notification.
Example 13 CPU Thresholding Notification
R1(config)#snmp-server enable traps cpu threshold
R1(config)#snmp-server host 192.168.1.25 traps version 3 priv vuser cpu
R1(config)#process cpu threshold type process rising 85 interval 6Similarly, memory thresholding notification can be configured to provide notification when available free memory drops below a certain level and when it rises higher than 5% of that level. In addition, you can configure the device to reserve some memory to send out critical notifications.
This is the syntax for the command to configure the notification:
memory free low-watermark {IO|processor} threshold
This is the syntax for the command to configure memory reservation:
memory reserve critical memory
In these commands, threshold and memory are specified in kilobytes. Example 14 shows the configuration required to enable memory threshold notification and critical memory reservation.
Example 14 Memory Threshold Notification
R1(config)#memory free low-watermark processor 25000
R1(config)#memory reserve critical 5000
Securing SNMP
SNMP is incredibly useful for monitoring network devices. It can also be used to make changes to devices remotely. This also brings with it risk of misuse and opens up an attack avenue. Hence, it is important to secure SNMP access on your network devices. There are multiple ways to do that, as discussed in the following sections, and Cisco recommends using all these methods together.
SNMP Authentication and Encryption
Three versions of SNMP can be configured on Cisco routers and switches: Versions 1, 2c, and 3. Versions 1 and 2c use simple community strings to provide read-only or read-write access. Community strings can be equated to passwords and are stored in the configuration in plaintext. Communications between the SNMP servers and clients are in plaintext and are prone to snooping.
On the other hand, SNMPv3 allows using usernames and a hash message authentication code (HMAC), and it can encrypt the traffic. SNMPv3 user details are not shown in configuration. SNMPv3 has three levels of operations:
- noAuthNoPriv: Uses username for authentication with no HMAC or encryption. Very similar to how Version 1 and Version 2c work.
- authNoPriv: Uses username with MD5 or SHA HMAC for authentication.
- authPriv: Uses username with HMAC for authentication and provides encryption based on DES, 3DES, or AES.
Given the security benefits, SNMPv3 should be preferred over older versions. Where SNMPv3 is not available, the community strings should be changed from the defaults. One of the most common SNMP strings is “public,” and that is typically the first string used by an attacker.
Table 1 lists the differences between the various versions of SNMP.
Table 1 SNMP Versions and Their Security
SNMP Version and Level | Security | Credentials Visible in Configuration? |
1 | Community string | Yes |
2c | Community string | Yes |
3 (noAuthNoPriv) | Username | Yes |
3 (authNoPriv) | HMAC | No |
3 (authPriv) | HMAC with encryption | No |
When configuring SNMPv3, users are tied to groups and SNMP traps. All SNMP server and trap configuration is then tied to the user. The commands to create groups and users are shown here:
snmp-server group group-name v3 {auth|noauth|priv}snmp-server user username group-name v3 auth {md5|sha} password [priv {3des|aes 128|aes 192|aes 256|des} encryption-key]
Example 15 shows how SNMPv3 groups and users are created and then applied to host configuration.
Example 2-15 SNMPv3 Configuration
R1(config)#snmp-server group snmpl33t v3 priv
R1(config)#snmp-server user l33t snmpl33t v3 auth sha gu3$$myPa$$ priv aes 256 encrypt
R1(config)#snmp-server host 192.168.1.25 traps version 3 priv 128SNMP with Access Lists
While authentication and encryption provide a high degree of security, SNMP access should be further restricted with an access list. Access lists can be applied to an SNMP group to limit the source address from which an SNMP read or write request will be received.
To apply an access list to a group, the previously discussed snmp-server group command is extended as shown here:
snmp-server group group-name v3 {auth|noauth|priv} access access-list
Example 16 shows how an access list is added to an SNMP group to allow SNMP queries from a known network management server only.
Example 16 Adding an Access List to an SNMP Group
R1(config)#access-list 1 permit 192.168.1.25
R1(config)#snmp-server group snmpl33t v3 priv access 1SNMP Views
The SNMP server on Cisco devices allows access to the whole MIB tree by default. Using authentication, encryption, and IP-based access restriction provides good security, but it can be further enhanced by restricting the MIBs that can be accessed. SNMP views provide the ability to define what MIBs an SNMP group has access to. A view is a list of MIBs that are included or excluded. The following command creates a view:
snmp-server view view-name mib-name-or-oid {included|excluded}
After a view is created, you can apply it to the SNMP group by extending the previously discussed snmp-server group command as shown here:
snmp-server group group-name v3 {auth|noauth|priv} [read view-name][write view-name] [access access-list]
Example 17 shows how to configure a view and apply it to an SNMP group with an access list.
Example 17 Adding a View to an SNMP Group
R1(config)#access-list 1 permit 192.168.1.25
R1(config)#snmp-server view limited system included
R1(config)#snmp-server group snmpl33t v3 priv read limited write limited access 1
