Chapter 13. Lock-and-Key Access Lists
One issue that you probably will have to face is allowing your users to access your network remotely, typically through a public network such as the Internet. In most situations, you will use a Virtual Private Network (VPN) to provide for the connectivity. VPNs are discussed in Part VIII, “Virtual Private Networks.” However, one limitation that VPNs have is that, after users are connected through a secure connection to your network, they have free reign over internal resources. You could implement an ACL to restrict their traffic, but this ACL applies to all users accessing a resource.
Some mechanism is needed to authenticate users and restrict what resources they can access. Cisco has two solutions to this problem:
• Lock-and-key ACLs
• Authentication proxy
This chapter focuses on lock-and-key ACLs; the next chapter focuses on authentication proxy.
Lock-and-Key Overview
As already discussed in Part III, “Nonstateful Filtering Technologies,” you can use ACLs to protect your internal resources from external threats. However, in some situations you might need to allow specific users to other internal resources, but prevent the Internet from reaching these services. Unfortunately, normal ACLs, such as standard and extended ACLs, cannot provide this functionality—they filter only on Layers 3 and 4 and cannot authorize access on a per-user basis. This section details how lock-and-key access lists can help address these limitations.
Lock-and-Key and Normal ACLs
Lock-and-key was Cisco’s first solution to the problem of authenticating users on unknown devices. Lock-and-key uses dynamic ACLs, somewhat similar to how Context-Based Access Control (CBAC) and reflexive ACLs work. However, whereas CBAC and reflexive ACLs add ACL entries based on inspected traffic, allowing the return of that traffic into the network, lock-and-key works differently. Lock-and-key requires a user first to authenticate to the router through Telnet or SSH. After being authenticated, specific dynamic ACL entries are activated on the ACL applied to the interface. These entries remain active for a specific period of time and then expire. This enables a user to authenticate and access resources that normally would be denied. Lock-and-key ACLs can be combined with other types of ACLs, such as extended ACLs.
The lock-and-key process is different from a normal extended ACL. With an extended ACL, all the statements are static. Therefore, if you want to allow specific users to access resources inside your network, you must set up a static ACL statement to grant this access; it remains active as long as the ACL is applied to the interface and the interface is up. Of course, if you do not know the IP addresses of these users, you must be fairly promiscuous in allowing a large range of addresses, which might be counter to your security policies. Lock-and-key is a more robust solution because static ACLs have the following characteristics:
• They cannot authenticate individual users.
• They are static and might require you to open a larger hole in your router to allow specific users into your network to access specific resources.
• They are difficult to manage, especially when you must control specific users’ access to resources, which also might cause the router to perform excessive processing of ACL statements.
When to Use Lock-and-Key
Lock-and-key, also referred to as dynamic ACL, was introduced to the Cisco IOS in version 11.1, so it has been around for quite a while. Originally, it was developed for dialup access and performed double authentication. With double authentication, the user was authenticated first through PPP’s CHAP and then through lock-and-key. Sometimes the terms double authentication and lock-and-key are used interchangeably; however, lock-and-key is one specific authentication method used within double authentication. Lock-and-key is not restricted to just dialup access, though—it also can be used for LAN access. This chapter focuses on the latter approach.
Lock-and-key typically is used in one of two situations:
• You want restricted access from your network based on a user’s identity—with lock-and-key, the user is authenticated first and then granted access.
• You want to control external access to internal resources based on a user’s identity.
Lock-and-Key Benefits
Lock-and-key actually works hand in hand with extended ACLs, enhancing their functionality. Lock-and-key benefits include the following:
• Authentication of the users can be centralized on an AAA server.
• Users must provide a username and/or password to authenticate. After they are authenticated, a dynamic ACL entry is activated to allow or restrict additional access.
• Management is simplified because ACL entries are created dynamically based on a user’s authentication.
• ACLs are smaller in size, and dynamic entries are added only when a user authenticates, placing a smaller burden of processing the ACL on the router.
• Exposure to your internal resources is limited because dynamic entries are added only when a user authenticates.
Lock-and-Key Process
This section looks at the process that occurs when granting a user access to internal resources when the perimeter router is using lock-and-key. Figure 13-1 illustrates this example.
The following is an explanation of the numbered steps in Figure 13-1 that occur during the entire process:
1. A remote user first opens a Telnet or SSH connection to the router. The router’s external ACL must permit this connection. The router prompts the user for a username and password, which the user enters.
Both Telnet and SSH are supported for the authentication. However, for public access to your router performing lock-and-key, I highly recommend that you use SSH instead of Telnet for the authentication connection. This is because SSH encrypts the session, including the password sent to the router. Remember that Telnet sends all traffic, including usernames and passwords, in clear text
2. The router authenticates the connection. Three choices can be used for authentication: the local username database defined with username commands, an AAA server using RADIUS or TACACS+, or the password command on the VTY lines. If the user fails the authentication, the user is reprompted for the authentication information. If the authentication is successful, the Telnet/SSH connection is terminated; the function of the Telnet/SSH connection is for authentication only. After the user has been authenticated, the Telnet/SSH connection no longer is needed, so the router terminates it.
3. After the user successfully authenticates, the Cisco IOS adds a dynamic ACL entry that grants the user access to the configured internal resources. As you will see later in the chapter, you cannot set up per-user access policies. Instead, you define one policy for all your lock-and-key users, and this single policy is applied to all the authenticated users.
4. At this point, the user can access the internal resources that would otherwise be denied (through the dynamic ACL entry).
If users do not authenticate first, they are allowed to access only resources specified in the static external ACL. To access other internal resources, the users first must authenticate through Telnet or SSH. Then the dynamic ACL entry added by the router allows them to access other internal resources.
Caution
Lock-and-key is susceptible to IP spoofing. After a user authenticates and opens a temporary hole in the firewall, the hacker can use this address to exploit a spoofing attack (typically, a DoS attack) if the hacker knows the user’s source IP address. To prevent this kind of attack, you might want to consider encryption, such as a VPN. The temporary dynamic ACL entry also is not deleted automatically when the user terminates the session. Instead, it remains in the ACL until the dynamic entry timeout value is reached or until the administrator manually clears the entry (whichever happens first).
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.
Caution
Two timeouts are associated with dynamic ACL entries for lock-and-key: absolute and idle. The absolute timer is specified in the dynamic ACL entry. If you do not specify a timeout, the default is never to time out the entry. The idle timeout value is specified in the autocommand command, which is used to enable lock-and-key authentication on your VTYs. As with the absolute timeout, if you do not specify an idle timeout, the default is never to time out the entry. Therefore, I highly recommend that you configure either an idle or an absolute timeout—or both. Otherwise, if you forget to configure these optional idle parameters, the dynamic ACL entries created will remain in your extended ACL.
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.
Note
Unfortunately, you can have only one dynamic entry in your extended ACL. This ACL entry must encompass all of the external users accessing internal resources. Therefore, some companies set up a bastion host(s) that these users can log into. Lock-and-key can be used to restrict access to the bastion host(s). Users then log into the bastion host to access other resources inside the network. Because of this limitation, many companies prefer to use authentication proxy, discussed in the next chapter. However, if you want external users to access only one resource (or all resources, for that matter), you can accomplish this with a single dynamic ACL entry. Just remember that you can have only one dynamic ACL entry in your extended ACL. Also, this entry typically is placed toward the top of the ACL, to prevent other ACL statements from prematurely dropping the user’s traffic.
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.
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.
Tip
When authenticating lock-and-key access, you will want to include all of your VTYs. Typically, this is 0 to 4, but some router models vary. Of the three methods, AAA is the most scalable.
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.
Caution
If you do not specify the host parameter, the Cisco IOS puts the parameters in the dynamic ACL entry in the temporary ACL entry. Therefore, permit ip any any in the dynamic entry also would appear in the temporary entry. If you use the host keyword, the Cisco IOS replaces one of the keywords, based on the application of the ACL, with the user’s IP address, as in permit user_IP any. Always code the keyword host in the autocommand access-enable command.
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.
Caution
If you are determined to use Telnet for remote administration, at least make sure that any type of Telnet access is prohibited from the external interface. In other words, you should use this method only from an internal interface.
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.
Lock-and-Key Example
Now that you have a basic understanding of the commands to configure lock-and-key, take a look at an example that uses this feature to restrict access through the router. This example uses the network shown in Figure 13-2. In this example, users will be authenticated before they are allowed access to the Internet from the internal network.
Example 13-6 shows the configuration for the router.
Example 13-6 Simple Lock-and-Key Authentication Configuration
Router(config)# ip access-list extended allowed-out
Router(confix-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255
host 192.168.1.1 eq 22 (1)
Router(config-ext-nacl)# dynamic dynamic-out permit ip any any (2)
Router(config-ext-nacl)# deny ip any any
Router(config)# interface etherent0
Router(config-if)# ip address 192.168.1.1 255.255.255.0
Router(config-if)# ip access-group allowed-out in (3)
Router(config)# username admin1 secret secretadmin1
Router(config)# username user1 secret secret1
Router(config)# line vty 0 4
Router(config-line)# login local (4)
Router(config-line)# transport input ssh
Router(config-line)# autocommand access-enable host timeout 10 (5)
Router(config-line)# exit
Router(config)# line vty 5 (6)
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
The configuration in Example 13-6 focuses only on the lock-and-key configuration. The following is an explanation of this configuration. The numbers on the right side of Example 13-6 correspond to the following numbers:
1. This statement grants SSH access to the internal interface of the router, which is necessary to authenticate the internal users.
2. This statement is the dynamic ACL entry that is the placeholder for the temporary ACL entries after a user is authenticated. Notice that, with the exception of the SSH connection, no traffic is allowed until a user is authenticated.
3. Notice the placement of the ACL—it is on the internal interface applied inbound, which restricts traffic leaving the network.
4. This statement specifies that username commands are used for the authentication. The statement below this restricts VTY access to SSH.
5. This statement enables lock-and-key for SSH authentication, setting the idle timer to 10 minutes.
6. This part of the configuration sets up a backdoor so that the administrator can access the router remotely from the internal network. I sometimes use this method instead of specifying lock-and-key in the username commands. This makes it more difficult for a hacker to figure out that remote management is allowed (albeit, this is a nonstandard port number).
Note that this example requires a lot more configuration than what is shown, such as an external ACL, address translation, CBAC or reflexive ACLs, and so on. Also note that, unfortunately, because only one user can authenticate, this configuration only allows the first authenticated user access to the Internet; if you remove the host keyword in Reference 5, when one user authenticates, the dynamic ACL entry is activated and all users can access the Internet.
Summary
This chapter showed you the basics of lock-and-key ACLs. Lock-and-key is what I like to call the poor man’s version of authentication proxy. Lock-and-key ACLs are used to authenticate a user, opening a temporary hole in your extended ACL filter to grant the user access to other resources. Lock-and-key can use a line password, a local database, or an AAA server to authenticate users, and can authenticate users as their connections either enter or leave the network (or both). Lock-and-key typically is used in a small network that needs to authenticate a specific type of access and when the perimeter router/firewall does not have the Cisco IOS Firewall feature set with authentication proxy installed.
Next is Chapter 14, “Authentication Proxy,” which shows you the replacement to lock-and-key ACLs on a router.