All Cisco-Network Study Notes: Cut-Through Proxy Authentication

Cut-Through Proxy Authentication
You can configure the firewall to force the users to authenticate before connections are permitted. After successful user authentication, the user's authentication status is cached to permit subsequent connections from the same IP address from where the initial connection authenticated user initiated. The firewall functions as an authentication proxy for the subsequent connections. Subsequent connections simply "cut through" the firewall very efficiently. That's why this feature is called Cut-Through Proxy.

While firewall can intercept all types of IP traffic, it can authenticate only the FTP, Telnet, SSH, HTTP, and HTTPS protocols traffic because of the authentication scheme available for these protocols.

Note that Figure 10-2 will be used for the remainder of the chapter as the AAA for Management and Cut-Through Proxy.

Figure 10-2. A Typical Setup for AAA for Management and Cut-Through Proxy Setup

If the cut-through proxy authentication is enabled on the firewall, when the user connections go through the firewall, they are intercepted by AAA, and the firewall presents a username/password prompt. How a user provides a username and password differs as follows:

For Telnet/SSH The user sees a username prompt, and then a request for a password. If authentication (and authorization) is successful at the firewall, the user is prompted for username and password by the destination host beyond. With Telnet/SSH, the username/password needs to be entered twiceonce for the firewall, and once for the end host.

For FTP The user sees a username prompt first and then the password. The user needs to enter local_username@remote_username for username and local_password@remote_password for password. The firewall sends the local_username and local_password to the AAA server and authenticates the user. If authentication (and authorization) is successful at the firewall, the remote_username and remote_password are passed to the destination FTP server beyond. With FTP, you have the option to enter the username/password once.

For HTTP/HTTPS The user sees a window displayed in the browser requesting username and password. If authentication (and authorization) is successful, the user arrives at the destination website beyond.

Authentication for Cut-Through Proxy
Cut-Through Proxy authentication can be performed by either of the following methods:

Cut-Through Proxy Authentication with Local User Database

Cut-Through Proxy Authentication Using TACACS+/RADIUS Protocol

The sections that follow go through the configuration of these two methods, followed by the troubleshooting steps for Cut-Through Proxy Authentication.

Cut-Through Proxy Authentication with Local User Database
To configure cut-through proxy with the local user database, you need to configure the local user database with the following command on the firewall:

[View full width]PIX(config)# username {name} {nopassword | password password [encrypted]} [privilege
priv_level]}

To remove a user, use the following command:

PIX(config)# no username [name]

You can turn on the authentication for the connections going across the firewall with one of the following ways:

1. Using the include/exclude option

The matching criteria are added to the firewall configuration using an include statement which will trigger the authentication. Exclude is used to exclude the traffic from exemption of cut-through proxy authentication. Use the following syntax to turn on authentication for different types of connection using a LOCAL user database:

[View full width]Firewall(config)# aaa authentication {include | exclude} service if_name local_ip
local_mask [foreign_ip foreign_mask] server_tag

The service can be http/https/telnet/ssh/ftp. It is possible to define these services as tcp/80, tcp/443, tcp/23, tcp/21, and so on. However, remember that not every protocol has native support for interactive authentication capability. For instance, you can define a service as tcp/25 for SMTP, but as the SMTP does not have the interactive native support for an authentication scheme, the packet for the mail traffic will simply be dropped, unless you authenticate from the mail server, and PIX caches the user information for the mail server IP. This can be accomplished with Virtual Telnet, which is discussed in detail in the Case Studies section of this chapter.

if_name in the command indicates the location from which the traffic will be initiated and intercepted by the firewall. Local_ip and local_mask indicate the source IP address of the packet, and the foreign_ip and foreign_mask define the destination address and mask of the traffic. For the inbound traffic, if you have the static defined for the destination IP address, the foreign_ip is the actual server IP on the inside network, not the translated IP that is seen on outside for a specific server or network. For example, if the server on the inside has an IP address of 10.1.1.50, which is translated with an external IP address of 200.1.1.50, then you should use the untranslated address 10.1.1.50, not the translated address 200.1.1.5 in the AAA statement, when you turn on authentication, authorization or accounting.

server_tag for the local user database is always LOCAL, and this is configured within the software.

Example 10-14 shows how to turn on authentication for both inbound and outbound traffic using the local user database.

Example 10-14. Turning on Cut-Through Proxy Authentication With Include/Exclude Option Using Local User Database
! Configure local user database with the following command first. Simple username
! and unsecure password is used for demonstration purpose only. You should choose
! secure password and different username
Firewall(config)# username cisco password cisco privilege 15
! The following static is for destination address translation for the inbound
! traffic, and source address translation for the outbound traffic.
Firewall(config)# static (inside,outside) 200.1.1.0 10.1.1.0 netmask 255.255.255.0
! Following command will turn on cut-through proxy authentication for all inbound
! TCP traffic
Firewall(config)# aaa authentication include tcp/0 outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 LOCAL
! Following statement will exclude exemption for cut-through proxy for only for
! server 10.1.1.100 that is on inside. Note carefully that even though the
! translated IP address for the 10.1.1.100 is 200.1.1.100, this translated IP is
! not used.
Firewall(config)# aaa authentication exclude tcp/0 outside 0.0.0.0 0.0.0.0
10.1.1.100 255.255.255.255 LOCAL
! The following command enables cut-through proxy authentication for the outbound
! http traffic.
Firewall(config)# aaa authentication include http inside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 LOCAL
Firewall(config)#

2. Using access-list

With the include/exclude option, you can turn on cut-through proxy authentication that is based only on source and destination IP and the service type. However, this does not allow authenticating the traffic based on source/destination port information. With access-list, you have this flexibility. Using ACL, you can define your traffic based on 5-tuples: source and destination address and port, and the service type. Then apply the ACL with the authentication statement by using the following command:

Firewall(config)# aaa authentication match acl_name if_name server_tag

Example 10-15 shows how to turn on cut-through proxy authentication using ACL.

Example 10-15. Turning on Cut-Through Proxy Authentication with ACL Option Using Local User Database
! Configure local user database and the statics using the following commands
Firewall(config)# username cisco password cisco privilege 15
Firewall(config)# static (inside,outside) 200.1.1.0 10.1.1.0 netmask 255.255.255.0
! Define two ACLs one for inbound traffic and one for outbound traffic Proxy
! authentication
Firewall(config)# access-list inbound deny tcp any host 10.1.1.100
Firewall(config)# access-list inbound permit ip any any
Firewall(config)# access-list outbound permit tcp any any eq www
! Now apply both of the ACLs with the following two statements to turn on cut-
! through proxy authentication for traffic in both direction that meet the ACL
! criteria.
Firewall(config)# aaa authentication match inbound outside LOCAL
Firewall(config)# aaa authentication match outbound inside LOCAL
Firewall(config)#

A local user database is not scalable for a large network. An external AAA server must be configured to address the scalability issue, which we discuss next.

Cut-Through Proxy Authentication Using RADIUS or TACACS+ Protocol
The configuration on the firewall to turn on cut-through proxy authentication is very similar to that of a local user database, which is discussed in the preceding section. The only exception is the server-groupinstead of using LOCAL, a server group for either RADIUS or TACACS+ protocol must be defined.

Before you attempt any configuration on the firewall for cut-through proxy, we recommend strongly that you configure the AAA server first.

Work through the following steps to configure the Cisco Secure ACS Server so that Firewall can use it for authentication purposes:

Step 1. Log in to the CS ACS GUI

Step 2. Define Firewall as an NAS on the CS ACS Server. To accomplish this, go to Network Configuration, click on the Network Device Group (if the Network Device Group option is turned on), then click on Add Entry for adding an AAA client. In the Add AAA Client window, define the AAA Client Hostname, AAA Client IP Address, and the Key that will be defined on the Firewall for authentication. Select TACACS+ (Cisco IOS) or RADIUS (Cisco IOS/PIX) protocol from the drop-down list of Authenticate Using drop-down box. If you want to use both TACACS+ and RADIUS protocol, be sure to use a different name for the AAA clients.

Step 3. Go to User Setup and add a user. Map the user to a specific group on the Cisco Secure ACS Server.

Step 4. Edit the group that the users are mapped to by going to Group Setup. For the TACACS+ protocol, you do not need any special settings for the group. However, if you use RADIUS protocol, check the [006] Service-Type check box under IETF RADIUS Attributes and select Login from the drop-down box next to it.

Step 5. Click on the Submit+Restart button.

Once AAA server configuration is complete, work through the following steps to configure firewall:

Step 1. Define the AAA server.

You need to define communication parameters for the AAA server to configure on the firewall. First, define the server tag name and identify TACACS+ or RADIUS protocol with the following commands:

Firewall(config)# aaa-server AuthTacacs protocol tacacs+
Firewall(config)# aaa-server AuthRadius protocol radius

Once the name is defined and you have chosen a specific protocol, define the communication details such as IP address and shared secret key of the AAA server by using the following command:

Firewall(config)# aaa-server AuthTacacs (inside) host 192.168.1.5 cisco
Firewall(config)# aaa-server AuthRadius (inside) host 192.168.1.5 cisco

Step 2. Turn on cut-through proxy Authentication.

Just as with the local user database, the cut-through proxy authentication can be turned on either with the include/exclude option or with the access-list option. Example 10-16 shows how to turn on authentication for both inbound and outbound traffic using the TACACS+ protocol.

Example 10-16. Turning on Cut-Through Proxy Authentication with Include/Exclude Option Using TACACS+ Protocol
! The following static is for destination address translation for the inbound
! traffic, and source address translation for the outbound traffic.
Firewall(config)# static (inside,outside) 200.1.1.0 10.1.1.0 netmask 255.255.255.0
! Following command will turn on cut-through proxy authentication for all inbound
! TCP traffic
Firewall(config)# aaa authentication include tcp/0 outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthTacacs
! Following statement will exclude exemption for cut-through proxy for only for
! server 10.1.1.100 that is on inside. Note carefully that even though the
! translated IP address for the 10.1.1.100 is 200.1.1.100, this translated IP is
! not used.
Firewall(config)# aaa authentication exclude tcp/0 outside 0.0.0.0 0.0.0.0
10.1.1.100 255.255.255.255 AuthTacacs
! The following command enables cut-through proxy authentication for the outbound
! http traffic.
Firewall(config)# aaa authentication include http inside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthTacacs
Firewall(config)#

If you want to accomplish the task shown in Example 10-17 with the access-list, follow the procedure it demonstrates.

Example 10-17. Turning on Cut-Through Proxy Authentication with ACL Option Using RADIUS Protocol
Firewall(config)# static (inside,outside) 200.1.1.0 10.1.1.0 netmask 255.255.255.0
! Define two ACLs one for inbound traffic and one for outbound traffic Proxy
! Authentication
Firewall(config)# access-list inbound deny tcp any host 10.1.1.100
Firewall(config)# access-list inbound permit ip any any
Firewall(config)# access-list outbound permit tcp any any eq www
! Now apply both of the ACLs with the following two statements to turn on cut-
! through proxy authentication for traffic in both direction that meet the ACL
! criteria.
Firewall(config)# aaa authentication match inbound outside AuthRadius
Firewall(config)# aaa authentication match outbound inside AuthRadius
Firewall(config)#

Troubleshooting Cut-Through Proxy Authentication
You must ensure that the connection across the firewall works before turning on cut-through proxy authentication. Once cut-through proxy authentication is turned on and if authentication fails, you need to enable logging with debug level turned on (see the "Syslog" subsection under the section entitled "Diagnostic Commands and Tools"). You need to run debug aaa authentication, and debug radius or debug tacacs to find out the details on authentication failure for the cut-through proxy authentication. If the syslog does not provide the cause of failure, you need to analyze the log on the AAA server. For details on how to analyze the log on the CS ACS server, refer to Chapter 13, "Troubleshooting Cisco Secure ACS on Windows."

Before delving into the details of the different issues with cut-through proxy authentication, this section first examines the look of a successful cut-through proxy authentication in the syslog. Example 10-18 shows a successful cut-through proxy authentication for inbound traffic authentication using TACACS+ protocol initiating the packet from 50.1.1.1 to inside 192.168.1.2 (20.1.1.102) and vice versa (see Figure 10-2).

Example 10-18. Successful Authentication for TACACS+ (Inbound)
PIX# logging monitor debug
Jul 25 2005 07:33:51 : %PIX-6-609001: Built local-host outside:50.1.1.1
Jul 25 2005 07:33:51 : %PIX-6-609001: Built local-host inside:192.168.1.2
Jul 25 2005 07:33:51 : %PIX-6-302013: Built inbound TCP connection 5947 for
outside:50.1.1.1/11003 (50.1.1.1/11003) to inside:192.168.1.2/23 (192.168.1.2/23)
Jul 25 2005 07:33:51 : %PIX-6-109001: Auth start for user '???' from 50.1.1.1/11003
to 192.168.1.2/23
Jul 25 2005 07:33:55 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:33:55 : %PIX-6-302013: Built outbound TCP connection 5949 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1428 (172.16.172.164/1428)
Jul 25 2005 07:33:57 : %PIX-2-109011: Authen Session Start: user 'kodom', sid 34
! Following message indicates successful user authentication.
Jul 25 2005 07:33:57 : %PIX-6-109005: Authentication succeeded for user 'kodom' from
50.1.1.1/11003 to 192.168.1.2/23 on interface outside
Jul 25 2005 07:33:57 : %PIX-6-302014: Teardown TCP connection 5949 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1428 duration 0:00:01
bytes 107 TCP FINs
PIX#

For additional details of a successful cut-through proxy authentication, refer to Example 10-19.

Example 10-19. Successful Cut-Through Proxy Authentication with Debug AAA Authentication And Debug Tacacs
PIX# debug aaa authentication
PIX# debug tacacs
JReceived response from , session id 2147485179
Making authentication request for host 171.69.89.217, user , session id: 2147485179
! Username challenged sent to the end user
Processing challenge for user , session id: 2147485179, challenge: Please enter your
username and password:
Username:
ul 25 2005 07:39:59 : %PIX-6-302013: Built inbound TCP connection 5960 for
outside:50.1.1.1/11004 (50.1.1.1/11004) to inside:192.168.1.2/23 (192.168.1.2/23)
Jul 25 2005 07:39:59 : %PIX-6-109001: Auth start for user '???' from 50.1.1.1/11004
to 192.168.1.2/23
Jul 25 2005 07:40:00 : %PIX-7-711002: Task ran for 130 msecs, process = dbgtrace
JReceived response from kodom, session id 2147485179
Making authentication request for host 171.69.89.217, user kodom, session id:
2147485179
mk_pkt - type: 0x1, session_id: 2147485179
user: kodom
Tacacs packet sent
! Sending the start packet to the AAA server
Sending TACACS Start message. Session id: 2147485179, seq no:1
Received TACACS packet. Session id:1683598253 seq no:2
! Getting password here.
tacp_procpkt_authen: GETPASS
Authen Message: Password:
Processing challenge for user kodom, session id: 2147485179, challenge: Password:
ul 25 2005 07:40:03 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:40:03 : %PIX-6-302013: Built outbound TCP connection 5962 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1429 (172.16.172.164/1429)
Received response from kodom, session id 2147485179
JuMaking authentication request for host 171.69.89.217, user kodom, session id:
2147485179
mk_pkt - type: 0x1, session_id: 2147485179
mkpkt_continue - response: ***
Tacacs packet sent
Sending TACACS Continue message. Session id: 2147485179, seq no:3
Received TACACS packet. Session id:1683598253 seq no:4
! Following message indicates a successful cut-through proxy authentication
tacp_procpkt_authen: PASS
user: kodom authenticated, session id: 2147485179
TACACS Session finished. Session id: 2147485179, seq no: 3
l 25 2005 07:40:07 : %PIX-2-109011: Authen Session Start: user 'kodom', sid 35
Jul 25 2005 07:40:07 : %PIX-6-109005: Authentication succeeded for user 'kodom' from
50.1.1.1/11004 to 192.168.1.2/23 on interface outside
Jul 25 2005 07:40:07 : %PIX-6-302014: Teardown TCP connection 5962 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1429 duration 0:00:04
bytes 107 TCP FINs
PIX#

Following is a list of some possible causes of cut-through proxy authentication problems:

Incorrect username or bad password User authentication might fail due to an incorrect username or bad password. In either case, the user will see the following message after getting three opportunities to enter the username and password.

Error: Max number of tries exceeded.

Example 10-20 shows syslog for authentication failure with TACACS+ protocol for inbound traffic.

Example 10-20. Syslog Message for Bad Authentication (Username or Password) TACACS+ (Inbound)
PIX(config)# logging monitor debugging
PIX-A# Jul 25 2005 07:48:16 : %PIX-6-302013: Built inbound TCP connection 5981 for
outside:50.1.1.1/11006 (50.1.1.1/11006) to inside:192.168.1.2/23 (192.168.1.2/23)
Jul 25 2005 07:48:16 : %PIX-6-109001: Auth start for user '???' from 50.1.1.1/11006
to 192.168.1.2/23
Jul 25 2005 07:48:20 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:48:20 : %PIX-6-302013: Built outbound TCP connection 5983 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1433 (172.16.172.164/1433)
Jul 25 2005 07:48:24 : %PIX-6-302014: Teardown TCP connection 5983 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1433 duration 0:00:03
bytes 108 TCP FINs
Jul 25 2005 07:48:30 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:48:30 : %PIX-6-302013: Built outbound TCP connection 5984 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1434 (172.16.172.164/1434)
Jul 25 2005 07:48:32 : %PIX-6-302014: Teardown TCP connection 5984 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1434 duration 0:00:01
bytes 107 TCP FINs
Jul 25 2005 07:48:39 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:48:39 : %PIX-6-302013: Built outbound TCP connection 5985 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1435 (172.16.172.164/1435)
! Following failed message indicates a failure with either username/password.
Jul 25 2005 07:48:41 : %PIX-6-109006: Authentication failed for user 'kodom' from
50.1.1.1/11006 to 192.168.1.2/23 on interface outside
Jul 25 2005 07:48:41 : %PIX-6-302014: Teardown TCP connection 5985 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1435 duration 0:00:01
bytes 109 TCP FINs
Jul 25 2005 07:48:42 : %PIX-6-302014: Teardown TCP connection 5981 for outside:50.1.1.1/
11006 to inside:192.168.1.2/23 duration 0:00:25 bytes 374 TCP FINs
PIX#

Communication Problem between PIX and AAA Server Several conditions might be considered communication problems between the PIX and AAA Server:

- PIX may not have proper routing. Execute ping from the PIX to verify.

- PIX has connectivity, but TACACS+ or RADIUS protocols might be blocked by a firewall between PIX and the AAA server.

- The shared secret might be a mismatch between the PIX and AAA Server.

- PIX might not be defined as the AAA client on the AAA Server.

Under any of these circumstances, PIX might be unable to send the authentication information to the AAA server, and this will result in authentication failure. The user sees a username, then a password, then RADIUS server failed, and then finally Error: Max number of tries exceeded. See Example 10-21 to see the syslog message when TACACS+ is used for inbound authentication, and the authentication fails.

Example 10-21. Syslog Message When PIX Has Communication Problem with AAA Server
PIX(config)# logging monitor debug
PIX-A# Jul 25 2005 07:55:12 : %PIX-6-302013: Built inbound TCP connection 5987 for
outside:50.1.1.1/11007 (50.1.1.1/11007) to inside:192.168.1.2/23 (192.168.1.2/23)
Jul 25 2005 07:55:12 : %PIX-6-109001: Auth start for user '???' from 50.1.1.1/11007
to 192.168.1.2/23
Jul 25 2005 07:55:16 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:55:16 : %PIX-6-302013: Built outbound TCP connection 5989 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1436 (172.16.172.164/1436)
Jul 25 2005 07:55:16 : %PIX-6-302014: Teardown TCP connection 5989 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1436 duration 0:00:00
bytes 0 TCP Reset-O
! Following message indicates server is unavailable
Jul 25 2005 07:55:16 : %PIX-6-109002: Auth from 50.1.1.1/11007 to 192.168.1.2/23
failed (server 171.69.89.217 failed) on interface outside
Jul 25 2005 07:55:16 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 07:55:16 : %PIX-6-302013: Built outbound TCP connection 5990 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1437 (172.16.172.164/1437)
PIX#

User's Account Locked Out If you configure a lockout feature on the AAA server after a certain number of failed authentication attempts, the user account will be locked out. Hence, subsequent authentication requests will fail. Re-enable the user account so that it can authenticate.

User reached the MAX session limit If you have a session limit configured on the AAA server, be sure that you do not exit more often than the number of times that is configured for simultaneous authentication for a specific user or a group.

User Reaches the Proxy Limit If you have too many simultaneous connection requests, you may run short of the proxy limit, which is by default 16. So, if a user makes 17 connection requests at the same time across the firewall, one connection will not be authenticated and the connection will be dropped. You can disable proxies by using the disable parameter. To return to the default proxy-limit value (16), use the no form of this command.

aaa proxy-limit proxy_limit
aaa proxy-limit disable
no aaa proxy-limit

Authorization for Cut-Through Proxy
To control the resources users may access once they are authenticated, you need to implement authorization. On the other hand, if you want to allow authenticated users to perform all operations, then authentication is sufficient. Authorization can be performed either with the TACACS+ or RADIUS protocol. Even though a PIX firewall supports a local user database for cut-through proxy authentication, it does not support authorization. Authorization for a cut-through proxy is implemented differently using TACACS+ and RADIUS protocols due to the different nature of the protocols.

Authentication and authorization are performed separately in TACACS+, whereas in RADIUS both authentication and authorization are performed together. Therefore, command authorization is possible with TACACS+, but not with RADIUS.

When an end user who is going through the firewall tries to Telnet/FTP/HTTP/HTTPS to an IP address of a server, the packets are intercepted and authenticated, and then the Telnet/FTP/HTTP/HTTPS are sent to the AAA server as commands, and the IP address after that goes as arguments to the TACACS+ server for the command authorization. For example, if the user enters http 192.168.1.105 on the browser, after successful user authentication, if the authorization is turned on for HTTP traffic for the specific destination, the firewall will send http as a command and 192.168.1.105 as an argument to the TACACS+ server for command authorization.

Authorization can be performed for any type of pass-through IP traffic across the firewall. For example, if you want to authorize the SMTP mail traffic, you can perform authentication from the main server using Telnet/FTP/HTTP/HTTPS, which will cause the firewall to cache the IP address of the mail server. Then, if the authorization is turned on for the mail server using tcp/25 as the service, mail traffic will be authorized. On the TACACS+ server, you need to ensure that tcp/25 is configured as the command and the destination IP address (not the mail server IP address) is configured as argument.

If you want to have more granular control with authorization, configure an access-list on the firewall and then download the name of the access-list from the TACACS+ server. Support for ACL for command authorization is introduced in PIX Firewall Version 5.2.

Authorization with RADIUS protocol for the pass-through traffic is only possible via ACL, which will be discussed in the coming section.

Note

To implement authorization for HTTP in an enterprise network, use URL filtering software such as Websense, N2H2, and so on. AAA Authorization implementation for HTTP authorization is limited based on the IP address not on the DNS, or other important criteria that these URL filtering servers offer.

Configuration steps for the cut-through proxy authorization are discussed in next two sections.

Configuring Cut-through Proxy Authorization using the TACACS+ Protocol
The cut-through proxy authorization configuration discussed in this section is based on Figure 10-2.

Configuring cut-through proxy authorization using the TACACS+ protocol is a two-step process: configuring user and group profiles with command authorization on the TACACS+ server, and enabling authorization on the firewall. For this configuration, Cisco Secure ACS on Windows is used. It supports the TACACS+ protocol.

Work through the steps that follow to configure the Group Profile on the ACS on Windows for Authorization. To illustrate this better, assume that you want the user to be able to use Telnet to access 20.1.1.100, use FTP to access 20.1.1.101, and use HTTP to access any website.

Step 1. Assume that PIX already was added as NAS during authentication configuration earlier on the CS ACS using TACACS+.

Step 2. Select Group Setup from the Navigation bar on the left side, choose the Group on the next window, and click on Edit. This is the group to which the end users belong that need to be authenticated by the firewall.

Step 3. On the Group Setup page, Choose TACACS+ from the Jump To drop-down box. That will take you to the TACACS+ configuration section of the page.

Step 4. Check Shell Exec, and under Shell Command Authorization Set, choose the Per Group Command Authorization button.

Step 5. Click Deny unmatched IOS commands.

Step 6. Check the Command check box. In the text box next to the command check box, enter telnet as the command, and in the Arguments: rectangle box, enter permit 20.1.1.100 as argument. Finally, choose Deny for Unlisted arguments.

Step 7. Click on the Submit + Restart button to restart the CS ACS services.

Step 8. To allow the FTP access to 20.1.1.101, follow steps 6 and 7. Instead of using telnet as a command, use ftp, and for argument use 20.1.1.101.

Step 9. To allow HTTP access to all sites, in the command text box, enter http, leave the arguments rectangle box blank, and for the Unlisted arguments, choose permit.

Step 10. Finally, click the Submit+Restart button.

Step 11. If you want to have more granular control using an access-list, define an ACL on the PIX firewall but do not apply this ACL on any interface. Check the Access control list box, and fill in the number (for example, access-list 115 is defined)

Step 12. Click the Submit+Restart button.

When you are finished with the CS ACS configuration, the next step is to enable authorization on the firewall as shown in Example 10-22.

Example 10-22. Turning on Authorization for Cut-Through Proxy
PIX# configure terminal
! Following three lines will turn on authorization for inbound traffic (telnet/http/ftp)
! using TACACS+ protocol. This is the only syntax available prior to PIX firewall version
! 5.2. The same syntax can be used on the latest version of PIX as well.
PIX(config)# aaa authorization include telnet outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthInbound
PIX(config)# aaa authorization include http outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
AuthInbound
PIX(config)# aaa authorization include ftp outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
AuthInbound
! If you are running PIX version 5.2 and above, it is strongly recommended to use the
! following syntax. The same ACL 101 that was created for earlier can be applied for the
! authorization as well. Hence, you just need to turn on authorization with the ACL 101
! earlier created to turn on authorization for cut-through proxy.
PIX(config)# aaa authorization match 101 outside AuthInbound
! If you want to have more granular control for instance you want to control the traffic
! based on 5-tuple of the connection source/destination port, source/destination IP
! address and the protocol. Define ACL 115 with along with the authorization line defined
! earlier. Do not apply the ACL on any interface.
PIX(config)# access-list 115 permit tcp any host 50.1.1.1 eq telnet
PIX(config)# access-list 115 permit tcp any host 50.1.1.1 eq www
PIX(config)# access-list 115 permit tcp any host 50.1.1.1 eq ftp
PIX(config)# access-list 115 deny tcp any host 30.1.1.1 eq www
PIX(config)# access-list 115 deny tcp any host 30.1.1.1 eq ftp
PIX(config)# access-list 115 deny tcp any host 30.1.1.1 eq telnet
PIX(config)# exit
PIX#

Caution

In Example 10-22, both ways to enable authorization for cut-through proxy are shown. Use either method, but not both. Otherwise, undesirable results will occur.

Troubleshooting Cut-Through Proxy Authorization using the TACACS+ Protocol
Most authorization problems for the cut-through proxy using the TACACS+ protocol arise because of a lack of understanding and misconfiguration. Careful review of the configuration of both the firewall and the AAA server can eliminate many problems. However, logs and debug commands available on the firewall, and the log on the Cisco Secure ACS software, can help you to nail down any problem. It's important to learn how to use the log and the debug/show command efficiently. It is equally important to be extremely familiar with the AAA server log. Refer to Chapter 13, "Troubleshooting Cisco Secure ACS on Windows" for details on how to use the logging capability on Cisco Secure on Windows software.

By now, you should be familiar with how to turn on the syslog in the debug level. Therefore, go through the debug level log for a successful user authorization session and become comfortable with it, so that you can easily identify a deviation when authorization does not work under a specific condition. Example 10-23 shows syslog when user authentication and authorization is successful.

Example 10-23. Syslog for a Successful Authentication and Authorization Using the TACACS+ Protocol
PIX(config)# logging monitor debugging
Jul 25 2005 08:10:32 : %PIX-6-302013: Built inbound TCP connection 5995 for
outside:50.1.1.1/11008 (50.1.1.1/11008) to inside:192.168.1.2/23 (192.168.1.2/23)
Jul 25 2005 08:10:32 : %PIX-6-109001: Auth start for user '???' from 50.1.1.1/11008
to 192.168.1.2/23
Jul 25 2005 08:10:35 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 08:10:35 : %PIX-6-302013: Built outbound TCP connection 5997 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1440 (172.16.172.164/1440)
Jul 25 2005 08:10:37 : %PIX-2-109011: Authen Session Start: user 'kodom', sid 36
! Following line indicates authentication is successful
Jul 25 2005 08:10:37 : %PIX-6-109005: Authentication succeeded for user 'kodom' from
50.1.1.1/11008 to 192.168.1.2/23 on interface outside
Jul 25 2005 08:10:37 : %PIX-6-302013: Built outbound TCP connection 5998 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1441 (172.16.172.164/1441)
Jul 25 2005 08:10:37 : %PIX-6-302014: Teardown TCP connection 5997 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1440 duration 0:00:02
bytes 107 TCP FINs
Jul 25 2005 08:10:37 : %PIX-6-302013: Built outbound TCP connection 5999 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1442 (172.16.172.164/1442)
Jul 25 2005 08:10:37 : %PIX-6-302014: Teardown TCP connection 5998 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1441 duration 0:00:00
bytes 87 TCP FINs
! Following line indicates authorization is successful
Jul 25 2005 08:10:37 : %PIX-6-109007: Authorization permitted for user 'kodom' from
50.1.1.1/11008 to 192.168.1.2/23 on interface outside
Jul 25 2005 08:10:37 : %PIX-6-302014: Teardown TCP connection 5999 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1442 duration 0:00:00
bytes 101 TCP FINs
PIX#

Now that you are familiar with a successful user authentication and authorization, go through Example 10-24, which shows an example of user authorization failure with TACACS+ protocol, but of successful authentication.

Example 10-24. Syslog for Successful Authentication with Authorization Failure Using the TACACS+ Protocol
PIX(config)# logging monitor debugging
Jul 25 2005 08:15:47 : %PIX-6-302013: Built inbound TCP connection 6009 for
outside:50.1.1.1/11009 (50.1.1.1/11009) to inside:192.168.1.2/23 (192.168.1.2/23)
Jul 25 2005 08:15:47 : %PIX-6-109001: Auth start for user '???' from 50.1.1.1/11009
to 192.168.1.2/23
Jul 25 2005 08:15:50 : %PIX-6-609001: Built local-host outside:171.69.89.217
Jul 25 2005 08:15:50 : %PIX-6-302013: Built outbound TCP connection 6011 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1443 (172.16.172.164/1443)
Jul 25 2005 08:15:53 : %PIX-2-109011: Authen Session Start: user 'kodom', sid 37
! Authentication is successful.
Jul 25 2005 08:15:53 : %PIX-6-109005: Authentication succeeded for user 'kodom' from
50.1.1.1/11009 to 192.168.1.2/23 on interface outside
Jul 25 2005 08:15:53 : %PIX-6-302013: Built outbound TCP connection 6012 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1444 (172.16.172.164/1444)
Jul 25 2005 08:15:53 : %PIX-6-302014: Teardown TCP connection 6011 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1443 duration 0:00:03
bytes 107 TCP FINs
Jul 25 2005 08:15:53 : %PIX-6-302013: Built outbound TCP connection 6013 for
outside:171.69.89.217/49 (171.69.89.217/49) to NP Identity Ifc:172.16.172.164/
1445 (172.16.172.164/1445)
Jul 25 2005 08:15:53 : %PIX-6-302014: Teardown TCP connection 6012 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1444 duration 0:00:00
bytes 87 TCP FINs
! Authorization is failing for telnet session.
Jul 25 2005 08:15:53 : %PIX-6-109008: Authorization denied for user 'kodom' from
50.1.1.1/11009 to 192.168.1.2/23 on interface outside
Jul 25 2005 08:15:53 : %PIX-6-302014: Teardown TCP connection 6013 for
outside:171.69.89.217/49 to NP Identity Ifc:172.16.172.164/1445 duration 0:00:00
bytes 101 TCP FINs
Jul 25 2005 08:15:54 : %PIX-6-302014: Teardown TCP connection 6009 for
outside:50.1.1.1/11009 to inside:192.168.1.2/23 duration 0:00:06 bytes 170 TCP
FINs (kodom)
PIX#

The log in Example 10-24 shows that authorization failed for the specific IP and port on the outside interface of the firewall. To understand why, analyze the log on the AAA server. For your setup, you are using Cisco Secure ACS as an AAA server. So, go under "Reports and Activity" and then "Failed Attempt," and find out how the commands are parsing to the AAA server from the firewall. Get the syntax from there and apply the same command and argument on the Group setup.

Following are some important points to check to ensure that authorization is configured correctly:

Verify that Shell/Exec is turned on under the TACACS+ Settings of the Group profile to which the user belongs.

Check that the ACL tag defined on the TACACS+ server matches the one defined on the PIX firewall.

Ensure that traffic is allowed on the ACL that is defined on the PIX firewall, and that the tag is downloaded to the PIX firewall.

Define the complete syntax of the commands when defining command authorization. If authorization fails, look under the Reports and Activity section for the failed attempt and find out how the commands are sent to the Cisco Secure ACS server. Based on this information, be sure to permit the commands and the arguments.

Configure the authorization to intercept the traffic for authorization on the PIX firewall. Otherwise, the authorization may be skipped.

For the inbound cut-through proxy, define the local IP address as the destination, not the translated IP in the include/exclude statement.

Define the authorization traffic for authentication, because authorization traffic will be denied if authentication is not performed on the traffic.

Configuring Cut-through Proxy Authorization using the RADIUS Protocol
As the RADIUS protocol cannot perform command authorization, it must rely on the access-list to control the traffic going across the firewall. Whereas the TACACS+ protocol can implement authorization using an access-list in addition to command authorization, ACL usage for controlling traffic is very limited; only downloading the ACL name/number is possible. ACL usage to control the traffic using the RADIUS protocol is very flexible. In addition to having the ability to download the ACL name from the RADIUS server, it is also possible to define and download the contents of the ACL using the RADIUS protocol. The following list explains methods available to implement authorization with ACL using the RADIUS protocol:

Downloading the name of the ACL from RADIUS Server

Defining access-lists on the firewall without applying any interface

Defining the ACL number under the user profile on the RADIUS server

Upon successful authentication, downloading the number from the AAA server to activate the ACL for controlling users' access to different network resources.

Note

Unlike TACACS+, you do not need to enable authorization on the firewall to download the ACL from the RADIUS Server. This is because the ACL name or the content of the ACL is downloaded from the RADIUS Server as part of the Access Accept packet of the RADIUS Protocol. There is no need to turn on authorization.

On the Cisco Secure ACS Server, access-list name or number can be defined in one of the two following ways.

Using vendor-specific Attribute Beginning with PIX Firewall Version 5.2, you can define the ACL using the vendor-specific attribute. A vendor-specific attribute for the ACL can be set under the Group setup by checking the box 009\001 AV_Pair (vendor-specific), and defining acl=115 in the Cisco/RADIUS rectangular box.

Using Standard IETF attribute Beginning with PIX Version 6.0.1, the ACL name/number can be defined using a standard Internet Engineering Task Force (IETF) RADIUS attribute 11 (Filter-Id).

Access-list 115 needs to be defined on the firewall.

Downloading the contents of the ACL from the RADIUS Server

If you have a large number of ACLs to manage for different users, the number of ACLs can outgrow the capacity of the memory of the firewall. In addition, if you have more than one firewall using the same policy to control the traffic, every firewall must be locally configured with the same ACL. So the authorization implementation defining the ACL on the firewall may not be scalable. To address this issue, you can define the ACL content on the AAA server and then download the ACL based on user authentication to one, or more than one, firewall. You must be running PIX Firewall Version 6.2 or above to implement this feature.

Note

Downloading contents of the ACL from the AAA server is not possible with the TACACS+ protocol. With TACACS+, only downloading the ACL name or number is possible, as discussed before.

You can define the ACL on the Cisco Secure ACS server in one of the following ways:

Using a Vendor-Specific Attribute

You can use a Cisco vendor-specific attribute to define the ACL that may be downloaded to the firewall. To set this up on the CS ACS Server, edit the group to which the users belong, and go under RADIUS (Cisco IOS/PIX) settings. Choose the [009\001] cisco-av-pair check box, and define the contents of the ACL that is displayed in a rectangular box, as shown in Figure 10-3, to allow only Telnet access and deny all other traffic.

ip:inacl#=permit tcp any any eq telnet
ip:inacl#=deny ip any any

Figure 10-3. Defining ACL Using the Cisco IOS/PIX RADIUS Attribute.

[View full size image]

Finally click the Submit + Restart button.

Using Shared Profile Components

If you have multiple groups that require the same ACL to be applied, defining the same ACL for different groups is not a very scalable solution. Beginning with Cisco Secure ACS 3.0, you can configure a Shared Profile Component, which is a template for the ACL that can be applied to different user groups.

Note

Configuring a Shared Profile component may not be possible with RADIUS servers from other vendors. Defining a Shared Profile Component is possible only if you are running Cisco Secure ACS version 3.0 and above.

Before you can configure a Shared Profile Component on the CS ACS, you must enable that option. Go to the Interface Configuration > Advance Options page. Then check either the User-Level Downloadable ACLs or Group-Level Downloadable ACLs checkbox or both checkboxes, based on your requirements. Finally, click on Submit.

Next you need to define the Shared Profile Component (ACL template), which can be mapped to different groups. To accomplish this task, click on Shared Profile Components, then Downloadable IP ACLs, and then Add. This will display the Downloadable IP ACLs window, where you need to define the Name and, optionally, Description. To define ACL contents for this ACL, click on Add, which will bring up the Downloadable IP ACL Content page (see Figure 10-4), where you need to provide a Name. In the ACL Definitions rectangle box, define the actual ACE in the ACL which follows the same syntax as the extended ACL of the firewall. For example, to allow only Telnet traffic, the syntax for the ACL Definitions will resemble the following:

Permit tcp any any eq telnet