In many practical situations, there is a
requirement to validate identity and associate the pertinent access
profile before allowing user traffic to flow through the firewall. Cisco ASA devices can fulfill this service need by using the Cut-Through Proxy feature.
If configured for intercepting packets that carry HTTP, HTTPS, Telnet, or FTP, the Cut-through Proxy
feature can leverage the authentication functionality embedded on these
protocols, to present the user with a characteristic username/password
prompt of the application protocol being intercepted. The user
information thus obtained is forwarded to the AAA server for
authentication.
If the user is successfully validated, the
authentication information is cached locally and the ASA creates
dynamic permissions for the application protocol under consideration.
For the duration of some configurable timers (uauth timeouts)
these permissions remain valid and there is no need to reauthenticate
the user, which translates in efficiency for traffic flow.
Figure 1 provides an overview of Cut-Through Proxy operation using HTTP as the triggering protocol.
A simple description of the steps represented in Figure 1 follows:
1. | The user attempts to establish an HTTP connection through the firewall.
|
2. | Cut-Through Proxy intercepts the HTTP request and presents a browser-based authentication prompt to the user.
|
3. | The ASA receives the user credentials and sends an Authentication Request message to the RADIUS server (CS-ACS). |
4. | The RADIUS server authenticates the user and sends an Access-Accept message to the ASA.
|
5. | ASA establishes a connection between the user browser and the web server.
|
This is a brief analysis of the simplest form of operation of the Cut-Through Proxy
mechanism. This initial discussion just considered the task of creating
permissions for the intercepted protocol. But this resource can be used
in many more situations to produce the interesting effect of
authorizing connections associated with protocols that do not natively
support authentication.
Study the instructive usage scenarios presented
throughout this section. They can help unveil the power of
Identity-based control.
Cut-Through Proxy Usage Scenarios
Figure 2
shows the base network topology for the Cut-through Proxy scenarios
investigated hereafter. HTTP is the protocol triggering the
authentication process.
Note
All the ASA Cut-Through Proxy scenarios use RADIUS
as the authentication protocol.
Example 1
is an assembly of the relevant configurations needed on ASA to
implement the Cut-Through Proxy feature. Except for a command added in Example 3, only CS-ACS configurations vary on scenarios 1 through 4.
Example 1. Baseline Configuration for Cut-Through Proxy Scenarios
!Defining the static ACL called "DMZ" and assigning to "dmz" interface
access-list DMZ extended permit tcp 172.21.21.0 255.255.255.0 172.16.200.0 255.255.255.0 eq www
access-list DMZ extended permit tcp 172.21.21.0 255.255.255.0 172.16.200.0 255.255.255.0 eq https
access-group DMZ in interface dmz
!
!Defining an AAA server-group called "RADIUS1"
aaa-server RADIUS1 protocol radius
aaa-server RADIUS1 (dmz) host 172.21.21.250
key cisco123
authentication-port 1812
accounting-port 1813
!
!Defining interesting traffic for authentication (using RADIUS)
access-list DMZ-AUTH1 extended permit tcp any 172.16.200.0 255.255.255.0 eq www
access-list DMZ-AUTH1 extended permit tcp any 172.16.200.0 255.255.255.0 eq https
aaa authentication match DMZ-AUTH1 dmz RADIUS1
!
! Defining interesting traffic for accounting (using RADIUS)
access-list DMZ-ACCT1 extended permit tcp any 172.16.200.0 255.255.255.0 eq www
access-list DMZ-ACCT1 extended permit tcp any 172.16.200.0 255.255.255.0 eq https
access-list DMZ-ACCT1 extended permit tcp any 172.16.200.0 255.255.255.0 eq telnet
aaa accounting match DMZ-ACCT1 dmz RADIUS1
!
!Customizing the authentication prompt presented to users
auth-prompt prompt **** INTERCEPTED BY CUT-THROUGH PROXY ****
|
