Basic Access Control

The Cisco IOS offers a series of mechanisms and protocols that help control the accessibility of devices. These basic access control mechanisms can help you restrict who is accessing your network devices and what they are doing on each device. This important task is needed to ensure the security of your network and to create an audit trail of any changes on the network.

Connecting to a Virtual Terminal Using Telnet and SSH

Common methods of accessing a device running the IOS are via the console port (as discussed in Chapter 2, "The Basics of Device Configuration" ) or via virtual terminal lines (vty). Virtual terminal lines are software that enables you to connect to the router via a data network. An IOS device also supports five simultaneous sessions through virtual terminal lines.

Using a Telnet client or using a Secure Shell (SSH) client are the two most common methods for connecting to a virtual terminal line. A Telnet client uses a standard protocol defined in RFC 854 to provide an unsecure connection to server software running on a virtual terminal line. By default, all IOS devices have a Telnet server enabled on all virtual terminal lines; we discuss securing these lines in the following section, "Enabling the SSA Server."

SSH is a protocol that provides a secure and encrypted connection between an SSH client and server running on a virtual terminal line with functionality that is similar to a Telnet connection. In contrast to the Telnet server, an SSH server is not enabled by default on the virtual terminal lines. Enabling the SSH server is discussed in the next section.

Your system administrator should be able to help use the Telnet client or SSH client on your local system. Also, from an EXEC prompt, an IOS device can be a Telnet client or an SSH client using the telnet or ssh commands.

Note

Currently, two versions of SSH are available: SSH Version 1 and SSH Version 2. At this time, the Cisco IOS supports only SSH Version 1.

SSH clients and servers can provide user authentication using a public key cryptographic system invented by Rivest, Shamir, and Adelman (RSA). RSA user authentication available in SSH clients is not supported in the SSH server for Cisco IOS. The Cisco IOS authenticates users using a user ID and password combination only. The SSH server in the IOS does use RSA to generate the key pair that is used for setting up an encrypted session to the client, as shown in the next section.

SSH secures the connection between the SSH client and server using the DES (56-bit) or Triple DES (168-bit) encryption algorithm. Not all IOS versions support DES or Triple DES, though, and you should use the show version command to see if the version of IOS that you are running supports these encryption algorithms.

Note

Some encryption algorithms (including 56-bit data encryption, among others) are subject to United States government export controls. Using these algorithms ”and the version of the IOS that supports them ”outside the United States requires an export license.

Enabling the SSH Server

To enable the SSH server and allow SSH clients to connect to virtual terminal lines, your IOS device must have a properly configured host name and domain name . You configure these parameters with the global configuration commands hostname and ip domain-name, discussed previously.

To configure the SSH server, you must generate an RSA key pair used to encrypt the session between the client and server. On the IOS device, you generate the RSA key pair using the global configuration command crypto key generate rsa. When you generate an RSA key pair for the IOS device, you automatically enable the SSH server on the virtual terminal lines. To delete an RSA key, you use the crypto key zeroize rsa global configuration command, which automatically disables the SSH server.

Note

The global configuration command crypto key generate rsa will not appear in the output of show running-config or show startup-config.

The global configuration command ip ssh enables the SSH server on all virtual terminal lines:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-1(config)#  crypto key generate rsa  SF-1(config)#  ip ssh  SF-1(config)#^  Z  

Verifying SSH Configuration

You can view the public RSA key used by SSH using the EXEC command show crypto key mypubkey rsa :

 SF-1>  show crypto key mypubkey rsa  % Key pair was generated at: 19:01:46 EDT Aug 7 2000 Key name: SF-1.zipnet.com  Usage: General Purpose Key  Key Data:   305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00C6F6D1 CCBF8B9A   6D3E451F C362DD75 866F084B 04F43C95 0B68BA44 0B8D5B8C 35264CFA 04B8B532   0FF6473C 4768C46F CD820DAF B7CA8C75 4977CF6E 7ED1ACE3 FF020301 0001 % Key pair was generated at: 23:14:52 EDT Aug 29 2000 Key name: SF-1.zipnet.com.server  Usage: Encryption Key  Key Data:   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C5D98C E628790E   17B0BA2B C31C9521 8543AE24 F19E0988 BF2901DC 11D723EF 3512DD29 C28DBC53   8112755C 307AC527 14B955F0 A0DD29AD AE53BA00 4D84657B 4C605E8E 6EBDDB6E   4FB98167 8616F964 E067604A F852A27D 1F9B7AFF 3EC73F5C 75020301 0001 

Furthermore, you can view the active SSH sessions on your IOS device using the show ip ssh command:

 SF-1#  sh ip ssh  Connection      Version     Encryption     State   Username     0            1.5            3DES          6    admin 

Securing the Console Port and Virtual Terminals

At the level of individual IOS devices, you can set up a password for access via the console port using the IOS major command line console 0 and the IOS subcommand password. For the virtual terminal lines, you can add passwords using the major command line vty 0 4 and the password subcommand.

Using the line subcommand access-class, you can specify a list of IP addresses that are capable of connecting to or being reached from terminal lines on an IOS device. You can specify whether an access class is used for inbound or outbound sessions by using the in or out keyword. This subcommand uses an IP access list to qualify IP addresses before any incoming or outgoing sessions are started. You can use the access-class subcommand as a way to permit only the network administrator's workstations to reach the virtual terminal lines on your IOS devices, which is an additional method of securing access to the devices.

In the following example, the SF-1 router is configured with the console and virtual terminal password Zipmein:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-1(config)#  line console 0  SF-1(config)#  password Zipmein  SF-1(config)#  line vty 0 4  SF-1(config)#  password Zipmein  SF-1(config)#^  Z  

The console and virtual terminal passwords are kept in clear text in the running and startup configurations. If you want to encrypt all passwords displayed by any EXEC command (such as show running-config or show startup-config ), you can use the global configuration command service password-encryption. As a result of this command, decrypted versions of the passwords are no longer visible via any EXEC command. Cisco has documented password recovery procedures for each device type, in case you forget your passwords.

An alternative to configuring passwords on a device-by-device basis for access control is to use an access control protocol on the network. These access control protocols perform three functions: authentication, authorization, and accounting, which are known collectively as AAA. Authentication is the process of identifying and verifying a user. Within the Cisco IOS, several methods can be used to authenticate a user, including a combination of a username and password, or the passing of a unique key. Authorization determines what a user can do after being authenticated, such as gaining access to and performing tasks on certain network devices or access hosts . Accounting is the method of recording what a user is doing or has done.

AAA requires two components : a client that functions on a Cisco IOS device, and related access control server software, which typically runs on a network workstation. The Remote Authentication Dial-In User Service (RADIUS) and Terminal Access Controller Access Control System (TACACS+) are two protocols commonly used to provide communication between the AAA client on a Cisco device and access control server software.

Consider a user who uses the Telnet application to connect to a router on which no access control protocol is configured. The user is immediately prompted for the virtual terminal line password, as follows :

 %  telnet singapore  Trying... Password: 

If the user enters the correct password, he or she is granted access to the EXEC mode of the router. This user is not subject to an authentication and authorization process and is free to perform any task (including entering privileged mode, if the password is known). Furthermore, the user who performs this action is not logged. Clearly, such an open policy is unacceptable in almost all networks. One exception may be in a laboratory or test environment in which unaccounted access to a device by many users does not affect network security, configuration, or performance.

If a Cisco IOS device is set up to use an access control protocol, the device prompts the user for a username and password:

 %  telnet singapore  Trying... Username:  allan  Password: 

Using an access control protocol, the Cisco IOS device performs the following tasks:

1. The access control client in the device prompts for the username and password when it receives the inbound Telnet connection request.

2. The access control client queries the user and sends the username and password combination in the authentication request message to the access control server.

3. The access control server authenticates the username and password combination. The combination passes or fails authentication, and the appropriate message is returned to the client. The server may give the client information about its authorization. The server accounts for the transaction.

4. The access control client permits or denies the username and password combination. If permitted, the user gains access to the system and is authorized to perform the actions specified in the authorization information passed by the server.

This sequence of communication between the access control client and the server is shown in Figure 7-1.

Figure 7-1. As an AAA Client, the Cisco IOS Device Exchanges Information with the AAA Server to Perform Access Control

Enabling AAA

To enable all AAA services in the Cisco IOS, you need to use the global configuration command aaa new-model.

You can then enable the AAA client for specific authentication, authorization, and accounting configuration using the following global configuration commands: aaa authentication, aaa authorization, and aaa accounting. Each of the AAA commands is configured using method lists. A method list is a configured list that describes the AAA methods to be attempted, in an ordered sequence, to authenticate a user, authorize an activity, or account for an action. For example, with method lists, you can specify multiple authentication mechanisms in an attempt to authenticate a user in case the initial method fails. An IOS device attempts to use the first method listed to authenticate users; if that method fails to respond, the device tries the next authentication method listed in the method list. This continues until there is successful communication with a listed authentication method, or until all methods defined are used. Method lists for authorization and accounting work in a similar fashion to those described previously for authentication.

Note

An IOS device attempts to use the next method in a method list only if the device cannot communicate with the previous method. For example, if any authentication method responds but fails to authenticate the user, the next authentication method is not used.

Two common AAA protocols are RADIUS and TACACS+, which are described later in this section. With the aaa authentication, aaa authorization, and aaa accounting global configuration commands, you can specify the method to use as RADIUS using the group radius method and as TACACS+ using the group tacacs+ method.

The aaa authentication command specifies authentication protocols in an ordered method list, which the device can attempt to use to verify access. The aaa authorization command enables you to specify whether authorization is done on EXEC commands or at the start of EXEC or network sessions (such as PPP sessions). It also enables you to specify the protocol to use to perform these tasks. The aaa accounting command enables you to specify when accounting messages are sent to the AAA server, such as at the beginning or end of each user session and after each command. This command also specifies the type of accounting that the AAA client performs. You can account for IOS system activity, network-related services (such as PPP and ARAP), and EXEC sessions. You can use both TACACS+ and RADIUS to send accounting information from an AAA client to an AAA server.

In the following example, AAA processes are configured for the Singapore router. AAA authentication is enabled for login sessions by using the aaa authentication login global configuration command. The first authentication protocol in the method list is TACACS+.

If the TACACS+ agent is incapable of contacting the server to perform authentication, the device performs authentication via a second method ”namely, by using the enable secret or enable password global configuration command. This method list is seen in the aaa authentication login command as the option group tacacs+, followed by the option enable.

Tip

We recommend that you do not rely solely on an AAA protocol for authentication of your login sessions on your IOS devices. Having a second authentication method for login sessions ensures that you can always gain access to your device if an AAA server is unavailable.

In configuring the aaa accounting and the aaa authorization commands, we apply the same logic as we did with the aaa authentication commands. You can specify different authorization methods for EXEC sessions and network sessions (such as PPP) using the exec and network options to the aaa authorization global configuration command. The if-authenticated method keyword tells the AAA client to grant authorization if authentication has passed for the session.

Finally, all EXEC sessions are accounted for when they have stopped using the TACACS+ protocol using the aaa accounting global configuration command.

 Singapore#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Singapore(config)#  aaa new-model  Singapore(config)#  aaa authentication login default group tacacs+ enable  Singapore(config)#  aaa authorization exec group tacacs+ if-authenticated  Singapore(config)#  aaa authorization network group radius if-authenticated  Singapore(config)#  aaa accounting exec stop-only group tacacs+  Singapore(config)#^  Z  

In this example, the group tacacs+ option instructs the IOS device to contact the TACACS+ servers defined by the global configuration command tacacs-server host, as discussed later in the section "TACACS+." You can optionally define your own groups of AAA servers with a user-defined name with an AAA server group using the global configuration command aaa server group and the subcommand server. A user-defined AAA server group is useful when you have a group of users who rely on one AAA server and another group of users who rely on another AAA server. These two groups may or may not be using the same AAA protocol (such as RADIUS). Before the invention of AAA server groups, only a single set of AAA servers could be used for each method for all users. A common example of using AAA server groups is authenticating dialup users using one RADIUS server and authenticating network administrators on another RADIUS server.

In the following sections, you can see how to specify the RADIUS and TACACS+ servers to the AAA client.

RADIUS

The RADIUS protocol was originally published by Livingston Enterprises, Inc., as a standard protocol that exchanges AAA information between a RADIUS client and server. RADIUS is an open protocol; a variety of network devices have a RADIUS client. A RADIUS server is a workstation running RADIUS server software from a vendor or organization such as Livingston, Merit, or Microsoft. You can specify the IP address of the RADIUS server with which the IOS client communicates by using the radius-server host global configuration command.

When performing authentication, the RADIUS protocol encrypts the passwords sent between the client and the server. You need to configure a secret string for this password encryption on both your RADIUS server and in the Cisco IOS. To configure this string in the Cisco IOS client, use the radius-server key global configuration command.

The San Jose router is configured on the ZIP network with a RADIUS server and encryption key, as follows:

 San Jose#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. San Jose(config)#  radius-server host 131.108.110.33  San Jose(config)#  radius-server key Radius4Me  San Jose(config)#^  Z  

TACACS+

TACACS+ is an AAA protocol that is conceptually similar to RADIUS. TACACS+ is the third revision of the TACACS protocol. The second revision is called Extended TACACS, or XTACACS. TACACS+ is a Cisco proprietary protocol, and all IOS devices have a native TACACS+ client.

TACACS+ server software is available from a variety of sources, including Cisco (in the CiscoSecure product) and other vendors , on many workstation hardware platforms. You can specify the IP address of the TACACS+ server with which the IOS client communicates by using the tacacs-server host global configuration command.

The TACACS+ protocol encrypts all communication sent between the client and the server. You must configure a secret string for this communication encryption on both your TACACS+ server and in the Cisco IOS. To configure the string in the Cisco IOS client, use the tacacs-server key global configuration command.

The SF-Core-1 router is configured on the ZIP network with a TACACS+ server and encryption key, as follows:

 SF-Core-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)#  tacacs-server host 131.108.110.33  SF-Core-1(config)#  tacacs-server key ZIPSecure  SF-Core-1(config)#^  Z  

RADIUS and TACACS+ Compared

The differences between RADIUS and TACACS+ are numerous , but their functionality is essentially the same. RADIUS, which is a standard, uses the UDP transport layer. TACACS+, which is proprietary, uses the TCP transport layer. RADIUS works well in IP-only environments, while TACACS+ is useful in multiprotocol environments. RADIUS currently supports more attributes in the protocol and allows the client and server to pass more information than TACACS+. RADIUS encrypts only the password sent between the client and server, while TACACS+ encrypts all communication.

Many vendors that support one protocol or the other vehemently argue the merits of the AAA protocol that they support. Cisco supports both protocols. If your network is largely heterogeneous, RADIUS is perhaps the right AAA protocol to use because many vendors currently support it. If your network mainly uses Cisco devices, TACACS+ is most likely the correct solution.