You want to administer login ID and password information centrally for all routers.

Cisco changed the AAA syntax slightly in Version 12.0(5)T. The following set of commands allows you to configure TACACS+ authentication in the older (pre-12.0(5)T) IOS versions:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default tacacs+
Router1(config)#aaa authentication enable default tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

Newer IOS versions require the group keyword, which defines server groups. Therefore, you would now configure the same functionality as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+
Router1(config)#aaa authentication enable default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

When you configure AAA authentication on a router, it starts to ignore the locally configured passwords in favor of those provided by the TACACS+ server. In this example, we have configured the router to consult TACACS+ for both the login and enable passwords. This is a great labor saver because it means that you don’t have to reconfigure all of your routers just because you want to change passwords. Instead, because the passwords are stored on a central server, you can change them once and the new passwords instantly propagate to all of your routers. If the router can’t reach the TACACS+ server due to a failure of either the network or the server, it resorts to using the locally configured passwords.

For audit and control reasons, most organizations that implement AAA supply a unique username and password for each individual user. While it is possible to store all of this information locally on the router, if you have a large number of routers, it is extremely time consuming to reconfigure all of the routers to reflect a password change, or to simply add a new user. One of the main advantages to using TACACS+ for AAA authentication is that none of the information is stored on the router. Instead, when a user tries to log in, the router automatically sends a query to the TACACS+ server to verify the login credentials. This minimizes the configuration on each router. And, because this query is done each time, the information is always up-to-date.

When TACACS+ is working correctly, the router prompts for both a login ID and password instead of the usual line password only:

freebsd% telnet toronto
Trying 172.25.1.5...
Connected to toronto.
Escape character is '^]'.


User Access Verification

Username: ijbrown
Password: xxxxxxxx

Router1>

The most obvious drawback to using a central server for authentication is that it represents a single point of failure. Therefore, TACACS+ allows you to configure several servers:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#tacacs-server host 172.25.1.1 key COOKBOOK
Router1(config)#tacacs-server host 10.12.1.33 key OREILLY
Router1(config)#end
Router1#

Note that we have defined different encryption keys for each server. This is the key that TACACS+ uses to encrypt the session between the router and the central server. It is important to protect this encryption key. The ability to configure different keys for the different servers helps to improve your overall security by making sure that you can always switch quickly to the backup server if you suspect that the primary’s encryption key has been compromised.

The order of these server commands is important because it reflects the order that the router uses to consult the servers. If the first server is unreachable, the router resorts to the next one, and so on. If no server responds, the router will use locally configured passwords. This also allows you to easily set up a simple form of load sharing among multiple servers by making one group of routers use the first server as their primary, and having the second group of routers use the second server. Then you can configure both groups of routers to use the other server as a backup. In this way, you can have all of the benefits of fault tolerance as well as load balancing.

The examples in this recipe and many others throughout this chapter show two sets of syntaxes because Cisco changed the AAA commands in IOS Version 12.0(5)T. The big change is the addition of AAA server groups. In the recipe example, we have opted to use the default TACACS+ group, which consists of all of the servers defined using tacacs-server host commands:

Router1(config)#aaa authentication login default group tacacs+
Router1(config)#aaa authentication enable default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1

However, some organizations are so large that they have to deploy many TACACS+ servers. In this case, it is convenient to create groups of servers, either by geography or some other logical grouping:

Router1(config)#aaa group server tacacs+ SERVERGROUP-A
Router1(config-sg-tacacs+)#server 172.25.1.1
Router1(config-sg-tacacs+)#server 10.12.1.33
Router1(config-sg-tacacs+)#exit
Router1(config)#aaa authentication login default group SERVERGROUP-A

You can also create groups of RADIUS servers if required.

By default, the router allows three login attempts before dropping a session. You can modify this limit using the TACACS+ command tacacs-server attempts. In the following example, we have configured the router to allow only one failed login attempt before dropping the session:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#tacacs-server attempts 1
Router1(config)#end

Once you implement this command, the router’s login behavior will change:

freebsd% telnet toronto
Trying 172.25.1.5...
Connected to toronto.
Escape character is '^]'.

User Access Verification

Username: ijbrown
Password: <wrong password>
Connection closed by foreign host.
freebsd%

You can configure the maximum number of failed login attempts to be any number between 1 and 1000. However, having a high number makes it considerably easier to launch a brute force password-guessing attack. So in general it is better to keep the maximum number small.

Most large organizations have a security policy that dictates the maximum number of failed logins, with typical values being three or four attempts. Check with your local security department to see what policies you should be following.

Recipe 4.3; Recipe 4.9; Recipe 3.1

You want to restrict permissions so that specific users can only use certain commands.

You can enable TACACS+ command authorization in newer IOS versions with the following set of configuration commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authorization exec default group tacacs+
Router1(config)#aaa authorization commands 15 default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

In any IOS version before 12.0(5)T, the AAA syntax was slightly different:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#aaa new-model
Router2(config)#aaa authorization exec default tacacs+
Router2(config)#aaa authorization commands 15 default tacacs+
Router2(config)#end
Router2#

After you configure AAA authorization, the router queries the TACACS+ server each time somebody enters a command to see if it is allowed. If the user is permitted to use this particular command, the TACACS+ server will respond with an “accept” message and the router will proceed to execute the command. However, if the user is not permitted to issue the command, the TACACS+ server responds with a “reject” message, and the router will not execute the command. The router also shows a rejection status message on the screen:

Router1#configure terminal
Command authorization failed.

Router1#

In this case, the current user is unable to modify the router configuration because of an AAA authorization rejection.

Command authorization is useful in many situations. For example, you can use it to allow novice users to access some commands on the router, while preventing them from modifying the configuration. Or, in other cases, you might need to give special access to different groups of users according to their job functions. For example, the night operator might need to have access to look at the routing tables. But you may not want to give this person the same command set that your network engineers have. In Recipe 4.9, we illustrate how to configure a TACACS+ server to permit and deny specific commands.

In the recipe examples, we have configured the router to authorize enable level commands only, by specifying the number 15 as an argument:

Router1(config)#aaa authorization commands 15 default tacacs+

You may recall from Chapter 3 that the enable level commands are assigned level 15, whereas VTY level commands are at level 1. You can authorize all level 1 commands as well, depending on the level of security and control you wish to enforce. You could authorize all level 1 commands as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authorization commands 1 default tacacs+
Router1(config)#end
Router1#

Recipe 4.3; Recipe 4.9; Chapter 3

You want to ensure that your router can still authenticate user sessions, even if it loses access to the TACACS+ server.

It is important to make sure that you can still enter commands on your router if your TACACS+ server becomes unreachable for any reason. The following set of commands ensures that you don’t lose functionality just because you lose your server connection:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+ enable
Router1(config)#aaa authentication enable default group tacacs+ enable
Router1(config)#aaa authorization commands 15 default group tacacs+ if-authenticated
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

One of the potential problems with using a central server to authenticate user access is the issue of what happens when you lose access to that server. It would not be terribly useful if you couldn’t plug in a console device and reconfigure the router to fix the problem that caused the router to lose access in the first place. But, by default, a router that can’t communicate with its AAA server can’t authenticate or authorize users.

Fortunately, Cisco’s AAA implementation also includes the ability to perform authentication locally on the router in case it can’t reach its TACACS+ server. Cisco documentation often refers to this authentication as the “password of last resort.” The various authentication methods available within the AAA feature set are shown in Table 4-1.

The example in this recipe shows how to use the router’s enable password as a redundant authentication method by adding the keyword enable to the aaa authentication command. As long as the primary authentication method (TACACS+ in this case) is working, the router never uses this password of last resort. However, when the server connection is lost, users will be prompted for the enable password instead of the TACACS+ username and password. This ensures that you will never be locked out of your routers.

You can also implement other backup authentication methods such as local authentication, line-based passwords, and even RADIUS. However, we recommend using the combination of the enable password method shown in this recipe along with using an enable secret password for two reasons. First, this password is local to the router so it will never become unavailable. Second, when you use enable secret passwords, the router stores the password using MD5 encryption internally, which will help protect it from prying eyes. We should also mention that it is possible to string together a few different methods of authentication, although this is usually unnecessary.

This example assumes that we are doing command authorization as well as authentication. The same problems that we just mentioned for authentication also apply to authorization. It doesn’t do you any good to get into the router if the router can’t verify which commands you are authorized to use. This is why we have included the if-authenticated keyword in the aaa authorizationcommand:

Router1(config)#aaa authorization commands 15 default group tacacs+ if-authenticated

We highly recommend using the if-authenticated option whenever you enable AAA authorization.

Recipe 4.1; Recipe 4.2

You want to disable TACACS+ authentication on your router’s console interface.

You can disable TACACS+ authentication on the router’s console port while leaving it active on the rest of the router lines:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+ local
Router1(config)#aaa authentication login OREILLY line
Router1(config)#line con 0
Router1(config-line)#login authentication OREILLY
Router1(config-line)#end
Router1#

By default, when you configure a router to use AAA authentication, it automatically applies this authentication method to all lines. This means that you don’t have to explicitly configure each line to use AAA authentication. Normally this default behavior is useful because it requires less configuration. But there are times when you may want to use different authentication methods on different lines. For instance, in our example we wanted to be able to access the router’s console line with a simple password. But we didn’t want this change to affect the AAA authentication on any of the VTY or AUX lines.

The first two lines in the example simply enable TACACS+ authentication for all login access to the router:

Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+ local

As soon as you enter these commands, every line on the router, including the console, will begin to use TACACS+ for authentication. The next command creates a new AAA authentication group called OREILLY that uses the local line password for authentication:

Router1(config)#aaa authentication login OREILLY line

This command doesn’t do anything yet, though, because none of the router’s lines belongs to this new authorization group. We have to configure the console line with the login authentication command to associate this line with the authentication group:

Router1(config)#line con 0
Router1(config-line)#login authentication OREILLY

Now, when a user connects on the console, they will use the type of authentication specified for this group. In this case, if you look back at the group definition, you will see that the OREILLY group uses line authentication. However, because we have associated only the console line with this group, all of the other lines will continue to use the TACACS+ authentication method.

If you wanted to, you could configure a different group for every line. But, in general, we recommend using the default TACACS+ authentication method on all lines, even the console, unless there is a compelling reason to do otherwise. You don’t need to worry about losing console access because of a problem on the central server; you can always implement a password of last resort, as described in Recipe 4.3.

You can return the console to the default authentication group by simply changing the login authentication line again:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line con 0
Router1(config-line)#login authentication default
Router1(config-line)#end
Router1#

Recipe 4.1; Recipe 4.3

You want to capture and timestamp all keystrokes typed into a router and associate them with a particular user.

The AAA accounting feature allows you to capture keystrokes and log them on the TACACS+ server:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa accounting commands 1 default stop-only group tacacs+
Router1(config)#aaa accounting commands 15 default stop-only group tacacs+
Router1(config)#end
Router1#

The ability to capture every keystroke entered into a router is a powerful security and quality assurance feature that is extremely useful. For instance, keystroke logging is extremely useful in forensic reconstruction of network events. TACACS+ provides the ability to capture all keystrokes typed into your routers and log them for future reference. The TACACS+ log contains the command that was typed, along with other useful information such as time and date, router name, username, originating IP address, and privilege level. Here is an example of a TACACS+ accounting record:

Fri Jan  3 11:08:47 2003        toronto ijbrown tty66   172.25.1.1
stop    task_id=512 start_time=1041610127   timezone=EST    service=shell
priv-lvl=15     cmd=configure terminal <cr>

In this log entry we can see that user ijbrown submitted the command configure terminal on router toronto at 11:08 on January 3, 2003. It also shows that this user accessed the router from IP address 172.25.1.1 using tty66.

To save disk space on your TACACS+ server, you may decide to log only level 15–based commands, which is done with this command:

Router1(config)#aaa accounting commands 15 default stop-only group tacacs+

Level 1 commands are generally relatively benign and pose little real threat to the security or health of the router. So logging them is less important than for level 15 commands. But we generally recommend logging all commands if you’re logging commands at all because the level 1 commands might show useful patterns of information. You can also log the commands issued at any other user level by adding more aaa accounting lines and specifying the appropriate user level.

Recipe 4.6; Recipe 4.9

You want to log various system events.

AAA accounting includes the ability to log a variety of system events, including timestamps along with associated usernames:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa accounting exec default start-stop group tacacs+
Router1(config)#aaa accounting connection default start-stop group tacacs+
Router1(config)#aaa accounting system default stop-only group tacacs+
Router1(config)#end
Router1#

In addition to capturing keystroke logs, AAA accounting can gather other useful pieces of information such as EXEC, connection, and system events.

Here is an example of an EXEC log entry:

Fri Jan  3 11:11:40 2003        toronto ijbrown tty67   172.25.1.1
start   task_id=514 start_time=1041610300   timezone=EST    service=shell1

Fri Jan  3 11:18:47 2003        toronto ijbrown tty67   172.25.1.1
stop    task_id=514 start_time=1041610300   timezone=EST    service=shell
disc-cause=1   disc-cause-ext=1020 connect-progress=101    elapsed_time=427
nas-rx-speed=0  nas-tx-speed=0

These two records show that user ijbrown logged into router toronto at 11:11:40 AM on January 3, 2003, and stayed connected for 427 seconds. This information is useful for security auditing, and also can be used for billing purposes if required. For example, if you are using this router to provide PAD or terminal server services to paying customers, this is an ideal way to gather billing information.

Here is an example of a connection log event:

Fri Jan  3 11:30:19 2003        toronto ijbrown tty67   172.25.1.1
stop    task_id=522start_time=1041611404   timezone=EST    service=connection
protocol=telnet addr=10.2.2.2 cmd=telnet 10.2.2.2    pre-bytes-in=0  pre-bytes-out=0
pre-paks-in=0  pre-paks-out=0  bytes_in=1843 bytes_out=81 paks_in=43  paks_out=50
connect-progress=47   elapsed_time=15 nas-rx-speed=0  nas-tx-speed=0

In this record you can see that user ijbrown initiated a Telnet session to IP address 10.2.2.2, and terminated it 15 seconds later. You can even see the total number of bytes and packets both sent and received by the Telnet process.

The system event log entries look like this:

Fri Jan  3 11:35:19 2003        toronto unknown unknown unknown stop   task_id=265
start_time=1041611719   timezone=EST    service=system  event=sys_acct
reason=shutdown

Fri Jan  3 11:37:35 2003        toronto unknown unknown unknown start   task_id=1
timezone=EST    service=system  event=sys_acct  reason=reload

These records show that somebody reloaded the router called toronto at 11:35 on January 3, 2003. It came back up at 11:37 some two minutes later. Notice that the system event logging did not capture information on the user who submitted the reload command. That information could be captured using command logging.

Actually, this points out an interesting side benefit to capturing this information on a central server. If you were just using regular system logging in the router’s log buffer, this information would be lost during the reboot. However, by storing system events on the TACACS+ server, you don’t lose anything when the router reboots.

Recipe 4.5; Recipe 4.9

You want the router to use a particular source IP address when sending TACACS+ logging messages.

The ip tacacs source-interface configuration command allows you to specify a particular source IP address for TACACS logging messages:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip tacacs source-interface loopback0
Router1(config)#end
Router1#

Note that implementing this command will not only affect AAA accounting, it will also affect AAA authentication and AAA authorization.

Normally, when you enable TACACS+ on a router, the source IP addresses on the messages that it sends to the TACACS+ server will be the address of the router’s nearest interface. However, this is not always meaningful. If there are many different paths to the server, the router could wind up sending messages through different interfaces. On the server, then, these messages will usually look like they came from different routers, which can make it difficult to analyze the logs.

However, if you use a loopback address for the source, all messages from this router will look the same, regardless of which interface they were delivered through. In many networks, the DNS database contains only these loopback IP addresses, which helps to make the logs more useful as well.

We strongly recommend using this command.

Recipe 4.5; Recipe 4.6

You are looking for TACACS+ server software for use in your network.

Cisco distributes a free TACACS+ software system from their anonymous FTP site on the Internet:

freebsd% ftp ftp-eng.cisco.com
Connected to ftp-eng.cisco.com.
220 ftp-eng.cisco.com FTP server (Version wu-2.6.2(1) Thu Dec 13 23:14:01 PST 2001)
ready.
Name (ftp-eng.cisco.com:ijbrown): ftp
331 Guest login ok, send your complete e-mail address as password.
Password: <email@address>
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd pub/tacacs
250-Please read the file README
250-  it was last modified on Sun Jun 18 10:29:35 2000 - 927 days ago
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII  mode  data connection for /bin/ls.
total 544
drwxr-x--x   2 1500       eng          4096 Dec  4  1998 RCS
-rw-r--r--   1 1500       eng          1602 Jun 18  2000 README
-r--r--r--   1 1500       eng         73880 Dec  4  1998 tac-rfc.1.78.txt
-rw-rw-r--   1 1500       eng        193771 Jun 18  2000 tac_plus.F4.0.4.alpha.tar.Z
226 Transfer complete.
ftp> bin
200 Type set to I.
ftp> get tac_plus.F4.0.4.alpha.tar.Z
local: tac_plus.F4.0.4.alpha.tar.Z remote: tac_plus.F4.0.4.alpha.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for tac_plus.F4.0.4.alpha.tar.Z (193771
bytes).
226 Transfer complete.
193771 bytes received in 1.81 seconds (104.58 KB/s)
ftp> quit
221-You have transferred 193771 bytes in 1 files.
221-Total traffic for this session was 196024 bytes in 2 transfers.
221-Thank you for using the FTP service on ftp-eng.cisco.com.
221 Goodbye.
freebsd%

Cisco offers a free version of TACACS+ that you can download. However, please note that it is not a fully supported version. In fact, Cisco seldom updates the free TACACS+ daemon and it lacks several of the advanced features of commercially available TACACS+ software. Furthermore, Cisco warns that this free software comes with no warranty or support.

With this in mind however, the free TACACS+ software is useful for testing, lab environments, or even small installations. You will find that the free Unix version is fully functional and provides an excellent range of features. In fact, all of the AAA accounting log files in this chapter were captured using Cisco’s free TACACS+ software.

Please follow the instructions that Cisco provides with the software to extract, compile, and install the TACACS+ server software. Recipe 4.9 includes some sample configuration files.

Recipe 4.9

You want to configure a TACACS+ server to accept AAA requests from your network devices.

Here is an example of a TACACS+ server configuration file that accepts AAA requests from network devices to authenticate users. You can use this example as a template to help you build your own configuration files:

freebsd% cat tac.conf
key = "COOKBOOK"

accounting file = /var/log/tacacs

user = ijbrown {
    default service = permit
    member = staff
    login = cleartext cisco
}

user = kdooley {
    default service = permit
    member = staff
    login = des l5c2fHiF21uZ6
}

user = $enab15$ {
    login = cleartext happy
}


group = staff {
    # Default Group
}

In this recipe, we look at how to configure Cisco’s free TACACS+ server software because we want to show how the TACACS+ server works. Most of the configuration is done at the central server, so understanding a basic configuration helps with understanding AAA services in general. Please note that other TACACS+ servers use different configuration syntax; however, the basic concepts are the same.

The first thing you need to configure is the TACACS+ encryption key. This key must be identical to the one configured on your router configuration with the tacacs-server key command. If the keys are not identical, none of the TACACS+ services will work. In the following example, we use the same encryption key as in Recipe 4.1, COOKBOOK:

key = "COOKBOOK"

To configure authentication for a single user, define a username and password combination as follows:

user = ijbrown {
        login = cleartext cisco
}

In this example, we configured the username ijbrown and assigned it a password, cisco. If you prefer, you can encrypt the password using DES encryption and store only this encrypted form in the configuration file. However, for this example, we chose to use a clear-text password. The TACACS+ server is now ready to accept authentication requests for this user.

If you choose to use TACACS+ to authenticate your enable password as well, you need to define a special enable user called $enabl15$. The following example creates this enable account using the password happy. After you define this username, the TACACS+ server will be able to handle authentication requests for the enable password:

user = $enab15$ {
    login = cleartext happy
}

To enable AAA authorization, you need to define command authorization using a series of grep-style regular expressions. For more information on regular expressions, see the egrep manpage, or Mastering Regular Expressions(O’Reilly).

By default, TACACS+ implicitly denies all commands. So, unless you explicitly allow a user to issue a command, it will be denied. Also note that the router will fully expand all commands before sending them to the TACACS+ server. This means that if a user types in sh ip rou, as a short form for show ip route, the TACACS+ server is asked to authorize the long form version of the command, show ip route. This is important to remember when you build your regular expression command statements.

The following example shows how to enable command authorization using the cmd statement. This configuration example permits the user sarnott to issue all show commands with the exception of show running-config:

user = sarnott {
    member = staff
    login = cleartext nssor
    cmd = show {
        deny running-config
        permit .*
    }
}

Notice that we have included two instructions in the cmd = show section. The first command, deny running-config, denies the user access to the show running-config command, while the permit .* line enables access to all other show commands. This works because the regular expression .* matches everything.

We mentioned earlier that, by default, the TACACS+ server implicitly denies all commands. This is a failsafe approach, but it does make things more difficult when you want to allow a large number of commands. Fortunately, you can use the default service = permit command to change this default behavior so that TACACS+ will permit any commands that you don’t explicitly deny. When you include this command in a user’s configuration, they can issue any command they like. If there are certain commands that you don’t want them to use, you can use a deny statement to prevent the specific commands, as follows:

user = ijbrown {
    default service = permit
    login = cleartext cisco
    cmd = debug {
        deny .*
    }
}

Here we have configured user