Overview
In the last chapter, I talked about filtering web content on your appliance. This chapter builds upon the traffic controlling and filtering features that I have so far discussed. In this chapter, I’ll explain how you can authenticate and authorize connections going through your appliance by using a feature called Cut-through Proxy (CTP). CTP adds an additional level of security over ACLs (discussed in Chapter 6). The topics discussed in this chapter include
-
An overview of authentication, authorization, and accounting (AAA)
-
Configuration of AAA servers and protocols
-
Authentication of connections using CTP
-
Authorization of connections using CTP
-
Accounting of connections using CTP
AAA Components
AAA helps you centralize your security checks and is broken into three areas: authentication (who), authorization (what), and accounting (when). Together, all three of these areas are referred to as AAA.
Authentication is responsible for checking a user’s identity to determine if she is allowed access to a networking device. A user must enter a username and password to validate. Once she has gained access to the networking device, authorization determines what the user can do—what commands she can execute and what privilege levels she has access to. For example, you could allow a person Privilege EXEC access to a router, but not allow her access to Configuration mode. And last, you can keep a record of a user’s actions, like what commands she executed and when she executed them, with the accounting function.
AAA Protocols
To implement AAA, you need a secure protocol to transport security information between the networking device and the security (AAA) server. Three security protocols commonly are used to implement AAA:
-
Kerberos
-
Remote Access Dial-In User Service (RADIUS)
-
Terminal Access Controller Access Control System (TACACS+)
Some Cisco networking devices support all three protocols; however, Cisco only supports the last two on its security appliances. The next three sections provide a brief overview of these security protocols.
Kerberos
Kerberos was developed at the Massachusetts Institute of Technology (MIT) and uses DES (40- or 56-bit keys) for encrypting information between the networking device and the security server, referred to as a Key Distribution Center (KDC). Kerberos is an open standard; however, it functions at only the application layer. This means that you need to make changes to the actual application to use Kerberos. On IOS-based routers, Cisco has included Kerberos authentication for telnet, RSH, RLOGIN, and RCP. Cisco doesn’t support Kerberos on the security appliances.
RADIUS
RADIUS was developed by the Livingston Corporation, which is now owned by Lucent. It is currently an open standard, defined in RFCs 2138 and 2139. However, many extensions have been added by various companies for their networking devices, making it a somewhat open standard. RADIUS supports UDP for the connection between the networking device and AAA server; it only encrypts the user’s password used for authentication, nothing else, making it less secure (more susceptible to eavesdropping attacks) than Kerberos or TACACS+. For example, if a user were trying to log into a router, the router would forward the authentication information (user’s access method—console, VTY, or other means—and the username) in clear text, but would encrypt the user’s password. Probably RADIUS’ biggest advantage over the other two security protocols is that, because it was developed for dialup and networks like ISPs, it has a very robust accounting system: keeping track of when a user connected, how long he was connected, and how many bytes were transmitted to and from the user.
Note | RADIUS is most commonly used on the appliances for connections going through it, like CTP and remote access VPNs. RADIUS is actually required for some security features, like 802.1x and LEAP. RADIUS uses one UDP connection for authentication and authorization, and a second connection for accounting. Depending on implementation of RADIUS, the port numbers for authentication/authorization and accounting are either 1645 and 1646, or 1812 and 1813, respectively. |
TACACS+
TACACS was originally developed for the U. S. Defense Department and has been updated over the years by Cisco, resulting in an enhanced version called TACACS+. Because of the many changes Cisco has made to the protocol, TACACS+ is proprietary. Unlike RADIUS, TACACS+ uses TCP (port 49) for the connection to the AAA server and encrypts the entire payload contents in the security packets, making it more reliable and more secure than RADIUS. TACACS+ also supports a single connection feature—the networking device opens a single TCP connection to the AAA server and uses this single connection for all AAA functions. This feature provides faster response times than with RADIUS, because RADIUS uses a separate UDP connection for each AAA request, like each username lookup, or each command executed on the networking device.
Note | TACACS+ is most commonly used on the appliances for controlling administrative access to the appliance itself. Note that you can use both RADIUS and TACACS+ simultaneously on your appliance. For example, you could use TACACS+ to control access to the appliance, but use RADIUS for CTP. Controlling access to the appliance using AAA is discussed in Chapter 26. |
AAA Servers
The security appliances support AAA functionality. Normally, AAA is used to control access to the command-line interface shell of a networking device. The appliances support this function of AAA, but also use AAA for network access through them, allowing users to authenticate to the appliance before their connection or connections are allowed through. Some examples of these AAA appliance features are CTP and remote access VPNs, like IPSec and WebVPN.
AAA Server Configuration
One of the first items you need to configure for AAA is the connection used between your appliance and your security server: TACACS+ and/or RADIUS. Minimally, you’ll need to configure the protocol that is used, the encryption key, and the remote server the appliance is connecting to. The following sections contain an overview of how to configure an AAA server and protocol on your appliance.
Appliance AAA Server Configuration
On your security appliance, the first thing you need to configure is the security protocol or protocols you’ll be using between the appliance and your AAA server(s) and who the server(s) are. Both tasks are configured using the aaa-server command:
ciscoasa(config)# aaa-server group_tag protocol {tacacs+ | radius}
ciscoasa(config)# aaa-server group_tag (logical_if_name)
host AAA_server_IP_address AAA_encryption_key
[timeout value_in_seconds]
ciscoasa(config-aaa-server-host)# server-port port_number
ciscoasa(config-aaa-server-host)# key encryption_key
ciscoasa(config-aaa-server-host)# timeout seconds
The first command specifies which security protocol you’ll use when your appliance accesses the AAA server: TACACS+ or RADIUS. The group_tag parameter is used to group your policy information, because you might have one set of security servers for authenticating command-line access and another set for authenticating CTP. In other words, the group tag determines where to direct AAA traffic (what protocol and server). The group tag is basically a string of characters, and the tag value must be different from other group tags.
Note | Cisco’s AAA server, CSACS, supports both RADIUS and TACACS+. Most other vendors only support RADIUS. |
Next you must specify the AAA server that your appliance will use. You must specify the name of the interface where the security is located; if you omit it, the logical name defaults to inside. Following this is the host parameter and the IP address of the AAA server. The AAA_key parameter specifies the encryption key used to secure the connection between the appliance and the AAA server—this key must also be configured on the AAA server and is case-sensitive. You can configure up to 256 different security servers, where each AAA server has its own configuration command.
When trying to connect to the AAA server, the appliance will wait for a reply for 5 seconds by default. It will try to contact an AAA server up to four times. If the appliance can’t reach the AAA server, it will try the second AAA server that you’ve configured (if you have configured another one); therefore the order of the server statements is important. You can change the timeout value with the optional timeout parameter. The timeout can be increased up to 30 seconds.
When executing the aaa-server command, you are taken into a subcommand mode. Here you can optionally change the port number used for the connection (applicable to RADIUS only). You can also enter the encryption key and timeout values if you omitted this from the aaa-server command.
Here’s an example of defining a protocol and server:
ciscoasa(config)# aaa-server RADIUS_SERVER protocol radius
ciscoasa(config)# aaa-server RADIUS_SERVER (inside) host 10.0.1.11
ciscoasa(config-aaa-server-host)# key cisco123
CSACS Configuration
Once you’ve logged into CSACS, you’ll need to individually add each of your appliances under CSACS’s Network Configuration section.
Note | If your appliance needs to use both TACACS+ and RADIUS to CSACS, you’ll need to add the appliance twice to CSACS, using a different hostname for each instance in CSACS. |
Follow these steps to add your appliance:
-
Click the Network Configuration button on the left side of the window.
-
Under the AAA Clients section, click the Add Entry button.
-
On the Add AAA Client screen, enter the following information:
-
AAA Client Hostname A locally descriptive name of the appliance.
-
AAA Client IP Address The IP address or addresses the appliance will use to initiate connections to CSACS.
-
Shared Secret This is the encryption key to encrypt the passwords for RADIUS or the payload of TACACS packets.
-
Authenticate Using The drop-down selector that lets you choose the AAA protocol, which can be either “TACACS+” or “RADIUS (Cisco VPN 3000/ASA/PIX 7.x+)” for the appliances.
-
All the other parameters are optional.
-
-
On the Add AAA Client window, click either the Submit or Submit+Apply button.
Note | The difference between the Submit and Submit+Apply buttons is that the Submit button saves your change, and Submit+Apply saves and activates your change(s). The problem of activating changes in CSACS is that the CSACS processes must be restarted, causing a small amount of disruption; therefore, it is best to save all your changes and restart the processes once. You can also restart the processes within the System Configuration section. |