Limiting Internet Access Based on User Profile Using ASA and RADIUS
Traditionally, IP Access lists (ACLs) have been used to restrict access to internal resources or to the Internet. With the growing complexity of networks, ACLs fail to provide the kind of dynamic access restrictions that are required. In this Chalk Talk, I am going to summarize Chapter 10 “Cut-through Proxy AAA on PIX/ASA” of the book AAA Identity Management Security, which discusses how ASA and RADIUS can be used to restrict access to Internet (and other network resources) based on user profile.
Cut-through Proxy Authentication
In normal scenarios, traffic from users is checked against interface ACLs and, based on Layer 3 and Layer 4 information, the packet is allowed or dropped. These interface ACLs are the same for all users.
Using the cut-through proxy authentication feature on ASA, it is possible to enforce authentication on all or certain types of traffic. After authentication, certain types of traffic can be denied or permitted based on user profile
To further elaborate the point, consider a situation where all traffic to the Internet goes through an ASA. You want to permit HTTP traffic for everyone but you also want to allow Telnet, FTP and RDP for a group of specific users only. In this situation, the following 2 things will be applied:
Now when ASA receives an outbound Telnet, FTP or RDP traffic on the inside interface, it will enforce authentication and then, based on user profile received from the authentication server, the traffic will be permitted or denied.
The following figure summarizes the steps involved in a typical cut-through proxy authentication.
Configuring Cut-through Proxy Authentication
You should remember the following rules before configuring Cut-Through proxy authentication:
Before enabling cut-through proxy authentication, configure an extended ACL that defines the traffic on which authentication needs to be enforced. Permit statements in the access list define which traffic needs to be authenticated. Deny statements define which traffic needs to be excluded from authentication.
Assuming you already added a RADIUS server on ASA, the following command will enable cut-through proxy authentication:
Note that the interface_name specifies the interface where the traffic is received.
Going back to our example, to enforce authentication on Telnet, FTP and RDP traffic outbound to the Internet, the following configuration can be used:
Virtual Telnet, Virtual HTTP and HTTP Redirection
As mentioned earlier, ASA supports direct authentication with HTTP, HTTPS, FTP, and Telnet protocols only. If authentication is required for any other protocol, the user must authenticate using the supported protocols first. If you do not want to enforce authentication for any of the supported protocols, you can use the Virtual Telnet, Virtual HTTP, or HTTP Redirection features in ASA.
For this section consider an example where you have applied an interface ACL permitting all IP traffic except outbound RDP session to the Internet. Now there is a requirement to permit RDP sessions for a group of users. In this situation you can enforce authentication on RDP using the following commands:
Because RDP traffic cannot be authenticated directly, ASA will drop all RDP traffic after applying the above configuration.. You will need to use one of the methods discussed in this section to first authenticate the user.
Each of the three methods of authenticating unsupported protocols—Virtual Telnet, Virtual HTTP and HTTP Redirection—have their own advantages and disadvantages. Your network, the technical level of the end users, security considerations, and other related considerations determine which method is best for you. Each of the three methods are discussed below:
When a cut-through proxy authentication is successful, ASA stores the authentication information and the user profile in its cache. The entry is created on the first authentication and is valid for any subsequent traffic. This means that if more than one kind of traffic needs authentication, the first authentication will be sufficient for all of them as long as the cache entry exists.
The uauth timer determines how long ASA will maintain the cache entry. When the uauth timer expires, the entry is removed, and the user will need to authenticate again. The uauth timer can be absolute or inactivity based. This means that the uauth timer can be made to expire after a fixed period or if there is no activity for a defined period.
In effect, the uauth timer influences the user experience to a great extent. If the timer is too short, the users will need to authenticate many times. If the timer is too long, the risk of misuse is high. So it is advisable that you experiment with the absolute and inactivity uauth timeouts to find the best range suited for your network.
By default, the uauth timer expires in 5 minutes, irrespective of activity status. You can change the uauth timer default using the following command:
To configure absolute and inactivity timers together, use the command twice. You must ensure that the uauth duration is shorter than the xlate duration. The xlate duration defines the idle time after which an address translation slot is freed. ASA will not accept a timer that is longer than the xlate timer.
You can disable caching by using a uauth timer of 0. The timer can be set to a maximum of 1193:0:0.
Configuring User Profile on RADIUS server for Cut-through Proxy
We know the cut-through Proxy Authentication allows ASA to fetch user profiles from the RADIUS server and permit or deny traffic based on it. What really happens is that the RADIUS server sends an ACL, called downloadable ACL, to the ASA with the Access-Accept packet. ASA replaces the source IP address on the ACL entries with the IP address of the authenticating user and applies it over the Interface ACL. Now, the user’s traffic is checked against this combined ACL before being permitted out. When the uauth timer expires, the downloadable ACL is removed from the ASA.
If you are using CiscoSecure ACS, you can create downloadable ACLs and apply them to the user profile or the user’s group profile. In CiscoSecure ACS 4.x, downloadable ACLs can be configured at Shared Profile Components > Downloadable IP ACLs and applied to the profile from User Setup or Group Setup page.
If you are using CiscoSecure 5.x then downlodable ACLs can be configured at Policy Elements > Authorization and Permissions > Named Permission Objects > Downloadable ACLs. After creating the ACLs, you will need to bind them to an Authorization Profile, which in turn can be applied to an authorization policy that is being used for Cut-through proxy authentication.
Note that the syntax of the downloadable ACL should match the ACL syntax used by ASA.
If you are not using CiscoSecure ACS then the Cisco vendor-specific attribute cisco-av-pair (Vendor ID 009 and attribute number 001) can be used to define downloadable ACLs in a user profile. An example of the ACL defined as the value for cisco-av-pair attribute is given below:
Cut-through proxy AAA is an often neglected part of identity management solutions. Effective use of this feature can strengthen your network security by providing dynamic access policies on a user-by-user basis. It will also ensure that the interface ACLs on ASA stay small and manageable.
Before configuring Cut-through proxy authentication, it is important to identify what traffic needs to be authenticated and remember where you will need to use Virtual Telnet, Virtual HTTP, or HTTP Redirection.
This Chalk Talk focuses on traffic outbound to v same principle can be applied to traffic inbound from the Internet or traffic flowing between different parts of the network separated by ASA.