5-5. Configuring AAA for End-User Cut-Through Proxy A firewall can be configured to require users to authenticate before connections are permitted. As soon as an authentication is successful, it is cached and used to permit subsequent connections from the same user. The firewall functions as an authentication proxy, because cached authentication information is used in place of repeated authentication credentials entered by the user. Connections simply "cut through" the firewall in a very efficient fashion. Devices that initiate connections but can't participate in authentication (Cisco IP phones, for example) can be exempted from AAA and allowed to pass through the firewall. Authenticating Users Passing Through You can use the following steps to configure AAA authentication for cut-through proxy users: 1. | (Optional) List protocols that trigger authentication:
Firewall(config)# aaa authentication {include | exclude} service if_name local_ip local_mask [foreign_ip foreign_mask] server_tag
To trigger user authentication, use the include keyword and identify the triggering protocol as service. This usually is a protocol that can support native authentication, where a username and password exchange is possible. These are telnet, ssh, ftp, http, and https, which can also be written as tcp/23, tcp/22, tcp/21, tcp/80, and tcp/443, respectively.
You can also specify other types of traffic as udp/port, tcp/port, icmp/type, or protocol/port (the IP protocol number and port number). You can use 0 for a port or type to indicate a wildcard for any value, as in tcp/0 for any TCP port. Notice that these values always pertain to the destination port and never the source port.
NOTE Be aware that the cut-through proxy authentication process can be triggered only with Telnet, SSH, FTP, HTTP, or HTTPS traffic. If you specify other types of traffic, those packets are dropped unless the user has already authenticated and has a cut-through proxy session already initiated. Authentication is triggered for connections initiated from the firewall interface named if_name ("inside," for example) from local addresses defined by local_ip and local_mask. You can define specific destination addresses by foreign_ip and foreign_mask if needed. To indicate a wildcard local or foreign address, you can use 0s or the any keyword for the address and mask values.
Authentication is performed by contacting the server group name server_tag. This can be a TACACS+ group name, a RADIUS group name, or the firewall itself with the LOCAL keyword.
TIP With the include keyword, no traffic is allowed to pass from a given user (source address) until that user has successfully authenticated using Telnet, FTP, HTTP, or HTTPS. You can define protocols that are allowed to pass without authentication by using the exclude keyword. | 2. | (Optional) Use an access list to trigger authentication:
Firewall(config)# aaa authentication match acl_name if_name server_tag
Here, an access list named acl_name is used to match connections that are initiated from hosts on the firewall interface named if_name. Protocols that can be authenticated are defined in permit statements in the access list.
Because this is the most specific method of traffic authentication, it is also the preferred method. You can make the matching conditions very specific by giving the local (source) and foreign (destination) addresses. Remember that the matching protocol is always specified as the destination port in the access list entry.
The authentication server group named server_tag is used to handle the actual authentication. This can be a TACACS+ server group name, a RADIUS server group name, or the firewall itself as LOCAL.
For example, all IP traffic coming from source addresses 172.16.0.0/24 should be authenticated before being passed through the firewall. In addition, all HTTP and HTTPS connections initiated from the inside interface should be authenticated. Authentication is handled by servers assigned to the default TACACS+ server group. The following commands can be used to accomplish this:
Firewall(config)# access-list AuthList1 permit ip 172.16.0.0 255.255.255.0 any Firewall(config)# access-list AuthList1 permit tcp any any eq http Firewall(config)# access-list AuthList1 permit tcp any any eq https Firewall(config)# aaa authentication match AuthList1 inside TACACS+
| 3. | (Optional) Use SSL for all web-related authentication:
Firewall(config)# aaa authentication secure-http-client
By default, if a user initiates authentication with either Telnet, FTP, or HTTP traffic, his or her username and password credentials are collected as cleartext through a popup browser window. You can use this command to force the firewall to use SSL to collect this information securely with encryption.
NOTE A firewall supports only 16 simultaneous SSL sessions for the initial user authentication. Any connections that require additional SSL sessions are dropped until a new session can be started. | 4. | (Optional) Exempt devices from authentication.
- a. Define a list of exempt MAC addresses:
Firewall(config)# mac-list id {deny | permit} mac macmask
The device list is named id (an arbitrary text name). You can permit the device to pass without authentication or deny it from doing so. The device is identified by its Media Access Control (MAC) address mac (in dotted-triplet form, as in 1111.2222.3333) and a MAC address mask macmask (in dotted-triplet format, where a 1 bit matches and a 0 bit ignores). To match a single-device MAC address, the macmask is given as ffff.ffff.ffff.
You can repeat this command to define multiple MAC addresses in a single list. For example, the following MAC list allows the host using MAC address 0006.5b02.a841 or 0040.9646.6cf6 to initiate connections without authentication:
Firewall(config)# mac-list Exemptions permit 0006.5b02.a841 ffff.ffff.ffff Firewall(config)# mac-list Exemptions permit 0040.9646.6cf6 ffff.ffff.ffff
NOTE If you decide to list device MAC addresses here, those devices must be located on the firewall interface's IP subnet. In other words, they cannot lie beyond a router, or their MAC addresses will become obscured by the router. Any devices not explicitly permitted or denied in a MAC address control list are subject to any other authentication methods that are configured on the firewall interface. - b. Apply the list to authentication:
Firewall(config)# aaa mac-exempt match id
The MAC address control list named id is used to permit or deny specific hosts from passing without authentication.
| 5. | (Optional) Limit per-user proxy connections:
Firewall(config)# aaa proxy-limit {proxy_limit | disable}
By default, a firewall supports cut-through proxy for up to 16 concurrent active connections per user. You can change this limit to proxy_limit (1 to 128 concurrent connections per user) or disable the limit completely.
| 6. | (Optional) Adjust the cut-through proxy session timer.
The firewall keeps two timers for each user's connection activity after a successful authentication: an absolute timer and an inactivity timer.
- a. Adjust the absolute timer:
Firewall(config)# timeout uauth hh[:mm[:ss]] absolute
By default, the absolute timer is used to require a user to reauthenticate if a new connection is initiated at least 5 minutes after the previous authentication. This timer runs for each user who authenticates with the cut-through proxy feature. The user must authenticate again if a new connection begins after the timer has expired, even if other connections are active or still initiating.
You can set the absolute timer by giving the hours, minutes, and seconds duration. Notice that minutes and seconds are both optional. It might seem intuitive that giving two digits (60, for example) would mean seconds, but in fact it means hours.
- b. Adjust the inactivity timer:
Firewall(config)# timeout uauth hh[:mm[:ss]] inactivity
By default, the inactivity timer is set to 0, which disables it for each user. You can use this timer to require a user to reauthenticate only after all his or her connections become idle or inactive (no data passed) for a period of time. Opening a new connection also resets the counter.
You can set the inactivity timer by giving the hours, minutes, and seconds duration. Notice that minutes and seconds are both optional. It might seem intuitive that giving two digits (60, for example) would mean seconds, but in fact it means hours.
TIP Setting and using the user authentication (uauth) timers is a bit of a trade-off. The absolute timer forces a strict authentication policy, making users reauthenticate again and again at regular intervals. This can be beneficial to protect access to sensitive data, but it also can be a nuisance to the end users. The inactivity timer is less secure but more user-friendly. As long as a connection is kept alive, the user is not asked to authenticate again. You can use both timers to gain some benefits from each. Always make sure that the inactivity timer is set to a value less than the absolute timer. In addition, the absolute timer must be set to a value less than the xlate timer. The idea is to require an absolute timer authentication only after all sessions become inactive. Any existing xlate entries for the user's connections should also stay alive until both types of timers have expired and the user has been given a chance to reauthenticate. You can use the show timeout command to see the current values of all connection timers. For example, this firewall is configured to reauthenticate users after their connections have been idle for 15 minutes and at regular 30-minute intervals: Firewall# show timeout timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00 timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout uauth 0:30:00 absolute uauth 0:15:00 inactivity Firewall#
|
Authorizing User Activity with TACACS+ Servers You can follow these steps to configure traffic authorization using AAA and TACACS+ servers: 1. | List protocols that require authorization:
Firewall(config)# aaa authorization {include | exclude} service if_name local_ip local_mask foreign_ip foreign_mask server_tag
The protocol that must be authorized for a user is identified as service with the include keyword. The protocol can be telnet, ftp, http, any, or protocol/port (decimal IP protocol number and decimal port number).
Connections using this protocol are initiated on the firewall interface named if_name from local addresses defined by local_ip and local_mask. You can define specific destination addresses by foreign_ip and foreign_mask if needed. To indicate a wildcard local or foreign address, use 0s for the address and mask values. This is similar to the any keyword in Cisco router IOS software.
Authorization is performed by contacting the TACACS+ server group name server_tag. For example, the following commands cause the firewall to generate requests to see if the users are authorized to initiate FTP and Telnet connections. All other connection types are authorized without explicit AAA authorization requests.
Firewall(config)# aaa authorization include ftp inside 0 0 0 0 TACACS_Farm Firewall(config)# aaa authorization include telnet inside 0 0 0 0 TACACS_Farm
| 2. | (Optional) Use an access list to trigger authorization:
Firewall(config)# aaa authorization match acl_name if_name server_tag
Here, an access list named acl_name is used to match connections that are initiated from the firewall interface named if_name. Protocols that are checked for authorization are defined in permit statements in the access list. You can make the matching conditions very specific by giving the local (source) and foreign (destination) addresses.
This is the preferred method of defining authorization, because the access list is the most scalable and easiest to administer. Remember that the matching protocol is always specified as the destination port in the access list entry.
The TACACS+ server group named server_tag is used to handle the actual authorization.
| 3. | Configure a user's TACACS+ profile.
To authorize a user to use a protocol, you must configure the user's profile on the TACACS+ server. TACACS+ has a facility to authorize only commands to be executed; therefore, the protocol is considered a "command" even though it is not.
You should configure the command by using any of the valid keywords or protocol/port definitions that are supported by the aaa authorization {include | exclude} command. For instance, you can use the telnet, ssh, ftp, http, or https keyword along with an optional permitted destination address. You can give the permitted address as any or * if no granularity is required.
For example, suppose a CiscoACS server is configured with a command authorization set called guests that allows HTTP, ICMP, SMTP, and DNS traffic from any host. Figure 5-5 shows the Shell Command Authorization Set configuration page. Each of the protocols is listed as a "command" by using a keyword or the protocol/port.
Figure 5-5. Sample Configuration of CiscoACS Traffic Authorization 
You then apply the shell command authorization set to a User Setup or Group Setup in CiscoACS by selecting it from the drop-down list. Figure 5-6 shows how the guests set is configured for a group of users.
Figure 5-6. Applying Traffic Authorization to a User Group in CiscoACS 
|
Authorizing User Activity with RADIUS Servers User authorization is not available as a part of the RADIUS protocol. However, if you have only RADIUS servers available and you need to set up authorization for user traffic, you can use access lists to emulate authorization. The RADIUS server can be configured to return a reference to an access list that is based on a user's authorization. The firewall can use the access list information to permit or deny the user's connections as they are initiated. You have two ways to approach RADIUS authorization: The RADIUS server returns the name of an access control list (ACL) that is defined locally on the firewall. The RADIUS server returns the contents of an ACL that is downloaded and used by the firewall. The ACL is actually defined on the RADIUS server, not on the firewall.
You can use the following steps to configure RADIUS user authorization: 1. | (Optional) Reference an ACL from the AAA server.
- a. Configure access lists to permit specific traffic:
Firewall(config)# access-list acl_name permit protocol any foreign_ip foreign_mask operator port
Add a permit access list entry for a protocol and destination address that should be allowed for a user. Normally, the access list entries are configured for groups of users so that one policy can be applied to multiple users.
Remember that the access list has an implicit deny any any at the end, so any traffic not specifically permitted in the list is rejected.
- b. Add the access list name to the RADIUS user profiles.
The RADIUS server simply returns a text value for attribute 11 from the user's profile. This is returned when the user authenticates, so RADIUS authentication must also be configured on the firewall. Attribute 11 is called filter-id. When the firewall receives this attribute value, it uses it to reference an access list by the same name.
On a CiscoACS server, begin by making the filter-id parameter available to user or group configurations. Go to Interface Configuration, select RADIUS(IETF), and make sure that attribute [011]Filter-Id is checked for User and/or Group.
Next, go to User Setup or Group Setup, select a user or group, and click Edit Settings. In the IETF RADIUS Attributes section, look for attribute [011]Filter-Id. Check that box and enter the name of the ACL in the text box.
For example, suppose an ACL named acl_http_only is used to "authorize" or control a user's access through a firewall. Only HTTP and HTTPS connections are allowed. First, the access list must be configured on the firewall with the following commands:
Firewall(config)# access-list acl_http_only permit tcp any any eq www Firewall(config)# access-list acl_http_only permit tcp any any eq https
Next, the user (or group) profile in CiscoACS must be configured with the ACL name as RADIUS attribute 11, as shown in Figure 5-7.
Figure 5-7. Defining the Filter-Id Attribute in CiscoACS 
TIP If attribute 11 (shown as [011]Filter-Id in CiscoACS) is not defined for a user, the AAA server does not return that attribute. In this case, traffic is assumed to be authorized. If attribute 11 is defined for a user on the AAA server but the corresponding ACL is not configured on the firewall, all traffic for that user is denied. This is because a nonexistent ACL is being referenced. Instead of attribute 11, you can also use a vendor-specific attribute-value pair. Use vendor 9 attribute 1, with the value text acl=acl_id.
| 2. | (Optional) Download an ACL from the RADIUS server.
Rather than preconfiguring ACLs on the firewall to authorize user traffic, you can use a RADIUS server to download the actual ACL content to the firewall. ACLs can be downloaded per user or per group. In either case, the ACL is actually downloaded during user authentication so that it is available when the users begin initiating connections. ACLs can be created on the RADIUS server at the same time a new user is added, making the administration a bit easier.
When the RADIUS profile is being edited, you can choose a "downloadable ACL" and enter the ACL contents exactly as you would in a firewall session.
If the firewall is configured for RADIUS authentication, it also begins accepting any downloadable ACLs that are returned in a RADIUS exchange. The firewall requests an ACL download only if the'''specified ACL is not already configured on the firewall. No other authorization commands are necessary.
- a. Create the downloadable ACL on the RADIUS server.
In CiscoACS, go to Shared Profile Components and select Downloadable IP ACLs. Click the Add button to create a new ACL. Give the ACL a name and an optional description.
To configure the ACL contents, click the Add button. You must enter the ACL name again, along with the actual ACL permit or deny statements in the ACL Definitions text box. As soon as the ACL contents are in place, click the Submit button.
Figure 5-8 shows an example in which a downloadable ACL called http_only has been created.
Figure 5-8. An Example of a Downloadable ACL in CiscoACS 
You should see a list of downloadable ACLs that includes the new ACL as well as the CiscoACS default called permit_anything.
- b. Assign the downloadable ACL to a user or group.
In CiscoACS, go to User Setup or Group Setup. In the Downloadable ACSs section, check the Assign IP ACL box and select the appropriate ACL from the drop-down list. In Figure 5-9, the http_only ACL has been selected and will be downloaded when the user authenticates with the CiscoACS server.
Figure 5-9. Assigning a Downloadable ACL in CiscoACS 
- c. Enable downloadable ACLs on the firewall:
Firewall(config)# access-group access-list {in | out} interface if_name per-user-override
After downloadable ACLs are accepted from a AAA server, they must be treated like any other access listthey must be applied to an interface. Therefore, you can use the per-user-override keyword when you apply an access list to an interface with the access-group command.
Any downloadable ACLs simply override the contents of the existing access list for a given end user. The access list statements aren't replaced, however; the per-user ACL is evaluated first, ahead of the regular access list.
|
TIP Downloadable ACLs are active only as long as the user is authenticated on the firewall. As soon as the uauth timer expires for a user, the corresponding downloadable ACL is removed. When the user initiates a new connection and authenticates again, the downloadable ACL is retrieved and put into service once more. You can verify downloadable ACLs on a firewall as they are being used. First, use the show uauth username and look for the access list that has been downloaded from the RADIUS server. This is indicated by a line beginning with access-list followed by the ACL name that was dynamically created. Next, use the show access-list command to see the current contents and counters for the ACL entries. The following example demonstrates this downloadable ACL verification process: Firewall# show uauth dhucaby user 'dhucaby' at 192.168.199.4, authenticated access-list #ACSACL#-PIX-dhucaby_access_list-1cff1dd1 absolute timeout: 0:05:00 inactivity timeout: 0:00:00 Firewall# Firewall# show access-list #ACSACL#-PIX-dhucaby_access_list-1cff1dd1 access-list #ACSACL#-PIX-dhucaby_access_list-1cff1dd1; 3 elements access-list #ACSACL#-PIX-dhucaby_access_list-1cff1dd1 permit tcp any any eq http (hitcnt=17) access-list #ACSACL#-PIX-dhucaby_access_list-1cff1dd1 permit tcp any 172.17.3.0 255.255.255.0 eq telnet (hitcnt=5) access-list #ACSACL#-PIX-dhucaby_access_list-1cff1dd1 deny ip any any (hitcnt=201) Firewall#
Downloaded ACLs always have this naming format: #ACSACL#-acl_name-versionID
where acl_name is the name of the access list (PIX-dhucaby_access_list in the preceding example) and versionID is a string of digits that uniquely identifies the current ACL (1cff1dd1 in the example). If the ACL is updated on the RADIUS server, the versionID is changed.
Keeping Accounting Records of User Activity You can use the following steps to configure user activity accounting using AAA servers: 1. | (Optional) List protocols that will be tracked:
Firewall(config)# aaa accounting {include | exclude} service if_name local_ip local_mask foreign_ip foreign_mask server_tag
The firewall sends accounting records when a user initiates a connection on the firewall interface named if_name with protocol service (telnet, ftp, http, any, or protocol/port), as long as you use the include keyword. You can further specify the user traffic by giving the local and foreign IP addresses and masks. You can also use a wildcard for any of the address and mask values by giving a 0 value.
Usually, you can enter this command with the same arguments as the aaa authentication command. In this way, the firewall tracks the same connection activity for which it acts as a cut-through proxy. Accounting records are sent only to the active AAA server in the server group named server_tag. The active server is determined by the firewall's AAA authentication feature.
TIP If you plan to generate accounting information for all user traffic involving a specific protocol, you can use this alternative form of the command: Firewall(config)# aaa accounting {include | exclude} service if_name server_tag
| 2. | (Optional) Use an access list to trigger accounting:
Firewall(config)# aaa accounting match acl_name if_name server_tag
Here, an access list named acl_name is used to match connections that are initiated from the firewall interface named if_name. Protocols that are recorded are defined in permit statements in the access list.
This method of traffic accounting is preferred, because it is more scalable and easier to maintain. You can make the matching conditions very specific by giving the local (source) and foreign (destination) addresses. The AAA server group named server_tag is used to receive accounting information.
|
AAA Cut-Through Proxy Configuration Examples In a sample network, user authentication is used on a firewall to require users on the inside to authenticate before initiating outbound connections. Users located on the 192.168.128.0/27 subnet should have all traffic except outbound DNS requests subject to authentication. The DNS traffic should be allowed without authentication so that users can resolve host names. Three TACACS+ servers are available on the inside network: 192.168.4.10 192.168.4.11 192.168.4.12
These are tried in succession until a responsive server is found. User authentication should be performed over an HTTPS session so that username and password credentials are encrypted from the client to the firewall. (The TACACS+ exchanges between the firewall and the servers are encrypted as part of the TACACS+ protocol.) After a user is authenticated, the firewall performs cut-through proxy service until the user's sessions have been idle for one hour. After two hours, each user is required to reauthenticate. You can use the following configuration commands to satisfy the cut-through proxy requirements: aaa-server tacacs-servers protocol tacacs+ aaa-server tacacs-servers (inside) host 192.168.4.10 SpecialKey99 aaa-server tacacs-servers (inside) host 192.168.4.11 SpecialKey99 aaa-server tacacs-servers (inside) host 192.168.4.12 SpecialKey99 aaa authentication include any inside 192.168.128.0 255.255.128.0 0 0 tacacs-servers aaa authentication exclude udp/53 inside 192.168.128.0 255.255.128.0 0 0 tacacs-servers aaa authentication secure-http-client timeout uauth 1:00:00 inactivity timeout uauth 2:00:00 absolute
Remember that only Telnet, SSH, FTP, HTTP, and HTTPS traffic can actually trigger a prompt for user authentication. What, then, is the point of excluding DNS for this example? Until a user authenticates, all traffic is dropped. By excluding DNS from authentication, those requests are allowed to pass on through, so the inside users might be able to resolve addresses and then initiate connections like HTTP that can trigger the actual authentication. You can also use an access list to trigger the authentication process. An access list might be preferable if you need fine granularity over combinations of source and destination addresses and protocols. The ACL and AAA commands required for the same example are as follows: access-list acl_aaa_trigger permit ip 192.168.128.0 255.255.128.0 any access-list acl_aaa_trigger deny udp 192.168.128.0 255.255.128.0 any eq domain aaa authentication match acl_aaa_trigger inside tacacs-servers aaa authentication secure-http-client
You can also apply AAA to authorize end-user connections through the firewall. The following command makes all outbound connections from the inside users subject to authorization: aaa authorization include any inside 192.168.128.0 255.255.128.0 0 0 tacacs-servers
Each new connection is presented to the active TACACS+_server in the tacacs-servers server group. The users or user groups must be configured in the TACACS+ servers to authorize the appropriate protocols. Finally, the AAA servers are used to collect accounting information about end-user activity through the firewall. Only HTTP, HTTPS, and FTP connections are recorded. You can use the following firewall configuration commands to implement this accounting action: aaa accounting include http inside 192.168.128.0 255.255.128.0 0 0 tacacs-servers aaa accounting include tcp/443 inside 192.168.128.0 255.255.128.0 0 0 tacacs-servers aaa accounting include ftp inside 192.168.128.0 255.255.128.0 0 0 tacacs-servers
|
