In large-scale environments, it is cumbersome to synchronize and maintain individual user accounts on each network switch and router. To simplify account management, Cisco routers can be configured to authenticate against a central account repository; this also removes usernames and passwords from local configurations. The process of authentication uses either Terminal Access Controller Access Control System (TACACS) or Remote Authentication Dial-In User Service (RADIUS) servers. TACACS has actually evolved over time, and the current version in use is TACACS+. There are a number of operational differences between the two systems, but both provide robust authentication and authorization services. The decision about which is implemented is mostly based on convenience and comfort level.

To enable TACACS+ authentication on a Cisco router, follow these steps:

1. Enable Cisco authentication, authorization, and accounting services, which contain the TACACS+ services, by issuing the following command:

aaa new-model

2. Specify the location of the TACACS+ account database and a shared key to use for encrypting communications (be sure to use the same key on the TACACS+ server). This is done with these commands:

tacacs-server host tacacs-server key

3. Associate the various access methods to be used with TACACS+. This is done with this command:

aaa authentication

For example, to configure TACACS+ as the default authentication method using a server at IP address 10.1.11.50 and a shared secret of S3cur1ty, the following commands would be used:

aaa new-model
aaa authentication login default tacacs+ local
tacacs-server host 10.1.11.50
tacacs-server key S3cur1ty

Authentication to the router should not rely completely on a remote authentication server. Should the server be down or unavailable, no one could log in. Therefore, keeping a local backup account is a good precautionary measure. Additionally, the router can be configured to permit a login with the enable password with this command:

tacacs-server last-resort password

Beyond simply authenticating access to the router, it is good practice to limit the locations from which such connections can be initiated. For example, why permit Telnet or SSH sessions to the border routers from external networks, or to core routers from the entire internal network? Administrators can configure ACLs to restrict administrative access to authorized hosts and subnets. ACLs are packet filters that will either accept or deny packets based on the packets’ layer three header information. Packet filters are discussed in more detail in Chapter 11.

The following example creates an ACL that permits Telnet and SSH traffic from a single administrative host to the router interface at 10.1.10.1. It then denies Telnet and SSH to the router from all other hosts while permitting all other IP traffic.

access-list 100 permit host 10.1.11.25 host 10.1.10.1 eq telnet
access-list 100 permit host 10.1.11.25 host 10.1.10.1 eq ssh
access-list 100 deny all host 10.1.10.1 eq telnet
access-list 100 deny all host 10.1.10.1 eq ssh
access-list 100 permit all all

Once created, the access list must be applied to an appropriate interface:

Router(config)#interface ethernet 0
Router(config-if)#ip access-group 100 in

This chapter is from Network Security: The Complete Reference, by Mark Rhodes-Ousley, Roberta Bragg, and Keith Strassberg (McGraw-Hill/Osborne, 2003, ISBN: 0072226978). Check it out at your favorite bookstore today. Buy this book now.