WORKSHOPS

You can safely use the Internet to transmit sensitive data among sites. Don't just plug in and start sending data, however. You'll need a firewall that supports virtual private networks (VPNs) or a separate piece of VPN hardware to augment the security of a firewall. Each will encrypt data as it pass es over the untrusted public Internet. In this article, we'll look at Checkpoint Software Technologies' software-based integrated solution, Firewall-1.

Keep in mind that virtual private networks will not work in every scenario. And though the security is very good, the reliability of the underlying Internet cannot be guaranteed. Therefore, your data will be safe, but it may not arrive in a timely fashion. When the quality of service needs to be guaranteed, private lines still are the best solution.

Off and Running As part of your VPN installation, consider adding out-of-band access to the VPN/firewall system. We found that simple errors in system configuration can lock you out. A simple modem will let you dial in to load a different rule set instead of requiring you to travel to a remote site for the fix.

The basics of virtual private networks are simple once you have the proper tools. Using Checkpoint's Firewall-1, we set up an encrypted path between two offices in our Madison, Wisc., lab. In our scenario, machines behind the firewall exchange completely encrypted data between private sites. But users can access any other site on the Internet without encryption.

Checkpoint's Firewall-1, which runs on SunSoft's SunOS or Solaris or Hewlett-Packard's HP-UX, sits atop the routing layer, checking every packet against a predefined rule set. We installed it on a Sun Microsystems' SPARC running Solaris 2.4.

In addition to examining the encryption capabilities, we investigated other aspects of the total security system, such as IP translation and proxying. Most firewalls will be able to support most of the features desired in a good security policy.

A private class of IP addresses behind your firewall also will protect from break-ins. Address translation allows outsiders to access certain machines, such as Web, FTP or e-mail servers, but only to the hosts that you allow. Remember that the goal is to keep data secure, whether on the local network or in transit to another site.

Setup and Reasoning To design a secure, distributed network using the Internet as your WAN, every aspect of your network must be secure. First, and foremost, your local networks must be behind firewalls. Once firewalls are in place, adding secure links to other sites is as easy as enabling VPN encryption.

We decided to keep one site entirely firewalled, and hid hosts using private IP addresses (see "Hidden Site Using Private IP Addresses," at left.) Using address-translation and hiding techniques, we were able to let everyone located behind the firewall use the Internet, while allowing access from the Internet only to specific machines.

Two methods of IP translation can be used: IP hiding and one-to-one mapping. With IP hiding, machines behind the firewall can "talk" to the Internet using the firewall's IP address. With one-to-one mapping, you can allow outside hosts on the Internet to directly address certain machines within the organization.

Machines that access the Internet via IP hiding only can initiate sessions, such as Web browsing or e-mail reading. However, one-to-one mappings, such as is shown with murphys.nwc.com, can be addressed from outside the firewall.

Once the basic site security is in place, you can think about implementing connections to other locations across the Internet. In our case, we have two offices in Wisconsin that are gatewayed to the Internet--one over a frame relay network to our San Mateo, Calif., lab and then to the Internet via an Internet service provider (ISP); the other through a local point of presence to NETCOM (see "Virtual Private Network Connection," at right).

Private Paths Once your security issues are understood, the implementation of virtual private networks should be fairly simple. A VPN-enabled firewall, usually acting as the Internet gateway as well, determines where traffic is headed and encrypts data destined for certain sites. Using a simple rule set, IP conversations are encrypted end to end and decrypted by a VPN counterpart at the o ther end.

Most VPN-capable firewall products, including Firewall-1, offer an easy setup that usually is not much more complicated than a few point-and-click commands. Each site is told which destinations are to be encrypted and from which sources it should accept and decrypt data. Once those steps are complete, every time a session meeting that criteria is opened, the VPN-enabled firewall negotiates an encrypted session.

Session encryption is not performed with smoke and mirrors, though it is completely transparent to the end user. VPN-enabled firewalls cannot encrypt data and assume that the other end can decrypt that data. There are two methods for encryption: shared key and public key. With shared-key technology, both ends use the same key, which travels with t he data, for encryption and decoding. However, with this method both ends must agree on the key and it must not be intercepted by an outside party.

To avoid these problems, public-key cryptography was invented. With this method, each end generates a matched public- and private-key pair. The public key can be given to anyone. Data that is encrypted with that public key can only be decrypted by a matching private key. The problem becomes keeping the private key safe (which is not too difficult) and ensuring that the person who gave you the key is not an imposter.

If your network is located completely within your organization, you can set up your own key server, possibly using the X.509 standard. Then, all public keys can be archived in a single secure location for all to use. In addition, using an X.509 certificate server will allow for digital signatures, which ensure that the data is not touched in transit.

In our scenario, we weren't especially worried about imposters trying to offer their keys to our VPN-enabled firewalls. So, we allowed the firewalls to generate and exchange their own keys. This is the fastest setup and also provides a very high level of security.

Other Issues Most VPN-capable firewall vendors would like you to believe that the hardware won't be a limiting factor, but in some cases it is. They may quote numbers related to encrypted throughput at full wire speed, but that isn't the only factor that should cause you concern. VPN-enabled firewalls require a lot of RAM and a fast CPU to handle all the session data related to IP translation, not to mention encryption cycles.

Obviously, the machine you choose for your VPN and firewall will depend on the traffic you generate. Factors to consider: Will you have multiple sessions open at once (Web browsing)? How many encrypted sessions will be open at the same time? How many machines will have IP translation?

Although we have no hard and fast rules, we can make some recommendations. Most will find that the size of the machine required will grow. You should pick a machine that can scale well. SPARCstations and Windows NT servers tend to scale easily and quite inexpensively.

RAM becomes an issue when there are many sessions open at once. Every session requires a certain amount of RAM and CPU time to maintain the information necessary to keep address translation (or encryption) going. Most Web browsers will download approximately four elements (such as graphic images) at a time. This means that each user may have as many as four sessions to be maintained.

In addition, CPU time is eaten up quickly when encrypted paths are used. Most VPN-enabled firewalls can maintain a wire-speed encryption stream; adding streams, such as Web browsing, can change resource requirements. Each of those streams has a session key associated with it and an encryption and decryption engine as well.