Building a Secure VPN

The VPN concept has been around for almost 10 years. Technologies that use public data lines for private corporate traffic promise companies a cornucopia of benefits—from saving money on expensive leased lines to a workforce empowered to access the entire wealth of corporate IT resources from any kind of connection anywhere on the globe. But as with other overhyped and overmarketed technologies, the devil is in the details.

The cost of VPNs has dropped dramatically and implementation has gotten much easier, but the VPN market is still confusing and crowded. Without proper research, planning, and deployment, a VPN can become a nightmare installation and an unusable system or even reduce your network's security.

The well-publicized case of the intruder who cracked Microsoft's VPN, accessed the corporate network, and almost made away with the company's precious source code should be a warning. VPNs offer many benefits but also open a hole into your network, usually bypassing your firewall or going right through it. So, you need to carefully consider which VPN product to choose and how to install and run it.

No one-size-fits-all VPN exists. Ambiguity in the standards and differences in feature sets from vendor to vendor make the decision process fairly complex. Several factors, including your organization size, privacy requirements, and user sophistication, determine which VPN solution might suit your needs. The right product and operational procedures can securely open your network borders, increasing worker productivity while still letting you sleep at night. If you keep in mind these considerations when purchasing a VPN solution and follow a few recommendations about how to securely run it, you can achieve the Private in your Virtual Private Network without pulling out your hair in the process.

Accommodating NAT
If your VPN will primarily support remote users such as telecommuters and traveling employees and these users will access internal LAN resources that use a Network Address Translation (NAT) address rather than a routable IP address, you might have problems with some vendors' VPN products. NAT lets multiple internal network hosts use nonroutable IP addresses to access the Internet through one IP address on a firewall or router. This arrangement provides an additional level of security and lets a company be much more flexible with its address assignments than if it used real IP addresses for all its hosts.

However, NAT can interfere with some VPN implementations because it changes information in a packet's IP header to route the packet to the correct internal IP address. VPN protocols often check the integrity of the packet header and terminate the connection if they detect any changes that were made after the packet was encrypted. Vendors have devised a workaround for this problem: A technique called UDP Traversal encapsulates the IP Security (IPSec) packet in a UDP packet so that the IPSec header can arrive intact. Most vendors, including Microsoft, Nortel Networks, SSH Communications Security, NetScreen Technologies, SonicWALL, and Cisco Systems—in IOS Software 12.2(8) and later—support UDP Traversal. However, some low-end VPN appliances and software implementations might not. Alternatively, if you use IPSec, your router or firewall might support IPSec pass-through, which recognizes the IPSec protocol and lets IPSec packets pass through unaltered, eliminating the need for NAT traversal. You might also be able to work around NAT by turning off IPSec's Authentication Header (AH) element (which verifies the header information), if your VPN allows this level of detail in configuration. Be sure to check with your VPN vendor about NAT if you plan to support remote users through a network that uses NAT.

IDS Placement
If you use Intrusion Detection System (IDS) technology, you should know that if the IDS machine is between the Internet and the VPN concentrator that decrypts the encrypted packets (e.g., on a demilitarized zone—DMZ—network), it won't be able to detect intrusion activity that occurs between VPN-connected machines. Most IDS sensors match packet payloads to a database of intrusion signatures so that they know when to flag something as suspicious. If the packets are encrypted, they'll look like gibberish to the IDS machine. If you want your IDS machine to be able to monitor network traffic from VPN connections, make sure you place the IDS machine behind the VPN concentrator so that the IDS machine checks the traffic after the VPN concentrator decrypts it. You can't use an IDS on a software VPN, which operates directly from one VPN host to another.

Preferred Protocols
One of the most important choices you make when selecting VPN hardware or software is which VPN protocol to use. A VPN product might support multiple protocols or only one. A protocol that's weak or not widely supported could render your VPN unusable if someone exploits a vulnerability. A proprietary protocol could mean future compatibility problems. Although the practice has become less common, a few vendors still try to do their own thing cryptographically. Avoid these vendors' products like the plague. I strongly recommend that you stay away from products that use proprietary, nonstandard protocols and stick to one of the following major protocols.

IPSec. Probably the best supported and most widely used protocol, IPSec is rapidly becoming the standard for VPNs. IPSec, which the Internet Engineering Task Force (IETF) developed, consists of multiple subprotocols; each handles a different element of the process, and some are optional or interchangeable. IPSec is a broad specification, and vendors' IPSec implementations differ. Make sure you read the fine print to understand what parts of IPSec a product uses.

The key IPSec protocols are the AH protocol and the Encapsulating Security Payload (ESP) protocol. As I mentioned earlier, the AH protocol verifies that the header information hasn't been tampered with. The ESP protocol handles the actual encryption and decryption of the data.

IPSec can operate in two modes: transport and tunnel. In the transport mode, only the packet payloads are encrypted, leaving the IP headers in plaintext. In the more secure tunnel mode, both the header and the data are encypted. Tunnel mode requires a dedicated device, typically a VPN concentrator, to decrypt the headers and reroute them.

IPSec supports several different enciphering algorithms. The most commonly used algorithm, Advanced Encryption Standard (AES), is widely acknowledged as one of the strongest algorithms available for data encryption. With a minimum key length of 64 bits, AES is strong enough for almost any commercial application. Some vendors' IPSec implementations use the Data Encryption Standard (DES) or Triple DES (3DES) ciphers. DES, whose 40-bit key has been cracked, is generally considered a weak algorithm for all but the lowest security levels. 3DES fixes DES's problems by using the algorithm three times and providing an effective key length of 168 bits. Note that if your VPN solution supports only one algorithm, any devices you add in the future must use that algorithm as well.

PPTP. A consortium of vendors, including U.S. Robotics, Ascend Communications (now part of Lucent Technologies), 3Com, and Microsoft, developed PPTP. VPN software implementations are more likely than hardware implementations to use PPTP, although some VPN hardware vendors (e.g., Lucent in its MAX and Pipeline communication products and Nortel in its Contivity products) use it. PPTP software implementations can't handle high volumes of traffic, but PPTP hardware implementations can. PPTP 1.2 had major flaws, but version 2.0 fixed most of the problems. However, even this version 2.0 as Microsoft has implemented it is weak cryptographically because it still relies on the user's password to generate keys. In addition, PPTP's design and heavy promotion by a few large vendors such as Microsoft have made it suspect in some quarters.

Probably PPTP's biggest advantage is that it lets you create an easy and inexpensive VPN between two Windows computers (e.g., in a RAS or Routing and Remote Access connection). PPTP also doesn't have the NAT-related problems that I mentioned earlier and works with non-TCP/IP protocols such as IPX. So if you're on a tight budget and you need minimal security, PPTP is certainly better than nothing. But even the budget conscious have other alternatives. Windows XP and Windows 2000 support IPSec natively, and I recommend it over PPTP.

Layer Two Tunneling Protocol. Microsoft uses the PPTP extension Layer Two Tunneling Protocol (L2TP) for authentication, as do some hardware vendors on communications hardware such as routers and firewalls. Again, if you can, choose IPSec because it's more widely deployed and supported.

SSH
Secure Shell (SSH) is a secure version of Telnet that you can use to log on and open a command line on a remote machine. You can also use SSH to establish an encrypted tunnel between two machines, effectively creating a VPN. Different versions of SSH use RSA or Digital Signature Algorithm (DSA) for secure key exchange and 3DES or Blowfish for data encryption. You can use a free program such as Stunnel (http://www.stunnel.org) along with a free version of SSH such as OpenSSH (http://www.openssh.org) to tunnel protocols such as Web and mail protocols through an encrypted SSH tunnel. All you need is a machine at either end running both these programs. SSH and Stunnel are an inexpensive way to implement a VPN, although setting up such a VPN requires a lot of configuration and might not scale to handle a large number of machines. An SSH VPN can, however, make a nice solution for connecting two servers that need to communicate securely, such as a Web server and a back-end database server.

Key Length
The heart of the security a VPN provides is its encryption keys—the unique secret that all your VPN devices share. If the keys are too short, VPN data is susceptible to brute-force cracking. You can often choose the key length to use in your VPN implementation. The longer you make keys, the harder they are to break, but the trade-off is that longer keys also require more processor power for encryption and might slow packet throughput. The minimum recommended key length now is 64 bits (128 bits, if possible) for the symmetric ciphers that encrypt the data and 2048 bits for public key cryptography such as RSA. Modern desktop computers can often crack 40-bit and shorter keys, such as those that DES uses.

Companies deploying VPNs internationally might face some restrictions on key length. Although the government has lifted most restrictions on exporting strong cryptography, you might still need to obtain approval. Check with the US Department of Commerce Bureau of Industry and Security's Commercial Encryption Export Controls (http://www.bxa.doc.gov/encryption) for specific restrictions that might exist for your deployment.

Hardware vs. Software
You'll have to decide whether you want to base your VPN on a software implementation or a dedicated hardware device. Some of the protocols make the decision for you—for example, SSH is strictly a software implementation, at least for now. Software implementations tend to be cheaper, sometimes even free. Windows NT 4.0 has PPTP support built in, and XP and Win2K have PPTP and IPSec built-in support, as I mentioned earlier. A nice open-source implementation of IPSec called Linux FreeS/WAN is available at http://www.freeswan.org. Software VPNs tend to work best for server-to-server communication or for small groups.

For large-scale implementations, choose a hardware device such as a VPN concentrator or VPN-enabled network appliance. Hardware-based VPNs perform better for larger installations. Also, the security of a software-based VPN built on a host with an OS such as Windows, UNIX, or Linux depends on the underlying security of that OS. Thus, you must keep the OS patched as well as keep an eye on the VPN software.

Hardware-based VPNs tend to be less vulnerable than software implementations because their chip-based OSs are more lightweight (i.e., they have fewer features to exploit than general-purpose OSs). Also, because they don't sit on everyone's desktop, they're less used and understood, although exploits on them aren't unheard of. For example, security researchers recently discovered several security holes in Cisco's VPN concentrators. Make sure you subscribe to your VPN vendor's security update mailing list and promptly apply all security patches.

If you're considering a hardware VPN, ask vendors whether their solution has a dedicated processor for encryption. Some of the newer VPN appliances use dedicated application-specific integrated circuits (ASICs) to handle the encryption algorithms, which make encryption much faster, especially on busy networks. Also make sure that the box you purchase will handle the number of tunnels and the throughput that you need now and in the future. You don't want to have to replace the box in a year or two.

Nokia, Cisco, Nortel, Lucent, and others offer dedicated VPN boxes, although standalone VPN concentrators are becoming less common. Most firewalls, routers, and network appliances—such as those by WatchGuard Technologies, SonicWALL, and NetScreen—provide some VPN functionality. For a good list of IPSec-certified VPN devices, go to http://www.icsalabs.com/html/communities/ipsec/certification/certified_products/index.shtml.

Secure Implementation
After you choose your VPN, you must install and maintain it correctly to enjoy all the benefits a VPN can provide. In addition to using a sufficiently long key length, you must properly secure keys and access to VPN concentrators. If you store your keys in plaintext files on Internet-connected computers, all the bits of key length in the world won't help you if someone compromises those computers. You should also change your shared base keys on a regular basis, preferably every 3 months. This practice limits your exposure if a key is compromised.

If you require a high level of trust on the authentication process as well as the encryption, you might consider using digital certificates instead of the standard preshared secret key that most VPNs default to. Digital certificates guarantee that the person trying to connect is who he or she says he or she is. A separate digital certificate for each end connection can be expensive; however, some VPN vendors offer authentication services that provide a bulk discount on certificates.

Closely control access to your VPN box, whether it's a concentrator or Windows machine. In the case of a Windows server, put the machine on a separate domain and have only a few accounts on it. Use the strongest possible passwords, and store and swap them out appropriately. In the case of a hardware device, disable insecure protocols, such as FTP and Telnet, that pass your logon information in the clear. An insecure VPN concentrator box or unpatched Windows VPN server presents a much easier target than do VPN keys that must be brute-forced.

Many installations treat external VPN clients as fully trusted internal hosts. I recommend that you create a second class of VPN user that doesn't have the full privileges of a local host and that can access only the resources that a user of that type requires. Don't give these users access to printers or shares that they don't need for external work.

Most VPN clients also let you set compulsory tunnels or disable split tunnels so that when the client has a VPN tunnel established, the client doesn't allow communications from outside channels. This restriction prevents an attacker who compromises the VPN client computer from leapfrogging from the Internet onto your network. These client measures aren't silver bullets, but they thwart all but the most serious attackers. Unfortunately, most software-based VPNs, including the XP and Win2K VPN clients, don't offer these protections.

Another solution for the really paranoid (and well funded) is to locate a second smaller firewall between your internal VPN concentrator and internal LAN, as Figure 1 shows. Then, if an attacker compromises a VPN host, he or she still must penetrate another firewall. You could open up a few common ports, but the firewall would still block ping scans, common worms, and other garbage. Of course, it wouldn't stop someone who's just looking around and it wouldn't work if VPN users need full access to the internal network, but it adds a second line of defense when security is paramount.

Secure External VPN Clients
One of the most important things to remember when building your VPN is that a VPN secures only the data transmissions between two machines—it doesn't protect the machines themselves. Some firms hand out VPN connections as though they were candy at Halloween—to anyone who asks for one and without regard to how secure those computers are. Remember, you're handing out the front-door keys to your network, and you shouldn't do that lightly. A virus can bypass network-based antivirus protection by coming in on an encrypted VPN connection. Like IDS systems, antivirus systems can't read encrypted data, so they have problems with VPN traffic. If an intruder takes over a remote VPN client, he or she has an encrypted tunnel right to the heart of your network, making discovery and surveillance of the intruder much more difficult than if the intruder entered over an unencrypted channel. So, you should protect your VPN clients even better than you protect your internal machines because they're typically at least partially exposed to the outside.

Make sure when allocating VPN connections that the remote computers meet the same security requirements as computers on your local LAN—stricter, if possible. At a minimum, all remote VPN clients should have antivirus software and firewall software to offer some minimal protection, although some personal firewall software can interfere with some VPN client software. Include VPN client systems, such as home computers, field laptops, and partner and vendor machines, in all security assessments or vulnerability scans that you perform. You can check them the same way you check your local machines by making sure your remote VPN clients are logged on when you do your security testing and including the VPN IP range in your tests. Just make sure you get permission before you scan any machines your company doesn't own. If you use Active Directory (AD), you can also push out a standard security policy to your Win2K or later VPN clients to make sure that they conform to the policy for machines on your network.

For a VPN that services telecommuters, consider using a vendor that offers a firewall with separate zones for work and home machines that share an Internet connection. As Figure 2 shows, the firewall's trusted zone gives the telecommuter's work PC access to the Internet and VPN access to the corporate LAN, and an untrusted zone allows a personal machine access to the Internet only. SonicWALL and WatchGuard currently offer such firewalls, which aren't much more expensive than home routers and eliminate worries about the other computers on your telecommuters' home LANs. However, multizone home firewalls don't eliminate the need to continually verify the security of remote VPN clients.

Adding VPN capabilities to your network isn't a decision to take lightly, although in this 24 x 7 day and age, you might find a VPN implementation impossible to avoid as users demand external access to your network. Just remember: A VPN adds access, not security, to your network. Think of a VPN as just another potential vector for intruders attempting to access your network or information. Done right, a VPN can improve your company's communications and still keep your network safe. So when you take the plunge, use the security checklist that Figure 3 shows to make sure you've done the research and preparation. That way, your VPN won't turn into a Virtual Public Network or your Very Personal Nightmare.