Introduction to AP

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 Features

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.

Table 14-1. AP Versus 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.


AP Process

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.

AP Process Example

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

Figure 14-1. AP Process Example

[View full size image]
graphics/14fig01.gif


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:

Step 1. In this example, the user opens a web connection (HTTP) to the internal web server (192.1.1.1).

Step 2. The router has AP configured, with HTTP as the authentication mechanism, and it intercepts the HTTP connection request. The router sends back a username and password prompt to the user. In the case of HTTP or HTTPS, this is a window that pops up with two text boxes for the username and password.

It is important to point out that if your user has software that blocks pop-ups, this window is not displayed. Therefore, care must be taken to ensure that this window appears on the user's screen.

Step 3. The user must enter a username and password for the appropriate prompts. For HTTP or HTTPS authentication, the user must click the OK button to send the information to the router.

For FTP, if the router is performing redirection and the AAA user account and the FTP server use different usernames and passwords, you can specify both in the username and password prompts. The router then uses the appropriate username/password combination for AAA and for the redirection to the FTP server. When entering the usernames, the user should enter them as AAA_username@FTP_username, where the AAA and FTP usernames are separated by the @ symbol. The passwords use the same nomenclature: AAA_password@FTP_password.

If you are using one-time passwords, such as token cards, a user can enter the username/password combination up to three times. After this, the user must enter two valid token passwords in succession before the AAA server allows authentication.

Step 4. When the router receives the user's authentication information, it forwards this through TACACS+ or RADIUS to the AAA server.

Step 5. The AAA server authenticates the user. If the user successfully is authenticated, the AAA server sends the user's access profile to the router. The access profile is basically a simplified grouping of ACL statements that define what the user is allowed access to.

Step 6. If the user successfully authenticates, the user receives a pop-up window indicating success (just click the OK button to close it). The router converts the access profile into actual temporary ACL entries that then are activated inbound on the appropriate interface. In this example, this would be inbound on the external interface. The dynamic ACL entries allow the user to access the approved resources. The router actually customizes the user's access profile by placing the user's source IP address in the source field of the ACL entry or entries.

If the router intercepted the HTTP connection, the router redirects the initial connection request to the internal web server.

If the user is not successful in authenticating, the router resends the prompts to the user so that the user can attempt to authenticate again. If the user fails to authenticate after five attempts, the router blocks all new authentication attempts from the user for 2 minutes. This is done to prevent DoS attacks.

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.

AP Authentication and JavaScript

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:

Step 1. Close the pop-up window. Do not click the Done button; instead, click File > Close from the main menu. It is important that you use this process; otherwise, manual authentication will fail.

Step 2. From the user's original web browser window, the user should click the Refresh or Reload button.

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 Usage

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.

When to Use AP

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.

Where to Use AP

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.

Figure 14-2. Where to Use AP

[View full size image]
graphics/14fig02.gif


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.

Limitations of AP

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.