Cisco IOS Firewall 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.

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.

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.

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.