When implementing Cisco IOS security solutions, you should secure both the management plane and control plane of a device, because operations of the control plane directly affect operations of the management plane. The following protocols are used at management plane:
- Simple Network Management Protocol
- Telnet
- Secure Shell Protocol
- File Transfer Protocol
- Trivial File Transfer Protocol
- Secure Copy Protocol
- TACACS+
- RADIUS
- NetFlow
- Network Time Protocol
- Syslog
When implementing security, it is important to understand that once the management plane is breached using any of the management protocols described above, the control and data plane are also compromised. While delving into detail on all possible management plane protocol troubleshooting scenarios is neither feasible nor within the scope of the TSHOOT certification exam, the following section describes some common problems and how to resolve them.
Telnet and SSH are two commonly used management protocols. Secure Sockets Shell provides a more secure and reliable method for device access and administration than Telnet. SSH secures the sessions using standard cryptographic mechanisms. SSH uses TCP and UDP port 22, although TCP port 22 is the de-facto port listed for SSH. Unlike Telnet, SSH ensures that data is encrypted and is therefore untraceable by network sniffers, for example.
There are two versions of SSH available: SSH version 1 and SSH version 2. While SSH version 1 is an improvement over Telnet, which sends the username and password information in clear text, some fundamental design flaws exist in SSH version 1. For example, there are several tools readily available on the Internet that can decrypt SSHv1 traffic on the fly thus removing most security from encrypting the traffic with SSHv1. Therefore, when implementing SSH, it is highly recommended that SSH version 2 be used. A commonly encountered error message when attempting to remotely access a device via SSH or Telnet is the ‘Password required, but none set‘ connection error.
This error indicates that the virtual terminal lines have not been configured with the password <secret> and login configuration commands. While it is common practice to simply use theline vty 0 4 command to configure the VTY password, keep in mind that certain devices support more than five VTY lines. Use the show line command to verify the number of lines that are supported by the device and then ensure that the password is configured for the correct range of supported lines. The following shows the output of this command on a Switch which supports sixteen (16) VTY lines:
| Switch>show line Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int * 0 CTY – – – – – 0 0 0/0 – 1 VTY – – – – – 0 0 0/0 – 2 VTY – – – – – 0 0 0/0 – 3 VTY – – – – – 0 0 0/0 – 4 VTY – – – – – 0 0 0/0 – 5 VTY – – – – – 0 0 0/0 – 6 VTY – – – – – 0 0 0/0 – 7 VTY – – – – – 0 0 0/0 – 8 VTY – – – – – 0 0 0/0 – 9 VTY – – – – – 0 0 0/0 – 10 VTY – – – – – 0 0 0/0 – 11 VTY – – – – – 0 0 0/0 – 12 VTY – – – – – 0 0 0/0 – 13 VTY – – – – – 0 0 0/0 – 14 VTY – – – – – 0 0 0/0 – 15 VTY – – – – – 0 0 0/0 – 16 VTY – – – – – 0 0 0/0 – |
If you were to use the line vty 0 4 command to configure login and password security for this switch, remote access would only be available via the first five lines. Both Telnet and SSH are allowed by default in Current Cisco IOS software versions as can be validated in the output of the show line command:
| Router#show line vty 0 Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 66 VTY – – – – – 2 0 0/0 -Line 66, Location: “”, Type: “” Length: 24 lines, Width: 80 columns Baud rate (TX/RX) is 9600/9600 Status: Ready, No Exit Banner Capabilities: none Modem state: Ready Group codes: 0 Special Chars: Escape Hold Stop Start Disconnect Activation ^^x none – – none Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch 00:10:00 never none not set Idle Session Disconnect Warning never Login-sequence User Response 00:00:30 Autoselect Initial Wait not set Modem type is unknown. Session limit is not set. Time since activation: never Editing is enabled. History is enabled, history size is 20. DNS resolution in show commands is enabled Full user help is disabled Allowed input transports are lat pad telnet rlogin mop v120 ssh. Allowed output transports are lat pad telnet rlogin mop v120 ssh. Preferred transport is lat. No output characters are padded No special data dispatching characters |
However, while SSH is allowed, unlike Telnet, additional configuration is required to allow a device to be managed via SSH. This additional configuration includes the following:
- Configure a domain name on the router. This is performed via the ip domain-name [name] global configuration command
- Generate the security keys that will be used by SSH using the crypto key generate rsaglobal configuration command and specifying the desired key size; or, alternatively, with the crypto key generate rsa general-keys and specifying the desired key size. Both of these commands automatically enable SSH when executed, and no further configuration is necessary. The key (modulus) size which is used for SSH, can be up to 2048 bits in length. The larger the key size, the more secure the implementation; however, larger keys also take a longer time to generate. When generating a public, Cisco recommends a minimum key size of 1024 bits
- Specify the time that the router waits on the SSH client, in seconds, to input username and password information before disconnecting the session via the ip ssh timeout global configuration command. This is an optional step because, by default, the router will wait for 120 seconds (2 minutes)
- Specify the number of SSH authentication retries before a session is reset via the ip ssh authentication-retries global configuration command. By default, the Cisco IOS router will allow up to three failed logins before resetting the SSH connection. As is the case with theip ssh timeout global configuration command, this is an optional step
If these configuration steps are not implemented, you will not be able to remotely manage the device using SSH. Telnet access, however, requires no additional configuration other than specifying and configuring relevant passwords, e.g. VTY line passwords.
Simple Network Management Protocol (SNMP) which was described earlier in this guide is a commonly used management protocol. SNMPv1 and v2c use a community-based form of authentication while SNMPv3 uses a user and group security model. When troubleshooting SNMP access issues, verify that the correct configuration has been implemented. This entails checking the configured community strings (SNMPv1 and SNMPv2c) or user and group configurations (SNMPv3) using commands such as the show snmp community command:
| R1#show snmp communityCommunity name: tsh00t! Community Index: cisco5 Community SecurityName: tsh00t! storage-type: nonvolatile active access-list: 1Community name: ccnp! Community Index: cisco6 Community SecurityName: ccnp! storage-type: nonvolatile active access-list: 2 |
Additionally, if ACLs have been implemented, so as to restrict SNMP access to the device, as is illustrated above, verify that the IP address of the NMS is included in the valid network range or list of hosts allowed to manage the device by using the show ip access-lists command.
File Transfer Protocol, Trivial File Transfer Protocol, and Secure Copy Protocol are commonly used methods for copying router and switch configuration or image files. While TFTP requires no additional configuration in Cisco IOS software, FTP and SCP both do. When using FTP, a username and password pair is required for access. This is configured using the ip ftp username <name> and ip ftp password <secret> global configuration commands. In addition to configuring a username and password pair, it is also important to ensure that the specified account has the correct privileges on the server.
SCP provides even greater security than the two previously discussed methods, by using SSH for secure transport. This means that SSH must be enabled on the device before SCP can be used. In addition to this, Cisco IOS software also requires that Authentication, Authorization, and Accounting (AAA) must also be configured on the router. Given understanding and troubleshooting AAA are core exam requirements; this service is described in additional detail in the following section.
Understanding Authentication, Authorization, and Accounting
Authentication, Authorization and Accounting, referred to as AAA, and pronounced as ‘Triple-A’, provides the framework that controls and also monitors network access. Authentication is used to validate identity, i.e. who the user is. Authorization is used to determine what that particular user can do, i.e. the services available to the user, and finally, Accounting is used to allow for an audit trail, i.e. what that user did during the period they were logged in.
AAA services can be used to control administrative device access, such as Telnet and Console login, which is referred to as character mode access. In addition, AAA can also be used to manage network access such as via dial-up or Virtual Private Network (VPN) clients, which is referred to as packet mode access. AAA relies on Attribute-Value (AV) pairs. An attribute-value (AV) pair is simply a secured network object. It is comprised of an attribute, such as the username or password, and a value for that particular attribute. Another example of an AV pair would be an attribute, such as a command, with a value of ‘configure terminal’.
The AAA services can be administered by using local username and password databases that are stored on the network devices or a centralized security server, with the latter being the most common. On the local device, the username and password pairs are configured using theusername <name> secret <password> global configuration command. The configuration of the AAA server is a little more complex, but is beyond the scope of the TSHOOT exam and will not be illustrated in this chapter or the remainder of this guide.
AAA allows devices to point to multiple security servers, which are often referred to as server groups. User, device and services information can be replicated between multiple servers, which provide redundancy in large networks. In order for AAA to work, the Network Access Server (NAS), which is any device – such as a router, switch or firewall must be able to access security information for a specific user to provide AAA services.
To reinforce the concept of AV pairs, the following Figure 8-1 is used to illustrate their use in AAA services when the security information is stored locally on the NAS:
Fig. 8-1. Understanding AAA Local Authentication Operation
Referencing Figure 8-1, in step 1, the remote user attempts to connect to R1 (NAS) via Telnet. Assuming that the NAS has been configured for AAA services, using its local database for Authentication, the NAS presents the remote user with the username and password prompt, as illustrated in step 2.
The remote user then enters their credentials, providing the username administrator, which is the ATTRIBUTE and password t5h00t!2010, which is the VALUE for that ATTRIBUTE, as illustrated in step 3. The NAS then checks the information against its local database. Assuming that the NAS has been configured with the username administrator secret t5h00t!2010global configuration command, each AV is on file and the AV pair is found. The request is accepted and a pass message is returned, as illustrated in step 4, which enables the connection from the remote user to be made.
Taking this example a step further, this time depicting the use of an external AAA server, the Figure 8-2 illustrates the use of AV pairs for Authorization, this time using an external server:
Fig. 8-2. Understanding AAA Remote Authorization Operation
In Figure 8-2, assume that the remote user has been successfully authenticated. Once logged into R1 (NAS), the remote user attempts to issue the configure terminal command, as illustrated in step 1. The NAS has been configured to use AAA services for Authorization, and so the request is sent to the AAA server, as illustrated in step 2. The AAA server checks its database for the relevant AV pair.
In step 3, the server finds that the attribute and value are on file, and the AV pair is found. The request is therefore accepted and the configure terminal command is successfully authorized on R1, as illustrated in step 4. The remote user successfully enters configuration mode. Again, the same concept would be applicable if Authorization was being performed using the local database.
NOTE: Of the three AAA services, only Accounting does not require AV pairs. Instead, information is simply received with AV pairs and stored in the database.
When implementing AAA services, two main security protocols are used. These protocols are RADIUS and TACACS+. Both are described in the following sections.
RADIUS
RADIUS stands for Remote Authentication Dial-In User Service. RADIUS is a client/server protocol that is used to secure networks against intruders. RADIUS was created by Livingston Enterprises, but is now defined in RFC 2138 and RFC 2139. The RADUIS protocol Authentication and Accounting services are documented separately in RFC 2865 and RFC 2866, respectively. These two RFCs replace RFC 2138 and RFC 2139.
A RADIUS server is a device that has the RADIUS daemon or application installed. RADIUS is an open-standard protocol that is distributed in C source code format. This allows for interoperability and flexibility between RADIUS-based products from different vendors. RADIUS uses UDP as the Transport layer protocol for communications between the client and the server, using UDP port 1812 for Authentication and Authorization, and UDP port 1813 for Accounting. However, it should be noted that earlier deployments of RADIUS use UDP port 1645 for Authentication and Authorization, and UDP port 1646 for Accounting. Because RADIUS uses UDP as a transport protocol, there is no offer of guaranteed delivery of RADIUS packets. Therefore, any issues related to server availability, the retransmission of packets and timeouts, for example, are handled by the RADIUS-enabled devices.
The RADIUS Accounting function is designed for data to be transmitted at the beginning and at the end of a session. This data can indicate resource utilization, such as bandwidth and time used, and may be used for billing and/or security purposes.
TACACS+
TACACS+ stands for Terminal Access Controller Access Control System Plus. Unlike RADIUS, which is an open-standard protocol, TACACS+ is a Cisco-proprietary protocol that is used in the AAA framework to provide centralized authentication of users who are attempting to gain access to network resources.
There are several notable differences between TACACS+ and RADIUS. One of the most notable differences is that TACACS+ uses TCP as a Transport Layer protocol, using TCP port 49. In addition to this, TACACS+ separates the three AAA architectures, unlike RADIUS which groups Authentication and Authorization together, and separates Accounting. TACACS+ also encrypts the data between the user and the server, unlike RADIUS which encrypts only the password. Finally, TACACS+ supports multiple protocols, such as IP, IPX, AppleTalk and X.25, whereas RADIUS had limited protocol support.
TACACS+ Authentication is initiated when a user attempts an ASCII login by authenticating to a server running the TACACS+ daemon. The TACACS+ Authorization process is performed using two distinct message types, which are the REQUEST and RESPONSE messages. The Authorization process is then performed using a session that consists of this pair of messages.
TACACS+ REQUEST messages are sent by clients and they contain information pertaining to the authenticity of the user or service (Authentication information), as well as a list of the services or options for which Authorization is being requested. When the TACACS+ server receives the REQUEST message, it replies with a RESPONSE message. And finally, TACACS+ Accounting occurs by sending a record to the AAA server. Each send record includes an AV pair that is used for Accounting.
NOTE: Going into detail in the types of messages is beyond the scope of the current TSHOOT certification exam and will not be included in this chapter or the remainder of this guide.
Implementing and Configuring AAA Services
There are three ways in which AAA services can be implemented:
- AAA can be implemented as a self-contained local security database which contains the usernames and passwords required for Authentication
- AAA can be implemented as a Cisco Access Control Server application server. This can be an external server that operates well. Cisco ACS can be installed onto both Windows and Unix-based platforms. This implementation is suitable for medium to large networks. Cisco ACS configuration is beyond the scope of the current TSHOOT exam
- Finally, AAA can also be implemented using the Cisco Secure ACS Solutions Engine appliance. This is a dedicated external platform offered by Cisco that scales very well and is suitable for very large networks. As with ACS configuration, Cisco Secure ACS Solutions Engine appliance is beyond the scope of the current TSHOOT exam
AAA services are based on method lists. Methods lists contain sequenced AAA entries and are configured to define which of the three AAA services will be performed and the sequence in which they will be performed. The method argument refers to the actual method the authentication algorithm tries. Therefore, when a user attempts to authenticate, the NAS contacts each of the entries in sequence to validate the user.
Method lists allow control of one or more security protocols and security servers to be used to offer fault tolerance and backup of authentication databases. The AAA engine will use the first method listed in the method list, and if that is unavailable, fall back to the next method list. However, it is important that this only works if the message received from the first method listed is not a FAIL message of any kind.
In other words, even though multiple methods may be listed, if a FAIL (i.e. deny) message is received from the first method tried, the authentication process stops and no further authentication methods are attempted in the list. In addition to this, it is also important to know that if all entries are processed without receiving a PASS message, access is denied. In AAA implementation, there are two basic types of method lists: named and default method lists.
- A named method list can be configured for any AAA service, such as Authentication or Authorization, for example. These methods are applied to specific interfaces or even terminal lines (e.g. Console and VTY) as required by the administrator
- The default method list is configured globally and applied to all interfaces and terminal lines on the device if no other method list is defined. However, if a defined (named) method list is configured, it will take precedence over the default method list
In order to configure AAA services, the following general sequence of steps should be taken:
- First, globally enable AAA services using the aaa new-model global configuration command. This is a mandatory requirement when configuring AAA
- Next, configure the security protocol parameters, such as the IP address and shared key of the TACACS+ and RADIUS server via the aaa group server [radius|tacacs+] [group_name] global configuration command for TACACS+ or RADIUS server groups. Alternatively, you can configure individual TACACS+ or RADIUS servers by using thetacacs-server host [address|hostname] key [shared_key] or the radius-server host [address|hostname] key [shared_key] global configuration commands, respectively
- Next, define the Authentication service and method list via the aaa authentication global configuration command and then apply the specified Authentication named method list to device interfaces or terminal lines by using the login authentication interface or line configuration commands
- Next, define Authorization method list(s) by using the aaa authorization global configuration command then apply the Authorization method list(s) to device terminal lines via the authorization line configuration command. Authorization can also be enabled for WAN interfaces using protocols such as PPP by using the ppp authorization interface configuration command
- Finally, define the Accounting service and method lists by using the aaa accounting global configuration command and apply the Accounting method list(s) to terminal lines via theaccounting line configuration command. Accounting can also be enabled for WAN interfaces using protocols such as PPP by using the ppp accounting interface configuration command
NOTE: Named (defined) method lists must be configured on the security server; they are simply applied (as configured on the server) to the NAS. You cannot configure method list parameters on directly on the NAS.
While delving into advanced AAA configuration is beyond the scope of the current TSHOOT exam, you are still expected to be familiar with basic AAA configuration. The sections that follow provide some basic common AAA configuration examples, along with the explanations of those configurations.
In the first example, Authentication will be configured on the device for all logins. This will use the default method list. The authentication will be performed using a TACACS+ server with the IP address 10.1.1.254 and a secret or password of t5shoot!2010. The default method list will be used to authenticate remote access to the device via the virtual terminal lines. The configuration is implemented as follows:
| R1(config)#aaa new-model R1(config)#aaa authentication login default group tacacs+ R1(config)#tacacs-server host 10.1.1.254 key t5sh00t!2010 R1(config)#line vty 0 4 R1(config-line)#login authentication default |
Referencing the configuration example above, the aaa new-model configuration command enables the AAA service on the device. Without this command, you cannot enable AAA.
The aaa authentication login default group tacacs+ configuration command specifies that the default method list be used for authentication using a TACACS+ server. It assumes that the default method list is configured and active on the TACACS+ server.
The tacacs-server host 10.1.1.254 key t5sh00t!2010 configuration command specifies the IP address of the TACACS+ server to be used for authentication as well as the password that is used on the server.
And finally, the login authentication default configuration command specifies that VTY authentication will be performed using the default method list, which is stored on the TACACS+ server with the IP address 10.1.1.254. Again, this also assumes that the AAA default method is configured and active on the TACACS+ server.
In the following example, be enabled for the Console and VTY lines using method lists named CONSOLE_AUTH and VTY_AUTH, respectively. The IP address of the RADIUS server is 10.1.1.254. This server will use a secret of t5h00t!2010. This configuration is implemented on the device as follows:
| R1(config)#aaa new-model R1(config)#aaa authentication login CONSOLE_AUTH group radius R1(config)#aaa authentication dot1x VTY_AUTH group radius R1(config)#radius-server host 10.1.1.254 key t5h00t!2010 R1(config)#line con 0 R1(config-line)#login authentication CONSOLE_AUTH R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#login authentication VTY_AUTH R1(config-line)#exit |
The third, and final, example illustrates how to configure login Authentication using the local device database. This will be used to authenticate Console and AUX port access against the locally configured username and password pair:
| R1(config)#aaa new-model R1(config)#aaa authentication login default local R1(config)#username admin secret t5h00t!2010 R1(config)#line con 0 R1(config-line)#login authentication default R1(config-line)#exit R1(config)#line aux 0 R1(config-line)#login authentication default R1(config-line)#exit |
The configuration of both authorization and accounting follows the same logic as that used to configure authentication. In Cisco IOS software, authorization is configured using the aaa authorization global configuration command. This configuration can then be applied to any lines, e.g. VTY and Console, using the authorization line configuration command. In order for authorization to work, authentication must be configured and the AAA client must have successfully authenticated. The options available for authorization in Cisco IOS software are:
| R1(config)#aaa authorization ? auth-proxy For Authentication Proxy Services cache For AAA cache configuration commands For exec (shell) commands. config-commands For configuration mode commands. configuration For downloading configurations from AAA server console For enabling console authorization exec For starting an exec (shell). multicast For downloading Multicast configurations from an AAA server network For network services. (PPP, SLIP, ARAP) reverse-access For reverse access connections template Enable template authorization |
The following configuration example illustrates how to configure AAA authorization on a device against a method list named PRIV_15_ONLY. This configuration is applied to the Console and VTY ports on the device.
| R1(config)#aaa new-model R1(config)#aaa authorization commands 15 PRIV-15-ONLY R1(config)#line con 0 R1(config-line)#authorization commands 15 PRIV-15-ONLY R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#authorization commands 15 PRIV-15-ONLY R1(config-line)#exit |
In the authorization configuration example above, the aaa authorization commands 15 PRIV-15-ONLY configuration command configures authorization for level 15 configuration commands against a method list named PRIV-15-ONLY. This authorization method list is applied to the Console and VTY ports using the line authorization commands 15 PRIV-15-ONLY line configuration command.
And finally, accounting is configured using the Cisco IOS software aaa accounting global configuration command. Accounting is enabled for terminal lines via the accounting line configuration command. As is the case with authentication and authorization, you can use the default method list or specify a named method list when configuring accounting. The configuration example that follows illustrates how to enable accounting to send start and stop records for EXEC sessions using a method list named EXEC-ACNTG:
| R1(config)#aaa accounting exec EXEC-ACNTG start-stop group radius R1(config)#radius-server host 192.168.1.254 auth-port 1812 acct-port 1813 R1(config)#line con 0 R1(config-line)#accounting exec EXEC-ACNTG R1(config-line)#exit R1(config)#line vty 0 4 R1(config-line)#accounting exec EXEC-ACNTG R1(config-line)#exit |
Troubleshooting AAA Services
Unlike other Cisco IOS features, AAA troubleshooting relies primarily on device configuration verification using the show running-config command and debugging using the debug aaa suite of commands. Commonly experienced issues include incorrect username and password configuration on the local device or security server, missing username and password pairs on the local device or security server, and misconfigured authentication lists.
For the most part, you can troubleshoot these issues by verifying the device AAA configuration. However, it is sometimes necessary to debug the AAA implementation in order to identify and isolate the root cause. An example of when you might need to debug is when you do not have access to the AAA server to verify username and password configuration, for example. Another example might be when the password in the configuration is encrypted, i.e. the username <name> secret <password> command has been issued and AAA has been configured to authenticate against the local database, for example.
The following shows the list of supported AAA debugging subcommands in Cisco IOS 12.4:
| R1#debug aaa ? accounting Accounting administrative Administrative api AAA api events attr AAA Attr Manager authentication Authentication authorization Authorization cache Cache activities db AAA DB Manager dead-criteria AAA Dead-Criteria Info id AAA Unique Id ipc AAA IPC mlist-ref-count Method list reference counts per-user Per-user attributes pod AAA POD processing protocol AAA protocol processing server-ref-count Server handle reference counts sg-ref-count Server group handle reference counts sg-server-selection Server Group Server Selection subsys AAA Subsystem |
Following is a sample output of the debug aaa authentication command. The output shows that the default method list is being used for login authentication against the local database for a user named ‘administrator’. The debug output also shows that authentication for enable access is also using the default method list. However, this is being performed by a TACACS+ server and unlike the local authentication, this authentication fails. You can use this information to further troubleshoot issues with the TACACS+ server:
| R1#debug aaa authentication AAA Authentication debugging is on*Mar 23 00:25:03.738: AAA/BIND(0000000A): Bind i/f *Mar 23 00:25:03.738: AAA/AUTHEN/LOGIN (0000000A): Pick method list ‘default’ *Mar 23 00:25:05.974: AAA: parse name=tty66 idb type=-1 tty=-1 *Mar 23 00:25:05.978: AAA: name=tty66 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=66 channel=0 *Mar 23 00:25:05.978: AAA/MEMORY: create_user (0x84BD69A8) user=’administrator’ ruser=’NULL’ ds0=0 port=’tty66′ rem_addr=’10.0.0.2′ authen_type=ASCII service=ENABLE priv=15 initial_task_id=’0′, vrf= (id=0) *Mar 23 00:25:05.978: AAA/AUTHEN/START (3856188155): port=’tty66′ list=’ action=LOGIN service=ENABLE *Mar 23 00:25:05.978: AAA/AUTHEN/START (3856188155): using “default” list *Mar 23 00:25:05.978: AAA/AUTHEN/START (3856188155): Method=tacacs+ (tacacs+) *Mar 23 00:25:05.978: TAC+: send AUTHEN/START packet ver=192 id=-438779141 *Mar 23 00:25:10.982: AAA/AUTHEN(3856188155): Status=ERROR *Mar 23 00:25:10.982: AAA/AUTHEN/START (3856188155): no methods left to try *Mar 23 00:25:10.982: AAA/AUTHEN(3856188155): Status=ERROR |