Virtual Private Networks: Help or Hype?

Robert Owen Thomas

One of the latest buzzwords to enter the information security community is the VPN, or Virtual Private Network. The purpose of a VPN is to create an intermediate-system to intermediate-system or end-to-end encrypted link over a (often public) network. This allows corporations to inexpensively, and in theory safely, interconnect geographically separate sites over the Internet. Using Checkpoint Firewall-1 as an example, I will discuss the theory, configuration, and pitfalls of a VPN.

Why VPN?

As a company grows, perhaps globally, it becomes extremely expensive to build a corporate WAN. The costs associated with the links, the necessary infrastructure and monitoring systems, as well as the cost in personnel to build and maintain the network, can quickly grow beyond the organization's ability to afford the necessary network infrastructure. However, with the current rapid pace of business, network connectivity between sites is a requirement. So, the question becomes: How can we interconnect all of the geographically disparate sites in a fast, scalable, secure, yet affordable manner?

Using the Internet as the "network backbone" of the organization, the company can cost-effectively interconnect geographically distant sites. As ubiquitous as the Internet has become, it is highly likely that there is a nearby Internet provider for any site an organization may currently have or consider.

The risk, of course, is obvious. Sending proprietary data over the Internet is dangerous. The data may be snooped or altered. If a company is targeted by a competitor, it becomes a far simpler task to obtain access to the intellectual capital of the company. Worse, the expensive firewall configuration becomes almost a paper tiger. Black Hats may sit outside the gates, waiting for the corporate crown jewels to come out unprotected.

The VPN becomes the bodyguard of the corporate crown jewels. As data flows between corporate sites, the data is encrypted in such a manner as to be intelligible only to sites with the encryption key. Snooping reveals only a stream of seemingly random data. This encryption can be accomplished with products such as Cylink encryptors, SSH, and Checkpoint Firewall-1.

VPN: The Details

Using a VPN, a system adminstrator creates an encrypted intermediate-to-intermediate or end-to-end channel for the transmission and receiving of data. As an example, a corporation may have sites in Atlanta, Georgia and Spokane, Washington. The corporation has opted to utilize the Internet as the corporate WAN, but also wants to ensure the secure transmission of data between the cities. Using the firewalls at both sites, the corporation is able to create a secure, encrypted channel between Spokane and Atlanta. However, if someone from Atlanta wishes to Web surf a vendor site, the communication is unencrypted. Only traffic between the two corporate firewalls is encrypted; all other traffic is "in the clear," or unencrypted. Data behind the firewalls is also not encrypted.

Obviously, the encryption of the data between the firewalls requires some sort of agreed-upon key. However, protecting this key is more important than protecting the data itself - for if someone can snatch the encryption key, that person can then easily decrypt all of the encrypted data. Thus, key exchange becomes a complex and critical first step in building the VPN.

First, a set of keys must be generated for the systems on either end of the VPN. Since sharing one key, in cleartext, over the Internet would be rather dangerous, a pair of keys is generated. The public key is shared with the world, and is used to encrypt messages. The private key is kept secret, and is used to decrypt messages that have been encrypted with the public key. So the VPN starts with two keys, and the two firewalls share their public keys with each other. But how do we safely share our public keys?

Any information to be exchanged between the two firewalls must be authenticated. To prevent someone from modifying the initial public key exchange, digital signatures and certificate authorities are used to verify both the sender of the message and the integrity of the message. The certificate authority (CA) is a trusted third party from which another party's public key can be obtained. The CA attaches a digital signature to the key, with a public encryption system such as RSA. This verifies the authenticity and integrity of the key, and prevents anyone from easily altering the key. If a trusted third party is not used to obtain public keys, then some other method of verification should be used, such as exchanging the keys over the phone.

After adding the necessary rules, the sys admin's job is now done. However, the real work for the VPN hosts is just beginning.

When a packet wishes to traverse the VPN, the sending firewall notifies the receiving firewall that an encrypted session is about to begin. Both firewalls then use the public key of the other firewall and their own private keys to generate the same key using the Diffie-Hellman calculation engine. The result is the basic session key. The basic session key is used to encrypt the packets between the firewalls that contain the negotiations on the session key.

Next, the two firewalls negotiate a session key. This is the key that will be used to actually encrypt the data packets. The types of encryption used in this step include DES and triple DES. Using the basic session key as protection, the two firewalls agree upon a session key, which is randomly generated.

At last, actual data transmission can begin. As an added safety precaution, the data packets are encrypted by a combination of the session key and the IP header. The VPN is now active, and the data is now encrypted.

Pitfalls

There are many hidden gotchas in a VPN configuration, and many more misunderstandings. As noted above, the actual creation of the VPN is simple, but the underlying process is complex.

First, take the time to become intimately familiar with the VPN configuration. It is certainly possible that a misconfigured VPN can actually prevent all data transmissions between two firewalls. Worse, a poorly configured VPN may offer no protection at all - leaving the corporation with a false sense of security.

Second, verify that the packets are actually encrypted. Amazingly enough, most sys admins never take this step, and therefore cannot be 100% certain that the VPN is actually working. Use a packet-sniffing tool, such as snoop(1M) under Solaris, to view the packets. You should not be able to read the data portion of the packets.

Next, realize what is not encrypted. Packets flowing behind the firewall are not encrypted. Remember that the VPN is point-to-point, meaning packets that do not traverse the VPN are also not encrypted. This is important information that must be shared with the user community. Otherwise, assumptions may be made regarding the encryption that result in sensitive or proprietary data being communicated over unsecure channels.

Last, and most important, realize that VPNs, as with all technology, have limitations. Although encrypting packet transmissions is certainly important, it does not replace good host security. What good is your VPN if your firewall is easily hacked? None at all. It is far more common for Black Hats to attack individual hosts and obtain access to information there. If some malefactor can get behind your firewall, your VPN will be for naught. I cannot stress this last point enough: Make sure that you do not adhere to the "crunchy on the outside, chewy in the middle" paradigm of information security infrastructure. A mix of data security techniques, such as PGP encrypting a message sent over a VPN, is often the best approach.

Conclusions

The VPN is more than just a passing techno-fad; it is here to stay. The VPN is yet another powerful data protection tool when utilized properly. It is another information security panacea when used improperly or misunderstood. If you are creating a VPN, remember to keep the big picture in mind. Strive for end-to-end data security, and use a VPN as only one step toward that goal.

About the Author

Rob Thomas is a long-time UNIX and networking geek specializing in information security. He can be reached at: robt@cymru.com, http://www.cymru.com/~robt.