The console line interface is a serial DCE RJ45 port on the router. It provides a clock, and you have to match its settings. You can connect a dumb terminal or a computer running a terminal emulation program to it with a Cisco rollover cable and access the various command prompts on the router. The default settings for the console port are 9600 bps, no parity, 8 data bits, and 1 stop bit—or 9600-N-8-1 for short. The terminal settings can be changed by modifying the configuration register using the config-register global configuration mode CLI command. Of course, router security starts with physical security controls, so make sure that only a privileged few have physical access to your router, or you might see it for sale on an online auction site! This is an out-of-band line interface.

All routers also have another physical line interface called the auxiliary port. You can attach an external modem to this interface so that you can dial in to the device’s auxiliary port over the plain old telephone system (POTS) to perform out-of-band configuration.

Finally, let’s review the virtual terminal line interfaces or vtys. By default, all Cisco routers (and many other Cisco devices) come with five virtual terminal line interfaces: vty 0, 1, 2, 3, and 4. These virtual line interfaces are pseudo or dummy interfaces that terminate configuration traffic that arrives on the router in-band.

When you put passwords on the console, auxiliary, and virtual terminal line interfaces, you are protecting user-level access only. Cisco makes specific recommendations for security best practices for passwords and other login settings on these line interfaces. We examine basic security of the user and enable modes (essentially review from CCNA) and then look at some more advanced security features, including how to secure the ROM Monitor (ROMMON) mode on the router.

So far, we’ve treated user privilege as binary. They either have next-to-none (level 0) or they have super-user privilege when they’re in enable mode (level 15). There might be a number of people who need access to the router. The ISP might need access; the ACL administrator might need access; the Change Control and Configuration Management Policy might dictate that only one person is privileged enough to save the router’s configuration; and so on. To account for the need for these various privilege levels of access, the interim privilege levels (1–14) can be customized in a very granular fashion. You can assign what configuration mode(s) a user who has a defined privilege level is allowed to use. Optionally, you can set what commands they are allowed to execute. Let’s look at a simple example.

If you wanted to allow users at privilege level 3 to enter the configure command (something that they’re not normally allowed to do), you could type in these commands:

Now, when a user logs in, either in-band or out-of-band to the user mode, they can enable privilege level 3. The show privilege command indicates the current privilege level:

With the parser view feature, you can create a “view” that is a collection of all the commands that someone who has the password to that view is allowed to execute. A view is a contained shell environment that limits their view of the router. Unlike access granted via privilege levels where someone with level 10 access also has access to commands authorized at levels 1–9, role-based CLI is more modular. Access that is granted within one view is separate from other views. We’ll go through it step-by-step in a moment, but sometimes it’s better to take a look at an example first and use intuition.

Here’s an example of how views may be used in real life. Let’s say our router is managed by an ISP.

The following bullets list the items we want the ISP user to be able to accomplish while logged into the view, followed by the command keywords to enable this command in the view. These keywords are highlighted in the subsequent command output so you can pair them up with their descriptions below. Note that the parser view defines separately which exec commands and which configuration mode commands you are authorized to execute in the view. This follows the general hierarchy of CLI commands:

    Exec Commands:

    Ping IP hosts: ping

    Use all show commands: all show

    Configuration Modes:

    Enter global configuration mode: configure

    Create ACLs: access-list

    Enter interface configuration mode: all interface

    Use all IP configuration commands: all ip

First, we enable the AAA system on the router:

Then we enable the view context and supply the enable secret password. The view hasn’t been created yet. The view context tells the router that subsequent commands are executed within the context of creating a view.

Now we enter global configuration mode and create the view by giving it a name, specify a password, and then we specify which exec mode commands can be executed in the view.

Here we specify that the user can configure from all sources (for example: terminal, memory, terminal):

Now we specify which global configuration commands the user can execute. He can use the access-list command, and all forms of the interface command and ip command:

Once you’ve configured this view for the ISP, here’s what it looks like from the ISP’s perspective. Should he be able to execute the write mem command? The answer is no, because we have not given the ISP view access to that command. Let’s enable the view and try out all the commands that the ISP user is authorized to execute, as well as the write mem command, which he is not authorized to execute:

Everything works great up to now, but then the ISP user tries to execute a command that he is not authorized to execute:

The show parser view command can be used to verify the views configured on the system:

In summary, here are the steps to create a view:

The Cisco IOS resilient configuration feature enables the router to take secure snapshots of the router’s running configuration file and image. This protects the router against attempts by an attacker to erase the contents of NVRAM and flash (persistent storage). These secured files are hidden from standard commands that view the contents of persistent storage. For example, the show flash command will not show the secure image file. If a router has been compromised, the resulting down time is reduced because the router maintains secure archives of the required files and there is no need to search for backups of these files elsewhere.

The first command creates a secure copy of the IOS image. It also indicates what happens if you don’t have an ATA disk (required):

That didn’t work too well. Let’s try to make a secure copy of the running configuration file:

Now, we’ll execute the command that verifies the bootset:

Recall from Chapter 1, “Network Insecurity,” that there are two broad categories of attacks: access attacks and DoS attacks. We will examine three methods to mitigate the successfulness of these attacks against SSH, Telnet, and HTTP login to the IOS router:

    Shutting down or “blocking” the login system if DoS attacks are suspected.

    Enforcing a delay between successive login attempts.

    Generating syslog messages for login detection.

Five different banners can be configured on the IOS router:

    Exec. This banner is displayed when an exec mode (user or enable) is entered on the router.

    Incoming. This banner is displayed when there is an incoming connection to a terminal line from a network host.

    Login. This banner is displayed before the username/password prompt.

    MOTD. The message-of-the-day banner.

    SLIP-PPP. This banner is displayed for dial-in users on a Serial Line Internet Protocol (SLIP) or Point-to-Point Protocol (PPP) connection.

Remember that the router, in its role as a perimeter device, is often the first device an attacker is likely to see as he probes the network. The banners are the first thing that users see when they login to the routers. This would be an appropriate place to put warning messages and legal statements, such as the repercussions of unauthorized access to the system. Don’t give away any information in your banner message that might be useful to an attacker. Above all, don’t tell anyone that they’re “Welcome.” If they’re an attacker, they certainly aren’t, and the router’s login banners should not be the equivalent of a welcome mat in any case. Here’s a partial configuration showing an example of a MOTD banner:

There are certain files that are required to run the Cisco SDM from the router’s flash file system. If these files don’t exist, they will need to be downloaded from Cisco. They come as part of a comprehensive download that also includes the files required to run the SDM applet from a PC workstation. Factory fresh routers from Cisco will have these files in flash. If they are not there, it means that someone has deleted them, perhaps because the organization’s security policy specifies that only the CLI can be used to configure the router.

These files are needed to run Cisco SDM 2.2a and later from the router:

    sdmconfig-modelxxx.cfg: The default configuration for the model of ISR (for example: sdmconfig-2811.cfg)

    sdm.tar

    es.tar (for SDM Express; can be deleted if only the SDM is being used)

    common.tar

    home.shtml

    home.tar

    wlanui.tar (if ISR has wireless interfaces)

This router does not have all the files necessary to run SDM:

Because the router in the previous example doesn’t have enough flash memory, not all the files necessary to run the Cisco SDM are present. If you browse to https://router-ip-address, the Cisco SDM Express will launch instead.

On a new router, you browse to http://10.10.10.1 that is the default IP address of a new router. The initial configuration is completed by using the Cisco SDM Express Wizard. After the initial configuration of the router is complete, the Cisco SDM Express is no longer offered. Subsequent changes to the configuration use the full Cisco SDM.

Figure 3.4 illustrates the Cisco SDM Express.

FIGURE 3.4 Cisco SDM Express.

After you have completed the router’s initial configuration with the SDM Express, you can now launch the SDM for more advanced configuration chores. There are two ways to launch the SDM, as follows:

    Cisco SDM on a PC. Use the Cisco SDM Launcher. The default location is Start->Programs->All Programs->Cisco Systems->Cisco SDM->Cisco SDM.

    Cisco SDM in Router Flash Memory. Open up a web browser and browse using either HTTP or HTTPS to the IP address that has been configured on the router.

Figure 3.5 shows both the SDM Launcher and using a web browser to access the Cisco SDM.

FIGURE 3.5 Two methods to launch the SDM.

If you choose to use a web browser to launch SDM, it must meet the requirements in Table 3.1.

Accomplishing tasks on the Cisco SDM is done through buttons along the top of the SDM home page corresponding to different modes. Figure 3.6 illustrates these buttons.

In summary, these modes are as follows:

    Configure Mode. Provides its own task panel with buttons that represent the different configuration tasks and wizards for the novice.

    Monitor Mode. Provides its own task panel with views to the current status of the router.

    Refresh. Updates the current running configuration on the router with the Cisco SDM.

    Save. Saves the running configuration to the startup configuration on the router (CLI: copy running-config startup-config).

When you press the Configure mode button, a task panel appears. Pressing some of the buttons in this task panel will launch a smart wizard. Figure 3.7 shows some of the tasks that come up when you press the Configure mode button.

FIGURE 3.7 Configuration task panel.

The following smart wizards are available from the tasks shown in Figure 3.7. Note that there is more than one wizard for each task. For example, in the Virtual Private Network (VPN) Wizards, you can configure site-to-site IPsec VPNs, remote-access Ipsec and Secure Sockets Layer (SSL) VPNs, Dynamic Multipoint VPNs (DMVPNs), and others. VPNs are discussed in Chapter 7, “Virtual Private Networks with IPsec.”

    Interfaces and Connections Wizards. Configure serial and LAN interfaces.

    Firewall and ACL Wizards. Configure basic or advanced firewall.

    VPN Wizards. Configure different types of VPNs.

    Security Audit Wizards. Perform a router security audit.

    Routing Wizards. Configure static routes and dynamic routing protocols.

    NAT Wizards. Configure basic and advanced NAT.

    Intrusion Prevention Wizards. Configure the IOS IPS.

    Quality of Service Wizards. Configure QoS to prioritize traffic as it flows through the router.

    NAC Wizards. Configure Network Admission Control policies.

If you scroll down one more button in the Configuration Task Panel (shown in Figure 3.7), you see a button marked Additional Tasks. Figure 3.8 shows the advanced configuration tasks that come up when you click the Additional Tasks button.

Here are the tasks that can be completed in the Additional Tasks menu illustrated in Figure 3.8:

    Router Properties. Some of the tasks that you can complete include configuring the router hostname, domain, password, date, and time.

    Router Access. Some of the tasks that you can complete include role-based user access, management, and SSH.

    DNS and DDNS. Some of the tasks that you can complete include configuring Domain Name Service (DNS) and Dynamic DNS.

    ACLs. You can create and edit standard, extended, and named ACLs here.

    AAA. The major tasks that you can accomplish include configuring local and external authentication and authorization.

    Router Provisioning. The USB port can be configured here for secure device provisioning.

    802.1X. Port-based authentication through IEEE standard Extensible Authentication Protocol (EAP) using IEEE 802.1X can be configured here.

In monitor mode, you can view important information about your router, including the firewall status, interface status, and active VPN connections. You can also view the router event log. This is illustrated in Figure 3.9.

FIGURE 3.9 Cisco SDM monitor mode.

Here is a summary of the information that can be viewed in monitor mode:

    Monitor Overview Window. Shows router status (CPU usage, flash memory usage, and flash usage) and a list of the error log entries.

    Interface Status. Shows whether interfaces are up or down, bandwidth utilization, and so on.

    Firewall Status. Shows a log with the number of access attempts that the router’s firewall has denied.

    VPN Status. Statistics about active VPN connections.

    QoS Status. Shows policy information on the interfaces.

    NAC Status. Shows the number of NAC sessions on the router.

    Logging. Contains the router event log grouped by severity level.

The following list represents a simple definition of the three A’s in AAA.

    Authentication. Establishes who you are.

    Authorization. Now that we know who you are, we can establish what you can do and what you can access.

    Accounting. Also, now that we know who you are, we can establish what you did, how long you did it, and how often you did it.

Note the heavy emphasis on you. (This isn’t a comment on society, by the way!) Clearly it all starts with authentication, because authorization and accounting would not be possible without establishing an individual’s identity first.

Cisco specifies two main reasons for implementing AAA on Cisco routers. These are outlined in the following list:

    Remote User Network Access. AAA is performed in support of IPsec and SSL VPN users and dial-up users before they are permitted access to an organization’s network.

    Administrative Access. AAA is performed before a user is permitted administrative access to a router (console, Telnet/SSH/HTTP, auxiliary).

Let’s now look at how Cisco implements AAA for Cisco routers. There are two main categories of AAA implementations: local AAA (or “self-contained” AAA) and external AAA. These are outlined next:

    Self-Contained AAA. Local authentication on the router or other network access server (NAS) using a local username/password database. Essentially, the device is acting both as AAA client and server.

    External Authentication. Authentication using an external Cisco Secure Access Control Server (ACS). There are three separate Cisco Secure ACS external AAA solutions:

    Cisco Secure Access Control Server for Microsoft Windows Server.

    Cisco Secure ACS Express: An entry-level RADIUS and TACACS+ AAA 1U server appliance. Supports up to 50 AAA clients, as well as 350 unique user logons in a 24-hour period.

    Cisco Secure ACS Solution Engine: An appliance that supports many more AAA clients and unique user logons than Cisco Secure ACS Express.

Recall from the “Two Reasons for Implementing AAA on Cisco Routers” section in this chapter that there are two types of access. Access to the router is called “remote administrative access”. Access through the router to networks beyond the router is called “remote network access.” Figure 3.10 illustrates this difference, as does Table 3.2, which defines how Cisco further categorizes these two main types of access.

FIGURE 3.10 Types of access and AAA placement.

TABLE 3.2 Types for Router Access

There are four basic tasks to configuring local AAA (whether character or packet mode) on a router:

Task 1: Configure user accounts by creating a username/password database on the router.

Task 2: Enable AAA on the router.

Task 3: Configure AAA on the router, defining what type of remote access (administrative or network) AAA is to be performed and tying it to the username/password database.

Task 4: Verify and possibly troubleshoot the AAA configuration.

These tasks are the same whether you are using the Cisco SDM or the CLI. The following sections show the detailed steps in each task. Let’s perform the first three tasks using the SDM. The equivalent CLI command appears as a separate note with each task. Judge for yourself whether you prefer to use the GUI or the CLI.

Task 1: Configuring User Accounts

Figure 3.11 illustrates the Add an Account dialog that you use to add a local user account on the router.

FIGURE 3.11 Configuring user accounts using Cisco SDM.

The separate steps to add a user per the dialog illustrated in Figure 3.11 are detailed next. The labels on Figure 3.11 correspond to the steps in the list:

1. Choose Configure->Additional Tasks->Router Access->User Accounts/View in the SDM.

2. Click Add to create a new user.

3. In the resulting window, enter the username and password.

4. If you haven’t created views or lesser privilege levels, change this user’s Privilege Level to 15.

5. (Optional) If views have been defined, you can check the Associate a View with the user check box and select a view from the drop-down list.

6. Click OK and you’re done.

Note

The SDM generates the username ispuser privilege 15 view root secret 5 $1$Q0Kr$YNRAK9n/9Y1SqprgqpmYC/ CLI command.

Task 2: Enabling and Disabling AAA

As we saw in the previous subsection, “Figure 3.12 illustrates the SDM dialog that is used to enable or disable AAA.

FIGURE 3.12 Enabling and disabling AAA using Cisco SDM.

Choose Configure->Additional Tasks->AAA-> Enable (or Disable). Note the status of AAA. The GUI will tell you if it is enabled or disabled. If it is enabled, the button will be labeled Disable. If it is disabled, the button will be labeled Enable. If you click the Disable button, you will be warned that all AAA will be disabled. Recall that enabling AAA was a prerequisite for creating privilege levels and for views.

Note

The SDM generates the aaa new-model CLI command when you click Enable. The CLI command no aaa new-model disables AAA.

Task 3: Configuring AAA on the Router

Figure 3.13 illustrates the basic steps required to configure AAA on the router.

FIGURE 3.13 Configuring AAA on the router.

What follows are the basic steps required to configure AAA on the router. The labels on Figure 3.13 correspond with the numbers of the following steps:

1. Choose Configure->Additional Tasks->AAA->Authentication Policies->Login and click Add.

2. In the resulting “Add a Method List for Authentication Login” window, verify that Default is selected in the Name drop-down list.

3. Click Add.

4. From the “Select Method Lists(s) for Authentication Login” window, choose local.

5. Click the OK button on the Select Method List(s) for Authentication Login window.

6. Click the OK button on the Add a Method List for Authentication Login window to complete the task.

Note

The SDM generates the aaa authentication login default local CLI command.

Let’s examine some additional CLI commands that help secure and verify an AAA configuration that uses the local database for authentication.

If you want to lock out any user after 10 failed login attempts for local AAA, you can issue this command:

To identify local AAA users whose accounts have been locked out, you type in this command:

Here’s an example. It appears that the ISP user has been locked out. What were they doing working on the weekend anyway?

To clear (re-instate) all local AAA users who have been locked out, type in this command:

If you want to clear a single local AAA user, you can use this form of the command, where ispuser is the locked-out user:

To display detailed statistics of all logged-in users, you type in this command:

The following command displays current sessions of users who have been authenticated, authorized, or accounted by the AAA module. It shows AAA sessions with their unique IDs:

Here’s an example of its output:

Cisco Secure ACS is most often used in networks where there are a large number of devices that need to be configured for AAA, and configuring local AAA on each device is thus made impractical and cumbersome. Here are some main reasons for implementing Cisco Secure ACS:

    Local authentication on a Cisco router does not scale well.

    Cisco Secure ACS can create a central user and administrative access database for an entire network (see the following note).

    Cisco Secure ACS works with many external databases, such as existing Active Directory, LDAP, and others.

These are the features shared by all versions of Cisco Secure ACS:

    Web-based GUI

    Supports LDAP, Active Directory, Novell Directory Services (NDS), and ODBC databases

    Rich accounting and user reporting features

    Supports TACACS+ and RADIUS

    Tightly integrated with Cisco IOS router and Cisco VPN solutions

    Supports third-party OTPs

    Access restrictions through dynamic quotas

Figure 3.14 illustrates the home page for Cisco Secure ACS.

Unlike the Cisco Secure ACS Solution Engine and the Cisco Secure ACS Express, which are appliances, Cisco Secure ACS for Windows must be installed as an application on top of an existing Windows server.

The Cisco Secure ACS for Windows software requirements are as follows:

    Windows 2000 Server with Service Pack 4

    Windows 2000 Advanced Servers with Service Pack 4

    Windows Server 2003 Standard Edition

    Windows Server 2003 Enterprise Edition

The Cisco Secure ACS for Windows hardware requirements are as follows:

    Pentium IV processor 1.8GHz or faster

    1GB of RAM

    Minimum 500MB to 1GB free disk space (more required if the database is on the same computer)

    Minimum graphics resolution of 256 colors at 800x600 pixels

One immediate advantage of these devices is that the software comes pre-installed on a 1U, rack-mountable server form factor with a security-hardened Windows Server pre-installed. Table 3.3 compares the specifications and capabilities of these devices.

TABLE 3.3 Rack-Mount ACS Solutions Comparison Matrix

Whether you use Terminal Access Control Access Control Server Plus (TACACS+) or Remote Dial-in User Services (RADIUS) in your AAA implementation depends very much on what you need to accomplish. For example, the business needs of a large ISP might dictate that they choose the RADIUS protocol for their AAA solution because of the detailed accounting that is needed for billing dial-up and DSL users. On the other hand, if yours is an enterprise that has many groups of users accessing your core network devices, a centralized means to deploy granular authorization policies on a per-user or per-group basis may be required. In that case, TACACS+ would be a good solution. Table 3.4 represents a summary of some of the important differences between the two protocols.

TABLE 3.4 TACACS+ vs. RADIUS Comparison

One of the main tasks in setting up Cisco Secure ACS is establishing communication between the AAA client(s) and the AAA server, Cisco Secure ACS. You must ensure that all the IP addresses and port numbers that are required to set up the TACACS+ or RADIUS link between the AAA devices are not blocked by other devices. You are not always lucky enough to have the devices physically co-located on the same IP subnet. Many security policies dictate that the AAA server be in a separate DMZ or other protected zone that implies that there may well be a firewall on the communication path between the AAA devices. (Firewalls are discussed in Chapter 5, “Using Cisco IOS Firewalls to Implement a Network Security Policy.”) There are some other prerequisites for Cisco Secure ACS of which you should be aware, as follows:

    Cisco IOS Release 11.2 or later must be installed on the Cisco AAA clients.

    Non-IOS Cisco devices (or non-Cisco devices) must be configurable for standards-compliant RADIUS and/or TACACS+.

    A supported web browser must be installed on the Cisco ACS server (see the following note).

We’re going to take a different approach from most texts to understanding how Cisco Secure ACS works. We start in a very task-oriented fashion. First, we focus on getting a working external AAA set up, and then we look at some of the features of Cisco Secure ACS that have not yet been examined, followed by some verification and debugging commands.

On Cisco Secure ACS, the starting point for setup will always be the navigation bar on the left side of the Cisco Secure ACS browser window. See Figure 3.15 for a screenshot. This screenshot was obtained by browsing to the Cisco Secure ACS home page using a web browser right on the server. Recall that when administering the ACS right on the hosting server, you browse to the local loopback IP address of the server.

The three main tasks for setting up external AAA are the following:

Task 1: Configure the AAA network (client and server).

Task 2: Set up users (server).

Task 3: Identify traffic to which AAA will be applied (client). This has three subtasks:

    Configuring authentication

    Configuring authorization

    Configuring accounting

Figure 3.16 shows where these three tasks occur The numbered labels in the figure match up with the task list. These general tasks would be followed regardless of the external AAA solution. Of course, we will model our solution after Cisco Secure ACS.

FIGURE 3.16 Three main tasks for setting up external AAA.

This section now goes on to discuss each of these tasks in more detail.

Task 1: Configuring the AAA Network (Client and Server)

Setting up the AAA network essentially consists of setting up a relationship between two peers, the AAA client and the AAA server. The server peers on the client and the client peers on the server. They perform mutual authentication using a pre-shared key and using the same protocol (RADIUS or TACACS+) to exchange AAA information. These main elements must be completed on both the AAA client and the AAA server:

    Set up the protocol (RADIUS or TACACS+).

    Specify the vendor of server (because port numbers used vary).

    Specify the IP address of the peer.

    Specify the pre-shared key (pre-shared because both client and server use the same key).

We perform these tasks first on the Cisco Secure ACS (the AAA server) and then on the IOS router (the AAA client).

Adding an AAA Client in Cisco Secure ACS

Figure 3.17 illustrates the fields that need to be filled out in adding an AAA client in Cisco Secure ACS.

FIGURE 3.17 Adding an AAA client in Cisco Secure ACS.

The steps to add a Cisco IOS router as an AAA client in Cisco Secure ACS are as follows:

1. Click the Network Configuration button on the navigation bar. The Network Configuration page appears.

2. Click Add Entry in the AAA Clients section.

3. Enter the client hostname in the AAA Client Hostname field. This is the name of the router that will be the AAA client from Cisco Secure ACS’s perspective.

   Note

   Here’s a tip. You should take care when choosing the name for the AAA client in the AAA Client hostname field referenced in Figure 3.17. The hostname is actually a unique connection name and should reflect the hostname of the router and the protocol name so that we can use both TACACS+ and RADIUS between the ACS and the router (that is, “hostname-tacacs” and “hostname-radius”).

4. Enter the router’s IP address in the AAA Client IP Address field.

5. Enter the pre-shared secret key in the Shared Secret field (remember this value, as you will need it when you set up the router for AAA).

6. Choose the correct AAA protocol in the Authenticate Using drop-down list.

7. Complete any other parameters as required.

8. Click Submit and Apply.

Adding an AAA Server on the Cisco IOS Router

Now that we have configured the AAA client information on the AAA server, we can perform essentially the same steps, but now on the AAA client. Figure 3.18 illustrates the Add AAA Server dialog in Cisco SDM.

FIGURE 3.18 Adding a TACACS+ server to Cisco IOS router.

The following shows how to use SDM to add a TACACS+ AAA server to a Cisco IOS router (the CLI appears in a note at the end):

1. Open up the SDM, and choose Configure->Additional Tasks->AAA->AAA Servers and Groups->AAA Servers.

2. Click Add in the AAA Servers pane. The Add Server window appears. From the Server Type drop-down list, choose TACACS+.

3. Enter the IP address or hostname of the Cisco Secure ACS in the Server IP or Host field.

   Note

   Put in the hostname only if the router has been configured for Domain Name Service (DNS) lookups.

4. (Optional) You can choose to maintain a persistent connection to the server rather than opening and closing connections with every transaction. If this is what you want, check the Single Connection to Server (for CiscoSecure) check box. This is more efficient but only supported on Cisco Secure ACS version 1.0.1 or higher.

5. (Optional) If you want to set a timeout value specific to this server, enter a value in the Timeout (seconds) field in the Server-Specific Setup section. Otherwise, the router will use the value configured in the AAA Servers Global Settings window.

6. (Optional) If you want to set a pre-shared key specific to this server, enter a value in the New Key field in the Server-Specific Setup section. Otherwise, the router will use the value configured in the AAA Servers Global Settings window.

7. Click OK.

Note

The CLI command generated by the SDM will be of the form tacacs-server host 192.168.99.133 key cisco123.

Task 2: Setting Up Users in Cisco Secure ACS (Server)

The users are set up on Cisco Secure ACS, as illustrated in Figure 3.19.

FIGURE 3.19 User setup in Cisco Secure ACS.

Open up Cisco Secure ACS and follow these steps to set up users. The labels on Figure 3.19 correspond with the step numbers:

1. In the navigation bar, click User Setup.

2. To create a new user, simply enter a username in the User field and click Add/Edit. (If this user already exists, you will be editing that user.)

3. Enter data in the fields to define the user account in the Edit pane. You will probably want to set the user’s password, as well as TACACS+ enable control, TACACS+ enable password, and TACACS+ shell authorized command. (Recall that command authorization is one of the features of TACACS+.)

4. Click Submit.

Note

What you see in the Edit pane in User Setup will depend on the interface configuration. “Interface” is this context means the user’s interface to ACS. The interface is set up when ACS is installed, but if you want to modify it, you may customize what fields are visible by choosing Interface Configuration->User Data Configuration from the navigation bar.

Task 3: Identifying Traffic to Which AAA Will Be Applied (Client)

The identification of which traffic must have AAA service applied to it is done on the AAA client, which is the IOS router in our example. This task has three different elements to it, depending on which of the 3 A’s in AAA we want to apply to the traffic. Recall that we must perform authentication at a minimum because authorization and accounting depend on authentication: To repeat, here are the subtasks that we examine separately and in order in the subsequent sections:

    Configuring authentication

    Configuring authorization

    Configuring accounting

Once the network is set up as in Task 1, this group of AAA server settings is modular and can be used for a number of purposes. For example, once you have set up a TACACS+ server for authentication, it could be used for both remote administrative access and remote network access purposes.

Creating an AAA Login Authentication Policy on the AAA Client

Figure 3.20 illustrates the steps that are required to create an AAA login authentication policy on the AAA client.

FIGURE 3.20 Adding a login authentication method in Cisco SDM.

Follow these steps to create an AAA login authentication policy using Cisco SDM on the IOS router, our AAA client:

1. Open up the Cisco SDM home page and choose Configure->Additional Tasks->AAA->Authentication Policies->Login.

2. Click Add from the Authentication Login pane.

3. From the Name drop-down list, choose User Defined to create a new authentication method.

4. In the Specify field, enter the authentication login method list name; MY_TACACS, for example.

5. To define the methods that this policy uses, click Add. The Select Method List(s) for Authentication Login window appears.

6. From the method list, choose group tacacs+.

7. To add group tacacs+ to the method list, click OK. This will return you to the Add a Method List for Authentication Login window. The just-added method will now appear in this list.

8. To add a backup method for this policy, click Add. The Select Method List(s) for Authentication Login window appears.

9. This time, choose enable from the method list. This will cause the enable password to be used as the backup login authentication method.

10. To add enable to the method list, click OK. This will return you to the Add a Method List of Authentication Login window. Both group tacacs+ and enable should show up in the window. To make the enable password a back up to the group tacacs+ authentication method, make sure it appears below the group tacacs+ authentication method.

11. To add the authentication login method list, click OK.

Note

The CLI command that is generated by the Cisco SDM is aaa authentication login MY_TACACS group tacacs+ enable.

Applying the Authentication Method

The authentication login method list, like any policy, has no effect by itself once created. It must be applied to an entity on the device. This is a handy rule of thumb on Cisco devices. You create a policy; then you have to apply it somewhere. Keeping in mind that we have set up a login authentication method (and using your intuition), this authentication method most likely needs to be applied to one of the line interfaces on the router. In this scenario, we apply the authentication method MY_TACACS, to the five default vty lines on the router.

The Cisco SDM dialog to apply the authentication method MY_TACACS to the vtys is illustrated in Figure 3.21.

FIGURE 3.21 Applying the authentication method to the vtys using the Cisco SDM.

To apply the authentication method to the vtys using the SDM, follow these steps:

1. Choose Configure->Additional Tasks->Router Access->VTY->Edit.

2. In the Edit VTY Lines window, choose the MY_TACACS login authentication method from the Authentication Policy drop-down list.

3. Click OK to deliver the commands to the router.

The CLI command to apply the authentication policy to the vtys would look like this:

CiscoISR#configure terminal
CiscoISR(config)#line vty 0 4
CiscoISR(config-line)#login authentication MY_TACACS

Now when administrators log in to the Cisco IOS router via the vtys, they will be prompted for a username and password. These credentials will be validated using the TACACS+ protocol against the user database on the Cisco Secure ACS. It should be noted that this will not affect SDM login, only access via Telnet or SSH.

Thus, we have completed the tasks to perform the first A in AAA, authentication. Let’s turn our attention to the second A in AAA, authorization. Leveraging on our TACACS+ server, we will:

    First, create and apply an authorization policy for exec (character mode).

    Second, create and apply an authorization policy for network (packet mode).

Creating and Applying an AAA Exec Authorization Policy

The method to create an exec authorization policy is illustrated in Figure 3.22.

FIGURE 3.22 Creating and applying an AAA exec authorization policy.

Note

The following steps assume that we have already configured an authorization policy on the Cisco Secure ACS (we have!). If you create and apply an AAA exec authorization policy before you have configured one on the authorization server, you will lock yourself out of the router. This is very embarrassing.

Using the Cisco SDM and starting at the home page, follow these steps to create and apply the default authorization method list for exec (character mode) access. Figure 3.22 is labeled to correspond to the numbers in the following list of steps:

1. Choose Configure->Additional Tasks->AAA->Authorization Polices->Exec.

2. Click Add in the Exec Authorization pane.

3. Choose Default from the Name drop-down list in the Add a Method List for Exec Authorization window.

4. To define the methods that this policy uses, click Add.

5. Choose group tacacs+ from the method list in the Select Method List(s) for Exec Authorization window.

6. Click OK on the next two windows in succession to return to the Exec Authorization pane.

Note

The Cisco SDM will generate this CLI command:

aaa authorization exec default group tacacs+

Now, when administrators access the CLI, they will only be allowed to execute the commands they are authorized to use as defined in the user’s authorization policy on the Cisco Secure ACS.

Creating and Applying an AAA Network Authorization Policy

Let’s now turn our attention to defining what a user is authorized to do on the network segment protected by the Cisco IOS router.

The method to create a network authorization policy is illustrated in Figure 3.23.

FIGURE 3.23 Creating and applying an AAA network authorization policy.

Starting on the Cisco SDM home page, complete the following steps to configure the default authorization method list for network (packet mode) access. Figure 3.23 has labels corresponding to the numbers of the following steps:

1. Choose Configure->Additional Tasks->AAA Authorization Policies->Network.

2. Click Add in the Network Authorization pane.

3. Choose Default from the Name drop-down list in the Add a Method List for Network Authorization window.

4. To define the methods that this policy uses, click Add.

5. Choose group tacacs+ from the method list in the Select Method List(s) for Network Authorization window.

6. Click OK on the next two windows in succession to return to the Network Authorization pane.

Note

The Cisco SDM will generate this CLI command:

aaa authorization network default group tacacs+

AAA Accounting Configuration

When properly configured, Cisco Secure ACS acts as a central repository of tracked events as they occur on the network. For example, our comprehensive network security policy might stipulate that all failed login attempts to (and through) the routers are to be tracked, with detailed information about the attempt such as user credentials, time of day, and date. Without keeping track of this information, we might not be able to provide data to aid in a forensic investigation should our network be compromised or otherwise attacked.

As with authentication and authorization, you must first create a method list (the policy), and then apply it to the right entity. As we have seen, method lists can be multi-purpose, so a method list may support all three As in AAA.

AAA involves six different types of accounting, as follows:

    Network. Runs accounting for all network-related service requests, including Serial Line Internet Protocol (SLIP), PPP, PPP Network Control Protocols (NCPs), and AppleTalk Remote Access Protocol (ARAP).

    Connection. Provides information about all outbound connections made from the network access server, such as Telnet.

    Exec. Runs accounting for the EXEC shell session.

    System. Performs accounting for all system-level events not associated with users, such as reloads.

    Commands. Runs accounting for all commands at the specified privilege level.

    Resource. Performs accounting for resource use by remote users of the system. (The command syntax for setting resource accounting is different than the other items listed.)

These different types of accounting are reflected in the command syntax of the aaa accounting command:

aaa accounting { system | network | exec | connection | commands level }
{default | list-name} {start-stop | stop-only | none} [method1 [method2]]

Use the following form of the command to perform accounting for system resource use by remote users:

aaa accounting resource method-list start-stop [broadcast] group groupname

To set up accounting using the CLI, follow these basic steps (with examples):

1. Create an accounting method list and enable accounting.

   CiscoISR(config)#aaa accounting connection default start-stop group
   tacacs+

   
   

2. Enter line configuration mode or interface configuration mode for the lines or interface to which the accounting method list will be applied.

   CiscoISR(config)#line vty 0 4

   
   

3. Apply the account method list to the line(s) or interface(s).

   CiscoISR(config-line)#accounting connection default

   
   

Here are a handful of useful commands for troubleshooting and debugging local AAA, RADIUS, and TACACS+.

For a high-level view of login activity, use the following CLI command:

Here is an example of the output of the debug aaa authentication command. The highlighted output indicates that someone logged on to this ISR and that the authentication method used was local_auth:

For more detailed debugging of TACACS+ in particular, use the following CLI command:

For even more detailed information about the TACACS+ helper process, you can use the following CLI command. Be careful with its use, because it generates copious amounts of output.

For more detailed debugging of RADIUS in particular, use the following CLI command:

For even more detailed information about the RADIUS helper process, you can use the following CLI command. Be careful with its use, because it generates copious amounts of output:

Here is a snapshot of a partial configuration with the commands in Tasks 1, 2, and 3 for setting up external AAA and including the preceding AAA accounting configuration. If the commands don’t make sense, review them in the preceding sections: