Lock-and-Key Configuration

Now that you have a basic understanding of how lock-and-key works, the next section takes a look at how to configure it. Lock-and-key uses extended ACLs?actually, you embed a dynamic ACL entry in an extended ACL, and this dynamic ACL entry creates the temporary ACL entry for your authenticated users. Therefore, you need to be very familiar with the configuration and operation of extended ACLs. The following sections discuss how to configure lock-and-key, as well as how to verify your configuration.

Configuration Steps

You must perform three basic steps when setting up lock-and-key:

Step 1. Create your extended ACL. At a minimum, you must permit Telnet or SSH access to the router, as well as put a placeholder entry in the ACL for the dynamic entry that your user's authentication will create.

Step 2. Define your authentication. Lock-and-key supports three methods of authentication: local (the username database), an external AAA server, and the line password. Typically, the line password is not used because all users would use the same password.

Step 3. Enable the lock-and-key authentication method. This occurs on your router's VTY lines. When you enable it, the router can create dynamic ACL entries on its interface ACL that has the lock-and-key ACL reference.

The following sections cover these three steps.

Step 1: Create Your Extended ACL

The first thing you need to do is configure your extended ACL for your router's external interface. The configuration of this ACL is discussed in Chapter 7, "Basic Access Lists." Lock-and-key supports both numbered and named extended ACLs. You must do two things with this ACL:

• The first (or one of the first) entries in the ACL should permit Telnet or SSH access to an IP address on the router that the external users will use. Typically, this is the IP address configured on the external interface.

• Second, you must embed a lock-and-key ACL entry into the ACL. This entry defines what internal resource(s) a user is allowed to access after authenticating.

The following commands create the dynamic lock-and-key ACL entry:

Router(config)# access-list ACL_# dynamic dynamic_ACL_name [timeout minutes]

  {deny | permit} IP_protocol source_IP_address src_wildcard_mask

  destination_IP_address dst_wildcard_mask [precedence precedence] [tos TOS]

  [established] [log]

or:

Router(config)# ip access-list extended ACL_name

Router(config-ext-nacl)# dynamic dynamic_ACL_name [timeout minutes]

  {deny | permit} IP_protocol source_IP_address src_wildcard_mask

  destination_IP_address dst_wildcard_mask [precedence precedence] [tos TOS]

  [established] [log]

The dynamic keyword in these two ACL methods enables you to specify the name of the dynamic ACL that is to be used. This name must be unique among all named ACLs on the router. The lock-and-key timeout parameter is optional. It enables you to specify an absolute timeout for the dynamic entry that an authenticated user creates. The timeout can range from 1 to 9999 minutes.

Following the timeout parameter in the ACL statement, you specify the user's traffic that you want to permit. Normally, you do not know the IP address of the external user (the source); therefore, use the keyword any. As you will see in the "Step 3: Enable Lock-and-Key Authentication" section, an option with the autocommand command allows the Cisco IOS to replace the keyword any with the actual source IP address of the authenticated user.

After you have created your extended ACL with Telnet and/or SSH permission and the dynamic lock-and-key entries, you must activate your ACL on your router's interface with the ip access-group command.

The access-list dynamic-extended command, shown here, extends the timeout value for lock-and-key entries by 6 minutes:

Router(config) access-list dynamic-extended

This is an optional command and typically is used when you have a job running that is near its absolute timeout, but the job will not finish in time. By configuring this command on your router, you can extend the timeout value by another 6 minutes.

Here are some important tips regarding the configuration of your lock-and-key ACL:

• You can have only one dynamic parameter in the ACL. In some Cisco IOS versions, other dynamic parameters are ignored; in others, they are flagged as invalid.

• Use a unique name for the lock-and-key ACL specified with the dynamic parameter.

• For the dynamic ACL entry, be as specific as possible regarding what the authenticated users are allowed access to?in other words, it is not recommended that you use the keyword any as the destination address.

• Make sure that one of your static ACL entries allows the external users to Telnet (23) and/or SSH (22) into the router.

• If you do not specify an absolute timeout in the dynamic ACL entry, make sure that you specify an idle timeout in the autocommand configuration.

• If you specify both an absolute and an idle timeout, make sure that the idle timeout value is smaller than the absolute value. Otherwise, the Cisco IOS might experience problems removing the temporary ACL entry.

• You can combine lock-and-key ACL entries with timed entries, thus restricting outside access to specific dates and times.

• The only values that the router can replace in the temporary ACL entry are the source and destination addresses, assuming that you used the host parameter in the autocommand command. For the extended ACLs that are applied inbound, the source address is replaced with that of the external user. You also can use lock-and-key to restrict outbound access. In this case, create an extended ACL and apply it outbound on the internal interface. This causes the Cisco IOS to replace the destination keyword any with the actual IP address of the internal device.

Here are some important tips about lock-and-key ACLs in general:

• Dynamic entries are removed when the router reboots, when you manually clear the entry, when the idle timeout is reached, or when the absolute timeout is reached. If you save your router's configuration, the dynamic ACL entries that users create when they authenticate are not saved; if your router reboots, however, they easily can be recreated by having the user reauthenticate.

• If you suspect that unauthorized users are trying to authenticate through lock-and-key, enable logging to capture their activity.

Lock-and-Key ACLs When Cisco first introduced lock-and-key in Cisco IOS 11.1, I thought that it would solve all my per-user authentication problems. Unfortunately, I soon found out that lock-and-key is somewhat restrictive in implementing per-user policies. I had hoped that each user or group could have its own set of defined policies and that these policies would be enforced when the user authenticated. However, lock-and-key allows you to define only one policy statement per ACL, which limits its usefulness in a LAN environment (multiaccess interface). Of course, Cisco intended customers to use lock-and-key to provide double authentication for dialup connections, in which each dialup interface could have a different ACL and, thus, different policies. The appropriate policy (or policies) could be enforced based on the phone number dialed by the user and the line that the user connected to on the router. Normally, I use lock-and-key in small environments, where only a small number of users need authentication and authentication proxy either is not necessary or is not available. In this environment, users need to authenticate only to access a specific host, such as a bastion host. As you will see in the next chapter, authentication proxy uses the same process as lock-and-key; however, it enables you to enforce per-user and per-group policies within the same ACL.

Step 2: Define Your Authentication Method

After you have created your extended ACL with its dynamic entry, you are ready to define your authentication method. Three methods of authentication exist:

• Line password

• Local database

• AAA server

The configuration of the line password is discussed in Chapter 3, "Accessing a Router." The local database and AAA server configuration are discussed in Chapter 5, "Authentication, Authorization, and Accounting."

I highly recommend that you not use the line password method because every user would have to use the same password. This is basically how you would set up authentication with a line password:

Router(config)# line vty 0 4

Router(config-line)# login

Router(config-line)# password password

To use a local username database, use the following configuration:

Router(config)# username user's_name secret user's_password

Router(config)# line vty 0 4

Router(config-line)# login local

To set up AAA with TACACS, use the following configuration:

Router(config)# aaa new-model

Router(config)# tacacs-server host IP_address

Router(config)# tacacs-server key key

Router(config)# aaa authentication login authentication_name group tacacs+

Router(config)# line vty 0 4

Router(config-line)# login authentication_name

Instead of the last line, you could use this:

Router(config-line)# login tacacs

Note that RADIUS is not supported with this option.

Step 3: Enable Lock-and-Key Authentication

The last thing you need to do is enable lock-and-key authentication on your VTYs. This is accomplished with the following configuration:

Router(config)# line vty 0 4

Router(config-line)# autocommand access-enable host [timeout minutes]

The autocommand access-enable command specifies lock-and-key authentication. When a user successfully authenticates, a temporary ACL entry is inserted into the extended ACL at the dynamic parameter placeholder in the extended ACL on the interface where the user is coming into the router. In other words, if you have two external interfaces, the temporary entry is added only on the one interface that the user connects to. Without the autocommand access-enable command, the router will not create the temporary ACL entries.

The host parameter is optional. By specifying this parameter, however, you cause the Cisco IOS to replace the dynamic ACL entry's keyword any with the user's IP address. If the extended ACL is applied inbound, the source keyword any is replaced with the user's IP address; if it is applied outbound, the destination keyword any is replaced.

The optional timeout parameter is used to set the idle timeout for the user's temporary ACL entry. As mentioned in the "Step 1: Create Your Extended ACL" section, if you do not specify an idle timeout, it defaults to no timeout.

Keep in mind these configuration tips regarding the activation of lock-and-key:

• You should secure all your VTYs with the same autocommand configuration, to ensure that you are protecting the router (there is one exception to this, covered shortly).

• If you did not configure an absolute timeout in the dynamic ACL entry, make sure that you configure an idle timeout with the autocommand command. When configuring an idle timeout, it must be less than the absolute timeout, if configured.

• When using a TACACS+ server to authenticate the user, you should configure the autocommand command on the TACACS+ server as a per-user, not per-group, command.

Allowing Remote Administration Access

One problem with the previous approach to securing all your VTYs with the autocommand command is that the VTY line is used for lock-and-key user authentication. After the user has authenticated, or when the user fails to authenticate, the Cisco IOS immediately disconnects the user from the router. However, this presents a problem if you want to access the router remotely and perform administration tasks.

Telnet Solution

To solve this problem, set up a semi-backdoor into your router. If you will be using Telnet to access your router remotely, you will perform something like one of the following:

Router(config)# line vty last_line_#_plus_1

Router(config-line)# login

Router(config-line)# password password

Router(config-line)# rotary rotary_#

or:

Router(config)# line vty last_line_#_plus_1

Router(config-line)# login local | tacacs

Router(config-line)# rotary rotary_#

The first thing to point out is that you will be creating an additional line number for your VTYs. If you already have VTYs 0 to 4, you use 5 as the VTY number. Second, My preference is to use the second method, not the first, because the second method uses a username and password for authentication instead of just the line password. The third item of note is the function of the rotary command. This command removes the Telnet function from port 23 and places it on 3000 + the rotary number. As an example, if the rotary number was 1, you would use a port number of 3001 (instead of 23) for the Telnet connection.

Example 13-1 demonstrates a simple example.

Example 13-1. Telnet Rotary Example

Router(config)# username richard secret itsasecret

Router(config)# line vty 5

Router(config-line)# login local

Router(config-line)# rotary 1

In this example, if you wanted to remotely access the router, you would have to Telnet to the router on port 3001. You also would need to make sure that your router allowed this port number in its inbound ACL on the interface that you would be using to access the router.

SSH Solution

My personal preference is not to use Telnet for remote access, but to use SSH instead. Therefore, for all VTYs that you will be using for either remote administration or lock-and-key, specify that only SSH should be used, like this:

Router(config)# line vty 0 last_VTY_#

Router(config-line)# transport input ssh

Second, perform the configuration in the "Telnet Solution" section. Finally, you must tell the Cisco IOS what port number SSH will use for accessing the router:

Router(config)# ip ssh port port_# rotary rotary_#

In this command, specify the port number that SSH will use, such as 2000. The rotary number that you specify here must match the rotary number in the rotary command configured on your backdoor VTY. With this configuration, SSH will be allowed access to the backdoor VTY only on the configured port number.

Example 13-2 shows a sample of setting up an SSH backdoor.

Example 13-2. SSH Rotary Example

Router(config)# username richard secret itsasecret

Router(config)# line vty 5

Router(config-line)# login local

Router(config-line)# rotary 1

Router(config-line)# transport input ssh

Router(config-line)# exit

Router(config)# ip ssh port 2000 rotary 1

In this example, only SSH access is allowed on VTY 5; plus, to access this VTY, the SSH client needs to use port 2000. Just make sure that any inbound ACL allows this access. If you will use SSH to access the router remotely, you must open this port number in the ACL.

Local Database Solution

A better option to solving remote administration than using rotaries is to use local authentication through the username database. The problem with using rotaries is that you, as an administrator, must remember the port number used for the connection. Instead of having to remember a port number, you can set up two local accounts: one for lock-and-key authentication and one for remote management. In the username command for these accounts, you specify when lock-and-key authentication should be used. Example 13-3 shows a sample of setting the local authentication database.

Example 13-3. Local Authentication Database and Lock-and-Key

Router(config)# username richard1 secret itsasecret

Router(config)# username richard2 secret itsadifferentsecret

Router(config)# username richard2 autocommand access-enable host

In this example, the account richard1 is used for remote management, and the account richard2 is used for lock-and-key authentication. With the second account, a second username command is used, with the autocommand access-enable host parameter. This parameter specifies that when a user authenticates with this account, lock-and-key authentication will take place.

Verification and Troubleshooting

After you have set up lock-and-key, the Cisco IOS supports various commands to verify and troubleshoot your configuration. One of the basic commands that you will use in your troubleshooting is the following:

Router# show [ip] access-list

Example 13-4 shows output of this command for a user who has not authenticated yet.

Example 13-4. Verifying Your Lock-and-Key ACL Entries

Router# show access-list

Extended IP access list 100

    10 permit tcp any host 192.168.1.254 eq 22

    20 Dynamic lockandkey permit ip any 192.168.2.0 0.0.0.255

    30 deny ip any any

In this example, only SSH access (port 22) is allowed. The dynamic lock-and-key ACL is called lockandkey. It allows a user to access 192.168.2.0/24, once authenticated. Any other traffic is dropped.

To test the connection, the user must use SSH to authenticate. Example 13-5 shows the ACL after a user authenticates.

Example 13-5. Dynamic ACL Entry Added After Authentication

Router# show access-list

Extended IP access list 150

    10 permit tcp any host 192.168.1.254 eq 22 (200 matches)

    20 Dynamic lockandkey permit ip any any

       permit ip host 200.1.1.1 any

    30 deny ip any any (162 matches)

In this example, 200.1.1.1 authenticated, and you can see the corresponding temporary entry that the Cisco IOS created for this user.

If you want to remove a temporary ACL entry manually in your extended ACL, use the clear access-template privileged EXEC command.

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