CCSP Cisco Secure PIX Firewall Advanced Exam Certification Guide, Second Edition [Electronic resources]

Foundation Topics

Chapter 16, "Overview of AAA and the PIX," provided a good overview of the AAA process and the Cisco Secure ACS for Windows 2000. This chapter addresses the configuration of the Cisco PIX Firewall and the Cisco Secure ACS required to build an operational AAA solution. The PIX Firewall must be configured to communicate with the Cisco Secure ACS, and the Cisco Secure ACS must be configured to control the PIX Firewall. Although the PIX Firewall configuration is completed using the command-line interface, the commands required are rather simple and fairly intuitive. The Cisco Secure ACS is completely web-based, with instructions on every page, and it is very simple to configure. After completing this chapter, you should be intimately familiar with the configurations of both the PIX Firewall and the Cisco Secure ACS combined as a functional AAA solution.

Specifying Your AAA Servers

Only two components are required to build an AAA solution:

• AAA server

• Network access server (NAS)

It is possible to divide the AAA functions among multiple devices to reduce the processing required by any single server. It is also possible for a single AAA server to support multiple NASs. The point is that there is no single solution. The number of AAA servers and NASs should be tailored to support the size and scope of the network being accessed. Configuring the PIX Firewall to connect to an AAA server requires only a few commands. Of course, quite a few options are available with each command. In this exercise, the PIX Firewall is configured to connect to a Cisco Secure ACS located on the DMZ segment. Figure 17-1 depicts the network configuration used for the examples in this chapter. Note that the Cisco Secure ACS is located on a DMZ segment rather than on the inside or outside segments. This allows you to restrict access to the Cisco Secure ACS from either segment, making the system more secure.

Configuring AAA on the Cisco PIX Firewall

Four steps are required to configure AAA on the PIX Firewall:

Each of these steps can be completed for the PIX Firewall to communicate with the AAA servers; however, it is possible to configure authentication without authorization or accounting. Each step is discussed in detail in the following sections.

Step 1: Identifying the AAA Server and NAS

You must be sure to have the correct information about your AAA server before you attempt to configure your PIX Firewall. You use the aaa-server command (from configuration mode on the PIX Firewall) to specify the AAA server. Remember that you are dealing with at least two devices: the PIX Firewall and the Cisco Secure ACS.

You must configure the PIX Firewall to recognize the Cisco Secure ACS as its AAA server for authentication. You also must configure the Cisco Secure ACS to communicate with the PIX Firewall with the necessary account information so that the Cisco Secure ACS can validate authentication requests from the PIX Firewall. To accomplish both tasks, you need to use the following commands:

 aaa-server   group-tag   protocol   auth-protocol 
 aaa-server   group-tag  [ if-name ]  host   server-ip key  [ timeout   seconds ]

You must define the following command options and parameters for the configuration to be successful:

• aaa-server Designates the AAA server or server group. A group can have as many as 14 servers, and the PIX Firewall can handle up to 14 groups of AAA servers, for a total of 196 AAA servers. This enables you to tailor which AAA servers handle certain services and lets you configure your AAA servers for redundancy. When a user logs in, the NAS contacts the first server in the group (see the group-tag description). If it does not receive a response within the designated timeout period, it moves to the next server in the group.

• group-tag The name used for the AAA server group. The group-tag is also used in the aaa authentication, aaa authorization , and aaa accounting commands.

• protocol auth-protocol The type of AAA server used (TACACS+ or RADIUS).

• if-name The interface name for the interface on which the AAA server resides. This designates how the firewall connects to the AAA server.

• host server-ip The AAA server's IP address.

• key A shared secret between the Cisco Secure ACS (server) and the PIX Firewall (client). It is an alphanumeric password that can be as many as 127 characters.

• timeout seconds How long the PIX Firewall waits between transmission attempts to the AAA server. The PIX Firewall makes four attempts to connect with the AAA server before trying to connect to the next AAA server in the group. The default timeout is 5 seconds; the maximum timeout is 30 seconds. Using the default timeout of 5 seconds, the PIX Firewall attempts four transmissions, waiting 5 seconds between each attempt, for a total of 20 seconds.

For the network example in this chapter, you would enter the syntax shown in Example 17-1.

Example 17-1. Identifying AAA Servers on the PIX Firewall

PIXFirewall(config)#  aaa-server TACACS+ protocol tacacs+ 
PIXFirewall(config)#  aaa-server TACACS+ (DMZ) host 172.16.1.2 abc123 timeout 20 

For smaller networks with a limited number of users, you can authenticate to a database configured locally on the PIX Firewall. This is not a recommended configuration for medium-size to large networks because the processing required to maintain and authenticate against a local database reduces the firewall's performance. As of PIX Firewall Version 6.2 the AAA server group "local" is predefined for console authentication and command authorization. The command to configure authentication to a local database is aaa-server local .

Note

To remove the AAA server from the configuration, enter no aaa-server . This disables the AAA server function, but the configuration for that server remains on the PIX Firewall.

You finish configuring the Cisco Secure ACS to connect to the PIX Firewall by selecting the PIX Firewall during the Cisco Secure ACS installation, as shown in Figure 17-2.

You also can create additional NASs or edit the current NAS settings in Cisco Secure ACS by clicking the Network Configuration button in the Cisco Secure ACS main window. Remember that the Cisco Secure ACS calls the NAS the "AAA client." Figure 17-3 shows the settings for the PIX Firewall in the Cisco Secure ACS. Notice that the authentication protocol has been changed from RADIUS to TACACS+.

Note

The TACACS+ or RADIUS key specified on Cisco Secure ACS must exactly match the key specified in the aaa-server command for communication between the Cisco Secure ACS server and the NAS to be established.

Step 2: Configuring Authentication

Now that you have the AAA server and the NAS configured to communicate with each other, you need to configure both for user authentication. First you need to configure the authentication parameters on the PIX Firewall, and then you need to create the user accounts on the Cisco Secure ACS. Three types of authentication are supported on the PIX Firewall:

• TACACS+

• RADIUS

• LOCAL

Both TACACS+ and RADIUS support numerous vendor-specific attributes (VSAs) or attribute value (AV) pairs. For a list of the specific VSAs or AV pairs and their definitions, see the User Guide for Cisco Secure ACS for Windows Version 3.2.

The aaa authentication command has three different types. The following list describes the options and variables you find collectively within all three:

• include Creates a rule with a specified service.

• exclude Creates an exception to a previously defined rule.

• authen-service The service that is included or excluded. It is the application with which the user accesses the network. The PIX Firewall can authenticate only via FTP, HTTP, and Telnet. You can configure the authen-service as "any" to allow the PIX Firewall to authenticate any of the three, but this does not allow your users to authenticate using any protocol other than FTP, HTTP, or Telnet.

• inbound Specifies that the PIX Firewall is to authenticate inbound traffic (originates on the outside interface and is directed to the inside interface).

• outbound Specifies that the PIX Firewall is to authenticate outbound traffic (originates on the inside interface and is directed to the outside interface).

• if-name The interface name from which the users should be authenticated. This is optional. By default, the user must authenticate before being allowed through the PIX Firewall. Therefore, outbound traffic authenticates at the inside interface, and inbound traffic authenticates at the outside interface.

• local-ip The host address or network segment with the highest security level. As with the other address definitions on the PIX Firewall, 0 is used to define "any."

• local-mask The subnet mask that applies to the local-ip; 0 is used to define "any."

• foreign-ip Defines the address space with the lowest security level. The use of 0 defines "any."

• foreign-mask The subnet mask that applies to the foreign-ip; 0 is used to define "any."

• group-tag The name used for the AAA server group. The group-tag is also used in the aaa-server, aaa authorization , and aaa accounting commands.

The following sections describe the three different formats and functions of the aaa authentication command in greater detail.

Manually Designating AAA Authentication Parameters

The first command enables you to manually designate the authentication parameters using the items in the preceding list. The syntax for this command is as follows:

 aaa authentication include  |  exclude   authen-service   inbound  |  outbound   if-name local-ip 
 local-mask foreign-ip foreign-mask group-tag 

Example 17-2 shows the syntax for requiring all inbound traffic to authenticate except for traffic connecting from host 192.168.1.28 based on the network shown in Figure 17-1.

Example 17-2. Configuring AAA Authentication on the PIX Firewall

PIXFirewall(config)#  aaa authentication include any outside 0 0 0 0 TACACS+ 
PIXFirewall(config)#  aaa authentication exclude http outside 0 0 192.168.1.28 
 255.255.255.255 TACACS+ 

The local-ip must be the actual IP address configured on a system without Network Address Translation. To configure this authentication, you must ensure that you have a static address translation or NAT configured for your local-ip but you must list the original IP address as the local-ip.

Designating AAA Authentication Parameters Via Access Lists

It is also possible to configure your AAA authentication to reference access lists using the match command. This configuration removes the requirement of manually defining the local and foreign addresses. The syntax for AAA authentication using access lists is as follows:

 aaa authentication match   acl-name if-name server-tag 

Example 17-3 is an example of the aaa authentication command, including the referenced access list.

Example 17-3. Configuring aaa authentication match

PIXFirewall(config)#  static (inside,outside) 192.168.200.1 10.10.10.10 netmask 
 255.255.255.255 
PIXFirewall(config)#  access-list PIXTEST permit tcp any host 192.168.200.1 eq 80 
PIXFirewall(config)#  access-group PIXTEST in interface outside 
PIXFirewall(config)#  aaa authentication match PIXTEST outside TACACS+ 

The static translation and access group are also included in this example because each is required to have the correct public address and to apply the access list.

Chapter 7, "Configuring Access," discusses access lists in greater detail.

One additional command you should use when configuring authentication is sysopt uauth allow-http-cache . This command allows the system to cache user authentication for HTTP requests, which relieves the user from having to reauthenticate when navigating the Internet when HTTP authentication is required. This could be a security concern in certain situations and, thus, you should carefully consider it before you add it to the PIX Firewall configuration.

Console Access Authentication

The final type of AAA authentication is for direct connections to the Cisco PIX Firewall. It is very important to restrict access to the firewall as much as possible. One way to increase your firewall's security is to require all access to the firewall to be authenticated by an AAA server. Console access is traditionally password protected; however, the aaa authentication console command prompts the user to authenticate differently, depending on the method used to access the PIX Firewall:

• serial Causes the user to be prompted before the first command of the command-line prompt when connecting directly to the firewall via a serial cable. Users are continually prompted until they successfully log in.

• telnet Causes the user to be prompted before the first command-line prompt when attempting a Telnet session to the CLI. Users are continually prompted until they successfully log in.

• ssh Causes the user to be prompted before the first command-line prompt when attempting a Secure Shell (SSH) session to the CLI. If users are unable to successfully authenticate within three attempts, they are disconnected and receive the message "Rejected by Server."

• http This option is selected when you use the PIX Device Manager (PDM) to manage your PIX Firewall. PDM users see a pop-up window in their browser (PIX Device Manager). Users are continually prompted until they successfully log in.

• enable With this option, the PIX Firewall requires AAA server authentication to enter privileged mode. The enable option prompts the user for a username and password before entering privileged mode for serial, Telnet, and SSH connections. If users are unable to successfully authenticate after three attempts, they see the "Access Denied" message.

Note

By default, the PDM can access the PIX Firewall with no username and the enable password unless the aaa authentication http console group-tag command is set.

The PIX Firewall supports usernames that are up to 127 characters and passwords that are up to 63 characters. Usernames and passwords cannot contain the @ character. The PDM is limited to a maximum of 30 characters for the username and 15 characters for the password.

Note

To remove the aaa authentication from the configuration, enter no aaa authentication.

Authentication of Services

The Cisco PIX Firewall is designed to authenticate users via FTP, HTTP, and Telnet. Many other services that pass through the PIX Firewall require authentication. To fulfill this requirement, the PIX Firewall supports virtual services . The PIX Firewall can perform functions for servers that do not exist and configures the PIX Firewall to authenticate users who want to connect to services other than FTP, HTTP, and Telnet. After a user has been authenticated, that user can access whatever authorized services they are requesting.

If your company uses Microsoft NetMeeting to communicate among its many different branch offices. NetMeeting runs on the H.323 protocol, which uses a number of different ports. To allow this access, users must authenticate via FTP, HTTP, or Telnet. If you do not have a server available to accept the FTP, HTTP, or Telnet connections, you can configure the PIX Firewall to accept the connections via a virtual service.

Virtual Telnet

Virtual Telnet enables the user to authenticate using Telnet and use a service that does not support authentication. The PIX Firewall accepts the user's connection and challenges the user for a username and password. The username and password are verified by the TACACS+ or RADIUS server. If the user successfully authenticates, the connection to the user's requested service is completed. An additional server is not required to accept the connection, because the PIX Firewall creates a virtual server to handle the authentication requests. Virtual Telnet sessions can be inbound or outbound on the PIX Firewall.

To configure virtual Telnet on the PIX Firewall, you must first create the virtual server on a segment that can be reached via the PIX Firewall. Normally this is an address on the firewall's outside interface. In Figure 17-4, the virtual IP address is 192.168.1.4. This public IP address can be accessed from both inside networks and public networks (such as the Internet). The syntax of the virtual telnet command is as follows:

 virtual telnet   ip-address 

Example 17-4 shows the virtual Telnet configuration that authenticates host 10.10.10.100 when you make an outbound connection to a NetMeeting server located on the Internet.

Example 17-4. Configuring Virtual Telnet Outbound Connections

PIXFirewall(config)#  ip address outside 192.168.1.1 255.255.255.0 
PIXFirewall(config)#  ip address inside 10.10.10.1 255.255.255.0 
PIXFirewall(config)#  global (outside) 1 192.168.1.20-192.168.1.40 netmask 
 255.255.255.0 
PIXFirewall(config)#  nat (inside) 1 0 0 0 0 
PIXFirewall(config)#  aaa-server TACACS+ protocol tacacs+ 
PIXFirewall(config)#  aaa-server TACACS+ (DMZ) host 172.16.1.2 abc123 timeout 20 
PIXFirewall(config)#  aaa authentication include any inside 0 0 0 0 TACACS+ 
PIXFirewall(config)#  virtual telnet 192.168.1.4 

Now let us change the positions of the client and server. This time the NetMeeting server is behind the PIX Firewall, and the client is on the Internet. Figure 17-5 depicts the configuration with the NetMeeting server on the internal network and the client on the Internet.

The PIX Firewall configuration must change to allow the inbound traffic to connect to the NetMeeting server. First, the NetMeeting server needs to have a public IP address, which means that you need to perform static translation. Second, you need to configure the access lists to allow the inbound traffic. Example 17-5 shows the configuration required to allow inbound connections to a destination on the protected network.

Example 17-5. Configuring Virtual Telnet Inbound Connections

PIXFirewall(config)#  ip address outside 192.168.1.1 255.255.255.0 
PIXFirewall(config)#  ip address inside 10.10.10.1 255.255.255.0 
PIXFirewall(config)#  global (outside) 1 192.168.1.20-192.168.1.40 netmask 255.255.255.0 
PIXFirewall(config)#  nat (inside) 1 0 0 0 0 
PIXFirewall(config)#  aaa-server TACACS+ protocol tacacs+ 
PIXFirewall(config)#  aaa-server TACACS+ (DMZ) host 172.16.1.2 abc123 timeout 20 
PIXFirewall(config)#  aaa authentication include any outside 0 0 0 0 TACACS+ 
PIXFirewall(config)#  virtual telnet 192.168.1.4 
PIXFirewall(config)#  static (inside, outside) 192.168.1.4 10.10.10.100 netmask 
 255.255.255.255 0 0 
PIXFirewall(config)#  access-list NetMeeting permit tcp any host 192.168.1.4 eq 23 
PIXFirewall(config)#  access-list NetMeeting permit tcp 192.168.128.128 
 255.255.255.255 192.168.1.4 255.255.255.255 eq H323 
PIXFirewall(config)#  access-group NetMeeting in interface outside 

Note

To remove the virtual Telnet from the configuration, enter no virtual telnet .

Virtual HTTP

Virtual HTTP functions similarly to virtual Telnet in that the PIX Firewall acts as the HTTP server via an additional IP address assigned to the firewall. Users might believe that they are accessing the web server, but they are actually accessing the virtual server for the authentication prompt, being authenticated by an AAA server, and being redirected to their destination after successful authentication. The syntax for virtual http is

 virtual http   ip-address  [ warn ]

The warn option is used for text-based browsers that cannot automatically be redirected. The option adds a link that would be used to redirect to the virtual HTTP server.

Normally the ip-address should be an address that the inside network routes to the PIX Firewall. This way, the internal users access it directly, and the external users connect to it via static address translation at the firewall. Of course, the inbound users require authentication and also must be permitted by an access list or conduit. Example 17-6 depicts the configuration for virtual HTTP on the PIX Firewall. This is the configuration shown in Figure 17-5.

Example 17-6. Configuring Virtual HTTP Inbound Connections

PIXFirewall(config)#  ip address outside 192.168.1.1 255.255.255.0 
PIXFirewall(config)#  ip address inside 10.10.10.1 255.255.255.0 
PIXFirewall(config)#  global (outside) 1 192.168.1.20-192.168.1.40 netmask 255.255.255.0 
PIXFirewall(config)#  nat (inside) 1 0 0 0 0 
PIXFirewall(config)#  aaa-server TACACS+ protocol tacacs+ 
PIXFirewall(config)#  aaa-server TACACS+ (DMZ) host 172.16.1.2 abc123 timeout 20 
PIXFirewall(config)#  static (inside, outside) 192.168.1.5 10.10.10.5 netmask 
 255.255.255.255 0 0 
PIXFirewall(config)#  aaa authentication include any outside 192.168.1.5 255.255.255.255 
 0 0 TACACS+ 
PIXFirewall(config)#  access-list WebTest permit tcp any host 192.168.1.5 eq www 
PIXFirewall(config)#  access-group WebTest in interface outside 
PIXFirewall(config)#  virtual http 192.168.1.5 

Note

To remove the virtual HTTP from the configuration, enter no virtual http.

Authentication Prompts

The auth-prompt command is used to configure the exact text used when the user is challenged to authenticate, successfully authenticates, or does not authenticate. This command sets the text for FTP, HTTP, and Telnet session authentication. The syntax of this command is

 auth-prompt  [ prompt  |  accept  |  reject ]  string 

The string is the text that is displayed. It can be up to 235 characters in length for FTP and Telnet connections. It is limited to 120 characters for HTTP connections using Netscape Navigator, and it is limited to 37 characters for HTTP connections using Microsoft Internet Explorer. The string should not include any special characters. It ends either by typing a question mark (?) or by pressing the Enter key.

The auth-prompt command has three options:

• prompt Configures the text that is displayed when the user is prompted to authenticate: "Access to this location is restricted, please provide username and password."

• accept Configures the text that is displayed if the user successfully authenticates using a Telnet session: "User Authentication complete, please continue." No text is displayed for authentication using FTP or HTTP.

• reject Configures the text that is displayed if the user is unable to successfully authenticate using a Telnet session: "Authentication unsuccessful; if you feel that you have received this message in error please contact your systems administrator." The text for FTP and HTTP authentication sessions cannot be configured on the PIX Firewall.

Authentication Timeout

After a user is successfully authenticated, their user information is saved in cache for a predetermined amount of time. You set this time by configuring the timeout uauth command. It is specified in hours, minutes, and seconds. If the user session idle time exceeds the timeout, the session is terminated and the user is prompted to authenticate during the next connection. To disable caching of users, use the timeout uauth 0 command. Be sure not to use timeout uauth 0 when using virtual http . This setting prevents any connections to the real web server after successful authentication at the PIX Firewall.

Note

If the firewall is performing NAT, the timeout uauth value must be less than the timeout xlate value to ensure that the user authentication times out before the address translation.

Two command options or settings are associated with the timeout uauth command:

• absolute The default setting for the uauth timer. This setting sets the timer to prompt the user to reauthenticate after the timer elapses only when the user starts a new connection. If the user leaves the session open and the timer elapses, and the user closes the browser without clicking another link, the user is not prompted to reauthenticate. Setting the uauth timer to 0 disables caching of user authentication and therefore disables the absolute option.

• inactivity The inactivity timer starts after the connection becomes idle. If the user establishes a new connection before the duration of the inactivity timer, the user is not required to reauthenticate. If a user establishes a new connection after the inactivity timer expires, the user must reauthenticate.

Example 17-7 depicts the timeout command with the absolute and inactivity settings. The first command sets the timer to 4 hours and tells the system not to prompt the user after the session times out unless the user initiates another session. The second command defines a 30-minute period of inactivity as an idle session and tells the system to start the timer at that point.

Example 17-7. Configuring Timeout on the PIX Firewall

PIXFirewall(config)#  timeout uauth 4:00:00 absolute 
PIXFirewall(config)#  timeout uauth 0:30:00 inactivity 

The final command associated with timeouts is clear uauth . This command forces the system to delete the authorization cache for all users. This makes the system reauthenticate every user when they initiate their next connection.

Step 3: Configuring Authorization

When discussing authorization, you should first understand the difference between authentication and authorization:

• Authentication identifies who the user is.

• Authorization determines what the user can do.

• Authentication can be implemented without authorization.

• Authorization cannot be used unless the user has successfully authenticated.

Authorization is not a requirement but rather a method of allowing you to become more granular in what access you give specific users. After users have successfully authenticated, they can be given the access they have requested. This access is configured using the aaa authorization command, the syntax for which is very similar to the aaa authentication command, except for the service. The PIX Firewall does not permit or deny any traffic based solely on the aaa authorization commands. This configuration merely tells the firewall which services it needs to reference the AAA server for authorization before allowing or denying the connection. A TACACS+ server performs AAA authorization. The server is configured using the following syntax:

 aaa authorization include  |  exclude   svc if-name local-ip 
 local-mask foreign-ip foreign-mask 

tacacs-server-tag specifies the TACACS+ server to be used for authorization. author-service is the service defined for aaa authorization . The author-service parameter defines any service that requires authorization by listing them as include or exclude and the interface that the traffic is passing through. Services not listed are implicitly authorized. author-service can be any, ftp, http, telnet , or protocol/port . Authorization of services is configured using the following syntax:

 aaa authorization include  |  exclude   service if-name local-ip 
 local-mask foreign-ip foreign-mask 

Example 17-8 shows the commands used to authorize outbound DNS requests and all inbound services except HTTP requests from 192.168.1.28 to any destination.

Example 17-8. Configuring Authorization on the PIX Firewall

PIXFirewall(config)#  aaa authorization include any outside 0 0 0 0 TACACS+ 
PIXFirewall(config)#  aaa authorization exclude http outside 0 0 192.168.1.28 
 255.255.255.255 TACACS+ 
PIXFirewall(config)#  aaa authorization include udp/53 inside 0 0 0 0 TACACS+ 

Note

To remove the AAA authorization from the configuration, enter no aaa authorization .

Cisco Secure ACS and Authorization

After the Cisco PIX Firewall is configured correctly, you must configure authorization on your Cisco Secure ACS. If your Cisco Secure ACS is already configured with the PIX Firewall as the NAS, a few steps remain to configure authorization:

Steps 1 and 2: Configuring User Accounts Within the Cisco Secure ACS and Assigning Users to a Group

To configure new users in Cisco Secure ACS, click the User Setup button on the left navigation bar. When the User Setup window appears, shown in Figure 17-6, enter the username in the User box and then click Add/Edit.

In the Edit pane of the User Setup window, shown in Figure 17-7, you can configure many options pertaining to the user account:

• Account Disabled Checking this box lets you create accounts for users who are not yet ready to begin using the system. For example, suppose you are told that the company has hired a new employee who is scheduled to being working in three weeks. You can configure the user account and then turn it on by deselecting the check box when the new employee starts work.

• Supplementary User Info An optional field for entering user information. It is a very good idea to complete these fields because they help you keep track of your user accounts as your user base grows:

  - Real Name The user's name, not the user account name.

  - Description A description of the user. Normally this field describes the user's position within the company.

• User Setup Select the type of authentication database, and enter the user password:

  - Password Authentication Two types of password authentication are available on the Cisco Secure ACS by default. You can add a number of additional authentication types by clicking the External User Databases button on the left navigation bar. Select the authentication type from the drop-down menu:

  CiscoSecure Database Authenticates the user from a database installed locally on the Cisco Secure ACS.

  Windows NT/2000 Authenticates the user against a Windows NT/2000 Server that is located on the same system that is running the Cisco Secure ACS or any Windows NT/2000 system that has a trust relationship with the domain that the Cisco Secure ACS is part of.

  External User Database You can add multiple configurations for each of the following authentication services: Vasco Token Server, RSA SecurID Token Server, RADIUS Token Server, External ODBC Database, Windows NT/2000, Novell NDS, Leap Proxy RADIUS Server, Generis LDAP, SafeWord Token Server, CryptoCard Token Server, AXENT Token Server, and ActivCard Token Server.

  - Password and Confirm Password Enter and confirm the user's password.

  - Separate (CHAP/MS-CHAP/ARAP) Password This feature is not used on the PIX Firewall.

  - Group Select a user group from the drop-down box. All users are assigned to the Default Group unless they are specifically assigned to another group. Grouping the users and applying rules to groups enables you to efficiently administer the authentication services.

  - Callback This feature is not used on the PIX Firewall.

  - Client IP Address Assignment This feature is not used on the PIX Firewall.

• Network Access Restrictions Defines per-user network access restrictions.

• Max Sessions Contains three radio buttons that define the maximum number of concurrent sessions the user can have:

  - Unlimited The user can maintain an unlimited number of concurrent sessions through the firewall.

  - Fill in the Box Defines the maximum number of concurrent sessions.

  - Use Group Settings The default setting. The maximum number is defined at the group level.

• Account Disable Configures the parameters for disabling a user account based on the date or a number of failed logon attempts. Do not confuse this option with the Account Disabled option at the top of the User Setup window.

  - Never The default setting. It allows the user unlimited attempts to log on.

  - Disable Account If:

  Date Exceeds Select the date from the drop-down boxes. The default setting is 30 days after the account is created.

  Failed Attempts Exceed Add the number of allowed failed attempts to the box.

  An indicator shows the number of failed attempts since the last successful logon.

  There is a check box for you to reset the failed attempts count. If this box is checked the reset will occur when you click the submit button.

Step 3: Applying Authorization Rules to the Group

Now that you have created the user account and assigned the user to a group, it is time to apply authorization rules to the group. Click the Group Setup button on the navigation bar on the left.

Figure 17-8 shows the available selections in the initial Group Setup window.

You can select the group from the drop-down box and select any of the following three options for that group:

• Users in Group Replaces the Help pane on the right side of the window with a list of the users assigned to the selected group, as shown in Figure 17-9. Each username is a link to that user's configuration in the User Setup window.

  Figure 17-9. Users in Group

• Edit Settings Allows you to edit the specific settings for the selected group. This is where the authorization rules are applied to the group.

• Rename Group Enables you to rename groups to simplify administration. You can add users to groups based on like positions or job functions (such as marketing, sales, infrastructure, and security).

You configure commands by editing the settings for a specific group. Select Group Setup from the navigation bar, click Edit Settings, and scroll down to the Shell Command Authorization Set. You see radio buttons and a Command box that is a subset of the Command Authorization Set, as shown in Figure 17-10.

To configure shell command authorization for AAA clients using TACACS+, set the options in this section as applicable:

• None If you do not want to apply TACACS+ shell command authorization for users who belong to this group, select this option (selected in Figure 17-10).

• Assign a Shell Command Authorization Set for Any Network Device To apply a shell command authorization set to all TACACS+ AAA clients, select this option and then select the set you want from the corresponding list.

• Assign a Shell Command Authorization Set on a Per Network Device Group Basis In ACS Version 3.1 and later, to apply a shell command authorization set to the TACACS+ AAA clients who belong to a particular Network Device Group (NDG), select this option, and then use the following options:

  - Device Group From the list, select the NDG to which you want to assign a shell command authorization set.

  - Command Set From the list, select the shell command authorization set you want to apply to the NDG.

  - Add Association Click to add the NDG and command set selected to the Device Group/Command Set list.

  - Remove Association To remove an NDG/command set association, select the NDG/command set association you want to remove from the Device Group/Privilege list, and then click Remove Association.

  Shell command authorization sets are created and configured in the Shared Profile Components window.

• Per Group Command Authorization To set TACACS+ shell command authorization on a command-by-command basis, select this option, and then use the following options:

  - Unmatched Cisco IOS Commands To determine how Cisco Secure ACS handles commands that you do not specify in this section, select either Permit or Deny as applicable.

  - Command Select this check box, and then enter the command in the corresponding box. The command can be listed by name for well-known commands such as telnet, ftp , or http; otherwise the command should be listed by protocol/port number (i.e., tcp/23).

  - Arguments In this case the term "argument" refers to the target address. This box lists to which target host you should allow (or deny) access via the previously listed command. These should be entered in the format permit argument or deny argument . This allows you to specify which commands are permitted or denied.

  - Unlisted Arguments To permit only the arguments listed, select Deny. To allow users to issue all arguments not specifically listed, select Permit. This setting allows you to permit or deny all commands and arguments not listed previously.

Figure 17-11 shows the configuration that would allow Telnet access to hosts at 172.16.1.5 and 172.16.1.7.

The excerpt of a PIX Firewall configuration below corresponds the Figure 17-11:

 nameif ethernet0 outside security0 
 nameif ethernet1 inside security100 
 nameif ethernet2 dmz1 security50 
 ip address inside 192.168.1.231 255.255.255.0 
 ip address dmz1 10.10.1.1 255.255.255.0 
 access-list from-inside-to-dmz permit tcp 192.168.1.0 255.255.255.0 host 10.10.1.3 eq 
 5631 
 access-list from-inside-to-dmz permit udp 192.168.1.0 255.255.255.0 host 10.10.1.3 eq 
 5632 
 access-list from-inside-to-dmz permit tcp 192.168.1.0 255.255.255.0 host 10.10.1.5 eq 
 telnet 
 access-list from-inside-to-dmz deny ip any host 10.10.1.3 
 access-list 121 permit tcp any host 10.10.1.3 
 access-list 121 permit udp any host 10.10.1.3 
 access-list 121 permit tcp any host 10.10.1.5 eq telnet 
 access-list 101 permit ip 192.168.1.0 255.255.255.0 host 10.10.1.3 
 nat (inside) 0 access-list 101 
 static (inside,dmz1) 192.168.1.1 192.168.1.1 netmask 255.255.255.255 0 0 
 access-group from-inside-to-dmz in interface inside 
 aaa-server AuthOutbound protocol tacacs+ 
 aaa-server AuthOutbound (inside) host 192.168.1.4 xxxxxxxx timeout 10 
 aaa authentication match 121 inside AuthOutbound 
 aaa authorization match 121 inside AuthOutbound 
 virtual telnet 10.10.1.5 

This PIX Firewall will not allow any connections from its inside hosts (192.168.1.0) to host 10.10.1.3 on DMZ1 except PCAnywhere (TCP/5631 and UDP/5632) application. But to allow this connection it asks authentication as well as authorization using a Cisco Secure ACS. A user on the 192.168.1.1 host would telnet to virtual telnet address at 10.10.1.5, authenticate and afterwards will run his PCAnywhere application with the target host as 10.10.1.3. The Cisco Secure ACS will authorize this user if in its database for this user has the following, shown in Figure 17-12.

Refer to the network map in Figure 17-13 for the following exercise. The configuration of the PIX Firewall and the Cisco Secure ACS controls access to the host 172.16.1.3.

In the PIX Firewall configuration in Example 17-9, hosts on the internal network are not allowed to make connections to 172.16.1.3 on the DMZ segment except for the PCAnywhere (TCP/5631 and UDP/5632) application. But to allow this connection the Firewall will ask authentication as well as authorization using a Cisco Secure ACS.

Example 17-9. Configuring AAA Authorization on the PIX Firewall

 nameif ethernet0 outside security0 
 nameif ethernet1 inside security100 
 nameif ethernet2 dmz1 security50 
 ip address outside 192.168.0.1 255.255.255.0 
 ip address inside 10.10.10.254 255.255.255.0 
 ip address dmz1 172.16.1.254 255.255.255.0 
 access-list from-inside-to-dmz permit tcp 10.10.10.0 255.255.255.0 host 172.16.1.3 eq 5631 
 access-list from-inside-to-dmz permit udp 10.10.10.0 255.255.255.0 host 172.16.1.3 eq 5632 
 access-list from-inside-to-dmz permit tcp 10.10.10.0 255.255.255.0 host 172.16.1.5 eq telnet 
 access-list from-inside-to-dmz deny ip any host 172.16.1.3 
 access-list 121 permit tcp any host 172.16.1.3 
 access-list 121 permit udp any host 172.16.1.3 
 access-list 121 permit tcp any host 172.16.1.5 eq telnet 
 access-list 101 permit ip 10.10.10.0 255.255.255.0 host 172.16.1.3 
 nat (inside) 0 access-list 101 
 static (inside,dmz1) 10.10.10.1 10.10.10.1 netmask 255.255.255.255 0 0 
 access-group from-inside-to-dmz in interface inside 
 aaa-server AuthOutbound protocol tacacs+ 
 aaa-server AuthOutbound (inside) host 10.10.10.4 xxxxxxxx timeout 10 
 aaa authentication match 121 inside AuthOutbound 
 aaa authorization match 121 inside AuthOutbound 
 virtual telnet 172.16.1.5 

A user on the 10.10.10.1 host would telnet to virtual telnet address at 172.16.1.5, authenticate and afterwards will run his PCAnywhere application with the target host as 172.16.1.3. The Cisco Secure ACS authorizes this user if in its database for this user the Command Authorization configuration of the Cisco Secure ACS is similar to Figure 17-13.

Step 4: Configuring Accounting

You have successfully configured both your Cisco PIX Firewall and your Cisco Secure ACS for authentication and authorization. The final portion is to configure accounting. Accounting is used to track specific traffic passing through the firewall. It also ensures that users are performing functions in keeping with company policies. Log data is commonly stored and can be used to investigate employees who are using their Internet connections for activities not authorized by the employer. The general syntax for the command that accomplishes accounting is as follows:

 aaa accounting include | exclude   acctg-service  |  if-name local-ip 
 local-mask foreign-ip foreign-mask server tag 

The following items are defined within the aaa accounting command:

• include Creates a rule with a specified service.

• exclude Creates an exception to a previously defined rule.

• acctg-service The service that is included or excluded. It is the service that the user is requesting access to via the network. You can configure acctg-service as any, ftp, http, telnet , or protocol/port . When you configure protocol/port , the protocol is listed as a number:

  - ICMP 1

  - TCP 6

  - UDP 17

• if-name The interface name from which the users should be authenticated and accounting should be performed.

• local-ip The host address or network segment with the highest security level. As with the other address definitions on the PIX Firewall, 0 is used to define "any."

• local-mask The subnet mask that applies to the local-ip; 0 is used to define "any."

• foreign-ip Defines the address space with the lowest security level. The use of 0 defines "any."

• foreign-mask The subnet mask that applies to the foreign-ip; 0 is used to define "any."

• server-tag The name used for the AAA server group. The server-tag is also used in the aaa-server , aaa authorization , and aaa accounting commands.

Example 17-10 shows how to configure AAA accounting on the PIX Firewall.

Example 17-10. Configuring AAA Accounting on the PIX Firewall

PIXFirewall(config)#  aaa accounting include any inbound 0 0 0 0 TACACS+ 
PIXFirewall(config)#  aaa accounting include any outbound 0 0 0 0 TACACS+ 

As with authentication and authorization, it is possible to configure the PIX Firewall to match an access list, as demonstrated in Example 17-11.

Example 17-11. Configuring AAA Accounting to Match an ACL

PIXFirewall(config)#  access-list PIXTEST permit tcp any host 65.197.254.5 eq 80 
PIXFirewall(config)#  access-group PIXTEST in interface outside 
PIXFirewall(config)#  aaa accounting match PIXTEST inbound TACACS+ 

Note

To remove AAA accounting from the configuration, enter no aaa accounting.

Viewing Accounting Information in Cisco Secure

Now that the Cisco PIX Firewall is configured to perform accounting, you need to ensure that the Cisco Secure ACS is properly configured to log the events. Select System Configuration in the navigation panel to open the System Configuration window, shown in Figure 17-14; then, click the Logging link in the Select pane, and check off the log format and the items you want to log (see Figure 17-15). Logs can be saved in a CSV (flat file) or ODBC (database) format.

You can view several reports from the Cisco Secure ACS browser interface. Select Reports and Activity from the navigation bar to open the Reports and Activity window, shown in Figure 17-16. Then, choose the report you want by clicking the applicable button in the Reports list. Reports are available for TACACS+ and/or RADIUS only if an AAA client has been configured to use that protocol.

Reports are generated daily and can be viewed or downloaded in comma-separated value (CSV) format. Figure 17-17 lists the titles of the TACACS+ reports that are available. Notice that there are gaps in the dates of available reports. This is because this particular Cisco Secure ACS is not in production, and the system generates logs and, therefore, reports only when it is running.

Some reports are available only if the applicable option is enabled in the Interface Configuration window, Advanced Options pane (see Figure 17-18) and configured in the System Configuration window. After you select the type of report to view, a list of choices appears in the right window. Click the name of the report you want.

Cisco Secure and Cut-Through Configuration

Chapters 1 and 2. The user initiates a connection to their destination and is prompted for a username and password by the PIX Firewall. The user-provided information is verified by the AAA server, and the connection is allowed by the firewall.

Configuring Downloadable PIX ACLs

Version 3.0 and later of Cisco Secure ACS allows you to create a "downloadable ACL" using the shared profile component. The downloadable ACL configuration is supported only for RADIUS servers. To verify that your configuration is for a RADIUS server, select Network Configuration from the navigation bar and click AAA Client. Verify that RADIUS (Cisco IOS/PIX) is selected, as shown in Figure 17-19.

Select Shared Profile Components from the navigation bar, click the link for Downloadable PIX ACL, and select Add.

Note

If you are not configured for a RADIUS server, the Downloadable PIX ACL link is unavailable.

If the Cisco Secure ACS is configured as a RADIUS server, but you still do not have the Downloadable PIX ACL option available, you must select either User-Level or Group-Level Downloadable ACLs in the Advanced Options menu of the Interface Configuration window, shown in Figure 17-20.

Add the following information in the Downloadable PIX ACLs configuration box, and click Submit:

• Name The access list name.

• Description A description of the access list.

• ACL Definitions A test of the command. This should use the same format as the command used on the PIX Firewall, except for the access list name and the fact that there is no requirement for the keyword "access-list." It also is not necessary to add the access list to an access group. This is done automatically when the ACL is downloaded to the PIX Firewall.

Figure 17-21 shows a downloadable ACL configured to allow outbound access to www.cisco.com

After you configure the downloadable ACL in the Shared Profile Components window, you can add it to either an individual user setup or a group setup. Figure 17-22 shows the Downloadable ACLs box in the Group Setup window. To add the downloadable ACL to the group, simply check the Assign IP ACL box and select the ACL name from the drop-down box.

Troubleshooting Your AAA Setup

Troubleshooting your AAA configuration can be a simple function or a difficult process, depending on how complicated the configuration is and how well you documented it. It is always in your best interest to document any configuration and to be as detailed as possible when doing so. It is also recommended that you use best practices such as adding users to groups and applying rules to groups rather than to users, using a standardized naming convention, and completing the description fields and comment blocks when creating elements, rules, components, and so on. Neglecting these basic steps can turn a relatively simple issue into an extremely difficult troubleshooting event. It also is a good idea to remember the basic troubleshooting method of "divide and conquer." In other words, do not start checking the PIX Firewall or the Cisco Secure ACS configuration until you have verified connectivity between the two devices.

Checking the PIX Firewall

The most effective command for troubleshooting the PIX Firewall is show . The show command is run in configuration mode and can be used to show the configuration for all the AAA components on the PIX Firewall. The following is a list of the show commands pertaining to the AAA configuration:

• show aaa-server Shows you the different group-tags , which protocol is used for each group-tag , and the ip-address, key , and timeout for each AAA server.

• show aaa Provides you with the output of the following commands:

  - show aaa authentication Shows you all AAA authentication rules

  - show aaa authorization Shows you all AAA authorization rules

  - show aaa accounting Shows you all AAA accounting rules

  - show timeout Shows the maximum idle time for a session

  - show timeout uauth Shows the duration in hours, minutes, and seconds before the authentication and authorization cache times out

  - show auth prompt Shows the prompt, accept, and reject text messages when a user attempts to authenticate via a Telnet session

  - Show uauth Shows the number of authenticated users and the number of authentications in progress

Troubleshooting Authentication

If you encounter issues with your AAA authentication, you can use the debug aaa authentication command to display the communication between the Cisco PIX Firewall and the AAA server. This command lets you determine the method of authentication and verify successful communication between the PIX Firewall and the AAA server. Example 17-12 shows where a login causes the PIX Firewall to initiate a connection to the AAA server at 17.16.1.2, requesting a login using TACACS+ and generating an eight-digit session ID. The session ID is used to distinguish between multiple concurrent authentication requests.

Example 17-12. debug aaa authentication Command Output

PIX-Firewall#  debug aaa authentication 
10:15:01: AAA/AUTHEN: create-user user='' ruser='' port='tty19'
rem-addr='172.16.1.2' authen-type=1 service=1 priv=1
10:15:01: AAA/AUTHEN/START (0): port='tty19' list='' action=LOGIN service=LOGIN
10:15:01: AAA/AUTHEN/START (0): using "default" list
10:15:01: AAA/AUTHEN/START (12345678): Method=TACACS+
10:15:01: TAC+ (12345678): received authen response status = GETUSER
10:15:02: AAA/AUTHEN (12345678): status = GETUSER
10:15:02: AAA/AUTHEN/CONT (12345678): continue-login
10:15:02: AAA/AUTHEN (12345678): status = GETUSER
10:15:02: AAA/AUTHEN (12345678): Method=TACACS+
10:15:02: TAC+: send AUTHEN/CONT packet
10:15:03: TAC+ (12345678): received authen response status = GETPASS
10:15:03: AAA/AUTHEN (12345678): status = GETPASS
10:15:03: AAA/AUTHEN/CONT (12345678): continue-login
10:15:03: AAA/AUTHEN (12345678): status = GETPASS
10:15:03: AAA/AUTHEN (12345678): Method=TACACS+
10:15:03: TAC+: send AUTHEN/CONT packet
10:15:03: TAC+ (12345678): received authen response status = PASS
10:15:03: AAA/AUTHEN (12345678): status = PASS

Troubleshooting Authorization

If you encounter issues with your AAA authorization, you can use the debug aaa authorization command to display the communication between the PIX Firewall and the AAA server, as demonstrated in Example 17-13.

Example 17-13. debug aaa authorization Command Output

PIX-Firewall#  debug aaa authorization 
10:15:01: AAA/AUTHOR (0): user='jdoe'
10:15:01: AAA/AUTHOR (0): send AV service=shell
10:15:01: AAA/AUTHOR (0): send AV cmd*
10:15:01: AAA/AUTHOR (123456789): Method=TACACS+
10:15:01: AAA/AUTHOR/TAC+ (123456789): user=jdoe
10:15:01: AAA/AUTHOR/TAC+ (123456789): send AV service=shell
10:15:01: AAA/AUTHOR/TAC+ (123456789): send AV cmd*
10:15:01: AAA/AUTHOR (123456789): Post authorization status = FAIL

Troubleshooting Accounting

If you encounter issues with your AAA accounting, you can use the show accounting command to step through the sessions and, if necessary, print records of actively accounted sessions. The debug aaa accounting command is used to display the output of AAA accounting and is independent of the protocol used to transfer records to the log server, as demonstrated in Example 17-14.

Example 17-14. debug aaa accounting Command Output

PIX-Firewall#  debug aaa accounting 
10:15:01: AAA/ACCT: EXEC acct start, line
10:15:01: AAA/ACCT: Connect start, line 10, glare
10:15:01: AAA/ACCT: Connection acct stop:
task-id=70 service=exec port=10 protocol=telnet address=172.16.1.13 cmd=glare
bytes-in=308 bytes-out=76 paks-in=45 paks-out=54 elapsed-time=14

If you believe you have encountered a protocol-specific problem, you can view the individual protocols using the following commands:

• debug tacacs Displays the packet information for communication between the PIX Firewall and the AAA server. Example 17-15 demonstrates typical output from this command.

• debug radius Displays the output of the RADIUS communication. This is more difficult to read, except for the obvious "Access-Accept" or "Access-Reject" message. Example 17-16 demonstrates typical output from this command.

Example 17-15. debug tacacs Command Output

PIX-Firewall#  debug tacacs 
10:15:01: TAC+: Opening TCP/IP connection to 172.16.1.2 using source 172.16.1.1
10:15:01: TAC+: Sending TCP packet number 123456789-1 to 172.16.1.2 (AUTHEN/START)
10:15:01: TAC+: Receiving TCP packet number 123456789-2 from 172.16.1.2
10:15:01: TAC+ (123456789): received authen response status = GETUSER
10:15:01: TAC+: send AUTHEN/CONT packet
10:15:02: TAC+: Sending TCP packet number 123456789-3 to 172.16.1.2 (AUTHEN/CONT)
10:15:02: TAC+: Receiving TCP packet number 123456789-4 from 172.16.1.2
10:15:02: TAC+ (123456789): received authen response status = GETPASS
10:15:02: TAC+: send AUTHEN/CONT packet
10:15:03: TAC+: Sending TCP packet number 123456789-5 to 172.16.1.2 (AUTHEN/CONT)
10:15:03: TAC+: Receiving TCP packet number 123456789-6 from 172.16.1.2
10:15:03: TAC+ (123456789): received authen response status = PASS
10:15:03: TAC+: Closing TCP connection to 172.16.1.2

Example 17-16. debug radius Command Output

PIX-Firewall#  debug radius 
10:15:01: Radius: IPC Send 0.0.0.0:1645, Access-Request, id 0xE len 12
10:15:01:       Attribute 5 5 CDA14568
10:15:01:       Attribute 7 9 B475B47A
10:15:01:       Attribute 6 2 45C4E78A
10:15:01:       Attribute 4 1 14568521
10:15:01: Radius: Received from 172.16.1.2:1645, Access-Accept, id 0xE len 33
10:15:01:       Attribute 2 2 0000000F

Note

It is important that you not run the debug command continuously because these commands can generate a significant amount of output.

The command to terminate the debug is no debug insert your command here.

Checking the Cisco Secure ACS

After you verify your settings on the Cisco PIX Firewall, you should double-check the settings on the Cisco Secure ACS to ensure that they match the PIX Firewall. You also can use the extensive logging information available in the Cisco Secure ACS Reports and Activity window. You can find a list of troubleshooting information for the Cisco Secure ACS in the Cisco Secure ACS online documentation. Simply enter Troubleshooting Information for Cisco Secure ACS in the Search box at Cisco.com to find this documentation.