AP Configuration

The next part of this chapter deals with configuring AP on your Cisco router. Before continuing with the configuration, though, you should meet some prerequisites:

• AP uses AAA to perform authentication and authorization. Make sure that you understand the operation and configuration of AAA discussed in Chapter 5.

• It is highly recommended that you use CBAC (see Chapter 9, "Context-Based Access Control") and ACLs (see Part III, "Nonstateful Filtering Technologies") to complement AP.

• With HTTP and HTTPS authentication, Cisco recommends that you use either Microsoft's Internet Explorer 3.0 or later, or Netscape's Navigator 3.0 or later. Other web browsers might or might not work, so you are on your own if you experience problems with other vendors' web browser products.

When you have met the prerequisites, you are ready to proceed to configuring AP. The following sections discuss the different components that you need to configure:

• Configuring AAA on your router

• Configuring AAA on your AAA server

• Preparing for HTTP and HTTPS (FTP and Telnet do not require special configurations for AP)

• Configuring AP policies

• Tuning AP

• Protecting against access attacks

Configuring AAA on Your Router

One of the first steps is to set up AAA on your router. AAA was covered in Chapter 5, so I do not spend that much time discussing its configuration here. However, one important point to make about AAA and AP is that you must use a TACACS+ or RADIUS server. AP does not support any method of local authentication or authorization.

You will use the following basic AAA commands:

Router(config)# aaa new-model                                     (1)

Router(config)# tacacs-server host IP_address                     (2)

  [single-connection] [port port_#] [timeout seconds]

  [key encryption_key]

Router(config)# radius-server host IP_address

  [auth-port port_#] [acct-port port_#] [timeout seconds]

  [retransmit retries]

  [key key_value]

  [alias {hostname | IP_address}]

Router(config)# aaa authentication login default                  (3)

  {group radius | group tacacs+ | group server_group}

Router(config)# aaa authorization auth-proxy default              (4)

  {group radius | group tacacs+ | group server_group}

Router(config)# aaa accounting auth-proxy default start-stop      (5)

  {group radius | group tacacs+ | group server_group}

Here is a brief explanation of these commands, with reference to the numbering on the right side of the syntax:

Configuring AAA on Your Server

When you have configured AAA on your router, you need to set up AAA on your security server. AP supports the following AAA security servers:

• Cisco Secure ACS 2.1.x and later for Windows NT/2000

• Cisco Secure ACS 2.3 for UNIX

• TACACS+ server

• The Ascend RADIUS server

• The Livingston RADIUS server

You need to do a few things on your AAA server:

• Add your users and groups.

• Enable the AP service.

• Create downloadable user profiles that the Cisco IOS converts to ACLs.

The following two sections cover the last two points.

AP Service

By default, the AP service on the Cisco ACS product is disabled. The first thing you need to do is enable it. Enabling it is a two-step process: You need to make changes to the Interface Configuration and Network Configuration sections.

To perform the necessary configuration for the Interface Configuration section, follow these steps:

Step 1. Click the Interface Configuration button in the left-side vertical toolbar.

Step 2. Click the TACACS+ (Cisco IOS) hyperlink in the middle section of the web page.

Step 3. Scroll down to the TACACS+ Services section.

Step 4. In the New Services section, click the closest empty check box and, under the Service column, enter auth-proxy.

Step 5. Click the Submit button at the bottom of the window to accept your changes.

In the Network Configuration section, make sure that your router is listed and that the AAA server and router can communicate with each other.

User Authorization Profiles

After you have enabled AP, you need to activate it in the group or groups that your users are associated with that will be using AP. To do this, follow these steps in ACS:

Step 1. Click the Group Setup button in the left-side vertical toolbar.

Step 2. Select the group that you want to add AP to, and click the Edit Settings button.

Step 3. Scroll down to the TACACS+ Settings text box.

Step 4. Toward the bottom of this box, you will find the AP service you just added.

Step 5. Click the check box to the left of the auth-proxy service name.

Step 6. Click the check box to the left of the Custom Attributes description.

Step 7. Beneath the Custom Attributes description is a large text box where you can configure your user authorization profile (UAP) statements. I describe this configuration later.

Step 8. After you have entered your custom attributes, at the bottom of the screen, click the Submit+Restart button.

The UAP in the custom attributes defines what resources a user is authorized to access after being authenticated. Two types of statements exist in a UAP:

priv-lvl=15

proxyacl#number=permit protocol any destination_address destination_mask

  protocol_information

The priv-lvl command assigns the privilege level to the authenticated user. For AP, this must be 15. The proxyacl# commands define the UAP?what the user can access after being authenticated. These are basically a simplified access-control entry, which, when the AAA server sends this to the Cisco IOS, the Cisco IOS converts into an ACL statement. Following the proxyacl# portion of the command is a statement number. The first statement is numbered 1, the second is 2, and so on. These are used to order your statements. This is followed by an equals sign (=) and then the ACL statement. Note that the format of the ACL statement is the same as that used by entries in a named extended ACL.

Here is a simple UAP example used for the external users in Figure 14-2 trying to access the private web server:

priv-lvl=15

proxyacl#1=permit tcp any 192.1.1.1 eq 80

This is a straightforward configuration. Note that you can configure multiple proxyacl# commands; just make sure that each entry has a unique command number.

Preparing for HTTP or HTTPS

After you have configured AAA on the server and the router, you need to take some preparatory steps on your router to allow AP to occur. As you recall, the Cisco IOS supports HTTP, HTTPS, FTP, and Telnet for authentication and authorization. This means that you need to allow these services in your ACL configuration. For example, if you are setting up AP that uses only HTTPS, and if HTTPS must be done to the router first, you need an entry in the router's inbound ACL that allows the HTTPS (TCP port 443) connection to the router (the destination IP address in the ACL entry should be an address on the router). If you are using other services, you also need to allow these in your ACL entries. Plus, if you are using redirection with HTTP or HTTPS, you need to allow the HTTP/HTTPS connection to the destination service in your ACL entry.

HTTP Configuration Tasks

For HTTP, you need to enable and set up the router's HTTP server. You need to configure these commands on your router:

Router(config)# ip http server

Router(config)# ip http authentication aaa

Router(config)# ip http access-class standard_ACL_#

The first two commands are necessary. The first command, ip http server, enables the router's HTTP server function. The ip http authentication aaa command allows the Cisco IOS to use AAA for authentication. The third command is optional: The ip http access-class command can be used to restrict certain source addresses to access the router's HTTP server function. This is useful if you will be using AP only to authenticate internal users accessing external resources. In this instance, you know the addresses that the internal clients use. However, for external users, you probably do not know the source addresses, so this command would not be appropriate.

Configuration Tasks for HTTPS

HTTPS was introduced in Cisco IOS 12.2(11)YU and 12.2(15)T. The main advantage that HTTPS has over HTTP, FTP, and Telnet is that information shared across the connection, such as the username and password, is encrypted.

To set up HTTPS for AP, perform the following:

Step 1. Disable the HTTP server:

Router(config)# no ip http server

Step 2. Enable the HTTPS server function:

Router(config)# ip http server-secure

Step 3. Enable AAA for the HTTPS server:

Router(config)# ip http authentication aaa

Step 4. Define a Certificate Authority (CA) trustpoint (optional):

Router(config)# ip http secure-trustpoint CA_name

In this configuration, the only command that is new is step 4. When two devices are trying to establish a connection, a CA can provide proof of the identities of the two parties, thereby defeating man-in-the-middle or spoofing attacks. Identity information is stored in a certificate, defined in the X.509v3 standard. CAs commonly are used in VPNs as well as secure web transactions. I thoroughly cover the configuration of CAs in Chapter 19, "IPSec Site-to-Site Connections"; refer to this chapter for the router's configuration for a CA.

Configuring AP Policies

After setting up AAA, and, if necessary, preparing the Cisco IOS for HTTP or HTTPS connections, you are ready to define your AP polices and tune AP parameters. To set and activate your AP polices, you need to perform two steps, similar to the steps that you perform when setting up CBAC:

• Define your AP policies.

• Activate your AP policies.

AP Policy Definitions

To define your AP policies, use the following configuration:

Router(config)# ip auth-proxy name AP_name {http | ftp | telnet}

  [inactivity-timer minutes] [absolute-timer minutes] [list {ACL_# | ACL_name}]

The ip auth-proxy name command is used to create your AP policies. If you have more than one interface and you need to define different policies for these interfaces, each policy will have a different AP_name. The name is used to group your policy statements.

Following the name is the authentication method that you want your users to use. For HTTPS, use http. If you want to use more than one method, list each method in a separate ip auth-proxy name command, but use the same AP_name.

Two optional parameters follow. The inactivity-timer parameter specifies the number of idle minutes that the user's authentication entries are kept before the Cisco IOS expires them. When they expire, the Cisco IOS removes the entries, which includes any temporary ACL entries that were downloaded from the AAA server. The absolute-timer parameter specifies that when the configured time period is reached, whether the user's connection(s) are idle or not, the user's authentication entries are expired and removed. By default, this value is set to 0, which means that only idle connections can be expired. These two timing parameters are used to override the global timing settings for AP (I discuss this command shortly).

One last optional parameter to this command is the specification of an ACL name or list. This can be a standard or extended ACL. For packets that match permit statements in the list, the router performs AP, ensuring that the user is authenticated. This enables you to control which users are authenticated.

Example 14-1 is a simple configuration example, based on the network shown in Figure 14-2, of defining your AP policies. Assume that HTTP is used here for authentication.

Example 14-1. Simple AP Policy Configuration

Router(config)# ip auth-proxy name internal_users http

Router(config)# ip auth-proxy name external_users http access-list 100

Router(config)# access-list 100 permit tcp any host 192.1.1.1 eq 80

As you can see in this example, two policies were defined: one for the internal users and one for the external users. For internal users, all users will be authenticated through HTTP, whereas, only external users trying to access web services on 192.1.1.1 will be authenticated.

AP Policy Activation

When you have created your AP policies, they are not used until activated on your router's interface(s). This is accomplished with the following configuration:

Router(config)# interface type [slot_#/]port_#

Router(config-if)# ip auth-proxy AP_name

The ip auth-proxy command activates the specified AP policy on your router's interface. For example, if you have defined two policies, one for internal users and one for external users, you need to activate the internal policy on all of the internal interfaces, and activate the external policy on all of the external interfaces.

In the previous example, to activate the two AP policies for Figure 14-2, you would use the configuration in Example 14-2.

Example 14-2. Activating AP

Router(config)# interface ethernet0

Router(config-if)# ip auth-proxy internal_users

Router(config)# interface ethernet1

Router(config-if)# ip auth-proxy external_users

Tuning AP

You globally can change two basic items to tune AP for your router: an authentication banner, and idle and absolute timeouts. The authentication banner is displayed during the login process and is similar to the banner created with the banner motd command. However, this banner is used only by users being authenticated through AP. Here is the syntax for this command:

Router(config)# ip auth-proxy auth-proxy-banner {http | ftp | telnet}

  [stop_character message stop_character]

As you can see, the format of this command is similar to that of the banner motd command: At the end, you need to specify a stop character at the beginning and ending of your banner message. Notice, however, that this is optional. If you omit the actual banner message, the router's default login banner is used; otherwise, the banner that you specify here is used. With AP, you must specify the authentication type?http, ftp, or telnet?for the banner. Unfortunately, currently there is no method of defining a different banner for different policies. In other words, it is not possible with the current versions of the Cisco IOS to create one banner for internal users and a second banner for external users.

Example 14-3 displays a simple sample of the use of this command.

Example 14-3. Creating a Banner for AP

Router(config)# ip auth-proxy auth-proxy-banner http #

***Unauthorized use of this system or the network***

***     is prohibited and will be punished to the***

***     fullest extent of the law                ***

***To gain access, you must be an authorized user***

***     and must authenticate with an approved   ***

***     username and password                    ***

#

Router(config)#

As you can see, you can enter a multiline banner.

As I mentioned with the ip auth-proxy name command previously, you can configure two timeouts for users' connections: idle and absolute. Changing these values with the ip auth-proxy name command affects only the timeouts for users authenticated with the specific policy name. You globally can set these timeouts with the following two commands:

Router(config)# ip auth-proxy inactivity-timer minutes

Router(config)# ip auth-proxy absolute-timer minutes

The inactivity-timer parameter specifies the number of minutes after a user is idle that the Cisco IOS will remove the user's authentication information, including any dynamic ACL entries that were created from the user's profile downloaded from the AAA server. This number can range from 1 to 2,147,483,647; the default is 60 minutes.

The absolute-timer parameter specifies the number of total minutes that the user's information is kept (it does not matter whether the user's connections are idle). This value defaults to 0, which means that the timer is disabled.

Remember my caution in the "AP Policy Definitions" section: Make sure that these timer values are greater than those that CBAC uses. Also, if a user's information is expired and removed, the user must reauthenticate before reaccessing previously authorized resources.

By default, even if you enable AAA accounting for AP, AP will not generate accounting records until you enable it with the following command:

Router(config)# ip auth-proxy auth-proxy-audit

When you do this and configure AAA accounting, the Cisco IOS creates start/stop records to record the users' authentication activities.

Protecting Against Access Attacks

AP provides a limited solution to protect you against access attacks, called watch lists. Watch lists enable you to place blacklisted users on a list, which AP denies access for. The IOS dynamically can learn blacklisted users by examining failed access attempts, or this information can be configured statically.

By default, watch lists are disabled. To enable them, use the following command:

Router(config)# ip auth-proxy watch-list enable

When it is enabled, AP uses watch lists to block blacklisted users from any further authentication attempts. The Cisco IOS automatically blacklists a person if he tries to authenticate and fails five successive times. You can change this value with this command:

Router(config)# ip auth-proxy max-login-attempts maximum_login_# 

The maximum number of logins can range from 1 to 2,147,483,647.

When a user exceeds the maximum number of allowed authentication attempts and watch lists are enabled, the user automatically is blacklisted. By default, a user is blacklisted for 30 minutes. After this time period, the user can attempt authentication again. To change this blocked period, use the following command:

Router(config)# ip auth-proxy watch-list expiry-time minutes 

The expiration, or block, period can range from 1 to 2,147,483,647. When a user is blacklisted, after this expiration time passes, the user automatically is removed from the watch list.

You manually can add and remove devices from the watch list with the following two respective commands:

Router(config)# ip auth-proxy watch-list add-item host_IP_address 

Router(config)# no ip auth-proxy watch-list add-item host_IP_address

Typically, you use the second command if a user accidentally enters the wrong username/password combination five or more times out of user/keyboard interface problems, and you need to remove that user from the watch list after instructing him what to enter to authenticate.

Copyright eTutorials.org 2008-2024. All rights reserved.