Introduction
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:
- An interface ACL permitting HTTP traffic outbound to the Internet
- A cut-through proxy authentication for Telnet, FTP and RDP traffic
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:
- You can configure ASA to enforce authentication on multiple types of sessions; however, the user needs to authenticate only once. This means that after the first authentication, the user profile is cached by the ASA for a duration specified by the User Authentication (uauth) timer.
- When the user authenticates, and ASA activates the uauth timer, those authenticated users will not be required to authenticate again and their traffic will be matched against the profile received from the authentication server.
- ASA supports direct authentication with FTP (TCP port 21), Telnet (TCP port 23), HTTP (TCP port 80), and HTTPS (TCP port 443). A user must first authenticate with one of these services before the security appliance allows other traffic that requires authentication.
- For Telnet and FTP, the security appliance generates an authentication prompt. For HTTP, the security appliance uses basic HTTP authentication and provides an authentication prompt. For HTTPS, the security appliance generates a custom login screen.
- ASA provides means to authenticate users using Virtual Telnet and HTTP sessions in case you do not want to enforce authentication on the supported protocols. This means that if you want to authenticate any other type of traffic, say RDP (TCP port 3389), users will need to initiate a Virtual Telnet or HTTP session to the ASA and authenticate first. When authenticated, they can initiate the other type of sessions. Virtual HTTP and Virtual Telnet sessions are discussed in detailed later in this Chalk Talk.
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:
aaa authentication match acl_name interface_name server_tag
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:
aaa-server radiusserver protocol radius
aaa-server radiusserver host 10.1.2.10
key test
access-list myauth permit tcp 10.0.0.0 255.0.0.0 any eq 23
access-list myauth permit tcp 10.0.0.0 255.0.0.0 any eq 21
access-list myauth permit tcp 10.0.0.0 255.0.0.0 any eq 3389
aaa authentication match myauth inside radiusserver
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:
access-list myauth permit tcp 10.0.0.0 255.0.0.0 any eq 3389
aaa authentication match myauth inside radiusserver
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:
Virtual Telnet - The Virtual Telnet feature enables you to configure an IP address to which users can Telnet to authenticate. When an unauthenticated user Telnets to this IP address, the user is challenged for a username and password, and then authenticated by the RAIUS server. When authenticated, the user sees the message “Authentication Successful” and is disconnected. The user can now access other services that require authentication. The IP Address used for Virtual telnet has to be in the same subnet as the interface on which ASA receives the traffic that needs to be authenticated. ASA will respond to the ARP queries received for the virtual IP address. To configure Virtual Telnet, use the following command:
virtual telnet virtual_telnet_ip_address
If you use Virtual Telnet, the example given above will change to the following:
access-list myauth permit tcp 10.0.0.0 255.0.0.0 any eq 3389
access-list myauth permit tcp 10.0.0.0 255.0.0.0 10.1.1.20 eq 23
aaa authentication match myauth inside radiusserver
virtual telnet 10.1.1.20
Virtual HTTP - Virtual HTTP is similar to Virtual Telnet. In this case, the end user uses HTTP to authenticate instead of Telnet. The IP Address and ACL considerations that apply to Virtual Telnet also apply to Virtual HTTP. ASA uses basic HTTP authentication for Virtual HTTP. It redirects all HTTP connections that require AAA authentication to the HTTP server on the security appliance, where the user is prompted for a username and password. To configure Virtual HTTP, use the following command:
virtual http virtual_http_ip_address
If you use Virtual HTTP, the example given above will change to the following:
access-list myauth permit tcp 10.0.0.0 255.0.0.0 any eq 3389
access-list myauth permit tcp 10.0.0.0 255.0.0.0 10.1.1.20 eq 80
aaa authentication match myauth inside radiusserver
virtual http 10.1.1.20
HTTP Redirection - Redirection is an improvement over the Virtual HTTP method in that it provides an improved user experience when authenticating. The users can connect to the ASA’s interface IP address directly using HTTP or HTTPS and will get an authentication page. The HTTP page used in this method provides information such as the user’s IP address, authentication status and logout button unlike the Virtual HTTP method where no information is displayed. Another benefit with this method is that a Virtual IP address is not required. You can configure HTTP Redirection using the following command:
aaa authentication listener http[s] interface_name [port portnum]
uauth Timer
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:
timeout uauth hh:mm:ss [absolute | inactivity]
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 anAuthorization 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-pairattribute is given below:
ip:inacl#1=permit tcp any any eq 3389
ip:inacl#2=permit tcp any any eq 23
Summary
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.
No comments:
Post a Comment