Case Studies
As discussed earlier, only Telnet/SSH/FTP/HTTP/HTTPS protocols have the option to provide the interactive authentication method, hence implementing the cut-through proxy is possible. However, for a mail server, an IP phone or printer does not have the options to provide the interactive authentication prompt. Under this circumstance, if authentication is not required, it is best is to configure AAA Exemption for these devices. However, if authentication is required for these devices, then to work around the problem posed by cut-through proxy authentication, Virtual Telnet or HTTP might be required. This case study section explores these options in detail and shows you how to get around some of the unique problems posed by the cut-through proxy configuration on the firewall.
Case Study 1: AAA Exemption
If authentication is not required, and you want avoid the problem with cut-through proxy authentications for the applications that do not have the capability to present interactive authentication prompts, you can use either of the following options as described in the sections that follow:
IP Exemption
MAC Exemption
IP Exemption
If you know the source and or the destination IP address of the devices for which you want to bypass authentication, you can use IP exemption.
You can exempt the IP from authentication and authorization in two ways, as shown in Example 10-32.
Example 10-32. Configuration for IP Exemption on the Firewall
! Following shows one of the two ways how to exempt IP from authentication and
! authorization.
Firewall(config)# aaa authentication exclude telnet outside 192.168.1.2
255.255.255.255
30.1.1.1 255.255.255.255 AuthTacacs
Firewall(config)# aaa authorization exclude telnet outside 192.168.1.2
255.255.255.255
30.1.1.1 255.255.255.255 AuthTacacs
! Following lines shows rest of the other telnet traffic will be intercepted for the
! authentication and authorization.
Firewall(config)# aaa authentication include telnet outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthTacacs
Firewall(config)# aaa authorization include telnet outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthTacacs
! The same task can be accomplished by access-list as well as shown in the following
! lines. Make sure not to configure both option as that will cause firewall to behave
! very unpredictable manner.
Firewall(config)# access-list 101 deny tcp host 30.1.1.1 host 192.168.1.2 eq telnet
Firewall(config)# access-list 101 permit tcp any any eq telnet
Firewall(config)# aaa authentication match 101 outside AuthTacacs
Firewall(config)# aaa authorization match 101 outside AuthTacacs
Firewall(config)#
Note
If you exempt an IP from authentication, you also must exempt the same IP from authorization if authorization is enabled; otherwise, packets will be dropped by the authorization.
MAC Exemption
IP Exemption works well if the devices behind the firewall have the static IP address. However, if the devices are assigned IP addresses dynamically, the IP Exemption does not work. This is where MAC Exemption is required. This feature is first introduced in PIX Version 6.3.
In MAC Exemption, both the IP address and MAC address of the traffic are checked to avoid the security risk of allowing a spoofed MAC address traffic to bypass authentication. If a firewall receives the first request for connection from a specific MAC address, the MAC will not exist in the cache of uauth table, which can be viewed by using the show uauth command on the firewall. Hence cut-through proxy authentication will be prompted. If subsequent connections are coming from the same MAC and the IP address, the connections will be bypassed from authentication. However, if the packet comes from the same MAC but a different IP address, authentication will be required.
Both authentication and authorization are bypassed if MAC Exemption is turned on. You can define the addresses that should bypass the authentication with the following command:
PIX(config)# [no] mac-list id deny|permit mac macmask
After a mac-list is defined, you can use the following command to turn on MAC Exemption:
PIX(config)# [no] aaa mac-exempt match id
You can view the mac-list with the following command:
PIX# show running-config mac-list [id]
To clear the mac-list, you can use the following command:
PIX(config)# clear configure mac-list [id]
Table 10-9 shows the meaning of arguments for the preceding commands.
Table 10-9. mac-list and mac-exempt Command Arguments Arguments
Meaning
Id
MAC access list number.
Deny
Traffic matching deny is not included in the MAC list and is subjected to both authentication and authorization.
Permit
Traffic matching permit is included in the MAC list and is exempt from authentication and authorization.
Mac
Source MAC address in aabbcc.ddeeff.gghhii form.
Macmask
Applies the netmask to mac, which is a string of 1's followed by 0's in the form aabbcc.ddeeff.gghhii, and allows the grouping of MAC addresses.
Show
Provides the MAC-list in the privilege mode.
Clear
Removes the mac-list command statements along with the rest of the AAA configuration.
Example 10-33 shows how to configure a MAC access list.
Example 10-33. MAC Access List Configuration
PIX(config)# mac-list adc permit 00a0.c95d.0282 ffff.ffff.ffff
PIX(config)# mac-list adc deny 00a1.c95d.0282 ffff.ffff.ffff
PIX(config)# mac-list ac permit 0050.54ff.0000 ffff.ffff.0000
PIX(config)# mac-list ac deny 0061.54ff.b440 ffff.ffff.ffff
PIX(config)# mac-list ac deny 0072.54ff.b440 ffff.ffff.ffff
!Following show command shows the mac-list configuration
PIX(config)# show running-config mac-list
mac-list adc permit 00a0.c95d.0282 ffff.ffff.ffff
mac-list adc deny 00a1.c95d.0282 ffff.ffff.ffff
mac-list ac permit 0050.54ff.0000 ffff.ffff.0000
mac-list ac deny 0061.54ff.b440 ffff.ffff.ffff
mac-list ac deny 0072.54ff.b440 ffff.ffff.ffff
!Following command bind the ac mac-list to the aaa mac-exempt
PIX(config)# aaa mac-exempt match ac
PIX(config)#
AAA Exemption with IP or MAC should be configured only when you want to bypass the authentication for certain IP or MAC addresses that do not support interactive authentication prompts. However, if the cut-through proxy authentication is required for these devices, then you need to configure Virtual Telnet on the firewall, which is discussed next.
Case Study 2: Virtual Telnet
Virtual Telnet can be used to address one of the following issues:
To use Next PIN or New PIN mode with an SDI server
To authenticate uncommon protocols (For example SMTP)
To authorize uncommon protocols (For example SMTP)
This section examines both configuration and troubleshooting of Virtual Telnets.
Configuring Virtual Telnet
Inbound virtual Telnet is implemented based on Figure 10-2. Authenticating mail inbound is not a good idea, as there is no interactive window displayed for mail to be sent inbound. Using the AAA Exemption is a better choice as discussed in the preceding section. However, if you really want to authenticate the mail traffic, you can accomplish that with the command shown in Example 10-34. The same implementation can be used for other uncommon protocols that do not have interactive authentication, such as TFTP.
Example 10-34. Configuration Needed for Inbound Mail Traffic Authentication
PIX# configure terminal
! The following statement is required for authenticating the mail traffic.
PIX(config)# aaa authentication include tcp/25 outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthTacacs
! The following statement is needed to turn on authorization.
PIX(config)# aaa authorization include tcp/25 outside 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 AuthTacacs
! The above two lines can be substituted by creating ACL and applying it with AAA as
! shown below.
PIX(config)# access-list 101 permit tcp any any eq smtp
PIX(config)# aaa authentication match 101 outside AuthTacacs
PIX(config)# aaa authorization match 101 outside AuthTacacs
! Following command is needed to turn on Virtual telnet on IP address 20.1.1.3. You need
! to make sure to create a static for this IP address for the inbound traffic. Also make
! sure to create the static for the actual destination.
PIX(config)# virtual telnet 20.1.1.3
! Following line is to create the static translation for Virtual IP address 20.1.1.3
PIX(config)# static (inside,outside) 20.1.1.3 192.168.1.103 netmask 255.255.255.255 0 0
! Following line is to create the static for the actual mail server
PIX(config)# static (inside,outside) 20.1.1.102 192.168.1.2 netmask 255.255.255.255 0 0
! Following access-list is to include Virtual server IP address for telnet for cut-thru
! proxy authentication
PIX(config)# access-list 110 permit tcp any host 20.1.1.3 eq telnet
! Following line is to configure cut-through proxy authentication for the mail server.
PIX(config)# access-list 110 permit tcp any tcp host 20.1.1.102 eq smtp
PIX(config)# access-group 110 interface outside in
PIX(config)#
Use the following procedure to configure the Cisco Secure ACS Server for the mail authentication:
Step 1. On CS ACS GUI, click on Group Setup, select the group to edit.
Step 2. On the Group Setup page, under TACACS+ Settings, check the Shell (exec).
Step 3. Under Shell Command Authorization Set, select the Per Group Command Authorization radio button.
Step 4. For Unmatched Cisco IOS commands select the Deny radio button.
Step 5. Check the Command box, and enter telnet as the command. Leave the argument rectangle blank, and choose Unlisted Arguments as Permit.
Step 6. Finally, click the Submit+Restart button.
With the preceding configuration, users first need to use Telnet to access the Virtual IP address from outside. This will authenticate the user, and caches the authentication based on source IP address. Then the user can send mail traffic. If authorization is turned on, you need to create the access-list on the PIX firewall and define this ACL number to the Group Profile under TACACS+ Settings. You need to check the Access control list checkbox and in the textbox next to it, put the ACL tag configured on the PIX firewall.
To authenticate outbound mail traffic, the procedure is the same. You do not however, need to configure static for the Virtual IP address for the Telnet.
Note
After successful user authentication, Virtual Telnet caches the user authentication and authorization information, which can be viewed with the show uauth command. This allows anyone from the authenticated host to bypass the authentication/authorization. To prevent this, if you want to clear the cache in the uauth table of the firewall after you finish your task, you need to Telnet to the virtual Telnet IP address again. This toggles the session off.
Troubleshooting Virtual Telnet
Troubleshooting Virtual Telnet is the same process as for the cut-through proxy authentication. Most of the problems pertaining to Virtual Telnet arise from the misconfiguration of the Virtual Telnet IP address. Following are some of the most important points you need to keep in mind when configuring Virtual Telnet:
For the inbound traffic, the virtual Telnet IP address must be a routable IP which is reachable from the end-user PC. For outbound traffic, the address can be a private address if it is reachable from the end user PC.
For inbound traffic, the virtual IP address must have an internal private address. For outbound traffic, translation is not required for the virtual IP address.
For both inbound/outbound traffic, virtual IP addresses must be included for AAA authentication.
A virtual IP address must be unique, which means that this address should not be used for any host in the network.
The virtual IP address for Telnet should not be the same as the virtual HTTP address, as discussed in the next case study.
Case Study 3: Virtual HTTP
Virtual HTTP is needed for the following reasons:
To avoid multiple authentications while visiting different sites
To avoid authentication failure if the web server requires a second authentication (double authentication)
To work with New PIN Mode for the web traffic, you must configure Virtual Telnet along with Virtual HTTP
If the web server requires user authentication in addition to a cut-through proxy authentication on the PIX firewall, you might consider configuring Virtual HTTP. Otherwise, the browser cache could cause problems with web server authentication.
The configuration for Virtual Telnet is very similar to that of Virtual HTTP except for the protocol type. With virtual Telnet, you use Telnet protocol, and for virtual HTTP, the HTTP protocol is used.
Following is the command needed to implement virtual HTTP:
virtual http #.#.#.# warn
Note the following important points:
When the user tries to go outside the PIX, authentication is required. If the warn parameter is present, the user receives a redirect message.
The authentication is good for the length of time in the uauth.
Do not set the timeout uauth command duration to 0 seconds with virtual HTTP. This blocks HTTP connections to the real web server.
The virtual HTTP IP address must be unique and can not be in use anywhere else in the network.
If the ACL is applied on the inside interface, you must allow the access to the IP address on port 80 or 443.
The virtual HTTP and virtual Telnet IP addresses must be included in the aaa authentication statements. In this example, specifying 0.0.0.0 does include these addresses.
Example 10-35 shows the configuration required to turn on virtual HTTP.
Example 10-35. Virtual HTTP Configuration on the PIX Firewall
PIX# configure terminal
PIX(config)# virtual http 192.168.1.40
PIX(config)#
When the user from 192.168.1.4 points the browser at 30.1.1.1, the following message is displayed to the user:
Enter username for PIX (IDXXX) at 192.168.1.40
After authentication, the traffic is redirected to 30.1.1.1.