VPN Components

Now that you have a basic understanding of what a VPN is, let's discuss the components that make up a traditional VPN. Not every VPN implementation will include any or all of these components. Plus, based on the requirements listed in your security policy, you might not need all of these components. Therefore, you need to examine your security policy to determine which VPN implementation (or implementations) has the necessary components to meet your security policy's requirements.

The following sections will discuss some of the more important components that are typically part of a VPN implementation. Specifically, they will cover the following:

Authentication

One concern you might have is to somehow verify a device's or user's identity before allowing it to establish a VPN connection to your network. There are two general categories of authentication:

Device Authentication

Device authentication allows you to restrict VPN access to your network based on authentication information that a remote VPN device provides. Typically this is one of the following two types of authentication:

Pre-shared keys are typically used in smaller VPN environments. One or more keys is configured and used to authenticate a device's identity. Setting up pre-shared key authentication is very simple. Many administrators prefer its use instead of digital signatures or certificates, which require a lot more work to set up. Pre-shared keys requires you to manually configure a key or keys on each device that will participate with VPN connectivity.

Given the amount of configuration, though, pre-shared keys have one main disadvantage: they don't scale well. For example, assume that you currently have nine sites with a router at each site, where pre-shared keys are used for device authentication and the VPN L2L design is fully meshed between the sites. You add an additional site. This requires you to add nine keys to the router at the new site and set up keying information on the routers at the other nine sites. So adding more sites makes addition and management of authentication keys very complex.

Note

The original idea behind the use of pre-shared keys was that a key would be associated with a specific static source IP address; however, this concept did not work for remote access where users can originate their connection from anywhere on the Internet and have dynamic IP addresses. As a result, the concept of group-based pre-shared keys came to life. In this model, a specific pre-shared key would be looked up based on a clear-text group name sent as part of the remote access VPN connection initiation process. Pre-shared keys, in general, suffer from some of the concerns associated with man-in-the-middle attacks as discussed earlier, since one end of the connection can only validate that the other end has the same pre-shared key, not who the other end actually is. The solution to this man-in-the-middle issue is known as mutual group authentication and allows the head-end to identify itself with a certificate without requiring a certificate for each of the end users.

Normally digital signatures or, more commonly, digital certificates, are used for device authentication in large VPN deployments. Certificates that are centralized by a common authority, known as a certificate authority (CA), make adding and removing VPN devices a simple process. Any time a device is added to the VPN topology, a new certificate is generated for the device, containing that device's authentication information. This is held by the certificate authority. Other VPN devices can access the certificate authority to validate another device's identity. As you can see, a device doesn't have to locally store other devices' authentication informationthis information is centralized by the certificate authority. However, the main drawback of the use of certificates is that the initial setup and deployment of certificate services can be work-intensive.

User Authentication

One issue with device authentication, like pre-shared keys, is that the device authentication information is stored locally on the device. This presents a problem if the device itself is compromised. Normally I'm not concerned about this issue where the device is located in a secure environment, like a data center; however, I am concerned about authentication information stored on insecure devices, such as PCs and laptops. Many VPN implementations, therefore, will add an additional layer of authentication, called user authentication, to verify whether or not a VPN connection is allowed by a user using a specific device. Normally this is employed in remote access VPNs. In some instances, depending on the VPN implementation type (discussed later in the "VPN Implementations" section of this chapter), the VPN might perform both device and user authentication.

With user authentication, the user must supply a username and a password. This password might be a static password or a one-time password (through the use of token cards). As an example, assume that your VPN implementation used both device and user authentication. If someone were to steal one of your employee's laptops, the thief would be able to use the device authentication stored locally on the device, but would have to know the user's name and password to gain access. With token cards, the thief would have to know the user's name, have access to the user's token card, and know the user's PIN (personal identification number). Plus, many VPN implementations allow you to prevent a user from storing user authentication information locally on their desktop. Chapter 2, "VPN Technologies," discusses authentication methods in more depth.

Encapsulation Method

Another component a VPN must define is an encapsulation method: how user information, like data, is to be encapsulated and transported across a network. In other words, what is the actual format of the contents? You can determine this by asking the following questions:

Encapsulation also defines what application(s) or protocol(s) can be placed in the payload of a VPN packet. Some VPN implementations will encapsulate only application layer information, whereas others can encapsulate an entire Layer-3 packet or Layer-2 frame. How information is encapsulated is important because it can affect whether or not the data might experience problems with firewall or address translation devices. This issue is discussed in the "Address Translation and Firewall Issues" section later in this chapter.

Data Encryption

Data encryption is used to solve eavesdropping issues. Data encryption basically takes user data and a key value and runs it through an encryption algorithm, producing what looks like a random string of characters. Only a device with the same key value can decrypt the information. Many encryption algorithms exist, such as DES, 3DES, AES, Blowfish, RSA, IDEA, SEAL, and RC4, to name a few; however, not every VPN implementation supports all encryption algorithms. Typically, two or three algorithms are supported. Encryption algorithms are discussed in more depth in Chapter 2.

Packet Integrity

Encryption is CPU-intensive for a device. An attacker, knowing that you are using a VPN with encryption, might take advantage of this by executing a denial of service (DoS) attack against your VPN device. Basically, the hacker would spoof packets with garbage in them, using an IP address from a trusted VPN source. When your VPN device received the spoofed packets, it would try to decrypt them. Of course, it would not be successful and would throw away the spoofed packets; however, your device would have wasted CPU cycles to perform this process.

Because of possible packet tampering or packet spoofing, some VPN implementations give you the option of performing packet integrity checking, or what some people commonly refer to as packet authentication. With packet authentication, a signature is attached to the packet. The signature is created by taking contents from the packet and a shared key and running this information through a hashing function, producing a fixed output, called a digital signature. This signature is then added to the original packet and the new altered packet is sent to the destination. The destination verifies the signature; and if the signature is valid, the destination will decrypt the packet contents. Verifying a hashed signature requires far fewer CPU cycles than does the decryption process.

Two of the more common hashing functions used for packet integrity checking are SHA and MD5. Hashing functions are discussed in more depth in Chapter 2.

Key Management

I've already mentioned three VPN components that use keys: authentication, encryption, and hashing functions. Management of keys becomes important with VPN connections. For instance, how are keys derived? Are they statically configured or randomly generated? How often are keys regenerated to increase security?

For example, assume that your security policy stated that keying material used for encryption and packet integrity checking needed to be changed at least once every eight hours. If you used static keys for different sites, and had 100 sites, you would be spending about an hour each time manually changing keys. Therefore, in most instances, a dynamic key management process is needed. You should carefully evaluate how this is handled when choosing a VPN implementation. Chapter 3, "IPsec," discusses how this is handled with the VPN implementation of the IPsec standard for VPNs.

Non-Repudiation

Repudiation is where you cannot prove that a transaction, like the establishment of a connection, or the purchase of an item, occurred. Non-repudiation is the opposite of this: you can prove that a transaction occurred between two parties. Attackers often attempt to execute repudiation attacks.

In the financial world, non-repudiation is very important. For example, if I were to go to an online store on the Internet, like Amazon.com, and buy a book with my credit card, Amazon would have to be able to prove that it was me buying the book before they could successfully bill my credit card. They would have to gather personal information about me when I filled out my order, like my name, billing address, telephone number, and credit card information, and use this information to verify my identity with my credit card company. And of course, Amazon would keep a record of the transaction: what I had entered, the date and time, and my IP address, to track me down if I was trying to use someone else's credit card fraudulently.

Non-repudiation can be a component of a VPN implementation. In the VPN world, non-repudiation involves two components: authentication and accounting. I've already discussed authentication in the "Authentication" section of this chapter. Accounting is the recording of the VPN session. This could include the identities of the two devices establishing the connection, how long the connection was used, how much information was transmitted across it, what types of information traversed the connection, and so on. This can then be used later to detect access attacks and for management purposes, such as creating baselines and looking for bandwidth issues.

Application and Protocol Support

When choosing a VPN implementation, you'll need to first determine what kinds of traffic need to be protected. For example, if you only have IP traffic in your network, most VPN implementations will be available to you; however, if you need to protect both IP and IPX traffic, the number of VPN implementations available to you quickly dwindles. Likewise, maybe you only need to protect traffic for specific applications, such as web and e-mail traffic. Again, this could affect the choice you make in choosing a VPN solution, like SSL versus PPTP or IPsec. Remember that a VPN implementation might pose restrictions on protocols and applications that can be encapsulated by the VPN, as I discussed earlier in the "Encapsulation Method" section of this chapter.

Address Management

Address management is an issue only with remote access connections. As I mentioned in the "Remote Access" section earlier in the chapter, a remote access client is commonly assigned an internal address. Keeping track of which internal address is assigned to which remote access client can be problematic.

Look at Figure 1-7 as an example of this problem. In this network, the client has two choices for setting up the VPN session: VPN gateway A and VPN gateway B. Perhaps the network administrator has no control over which gateway the remote access user connects to, or perhaps it's random. Let's assume that the client belongs to a group where the pool of addresses assigned to the client is from 172.16.254.0/24. That means that if the client connects to VPN gateway A and is assigned an IP address of 172.16.254.1, VPN gateway B must know somehow that it cannot use this address to assign to a different client. Plus, devices on the internal network somehow need to know that when they want to send traffic to 172.16.254.1, they forward the traffic to VPN gateway A and not B. In addition, if the remote access user would tear down his VPN connection and re-establish the connection to the network, but via VPN gateway B, VPN gateway A would have to know this to update its addressing pool information. VPN gateway A also would need to update its routing information to reach 172.16.254.1.

Figure 1-7. Remote Access Addressing Example

There are actually many ways of solving the address/assignment problem, in addition to the routing problem, for this type of situation. As to the assignment of addresses, a common solution is to use an external DHCP server or an AAA (authentication, authorization, and accounting) server to assign an address to the user. An AAA server assigning addresses is done typically in situations where the client always needs the same address assigned to it; otherwise, either a DHCP server or the VPN gateway will assign the client its IP address. As to the routing issue of internal devices reaching the remote access user, the VPN gateways can create static host routes in their local routing tables and redistribute this information via a dynamic routing protocol. Cisco commonly refers to this process as Reverse Route Injection (RRI) when dealing with IPsec. For devices on the same segment as the VPN gateways, the VPN gateways can use proxy ARP to tell directly connected devices how to correctly reach the remote access clients.

Note

When an IP address is assigned from the VPN gateway's local interface subnet (the Internal Network in Figure 1-7), proxy ARP is used. When the assigned IP comes from a non-local subnet, the address must be routed to the VPN gateway for local devices. This can be done using a dynamic routing process. Another option is to add static routes to internal routers for this subnet pointing to the VPN gateway's internal interface; however, this only works if there is only one VPN gateway. When you have two or more gateways, you'll need a dynamic routing process to discover which client is connected to which VPN gateway.

Again, you need to weigh this factor when choosing a VPN implementation. Some VPN implementations might lack address management, or have very poor address management, affecting your choice in a VPN implementation.

Related

Категории