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 ExemptionIf 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 ExemptionIf 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
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 ExemptionIP 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.
Example 10-33 shows how to configure a MAC access list. Example 10-33. MAC Access List Configuration
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 TelnetVirtual Telnet can be used to address one of the following issues:
This section examines both configuration and troubleshooting of Virtual Telnets. Configuring Virtual TelnetInbound 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
Use the following procedure to configure the Cisco Secure ACS Server for the mail authentication:
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 TelnetTroubleshooting 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:
Case Study 3: Virtual HTTPVirtual HTTP is needed for the following reasons:
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:
Example 10-35 shows the configuration required to turn on virtual HTTP. Example 10-35. Virtual HTTP Configuration on the PIX Firewall
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. |