Friday, March 13, 2009

ASA Cut-Through Proxy

From the notes given to me by Rob Chee...

Configure authentication using TACACS+

Aaa-server RAD protocol tacacs
Aaa-server RAD (outside) host 192.168.137.10
Key cisco

Configure login prompt:

auth-prompt prompt Enter Your Authentication
auth-prompt accept You are Good
auth-prompt reject Goodbye

Through traffic authentication – This is the default mechanism for authentication. When a user attempts to access a HTTP, HTTPS, FTP, or telnet resource behind the PIX, the PIX redirects users to an authentication page if the traffic matches the cut-through proxy ACL.

Using Telnet

Static (inside,outside) 192.1681.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 23
Access-list AUTH permit tcp any host 192.l68.137.2 eq 23
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RAD

Using Encryption for HTTP

Static (inside,outside) 192.1681.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 80
Access-list AUTH permit tcp any host 192.l68.137.2 eq 80
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RAD
Aaa authentication secure-http-client

Using HTTPS

Static (inside,outside) 192.1681.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 443
Access-list AUTH permit tcp any host 192.l68.137.2 eq 443
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RAD


The authentication listener mechanism is the recommended method of authentication. With the basic configuration, a user must access a specific URL on the PIX to authenticate. Since it relies on accessing a URL, only the HTTP and HTTPS authentication methods are supported for this mechanism.

Static (inside,outside) 192.1681.137.2 10.100.100.2
aaa authentication match AUTH outside RAD
aaa accounting match AUTH outside RAD
aaa authentication listener HTTPS outside port HTTPS redirect
aaa authentication listener HTTP outside port HTTP redirect

Authenticate against a virtual IP address, configured on the PIX, through HTTP, HTTPS, and Telnet by redirecting to the virtual IP address when they try to access a resource, through the PIX, that matches the cut-through proxy ACL.

Virtual HTTP 192.168.137.20
Virtual Telnet 192.168.137.20

Static (inside,outside) 192.168.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.20 eq 80
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 80
Access-list AUTH permit tcp any host 192.168.137.20 eq 80
Access-list AUTH permit tcp any host 192.168.137.2 eq 80
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RADIUS
! If secure authentication to the PIX is required
Aaa authentication secure-HTTP-client

With RADIUS, authentication and authorization are bound together. This means that verifying authentication and providing authorization are handled during the same negotiation when a user logs in. It also means that no further authorization privileges can be granted after the login.

When RADIUS is used for PIX cut-through proxy, the ACS server provides downloadable ACLs as authorization. This downloadable ACL becomes a temporary ACL that is created on the PIX with a dynamically created name. This ACL can be viewed with “show access-list” after successful authentication. Below is an example of this.

access-list #ACSACL#-IP-cutthroughproxy-47b78823; 3 elements (dynamic)
access-list #ACSACL#-IP-cutthroughproxy-47b78823 line 1 extended permit tcp any host 192.168.137.2 eq telnet (hitcnt=0) 0x78ea2fad
access-list #ACSACL#-IP-cutthroughproxy-47b78823 line 2 extended permit tcp any host 192.168.137.2 eq www (hitcnt=0) 0x4519be9a
access-list #ACSACL#-IP-cutthroughproxy-47b78823 line 3 extended permit tcp any host 192.168.137.2 eq https (hitcnt=5) 0x0c281b01

RADIUS Downloadable ACL Authorization

access-list OUTSIDE extended permit udp host 192.168.137.10 eq radius host 192.168.137.8
access-list OUTSIDE extended permit udp host 192.168.137.10 eq radius-acct host 192.168.137.8
access-list OUTSIDE extended permit udp host 192.168.137.10 eq 1812 host 192.168.137.8
access-list OUTSIDE extended permit udp host 192.168.137.10 eq 1813 host 192.168.137.8
access-list AUTH extended permit tcp any any eq www
access-list AUTH extended permit tcp any any eq HTTPS
access-list AUTH extended permit tcp any any eq Telnet
static (inside,outside) 192.168.137.2 10.100.100.2 netmask 255.255.255.255
access-group OUTSIDE in interface outside per-user-override
aaa-server RADIUS protocol radius
aaa-server RADIUS (outside) host 192.168.137.10
key cisco
aaa authentication match AUTH outside RADIUS
aaa accounting match AUTH outside RADIUS
aaa authentication listener HTTPS outside port HTTPS redirect
auth-prompt prompt Enter Lab Authentication
auth-prompt accept You're In
auth-prompt reject You're Out

TACACS+ Authorization

access-list OUTSIDE extended permit tcp host 192.168.137.10 eq tacacs host 192.168.137.8
access-list AUTH extended permit tcp any any eq www
access-list AUTH extended permit tcp any any eq HTTPS
access-list AUTH extended permit tcp any any eq Telnet
static (inside,outside) 192.168.137.2 10.100.100.2 netmask 255.255.255.255
access-group OUTSIDE in interface outside
aaa-server TAC protocol tacacs
aaa-server TAC (outside) host 192.168.137.10
key cisco
aaa authentication match AUTH outside TAC
aaa authorization match AUTH outside TAC
aaa accounting match AUTH outside TAC
aaa authentication listener HTTPS outside port HTTPS redirect
auth-prompt prompt Enter Lab Authentication
auth-prompt accept You're In
auth-prompt reject You're Out

1 comment:

Dan said...

I've been working with this as well, and I'm troubled that the ASA uses PAP when authenticating against a RADIUS server. I'm fine with the password being encrypted between client and ASA with SSL, but obfuscating the password with RADIUS shared secret has never been my preference on the back end. Are you aware of any way to make the ASA use a "stronger" protocol?

Contributors