Looking Into Lock-and-Key

Peter J. Welcher

Introduction

Companies that are trying to maintain security these days generally disallow remote access across the Internet, because of the possibility of snoopers watching for passwords or valuable information. Some require that all remote access be via direct dialup, with PPP and CHAP protocol, possibly callback, providing security.

That's fine for local access, but for travelling or remote employees, the long-distance bill adds up. Telecommuting and remote access by mobile ("outbound") staff is on the upswing. Serious numbers of remote users using multiple access servers can be a burden for network staff to have to manage.

Meanwhile, as Internet Service Provider networks grow, local access points make Internet access financially attractive. Not only does using an ISP (Internet Service Provider) save the cost of phone calls, but it outsources the task of managing NAS's (Network Access Servers) to the service provider.

So How Do I Secure It?

There are several approaches to remote access via the Internet.

One is one-time password generators and server software, such as SecureID or DES Gold. This is considered effective against password compromise. It does not address exposure of information while connected.

Another possibility is encryption, which may serve to authenticate the source, and may also conceal the information being transmitted. It also may reduce vulnerability to spoofing attacks, where false transmissions are injected into the data flow between the legitimate source and destination.

I'm aware of two market movements towards encryption. Cisco and others are producing a standard called Layer 2 Forwarding (L2F) for tunneling IP traffic; the standard allows for encryption. In this scheme, the Network Access Server (NAS) does the encryption. Microsoft has a somewhat competitive standard, PPTP, for tunneling PPP traffic with encryption. In PPTP, the end node handles encryption.

Encryption over the Internet is still bleeding edge technology, and not one I claim to know much about, so I'll change the subject.

What Is Lock-And-Key?

Let's assume that we know how to do authentication and encryption. That's two pieces of the puzzle. There's one other little problem that comes up. We dial into our ISP, we identify ourselves to them, and we try to connect up to our company ... only to run smack into an access list on a packet-filtering router. Access denied! Oops!

This is where Cisco's Lock-And-Key technology comes in. The way it works is that we connect to our ISP, we Telnet to a key router or access server (the gateway to the company), we authenticate ourselves to it, and then it punches a temporary hole in the firewall that lets us (and only us and other authenticated Lock-And-Key users) in.

Note that Lock-And-Key assumes we have some secure way to authenticate ourselves. (It complements the CiscoSecure product, which authenticates and logs access). Lock-And-Key assumes we probably are doing something to secure the other connections through our firewall, something like encryption of sessions. It's just another modular piece in the security puzzle.

Note that this is better than standard and extended access lists, because static access lists:

leave permanent openings that hackers might find and exploit
are difficult to manage in a large network
can require the router to do excessive processing, depending on what's in the list
do not offer a mechanism to authenticate individual users

There's another use for this: allowing selected users (and the hosts they're on) through a firewall into a secured internal or external network.

Dynamic Access Lists

The crucial (dare I say "key"?) component of Lock-And-Key is Dynamic Access Lists. These are access lists that are temporary, active only after user authentication, and which eventually go inactive, either after an idle period or when we wish to force the user to re-authenticate.

The syntax template is as follows:

access-list number [dynamic dynamic-name[timeoutminutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log]

For example:

access-list 101 dynamic open_sesame timeout 5 permit ip any any log

This specifies a dynamic access list named open_sesame with absolute timeout of 5 minutes. (The default is absolute timeout never times out: infinite time.)

At activation time, when the user Telnets into the NAS or router from say 131.108.1.1, this turns into

access-list 101 permit ip 131.108.1.1 host any

In general, the IP address of the Telnet source is substituted for the source address or the destination address in the dynamic statements, depending on whether the access list is inbound or outbound. Inbound access lists, the Telnet source is the source in the access list statement. For outbound lists, the Telnet source becomes the destination of the dynamic access list. Therefore, the intent is for the dynamic access list to be applied to the interface connecting to the Internet, to the user who is authenticating themselves.

The access list may also have non-dynamic statements in it, which act as they usually would. Generally, Telnet into the router needs to be allowed, so that the user may authenticate themselves. You would generally bar other access, so that Lock-And-Key access is needed to pass other types of traffic through the gateway router.

Words of wisdom from the programmers at Cisco:

Do NOT create more than one dynamic access list name for any one access list. Only the first one will be used.
Do NOT assign the same dynamic-name on another access list. The software just re-uses the entry (name) it already has.
If multiple users cause temporary entries to a dynamic access list, they go at the beginning of the list. Ordering cannot be specified, but doesn't matter as they are host-specific entries.
Temporary access list entries are never written to NVRAM. The dynamic list is saved, but temporary entries are not.

Lock-And-Key Activation

Here's a formal list of what takes place in a Lock-And-Key session:

User Telnets to access server configured for Lock-And-Key.
User authentication takes place. Authentication from local access server or RADIUS or TACACS+ (CiscoSecure). If user passes authentication, the IOS software creates a temporary entry in the dynamic access list. The user Telnet session is terminated at this time.
The user exchanges data through the firewall.
The IOS software deletes the temporary access list entry when a configured timeout (idle or absolute) is reached, or when the system administrator manually clears it. Note that the temporary entry can persist after the user is done. If the absolute timeout kicks in while the user is still active, the user must re-authenticate via another short-lived Telnet.

Configuring Lock-And-Key

There are several steps to setting up Lock-And-Key access, so here's a checklist.

[Preparation] Set up and test authentication methodology.
[Preparation] Set up encryption (future feature, details to follow later).
Configure a dynamic access list, as above. Apply it to an interface, using the usual command

ip access-group access-list-number

In line configuration mode, specify authentication method for the full range of VTY ports:

line vty 0 4
login tacacs

or perhaps

line vty 0 4
login local
username johnsmith password secret
etc.

or even

line vty 0 4
login
password cisco

Allow (enable) the creation of temporary dynamic access list entries. If the host argument is not specified, all hosts on the entire network are allowed to set up a temporary access list entry. The timeout option here is an idle timeout, defaulting to no timeout.

autocommand access-enable [host] [timeout minutes]

This command is applied to the VTY ports.

Other useful commands

The EXEC command to clear a temporary access list entry (you have to be enabled to do this):

clear access-template access_list_number dynamic_name src dst

The EXEC command to view current dynamic access list entries:

show access-list

Cautions

Authenticate all VTY ports (remote connections) or you've left an open door.
Define either an idle timeout or an absolute timeout value, or your temporary access list entry won't go away.
Once the firewall has the temporary opening, the access server is vulnerable to source address spoofing. To prevent this, you need to provide encryption support using IP authentication or encryption. Otherwise, someone can pretend to be the authenticated host and gain access. Note that if the authenticated host is a multi-user computer, access is opened up to any user on that machine, because the control is strictly based on IP address.
Perfomance issues: each dynamic access list forces an access-list rebuild on the silicon switching engine (SSE). This briefly reduces performance. The idle timeout feature (even defaulted) cannot be SSE switched because the CPU in the router is used to check elapsed time.

Example

The router connects to the Internet via serial interface 0.

access-list 101 dynamic open_sesame timeout 60 permit ip any any log
access-list 101 permit tcp any 131.108.5.1 host eq telnet

interface serial 0
ip address 131.108.5.1
ip access-group 101 in

line vty 0 4
login
password cisco
autocommand access-enable timeout 5

This configuration allows users to Telnet in from the Internet on serial 0 and authenticate themselves. It sets up an absolute timeout of 60 minutes, idle timeout of 5. Note that 131.108.5.1 is the serial port address of the access server, and that it occurs twice in this example.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .