Chapter 10: Virtual Private Networks

Overview

This chapter addresses the role of the virtual private network (VPN) as a countermeasure in your network. There are many different types of VPNs, but the public is generally sold on the definition of VPN that means "using encryption over a public IP network to make sure nobody can read my data." This chapter discusses the types of VPNs, including those based on the public Internet and where they may be applicable as countermeasures in your network.

The commonly used selling tactic for purchasing VPN equipment is that "someone" on the Internet would be able to read your data. Using a VPN will make it so that your data is safe. While this is true, let us put things into perspective a bit.

Most VPNs are one of two types. The first type is the remote user of corporate resources. This is formally known as the "host to gateway" model. These are users that dial up to a service provider and then route their packets to a corporate VPN server. The data is encrypted from the host device of the remote user to the VPN server at the corporate office. Once inside the corporate network, most implementations decrypt the data and forward it throughout the internal network (see Exhibit 1). Host-to-gateway VPNs are found in two different varieties. The first is known as a voluntary tunneling. This means that users have the option of connecting to the Internet or other network resources not using the VPN. For example, home users with DSL lines are always connected to their DSL providers. When they have work that specifically requires access to the company network, they create a VPN service to the corporate site. The user is allowed to make the distinction between using or not using the VPN. This can be advantageous to the company and the user because it creates less demand on company resources. VPN connections are only being utilized when users are accessing company resources and are otherwise available. A company may have 500 remote users, but because the tunneling (VPN connection) is voluntary, only 100 of those users would ever be connected during peak hours. This has a significant impact on the planning that a company needs to do for VPN countermeasures.

Exhibit 1: Host-to-Gateway VPN

The disadvantage to voluntary tunneling is that users are free to use the Internet outside the VPN. At least when users are using the VPN, their traffic is usually protected by the company firewall. It is entirely likely that users would download or otherwise infect their computer while they are using the Internet for general purposes and then infect the company through their own VPN once they have connected to the LAN. Further-more, when the users are not using the VPN, the company has no control over the type of Internet usage in which the user is engaging. Depending on the security policy of the company in question, this may be an unacceptable risk.

The other option is known as compulsory tunneling. This means that the only way a remote user in a host to gateway environment can access the Internet is through the company VPN. Each time a user connects to the Internet, a VPN session is established. This provides the company using compulsory tunneling control and safeguards over user traffic but at the same time increases the use of company resources. Consider the diagram in Exhibit 1. Remote users need to use the company's Internet access to tunnel into the VPN gateway and then use that same Internet connection to send normal IP packets out to the Internet. Return traffic follows the same path. This leads to increased utilization of the company's Internet access links and increased delay for the remote user. Because all remote users will be expected to use the company VPN, the VPN needs to be sized so that all users can connect concurrently. Depending on the usage habits of your users, this can be a significant increase in the bandwidth and processing power required to support remote users.

While compulsory and voluntary tunneling have been described in the host-to-gateway context, there is no reason that the same concepts cannot be applied to gateway-to-gateway scenarios. A remote company site may have the ability to direct Internet traffic to its ISP locally, or may have to tunnel all data to corporate headquarters first and then send it out through the central Internet access connection.

The choice of which to use or which is "best" is entirely up to the company in question and is best answered according to the requirements set forth in the security policy. Maximizing security as in the compulsory tunneling example also maximizes the cost of the solution. In some instances, this may make financial sense; while in others, it is best for users to decide when to use the VPN on their own and provide other methods of protecting remote hosts (e.g., using personal firewalls, providing anti-virus updates, etc.).

In the second most common implementation of VPNs, two company locations have VPN gateways that create an encrypted tunnel between the two gateways (see Exhibit 2). Appropriately enough, this is known as the "gateway-to-gateway" model. Traffic internal to the corporate networks is unencrypted. Traffic traveling between the gateways is encrypted at one gateway and decrypted at the other. When the data is forwarded over the remote gateway, it is unencrypted. Now take a look at the vulnerabilities in the network. While it is true that someone could sniff data off the network, it is not as easy as it sounds. Consider the case of the remote user dialing into the network without using a VPN. The call is placed and a virtual circuit is set up to the local phone company and switched through their system from the POTS line to a digital circuit that is used to connect to the remote access server of the local ISP. This ISP may be a reseller of data or may be a major ISP. From the ISP, the data travels through their network and the network of a number of other ISPs. As the data passes from ISP to ISP, it is transferred through peering points — either public or private. Each of these peering points, in addition to employing much better physical controls than most corporations, also employ a high-speed switch, further reducing the risk that someone is running an undetected packet sniffer in a peering point. Finally, after traveling through one, two, or at most three (on average) ISP backbones, the data is delivered to the company network over some sort of point-to-point connection.

Exhibit 2: Gateway-to-Gateway VPN

While the data is vulnerable inside the ISP network, most long-haul service providers' network nodes are little more than small, climate-controlled rooms with powerful switches and routers built into them. Most of the work is done by long-haul circuits that transport gigabits of data across the country every second. Fiber, contrary to popular belief, can be "sniffed," but it is much more difficult for someone to do than just plopping a sniffer onto your LAN. In fact, when considering an overall risk analysis, if you have to include threats that are willing to sniff in an ISP network or crawl into a sewer to apply expensive and specialized sniffing tools to fiber optic, you have a generally high risk factor overall for your network

For the second VPN option — that is, gateway to gateway, the same scenario applies. Where is the sniffing going to be done? Outside on a telephone pole? Under the street? While it is possible to intercept data in these locations, they generally require a dedicated threat agent to pull it off.

Even if some unauthorized agent were able to pull data off the network data that traveled from point A to point B, most attackers that are likely to affect your network; script kiddies, the curious, and vengeful individuals, are unlikely to have the resources to crack even the most basic of encryption algorithms. Encryption has been broken, but assuming that it is an encryption algorithm that has been rigorously peer reviewed, it requires the cooperation of hundreds of individuals sharing their computer time or the largest of governments and scientific computers to do so in a period of time that makes deciphering the data worthwhile.

Most people are not even going to attempt to capture and decrypt encrypted data. Most attackers will not even go through the effort of attempting to capture unencrypted packets as they travel over the Internet. There are far easier ways of getting to data. The attacker might simply attack the VPN gateway itself. Either they can DoS it or otherwise gain privileged access. An attacker might take advantage of weak authentication mechanisms and try spoofing or redirecting traffic based on DNS entries to create a VPN connection. Or the attacker might simply gain access to the company itself and install their network monitoring tools there. As pointed out in the examples above, most of the time data is encrypted as it travels over the open waters of the Internet. Traffic on the LAN, being "safe," is normally sent in plaintext. As more and more companies start employing wireless networks, the attacker may simply drive past the company with a directional antenna to pick up the information he needs.

This is not meant to undermine those institutions that have legitimate fears of someone going through those great lengths to attack their data in transit. Depending on the motivation of the attacker, the risk may be worth it. This category of risk, however, is evident in relatively few cases. What this discussion is meant to point out is that it is common to see VPNs used to solve the wrong problem.