AP is part of the Cisco IOS Firewall feature set and thus requires you to purchase the appropriate Cisco IOS software to access this feature. If you do not have the budget for the Cisco IOS Firewall feature set, you are limited to using lock-and-key for user authentication of connections traveling through the router.
AP enables you to define per-user security access policies that are activated when a user authenticates to the router. For example, you might want to deny all kinds of inbound traffic into your network but open temporary holes in your perimeter router/firewall for specific users. Of course, in many instances, you might not know from what devices these users will be initiating their inbound connections.
AP can deal with this by having the Cisco IOS authenticate users and, based on their authentication, open temporary holes in your router's ACL configuration to allow users to access allowed resources. Unlike with lock-and-key, you can control this access on a per-group or per-user basis. For example, you might have two sets of external users, programmers and network administrators, with two different access policies. When an external user authenticates, the appropriate ACL entries are added to the inbound ACL to allow the user to access the appropriate services. For the programmers, you might set up policies to allow them access to specific development machines; for the network administrators, you might set up access policies to allow them to access specific network-management devices, such as a bastion host.
AP first was introduced in Cisco IOS version 12.0(5)T. However, it was limited to performing authentication by HTTP: The user had to use a Java-enabled web browser for authentication. Since then, Cisco has added support for other methods of authentication. These authentication methods are supported:
HTTP? Cisco IOS 12.0(5)T
HTTPS (using SSL)? Cisco IOS 12.2(11)YU and 12.2(15)T (you need a Cisco IOS crypto k8 or k9 image to support encryption with HTTPS)
Telnet? Cisco IOS 12.3(1)
FTP? Cisco IOS 12.3(1)
As you can see from this list, AP is more flexible than lock-and-key: Lock-and-key supports only Telnet.
AP also supports a form of downloadable ACLs called access profiles. AP requires you to use an external AAA server that has the users' accounts and access profiles configured on it. When a user successfully authenticates, the user's access profile is downloaded to the router, where the Cisco IOS includes the access profile as temporary ACL entries in the router's static ACL. Cisco's Cisco Secure ACS product supports access profiles with AP.
AP is compatible with many other Cisco IOS security features, including IDS, CBAC, NAT, and IPSec and VPNs. For example, AP keeps track of incoming HTTP requests to determine whether authentication is needed. If AP sees an abnormally high number of open HTTP requests, this can indicate that the router is under a DoS attack. AP can limit the number of these open requests and drop any requests that go above this threshold.
AP even works with CBAC and NAT; however, if you want to use AP and have NAT configured on your router, Cisco requires you also to use CBAC. NAT can be somewhat tricky with AP. For example, a user might use AP to authenticate using its original address, but NAT then translates this address to another. The concern here is that any temporary dynamic ACL entries created because of the AP authentication should have the correct addressing information. CBAC is needed here because CBAC inspects traffic to make sure that the correct ACL entries are created for the authenticated user.
AP is integrated into AAA, as briefly mentioned in Chapter 5, "Authentication, Authorization, and Accounting." One nice feature of AP and AAA is that you can generate start and stop accounting records for the traffic originating from the authenticated user (this requires the configuration of RADIUS attributes 42, 46, and 47 for both RADIUS and TACACS+ server connections).
Table 14-1 summarizes the features of AP by comparing AP with lock-and-key.
Comparator | Authentication Proxy | Lock-and-Key |
---|---|---|
Authentication connection | HTTP, HTTPS, Telnet, and FTP. | Only Telnet. |
User's connection | Can be directed to the router or to one of the previously mentioned services. | Must be directed to the router. After authenticating, the user can use other services dictated by the interface's ACL entries. |
Authentication method | AAA authentication and authorization with either TACACS+ or RADIUS. | AAA authentication with TACACS+, RADIUS, or username commands. |
Temporary ACL location | Defined on the AAA server and downloaded to the router. | Defined as a single dynamic entry in the ACL. |
Temporary ACL entries | Each user or group can have its own access profile. | Only a single dynamic ACL entry is used to define all users' policies. |
TIP
Cisco recommends that you use lock-and-key if you do not have an AAA server or the Cisco IOS Firewall feature set. I highly recommend that if you need to authenticate users before allowing them through your perimeter router/firewall, you purchase the Cisco IOS Firewall feature set as well as Cisco Secure ACS. This solution provides a more secure and scalable solution than lock-and-key. I commonly refer to lock-and-key as the "poor man's" version of AP.
Now that you understand some of the features of AP, this section examines the process that AP uses to authenticate a user and open temporary holes in your ACL.
As you will see later in this chapter, configuring AP is more complex than configuring lock-and-key. One of the things you need to decide is what authentication method or methods are needed: HTTP, HTTPS, Telnet, and/or FTP. My personal recommendation is HTTPS because the connection is encrypted. However, if you are using one-time passwords (OTP), described in Chapter 3, "Accessing a Router," any of these authentication methods is fine.
Figure 14-1 illustrates the process that takes place with AP. This example assumes that HTTP is used to perform the authentication by the router. As you can see in Figure 14-1, this process is similar to what lock-and-key does during the authentication process, although some differences exist. In this example, the user can cause authentication to occur in one of two methods:
Open a web connection to the router itself
Open a web connection to an internal web server
One main difference exists between lock-and-key and AP: AP allows the router to intercept the user's connection (only HTTP, HTTPS, Telnet, and FTP) and perform authentication; after authentication, it allows the router to redirect the user's connection to the resource.
The following is an explanation of the numbered steps in the example shown in Figure 14-1:
One nice feature about this process is that AP enables the router to intercept supported connections, perform authentication, and, for successful authentications, redirect the initial connection request to the appropriate resource.
Of course, the process just described assumes that this is the first time the user initiates a connection. After authentication, the router caches the user's information from the AAA security server and uses this information to determine whether subsequent connections need to be authenticated. The router keeps the cached information for a user as long as traffic is coming to and from the user. If the user is idle for a specified period of time, AP removes the temporary ACL entries and cached information and forces the user to reauthenticate when the user initiates new traffic.
To provide for secure authentication, AP uses JavaScript. This ensures that the user's username and password are sent to the router instead of accidentally being sent to another web server. Therefore, Cisco highly recommends that JavaScript be enabled for HTTP/HTTPS AP connections on your users' desktops.
However, AP does support authentication without JavaScript, especially in sites that have disabled Java because of security reasons. If JavaScript is disabled, when the user attempts the web connection and the router intercepts it, a pop-up window is opened on the user's desktop that contains the following:
Instructions on how to enable JavaScript to perform the authentication process automatically
Instructions on how to manually complete the authentication process and establish the user's web connection
To perform the authentication process manually, follow these steps:
If the user's last authentication attempt succeeded, the web page that the user initially was trying to access is displayed. Otherwise, the username/password pop-up window is redisplayed and the user must authenticate again.
CAUTION
Because of the process used with manual authentication, I highly recommend that you explain to your users the process that needs to be done to complete the authentication process successfully. If the user clicks the Done button from the JavaScript warning window, the authentication process will not complete correctly.
AP can be used in many different situations to provide a more secure access method. The following two sections describe when you might want to use AP and where AP typically is deployed.
AP actually has many practical uses. AP proves useful to your security arrangements in these situations:
You need to authenticate and authorize external users before allowing them to access specific internal resources, such as a private web server.
You need to authenticate and authorize internal users before allowing them to access extranet or Internet resources.
You want to enhance your VPN setup by preauthenticating users before allowing them to set up a VPN connection to your router.
You need to set up different levels of access on a per-user basis, but you do not necessarily know the IP addresses of the users because these can change on a day-by-day basis (probably because they use PPP or DHCP to acquire their addressing information).
You need a detailed audit of who connects through the router, how long they were connected, and when these connections occurred.
As you saw in the last section, you can use AP to authenticate and authorize access for external users accessing internal resources, as well as internal users accessing external resources. You can configure both of these policies simultaneously on your router.
Figure 14-2 illustrates these policies. In this example, two AP policies have been defined:
Internal? All users must be authenticated before accessing the Internet. Salespeople have complete access, but accounting people are allowed access only to port 80 and ports 8080 through 8099.
External? Any external user who wants to access the internal private web server first must be authenticated.
In this example, you create two AP policies: one applied inbound on the internal interface (e0) for the internal users, and one applied inbound on the external interface (e1) for the external users.
Despite its advantages, AP has limitations. As with lock-and-key, AP is susceptible to spoofing. After authentication, the router inspects subsequent traffic from the user by examining the user's source IP address. Therefore, if a hacker knows that a user successfully has authenticated, the hacker can compromise the router by executing some form of spoofing attack, taking advantage of this knowledge (and weakness within the mechanics of AP).
Other limitations of AP include these:
AP works only for traffic traveling through, not to, the router.
Authentication must occur with HTTP, HTTPS, Telnet, or FTP. These are the most commonly used protocols that provide a mechanism for bidirectional communication, which is why you see only these four methods for authentication on the router. However, after being authenticated, based on any downloaded ACLs, the user can access other resources in the network.
With HTTP, the Cisco IOS examines only port 80 connections.
Load balancing with multiple AAA servers is not supported currently with AP.
If two users are sharing the same device, AP authenticates only the first user, not the second, because AP examines the source IP address in packets to determine whether authentication has been performed.
As mentioned in the "AP Authentication and JavaScript" section, you can perform authentication without JavaScript, but it is not recommended because it is not as secure.