Cisco IOS Firewall Authentication Proxy

Cisco IOS Firewall Authentication Proxy

The Cisco IOS Firewall authentication proxy feature allows network administrators to implement security policies on a per-user basis through personalized ACLs. Without firewall authentication proxy, user identity and any authorized access was associated with a user’s IP address. Any single security policy had to be applied to an entire user group or subnet. Now, users can be identified and authorized on the basis of their per-user policy, and any access privileges can be customized based on their individual access profiles.

With the authentication proxy feature, users can log in to the network or access the Internet via HTTP. Their specific access profiles are automatically retrieved and applied from a Cisco Secure Access Control Server (ACS), or another RADIUS or TACACS+ authentication server. The user profiles are active only while there’s active traffic from the authenticated user.

The authentication proxy is supported on the latest IOS versions (12.2) of the SOHO 70, 800, uBR900, 1720, 2600, 3600, 7100, 7200, and 7500 series routers. Earlier versions won’t support the feature on the smaller units (SOHO 70 to 1720s). Authentication proxy is compatible with other Cisco IOS security features, such as NAT, CBAC, IPSec encryption, and VPN client software.

How the Authentication Proxy Works

Unlike many Cisco IOS Firewall features that operate transparently to the user, the authentication proxy feature requires some user interaction on the client host. When a user, using a web browser, initiates an HTTP session through a firewall configured to support the authentication proxy, the process is triggered. The first thing the authentication proxy checks is to see if the user has already been authenticated. If so, the connection is completed without further intervention. But, if no valid authentication entry exists, the authentication proxy responds by providing a screen that prompts the user for a user name and a password. Figure 8-1 shows the message that greets the user.


Figure 8-1: Authentication proxy login screen

In the sample, the Rtr1 text is the host name defined for the firewall router. The rest of the text might vary slightly with the version of Cisco Secure ACS and the operating system (OS) platform.

The users must successfully authenticate by supplying a valid user name and password combination recognized by the defined authentication server. Figure 8-2 shows a successful attempt response.


Figure 8-2: Authentication successful attempt response message

If the authentication attempt failed, the authentication proxy would display a message stating Authentication Failed! and then prompt the user for retries. After five failed attempts to authenticate, the user would wait two minutes, and then would have to initiate another HTTP session to trigger authentication proxy.

User Profiles and Dynamic ACL Entries

With a successful authentication, the user’s authorization profile stored on the AAA server is downloaded to the firewall to create dynamic access control entries (ACEs). These temporary ACEs are added to the inbound ACL for an input interface and to the outbound ACL of an output interface, if an output ACL exists at the interface. These temporary ACEs configure the firewall to allow only the authenticated users access to the network that was specifically permitted by the authorization profile. For example, the user could only initiate a Telnet session through the firewall if either Telnet or all of TCP is specifically permitted in that user’s profile. The following example is a TACACS+ user profile stored on a Windows AAA server.

default authorization = permit
key = test
user = newuser1 {
login = cleartext test
service = auth-proxy
{
priv-lvl=15
proxyacl#1="permit tcp any any eq 69"
proxyacl#2="permit icmp any host 192.168.7.2"
proxyacl#3="permit tcp any any eq ftp"
proxyacl#4="permit tcp any any eq ftp-data"
proxyacl#5="permit tcp any any eq telnet"
proxyacl#6="permit tcp any any eq smtp"
}
}

The various proxyacl#n lines will be downloaded as ACEs in the firewall router to allow the defined protocol or activity. Notice no deny statements exist because all traffic should have already been denied by a standard ACL. These entries are creating the exceptions. All source addresses are set to any because they’ll be replaced by the IP address of the authenticating user.

The following output shows input ACL (160) following the user on host 192.168.1.10 successfully authenticating. The first six permit statements represent the downloaded user profile enabling the specified features for the authenticated user. The last four lines are the “real” ACL entries.

Rtr1#show ip access-lists
Extended IP access list 160
permit tcp host 192.168.1.10 any eq 69
permit icmp host 192.168.1.10 host 192.168.4.2
permit tcp host 192.168.1.10 any eq telnet
permit tcp host 192.168.1.10 any eq ftp
permit tcp host 192.168.1.10 any eq ftp-data
permit tcp host 192.168.1.10 any eq smtp
deny tcp any any eq telnet
deny udp any any
permit tcp any any (76 matches)
permit ip any any

Idle Timer

With a successful authentication, the authentication proxy sets up an inactivity (idle) timer for the created user profile. As long as any authorized user traffic goes through the firewall, the idle timer is continuously reset and the user’s host doesn’t trigger the authentication proxy. The ip auth-proxy auth-cache-time minutes command is used (covered in the section “Authentication Proxy Configuration on the Router”) to set the idle timer. The default is 60 minutes.

If the idle timer expires, the authentication proxy then removes the user’s profile information and any related dynamic ACEs in the access lists. Any subsequent traffic from the client host is blocked until they initiate another HTTP session to trigger the authentication proxy.

Secure Authentication

The authentication proxy uses a JavaScript applet to help establish a secure authentication session with the user’s web browser. This secure authentication prevents a client from mistakenly submitting a user name/password combination to a network web server other than the authentication proxy router. For this to work, user browsers must allow JavaScripts prior to initiating the HTTP connection. With the JavaScript feature enabled on the browser, secure authentication is done automatically and the user sees the authentication message displayed earlier in Figure 8-2.

Note?

There is a work-around for networks that won’t allow the JavaScript feature. While this technique works, it’s neither automatic nor particularly reassuring to the user. The Cisco online documentation has the steps to follow if the JavaScript feature can’t be enabled.

Applying the Authentication Proxy

Figure 8-3 shows a simple authentication proxy implementation where a single connection exists to the local, protected network and a serial connection exists to the Internet via an Internet service provider (ISP). Access control lists are applied inbound on both interfaces to block all incoming traffic. The lone exception is this: an opening must be created that allows the AAA server to communicate with the firewall router.

Click To expand
Figure 8-3: Simple network implementation for authentication proxy

One strategy is to apply the authentication proxy in the inbound direction for any router interface for which per-user authentication and authorization is required. By applying the authentication proxy inbound, all user connection requests are intercepted before they’re processed by any IOS or firewall features. If the user authentication attempt fails, the connection request is dropped.

The authentication proxy feature supports using a standard access list to specify a particular host or group of hosts whose initial HTTP traffic triggers the proxy. How the authentication proxy will be applied should be driven by the organization security policy.

Comparison with the Lock-and-Key Feature

Chapter 5 covered another IOS feature—lock-and-key—which seems to provide a similar service to authentication proxy. Lock-and-key also uses authentication and dynamic access lists to provide user access through a firewall. The following table compares the authentication proxy and lock-and-key features.

Authentication Proxy

Lock-and-Key

Triggers on HTTP connection requests.

Triggers on Telnet connection requests.

TACACS+ or RADIUS authentication and authorization.

TACACS+, RADIUS, or local authentication.

Access list entries are created from profile information retrieved from the AAA server only.

Access lists are configured on the router only.

Access privileges are granted on a per-user and host IP address basis.

Access privileges are granted on the basis of the user’s host IP address only.

ACLs can have multiple entries defined by the user profiles on the AAA server.

Access lists are limited to one entry for each host IP address.

Allows DHCP-based host IP addresses, meaning users can log in from any host location and obtain authentication and authorization.

Associates a fixed IP address with a specific user. Users must log in from the host with that IP address.

Compatibility with Other Features

The authentication proxy works transparently with the Cisco IOS Firewall intrusion detection system and Cisco IOS IPSec encryption features. This section looks at issues related to authentication proxy and features, such as NAT, CBAC, VPN client software, AAA, and one-time password (OTP) features.

CBAC Compatibility

Authentication proxy does not create ACEs to support returning data traffic or data channel traffic, so you must either create static ACLs to allow the return traffic or configure the CBAC inspection rules in the firewall configuration. Remember, static ACLs increase the network vulnerability because they’re permanent “holes” in the firewall, whereas a CBAC “hole” only exists as long as it’s needed.

Configuring CBAC with any authentication proxy implementation is the most reliable and secure method to ensure return traffic for authorized user connections through the firewall.

Network Address Translation (NAT) Compatibility

Authentication proxy can be successfully implemented on a network using network address translation (NAT) if the CBAC features are configured. Figure 8-4 shows a firewall router performing NAT translation on traffic heading out into the Internet.

Click To expand
Figure 8-4: Firewall router performing NAT translations

With the NAT service, the client local IP address is translated to a “real” global address for any packets traveling out into the Internet. This translation is stored in a NAT translation table on the router, so returning traffic can be retranslated back to the appropriate local address. For example, traffic from host 192.168.1.2 might travel out through the Internet using 172.16.1.1:2070.

But, earlier, when 192.168.1.2 used authentication proxy, a set of temporary ACEs were established using 192.168.1.2 as the authenticated address, not 172.16.1.1. Depending on where those ACEs were applied, our user might not have ACEs to allow the traffic to pass through the router.

Assuming authentication proxy is applied inbound on the LAN interface (e0) only, temporary ACEs are created inbound on that interface to allow that user the use of whatever protocols and features were defined in the downloadable profile. Because NAT will occur outbound after the traffic has passed through the LAN interface, everything should be okay so far. The NAT translations on returning traffic shouldn’t be an issue because the returning traffic is unfiltered outbound on the LAN interface. Even if the traffic was filtered, the addresses have been retranslated back to the local addresses before heading out into the LAN.

But, what if the ACEs were applied to the Serial 0 interface? Now the traffic reaching the interface doesn’t match the original dynamic ACEs created by the authentication proxy. Configuring CBAC when using authentication proxy with NAT services will take care of the problem by using the translated addresses to create matching ACEs. CBAC makes sure the NAT translated address for the session is associated with the original host address.

When in doubt, use CBAC with NAT and the authentication proxy feature.

VPN Client Compatibility

Authentication proxy can add an extra layer of security and access control for VPN client sessions. A VPN client initiating an HTTP connection through the firewall router is treated like any other user. The authentication proxy checks for a prior client authentication. If a valid authentication is found, authorized traffic is permitted. If not, the HTTP request triggers the authentication proxy and the user is prompted for a user name and password.

Once the VPN user authenticates successfully, the authentication proxy retrieves the user profile from the AAA server. The source address in the user profile entries is then replaced with the IP address of the authenticated VPN client from the decrypted packet.

Compatibility with AAA Accounting Features

Authentication proxy supports the AAA Accounting feature by being able to generate “start” and “stop” accounting records with enough detail to be used successfully for billing and security auditing purposes. This also allows the network administrator to monitor the actions hosts that have used the authentication proxy service.

If the accounting Start option has been enabled, a start record will be generated every time an authentication proxy cache entry and associated dynamic access control list entry are created. Any subsequent traffic from the authenticated host will be recorded when the ACEs created by the authentication proxy receive the packets. The accounting feature saves data about this event in a data structure stored with the data of other users on a defined server.

When the authentication proxy cache expires and is deleted along with the related ACEs, any additional data, such as elapsed time, is added to the accounting information and a stop record is sent to the server.

Operation with One-Time Passwords (OTS)

Authentication proxy supports the use of one-time passwords (OTPs) because AAA supports them. Remember, OTPs typically require an additional authentication server and will require additional configuration of the AAA server. When using an OTP, the user enters the user name and OTP in the HTML login page as usual.

One minor difference is this: the user must enter the correct token password within the first three attempts. If a user has made three consecutive incorrect entries, they must enter two valid token passwords in succession before authentication is granted by the AAA server.

Security Vulnerability Issues

Any time holes are punched through a firewall defense, an increased vulnerability occurs to those who would capitalize on those vulnerabilities. Because authentication proxy should be configured with CBAC, it only makes sense to implement the CBAC attack defenses introduced in Chapter 6.

Denial of Service (DoS) Attacks

Any time a firewall experiences a high level of connection requests requiring authentication, legitimate network users might experience delays in making needed connections or the connection could be rejected and the user would need to try reestablishing the connection. For each request, the authentication proxy prompts the users for login credentials. A high number of open requests could indicate that the router is the subject of a denial of service (DoS) attack.

As a protective mechanism, the authentication proxy monitors incoming HTTP requests, limits the number of open requests, and then drops any additional requests until the number of open requests has fallen below 40.

Source Address Spoofing

Spoofing a source address involves a hacker substituting a known or suspected trusted address for their address both to gain access and conceal their identity. When an HTTP session triggers a successful authentication proxy session, a dynamic opening is created in the firewall by reconfiguring an interface with temporary user-access privileges. As long as this opening exists, it’s always technically possible for another user to detect the source IP address information and spoof the address to gain access behind the firewall.

Spoofing is a problem inherent to all access list implementations. Important to realize is that the authentication proxy feature doesn’t cause this address spoofing problem, but it does have some level of vulnerability. The authentication proxy doesn’t specifically address this problem.

Before Configuring Authentication Proxy

Authentication proxy (auth-proxy) is available only on Cisco IOS Software containing the firewall feature set since version 12.0.5.T.auth-proxy can be used to authenticate inbound or outbound users, or both, by using a web browser to pass through the firewall and authenticate on a TACACS+ or RADIUS server. Traditional access lists are in place to block all traffic. After authentication, the AAA server passes temporary access list entries to the firewall router to allow predefined types of traffic.

Authentication proxy has certain requirements that must be met for effective use of this technology in a network. This section looks briefly at some of the system requirements, as well as the skill sets required of a network administrator tasked with implementing and supporting Cisco secure authentication proxy.

  • Client hosts must be running one the following software browsers. These client browsers must have the JavaScript capabilities enabled for secure authentication.

    • Microsoft Internet Explorer 3.0 or later

    • Netscape Navigator 3.0 or later

  • Because the authentication proxy activates only on HTTP connections, HTTP services must be running on the standard (well-known) port 80 on the firewall router.

  • The authentication proxy feature and related access list entries only apply to traffic passing through the router. Any administrative traffic with the router as the destination is authenticated by the standard authentication methods provided by IOS software.

  • Authentication proxy doesn’t support concurrent use, meaning it can’t be used for multiple users to log in from the same host device at the same time. The authentication and authorization apply only to the first user to submit a valid user name and password. Any others are ignored until the first user ends their session.

  • Load balancing between multiple AAA servers isn’t supported. Requests only go to any additional AAA server if the first one configured times out.

  • Because authentication proxy can use standard access lists, how access lists are used to filter traffic before configuring the authentication proxy is important. For more information on how to configure and use access lists, see Chapter 2 and Appendix A.

  • The authentication proxy is a feature of the Cisco Authentication, Authorization, and Accounting (AAA) strategy. It’s important to understand how to configure AAA user authentication, authorization, and accounting before you attempt to configure the authentication proxy. For more information on how to configure AAA, see Chapters 3 and 4.

  • To create a completely secure and successful implementation of the authentication proxy feature of the Cisco IOS Firewall, you must configure CBAC on the firewall. CBAC features are typically required to allow filtering of protocols permitted by the downloadable user profiles. For more information on configuring and using the CBAC features, see Chapter 6.

Cisco suggests the following tips for implementing the auth-proxy features to reduce the impact on the existing network and the variables involved. This makes it easier to see if the process is being implemented as defined in the security policy.

  • Confirm that traffic is flowing properly through the firewall before configuring auth-proxy. Remember, other firewall features exist, such as ACLs and CBAC, that can restrict traffic flow.

  • To reduce disruption of the network during testing, modify any existing access list or add an access list to deny access to only one test client.

  • Confirm that only the one test client can’t get through the firewall and that all other hosts can pass through.

  • Add the exec-timeout 0 0 command under the console port (line con 0) and/or virtual type terminals (line vty 0 4) to prevent your sessions from timing out while you’re busy on other devices or reading online documentation. The first 0 is minutes, the second 0 is seconds: exec-timeout 20 30 would set the idle timer to 20 1/2 minutes. The 0 0 combination turns off the idle timer.

Authentication Proxy Configuration Task List

The authentication proxy feature requires an AAA server running Cisco Secure Access Control Server (ACS) to be present on the network. This is necessary to configure the AAA server to enable the features.

Next, the router running the firewall feature set, typically the perimeter router, must be configured by performing the following tasks:

  • Configuring AAA support

  • Configuring the HTTP server feature

  • Configuring the authentication proxy

  • Verifying the authentication proxy

Technically, only the first three tasks and configuring the AAA server are required. Skipping the optional verifying is done only at risk to the resources you’re charged to protect. The next section looks first at configuring the AAA server, and then at the firewall router.




Part III: Virtual Private Networks (VPNs)