| Downloads |
|---|
| 7529.zip |
PCs have made computing power widespread, which in turn has placed cryptography firmly in the hands of commercial enterprises. Despite widespread computing power and the security that cryptography can provide, more and more businesses use nonsecure means (e.g., public switched networks, WANs) to transfer larger and larger volumes of information. You can implement secure VPN links using Cisco Systems' IP Security (IPSec) protocol to secure data. (For a list of networking-related terms, see the sidebar "Networking Terms and Technologies," page 114.) If you implement IPSec correctly, remote users can securely access corporate resources confident of privacy. To fully understand this article, you need to be familiar with Cisco router configuration for basic IP.
Cisco's IPSec Implementation
When the Internet Engineering Task Force (IETF) standardized IPSec in 1995, vendors began to offer both hardware and software implementations of IPSec. Firewall vendors and hardware vendors quickly realized the advantages of a secure interoperable standard. Cisco implemented IPSec in routers and put the packet data functionality where it belongs.
IPSec security has been available in the Cisco Internetwork Operating System (IOS) since Release 11.3T in April 1998. Before implementing IPSec, Cisco IOS was available with Cisco Encryption Technology (CET), a proprietary encryption capability that Cisco IOS still supports in release 12.x. In fact, you can use IPSec and CET in a router's configuration to support a mix of new and old technologies.
Another important capability that Cisco provides is Generic Routing Encapsulation (GRE) tunneling. Available since Cisco IOS Release 10, GRE tunneling lets two Cisco routers pass non-IP traffic through an IP-only network. This feature is handy when you need to pass IPX, AppleTalk, or DECnet over the Internet. IPX requires special packaging to traverse an IP network. GRE encapsulates IPX into an IP packet. You don't need GRE to implement IPSec, but GRE tunnels provide a significant degree of flexibility, especially when connecting to more than one remote site. Implemented as a virtual interface on the router, each GRE tunnel can have different filtering rules and protocol capabilities. We used GRE and IPSec security to configure a simple tunnel from our Los Angeles host site over the Internet to our New York host site, which the network in Figure 1 shows.
The Configuration Process
To enable features on a Cisco router, you can set several parameters. Cisco generally sets the default values of these parameters to the most common configuration. When Cisco sets a parameter to the default value, the router's configuration doesn't list the parameter when performing a Show Run or Write T operation. In our examples, we discuss only items that you need to set for each configuration to work, and we mention default values only when necessary to make the configuration more understandable or to provide insight into a particular process.
Basic IP configuration. For this implementation, you don't configure any routing protocols because you can use simple static routes. You use private, nonroutable addresses on the inside interfaces, so you need to configure Network Address Translation (NAT).
To set up the configuration in Figure 1, we used three different access lists for the Los Angeles host, as callout E in Listing 1 shows. We used access list 1, which is a basic IP list, in the address translation configuration to specify which internal IP addresses the router can translate. Access list 101, which is an extended list, is the IPSec configuration list. This list specifies which traffic a particular crypto mapping can encrypt. Finally, we used access list 110 as an inbound filter on the serial interface. You configure this crucial filter to deny every inbound packet other than GRE and the additional three protocol types that IPSec needs to work: Internet Key Exchange (IKE), which uses UDP port 500 for protocol negotiation, and either Encapsulating Security Payload (ESP), which uses port 50, or Authentication Header (AH), which uses port 51. If the inbound interface blocks these ports, all IPSec transactions will fail.
The Los Angeles and New York hosts are Internet routers that provide Internet access for the organization, so we used the firewall feature set available in Cisco IOS. This firewall feature set adds entries to the inbound access list for connections that originate from the inside. This ability lets a client on the interior network request a connection with an outside host and receive data from the outside host, even though the base filter doesn't permit this connection. When you have outbound Internet connections, use the Show Access-List 110 command from the router's enable prompt to see the temporary entries created in the access list that accommodate user connections.
After you set up a basic IP configuration at each site, the next step is to create the GRE tunnel. At callout D in Listing 1, the Unnumbered command lets you create the tunnel without creating a new IP subnet between the two sites. Ordinarily, you assign individual IP addresses to the new tunnel interfaces you're creating. But because the tunnel must traverse physical addresses, new IP subnets aren't necessary, and you can simply use the serial interface IP addresses. The Directed-Broadcast command at callout D in Listing 1 prevents the forwarding of IP protocol broadcasts that intruders sometimes use in Denial of Service (DoS) attacks. The Tunnel Source command specifies the source address to use when sending tunnel packets; the Tunnel Destination command tells the router where to send the resulting tunnel packets.
After you configure each site, a traceroute from either host to the Ethernet address reveals only two hops from one host to the other. A traceroute to the serial interface of either host reveals the path that the packets take. To pass other protocols through the tunnel, simply add other addresses to the tunnel. For example, you can use an Ipx Network command to create an IPX path through the tunnel.
IKE process configuration. Notice the lack of indentation on the Crypto Isakmp Key statement at callout A in Listing 1. We entered this statement in global mode. If you were to type the statements into the router in order, you would add an Exit command after the Lifetime 28800 statement. The Crypto Isakmp Policy 1 command at callout A in Listing 1 creates a new IKE authentication policy. In this policy, you define the parameters necessary for negotiation with the remote router. You can set the number at the end of the command from 1 to 10,000. The number specifies this entry's priority in relation to similar entries. You can also make multiple entries have different encryption levels for different remote sites. For example, you can encrypt traffic to a research facility that deals with important data to a higher standard than data to other branches.
At callout A in Listing 1, the Authentication Pre-Share Command tells IKE that we will manually input the keys needed for this connection. Alternatively, you can use the Rsa-Sig option, which lets a Certificate Authority (CA), such as VeriSign, provide keys. Or you can use, for example, Entrust Technologies' PKI product to set up a local certificate server on the LAN. The advantage to using the certificate server is scalability. If our example network had more than 10 VPN links, manually managing the keys would soon become time-intensive because you need to manually configure the keys of each router's potential peers using the Crypto Isakmp Key command. In the case of a fully meshed VPN configuration, a network of more than 10 VPN links would mean N * (N-1) key entries (e.g., 5 routers would mean 20 keys, 10 routers would mean 90 keys) in each router.
To authenticate any inbound request for an encrypted connection using a CA, a router can query the CA and ask if the inbound connection is coming from an authorized host. The Lifetime 28800 command at callout A in Listing 1 tells the router to renegotiate the IKE security association every 28,800 seconds (i.e., 8 hours). Because IKE renegotiates every 8 hours, packets that servers encrypt through the IKE security association receive a new encryption key. Changing the keys is important because after an intruder compromises a key, all traffic encrypted with that key becomes unprotected. You can generate keys at certain intervals to ensure that if a compromise occurs, only traffic that servers transmit before the next key exchange is vulnerable. You use the Crypto Isakmp Key command to set the prearranged key for this host.
Two parameters are set to defaults, therefore Listing 1 doesn't show them. The first parameter is Encryption Des, which sets the type of encryption for this connection to standard Data Encryption Standard (DES). The IOS feature set we used for this example includes only the standard DES feature. Cisco now offers Triple DES (3DES) as a feature in Cisco IOS Release 12.0(2)T and later. 3DES is subject to more stringent export controls than DES but is more secure than standard DES. If you consider strong security a must, you need to pursue the 3DES feature set. (Keep in mind that if parts of your operations are overseas, exporting the 3DES software might be difficult.) The second default command is Hash Sha. This command sets the hash for the IKE negotiations to the more secure SHA-1 hash algorithm.
Transform set creation. A transform set is the combination of rules that govern exactly how to encrypt and authenticate your data. The IKE process established only the identity of each party in the communication. Now that you know the identity, you can consider passing data between them. The Transform-Set command provides for both forms of packet security: AH for authentication and replay detection and ESP to encrypt the data payload of each packet, as callout B in Listing 1 shows. This command has many possible combinations, especially if you're creating an IPSec VPN with non-Cisco hardware. In the command, we provided the name XFORM for this transform set. However, you can set XFORM to anything you want.
Mapping creation. Everything up to this point has been peripherally involved with protecting route data flows. In the Crypto Map command at callout C in Listing 1, everything comes together. We provided the name VPN, but you can set the name to anything you want. The 10 is a sequence number, which is necessary if you're creating multiple mappings to provide different levels of encryption for different data flows, and the Ipsec-Isakmp command tells the mapping that you're using IKE. The Set Peer command sets the destination for this protected data flow. Callout C in Listing 1 also shows another Lifetime command. This command functions the same as the Lifetime command at callout A in Listing 1 and forces a new key exchange at the end of the lifetime. In the mapping section, you can use the command Set Security-Association Lifetime Kilobytes to force a new key exchange after a certain volume of traffic has passed between the routers. For example, you could force a new key exchange after every hundred megabytes. You might also use a combination of the lifetime commands to force key exchanges based on either time or traffic volume, whichever comes first. We use our XFORM set to specify that we're using AH and ESP to protect the data. The Match Address 101 command at callout C in Listing 1 tells IPSec which packets to protect. In this context, we use access lists to protect an outbound IP packet that matches the list and to tell IPSec to ignore packets that don't match the list.
VPN Completion
You need to verify that your VPN works. To verify proper operation, run the Show Crypto Isakmp Sa command. This Show command will let you see if IKE has established a security association with the remote router. You won't have any communication over the tunnel until you configure IKE correctly. If you aren't establishing the IKE security association (SA), use the Debug Crypto Isakmp command to see if any errors exist in the IKE process. Listing 2 shows the output from this command.
After IKE finishes its process, IPSec needs to form an SA with the remote router. This command will verify that you're encrypting data. If you receive zeros, use the Show Crypto Ipsec Sa command to see the errors. Listing 3 shows the output from Show Crypto Ipsec Sa that includes information about the number of encrypted packets.
After verifying the implementation, you will have a working VPN in place. Listing 1 shows the full text of the working configuration that you see when you run the Show Run command for the Los Angeles host site. To view Listing 4, which provides the full text for the configuration for the New York host site, go to http://www.winntmag.com/articles and enter 7529 in the InstantDoc ID text box. This VPN uses GRE tunnels and IPSec for security. Using this configuration, we can transfer data securely across the Internet from our Los Angeles host site to our New York host site.
