The previous section presented a thorough
analysis of the Cut-Through Proxy operation on the ASA family. In the
current one a similar IOS mechanism called Auth-Proxy
is covered in detail. Although the conception and purpose of the
features are similar, they have some distinct operational behaviors.
The differences that deserve special mention follow:
Although the dynamic permissions created by
Cut-Through Proxy are natively stateful, IOS Auth-Proxy permissions are
originally stateless. Nevertheless, after being combined with CBAC or
Zone Policy Firewall, the Auth-Proxy permissions will undergo stateful
inspection and behave much like as ASA’s.
In ASA, inbound Interface ACLs initially have precedence over Cut-Through Proxy derived permissions .
It is therefore necessary to explicitly allow the application protocol
in this ACL before the interception can take place. If the per-user-override option is enabled and a DACL is downloaded, the dynamic permissions take precedence over the static ones.
In
IOS, the Auth-Proxy intercepts the application protocol that triggers
authentication before it reaches the inbound interface ACL. You can see
how this works through the analysis of some usage scenarios.
Although IOS uses the proxyacl RADIUS VSA to download individual ACEs to the NAS, ASA uses the ip:inacl VSA to accomplish this task.
The RADIUS server can send the IETF Filter-ID attribute pointing to an ASA locally defined ACL. The activation of such an ACL in IOS currently requires the usage of the tag-name VSA.
After this brief introduction, you can now get back
to a set of practical usage scenarios that serve to emphasize the
potential of the Auth-Proxy feature.
For the following examples Telnet is chosen as the
triggering protocol because its connections are long living compared to
HTTP. This makes life easier when dealing with debug
commands and viewing established sessions. After becoming familiar with
Auth-Proxy concepts, you are greatly encouraged to proceed an
equivalent analysis using HTTP (or even better, HTTPS) as the
triggering protocol.
Figure 1 shows the reference topology used for the Auth-Proxy scenarios that follow.
![](http://programming4.us/image/022015/IOS%20User-Level%20Control%20with%20Auth-Proxy_1.jpg)
Example 1 shows the relevant AAA commands for the Auth-Proxy scenarios. Example 2 complements the previous one, by including the necessary commands to enable Auth-Proxy for Telnet interception.
Example 1. Baseline AAA Configuration for Auth-Proxy Scenarios
aaa new-model ! ! Instructing the NAS to receive, send and process Vendor Specific Attributes (VSAs) radius-server vsa send accounting radius-server vsa send authentication ! ! Instructing NAS to send the IETF "Service Type" attribute to the RADIUS Server
radius-server attribute 6 on-for-login-auth ! ! Defining the source interface for RADIUS packets
ip radius source-interface Vlan21 ! ! Defining an AAA server-group called "RADIUS1"
aaa group server radius RADIUS1 server 172.21.21.250 auth-port 1812 acct-port 1813 server-private 172.21.21.250 auth-port 1812 acct-port 1813 key 7 13061E010803557878 ! ! This method list will be applied to the console and VTY lines
aaa authentication login CONSOLE none ! ! Auth-Proxy service uses the AAA server-group "RADIUS1" previously defined
aaa authentication login default group RADIUS1 aaa authorization network default group RADIUS1 aaa authorization auth-proxy default group RADIUS1 aaa accounting auth-proxy default start-stop group RADIUS1 ! ! Excluding console and VTY lines from the "default" login method (that uses RADIUS) line con 0 login authentication CONSOLE line vty 0 4 login authentication CONSOLE transport input telnet ssh
|
Example 2. Baseline Auth-Proxy Configuration
! Defining an ACL to be applied to the same interface as Auth-Proxy
access-list 100 permit udp host 172.21.21.250 eq 1812 host 172.21.21.1 access-list 100 permit udp host 172.21.21.250 eq 1813 host 172.21.21.1 access-list 100 permit tcp any 172.16.201.0 0.0.0.255 eq telnet
! Defining the Auth-Proxy policy to intercept Telnet traffic
ip admission name ADMISSION1 proxy telnet ! ! Applying the Auth-Proxy policy to interface Vlan21 (Auth-Proxy incoming interface) interface Vlan21 description *** INSIDE interface *** ip address 172.21.21.1 255.255.255.0 ip access-group 100 in ip admission ADMISSION1
|