12-3. Using Authentication Proxy to Manage User Access An IOS firewall can control user access to protected networks by using the authentication proxy feature. Specific networks are protected by an inbound access list, applied to an interface toward the user community, which blocks traffic. The IOS firewall can intercept HTTP traffic (TCP port 80) from users and require authentication if needed. An access list can be used to limit what HTTP traffic can trigger authentication proxy. You can configure and apply security policies on a per-user basis. Access is denied until the user can be prompted for authentication credentials. If the user is not already authenticated, the router prompts for a username and password. After successful authentication, the user's authorization profile is requested from a AAA server. A dynamic access control entry (ACE) is added to the inbound access list, permitting the user's traffic to pass into the network. Even non-HTTP traffic can be permitted from the authenticated user. Authentication proxy must be configured on an inbound interface at the edge of the network closest to the users. NOTE Beginning with Cisco IOS software Releases 12.2(11)YU and 12.2(15)T, authentication proxy can use HTTPS for secure exchanges of the username and password credentials. If normal HTTP is used, the credentials pass across the network in the clear, with no encryption. HTTPS uses Secure Socket Layer (SSL) version 3.0 to encrypt all transactions.
Configuring Authentication Proxy Follow these steps to configure all the features needed for authentication proxy: 1. | Configure AAA services.
Enable AAA features: IOSFirewall(config)# aaa new-model
Enable login authentication: IOSFirewall(config)# aaa authentication login default group {radius | tacacs+}
No special keywords are needed to use authentication proxy with AAA. The default authentication method should be configured, at a minimum, if no other methods are already being used for other purposes. Choose either radius or tacacs+, depending on the AAA servers available to you. Enable AAA authorization to import dynamic access list information: IOSFirewall(config)# aaa authorization auth-proxy default group {radius | tacacs+}
The auth-proxy keyword causes AAA authorization to interoperate with authentication proxy. At a minimum, you should use the default authorization method, working with either radius or tacacs+ AAA servers. (Optional) Enable AAA accounting to generate an audit or billing trail: IOSFirewall(config)# aaa accounting auth-proxy default start-stop group {radius | tacacs+}
Authentication proxy activity is reported to the AAA accounting server, providing a per-user audit trail. Use the start-stop keyword to generate both start and stop records as the user authenticates and uses the dynamic access list entry. Configure the AAA server addresses: IOSFirewall(config)# tacacs-server key key IOSFirewall(config)# tacacs-server host ip-address [key key]
or IOSFirewall(config)# radius-server key key IOSFirewall(config)# radius-server host ip-address [key key]
A TACACS+ or RADIUS server is identified by its IP address. The shared secret key is configured as key (an arbitrary text string). You can repeat these commands to define multiple AAA servers. (Optional) Add TACACS+ or RADIUS traffic to any inbound access list: IOSFirewall(config)# access-list acc-list-number permit tcp host aaa-server eq tacacs host router-address
or IOSFirewall(config)# access-list acc-list-number permit udp host aaa-server eq 1812 host router-address
If you have configured and applied an inbound access list on an IOS firewall interface toward the AAA servers, be sure to make adjustments to it at this point. Configure the ACL to permit the return (inbound) AAA traffic from the AAA server back to the router interface. If you fail to do this, when the IOS firewall requests the user authorization information from the server, the replies might be filtered out and blocked. For TACACS+, you can use the tacacs keyword or TCP port 49. RADIUS uses UDP port 1812, but it has no corresponding access list keyword.
| 2. | Enable the HTTP server on the IOS firewall.
The IOS firewall must run its own web server to offer web-based authentication proxy prompts to end users.
Enable the HTTP server: IOSFirewall(config)# ip http server
The HTTP server is used to present a username/password authentication prompt to the user. Use AAA authentication for the HTTP server: IOSFirewall(config)# ip http authentication aaa
After you're prompted for authentication credentials, end user information is handed off to the AAA mechanism for approval. Define an access list to deny all inbound traffic to the HTTP server: IOSFirewall(config)# access-list acc-list-number deny any IOSFirewall(config)# ip http access-class acc-list-number
You need to apply a standard IP access list (numbered 1 to 99) to ensure that no outside user can initiate a connection to the IOS firewall's HTTP server. The HTTP server is used only for outbound traffic, to present prompts to the user. Notice that the ACL is applied only to the HTTP server itselfnot to an interface.
| 3. | (Optional) Use HTTPS for user credential exchanges.
Enable the HTTPS server: IOSFirewall(config)# ip http secure-server
(Optional) Change the HTTPS port: IOSFirewall(config)# ip http secure-port port-number
By default, the IOS firewall uses TCP port 443 for SSL traffic with the embedded HTTPS server. You can change the default port to port-number (1025 to 65535) if needed. (Optional) Define a certification authority (CA). By default, the IOS firewall uses a self-signed certificate for all HTTPS exchanges. You can point the firewall to use a CA as the trustpoint for X.509v3 certificates instead.
| 4. | Enable authentication proxy.
(Optional) Define an authentication idle timeout: IOSFirewall(config)# ip auth-proxy auth-cache-time minutes
Authentication proxy keeps a cache of authenticated users. After user traffic has been idle for minutes (1 to 2147483647 minutes; the default is 60), the dynamic access list entry for the user is removed, and the user has to authenticate again. (Optional) Display the IOS firewall host name in the login banner: IOSFirewall(config)# ip auth-proxy auth-proxy-banner http
By default, the authentication proxy banner is disabled, preventing the firewall's name from being seen. A best practice for security dictates keeping host names, hardware, and IP address information hidden so that end users can't leverage that information to gain access. Specify an authentication proxy rule: IOSFirewall(config)# ip auth-proxy name auth-proxy-name http [auth-cache-time minutes] [list std-access-list]
Here, the HTTP authentication process is triggered by specific traffic from the end user. An authentication proxy rule is associated with an arbitrary rule set named auth-proxy-name (up to 16 characters). The authentication proxy cache timeout can be overridden from the default, with auth-cache-time given in minutes (1 to 2147483647 minutes; the default comes from the ip auth-proxy auth-cache-time command). You can use a standard IP access list to limit what HTTP traffic triggers authentication proxy. If used, the list is referenced as std-access-list (1 to 99) and must contain permit statements for the source addresses that trigger the authentication process. Other addresses that are denied are passed normally, without triggering authentication proxy. If no access is specified, all HTTP traffic is intercepted and subject to authentication proxy. Apply the authentication proxy rule to an inbound interface: IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip auth-proxy auth-proxy-name
The authentication proxy rule named auth-proxy-name is used to define whether incoming traffic from end users requires authentication.
| 5. | Configure user profiles in the AAA server.
The profile for each user permitted to authenticate must be edited in the AAA server's configuration. The following steps use Cisco ACS (Windows version) as the AAA server.
Define an auth-proxy service in Cisco ACS. From the main Cisco ACS page, click the Interface button, and select TACACS+(Cisco IOS). Under New Services, enter auth-proxy in the Service field, as shown in Figure 12-2. Leave the Protocol field blank, and check the User and Group checkboxes. Click Submit. Figure 12-2. Configuring the Auth-Proxy Service in Cisco ACS 
Define an auth-proxy section in each user's profile. Click User Setup or Group Setup on the main Cisco ACS page. Auth-proxy settings can be applied to individual users or an entire group of users. Scroll down to find the TACACS+ Settings section, and check the auth-proxy checkbox. Define a privilege level for the user. In the text box below auth-proxy, enter the following line: priv-lvl=15
The privilege level must be 15 for all users who are authorized through authentication proxy. Define the dynamic access list entries for the user. In the text box below the auth-proxy checkbox, enter each line of the dynamic access list in the following format: proxyacl#1=permit protocol any ... proxyacl#2=permit protocol any ...
Enter the ACEs under the attribute values of the form proxyacl#n, where n represents the ACL line number. The attributes must be entered exactly as if you were configuring access list statements on the IOS firewall. Always use the source address any in the rules. As soon as the IOS firewall's authentication proxy imports the access list rules from the AAA server, it replaces any with the source address of the host that the user is using. This allows a user to authenticate from any IP address and to be allowed to make connections while using that same address. For example, to authorize the user to participate in ICMP, UDP, and TCP traffic with any other host, you could enter the following lines: proxyacl#1=permit icmp any any proxyacl#2=permit udp any any Zproxyacl#3=permit tcp any any
Figure 12-3 shows the complete auth-proxy attribute definition. After you enter this information, click the Submit button. Figure 12-3. Entering the Privilege Level and Dynamic ACL Attributes in Cisco ACS 
|
Authentication Proxy Example Authentication proxy is configured to inspect all inbound HTTP traffic and to authenticate any users who aren't already authenticated. TACACS+ servers at 192.168.88.253 and 192.168.88.254 are used for authentication, authorization, and accounting in conjunction with authentication proxy. The authentication proxy rule named Corporate is defined so that all users using HTTP from any source address are required to authenticate. The AAA authorization policies configured in the TACACS+ servers are retrieved for each user to determine what resources the user is allowed to access. The following example shows the necessary IOS firewall configuration commands: IOSFirewall(config)# aaa new-model IOSFirewall(config)# tacacs-server host 192.168.88.253 IOSFirewall(config)# tacacs-server host 192.168.88.254 IOSFirewall(config)# tacacs-server key mysecretkey IOSFirewall(config)# aaa authentication login default group tacacs+ IOSFirewall(config)# aaa authorization auth-proxy default group tacacs+ IOSFirewall(config)# aaa accounting auth-proxy default start-stop group tacacs+ IOSFirewall(config)# access-list 10 deny any IOSFirewall(config)# ip http server IOSFirewall(config)# ip http authentication aaa IOSFirewall(config)# ip http access-class 10 IOSFirewall(config)# ip auth-proxy auth-cache-time 120 IOSFirewall(config)# ip auth-proxy name Corporate http IOSFirewall(config)# interface fastethernet 3/1 IOSFirewall(config-if)# ip address 10.14.21.10 255.255.255.0 IOSFirewall(config-if)# exit IOSFirewall(config)# ip auth-proxy Corporate
Access list 10 is used to prevent anyone from connecting to the IOS firewall's HTTP server. The server is used only for outbound authentication proxy prompts. |
