There are several existing security services that have been leveraged to provide a VPN-quality connection over public networks. These are referred to upper layer VPNs and typically operate at the application and session layers. There are several examples, including SSL, SSH, and SOCKS.
Secure Shell (SSH) is a derivative of the remote administration UNIX utility SH. SSH uses encryption to establish a private TCP/IP session from a host to a server to allow for secure administration. It soon became clear that any type of data could populate the data portion of the encrypted packet. Now, several VPN solutions leverage the SSH protocol to accommodate VPN connectivity.
Exhibit 2-17 L2TP connection where the LAC is provided by client software loaded on the laptop.
Secure Sockets Layer (SSL) is, conceptually, very much like SSH. SSL is typically associated with application-based connectivity such as Internet browsing and the use of Certificates to authenticate clients and servers for encrypted communications. Recent history has changed the definition of SSL connectivity from application level encryption and relationships to network layer functionality. In its simplest form, an SSL VPN is an application that resides at the network layer processing the payloads with the appropriate attributes. Sound familiar? SSL, traditionally speaking, uses Certificates to authenticate the peers and uses the information to create symmetrical keys to encrypt the messages.
Aventail SSL VPN Solution. A good example of the new direction of SSL-based VPNs is Aventail. Aventail is a VPN product that is primarily designed for remote access and uses a sophisticated client to generate tunnels into the home network. The client operates low enough in the protocol stack to provide security services to upper layer applications without requiring changes to those application, exactly what IPSec accom-plishes. However, many of the technical similarities stop cold at that point. The solution, at least from the client side, is based on a simple configuration file (.cfg) that can be generated by a configuration tool on the client and easily distributed via normal com-munication channels.
Following are some descriptions and exhibits that show how a VPN is configured using Aventail based on SSL. This book, of course, is about IPSec VPNs, and SSL represents the furthest from IPSec one can imagine, from a technical perspective. However, by including discussions about other solutions that are popular and successful in the VPN market, the reader is exposed to other options and can identify similarities in the aspects of VPNs regardless of the underlying support protocols. Simply stated, knowing more is good; understanding commonalities is better.
As with any VPN solution, one must configure servers and networks, the foundation of a VPN. What to encrypt and where to send it are the building blocks of secured communications.
First, one must create a secure server object that represents the final destination of encrypted packets — the security gateway. There can be several VPN gateways defined that reside on many networks and provide various services to internal networks, systems, and services — just like IPSec. Exhibit 2-18 depicts the creation of a server by giving it a common name that can be easily identified in the configuration tool. The actual identification is provided by an IP address or fully qualified domain name. The port number should look familiar — 443 is SSL. While other ports can be used, 443 is the most common, due to the nature of the VPN. There are different versions of proxy protocols that can be established with the remote VPN gateway by the client. SOCKS v.5 is the most robust of the available and provides a great deal of flexibility.
Note: Another primary technical difference between SSL-based and IPSec-based VPNs is that SSL is typically proxy driven. Remote clients make requests to the gateway and the gateway completes the transac-tion on behalf of the client. This is not network address translatransac-tion, where the IP address changes to allow internal communications; an entirely new connection to the internal system is established. For many in the security industry, this represents the strongest form of security;
however, it is only as strong as the implementation and the code being implemented to support the proxy services.
Finally, an option exists to provide another VPN gateway as a failover (see Exhibit 2-18). Many solutions provide this option, for example, Compatible, Altiga (both recently purchased by Cisco), Check Point, and VPNet, to name a few. In this section, one can see that a separate server object has been defined and is being used as a failover.
Failover within the realm of VPNs represents a very interesting aspect not necessarily available in other data communications. For example, if the Internet connection goes down at the main office and 1000 remote users were accessing internal applications at the time of failure, a second VPN device on the same network that uses the same Internet connection will not be much help. However, many large organizations, ones that would have 1000 remote users, typically have more than one office that has an Internet connection. By placing the other VPN device on the remote Internet connection, the clients can resume communications over the Internet to the backup site and regain access via the wide area network — a communication backdoor so to speak. The other network can be half way around the world and will have little effect on the communi-cations from the aspect of the client systems. Designs that take advantage of the Internet and natural redundancy are discussed later.
Exhibit 2-18. Creating a secure server object.
Once the VPN device has been identified, configured, and is represented by an object, a network object can be created. When creating a network object, the VPN device is not identified. The goal is to define several servers and network objects and align them at a later point in the configuration. As mentioned before, everything so far is common among nearly every VPN solution with varying degrees of control and customization, as one would expect. However, the core components are identical.
As shown in Exhibit 2-19, there is not much to defining an object. This has been described as a network object because that is how it is used in the example, but a single host or a range of addresses can be defined to provide granularity. Remember this aspect of granularity in destination definition because later in the configuration one will be able to limit the services and ports. In the example, it will have the destination as networks, but one can configure it to the actual system’s IP address.
Exhibit 2-19. Creating a network object.
The next major step it to associate the network, or system, object with permitted (or denied) services and the destination VPN system. At the top of Exhibit 2-20 there is a dropdown list of all the created objects that can be selected for this particular rule.
Once the target is identified, one can define the applications to associate with the rule.
Once the application has been configured, or the option to protect all traffic is selected, the rule must have an action defined. The three states of action should look familiar — they are identical to IPSec. If traffic matches the rule, one can configure the rule to do one of the following: apply protection and forward it to the defined gateway, deny the packet, or simply pass the data to the Internet as normal.
Once the rule is defined, is can be combined with other rules and placed in a specific order to define a high state of granularity in the identification and control of traffic.
Exhibit 2-21 provides a list of different rules with varying services being allowed. There is one added entry at the bottom that would not normally exist, but was added to convey a point. Of the bottom two entries, only one should exist to capture the remaining traffic.
The first of the two entries is a very typical addition for many currently installed implementations. By stating “everything else,” representing all destinations other than Exhibit 2-20. Creating a VPN rule.
the one defined in other rules, “ALL” represents the services to be identified, and finally the “NONE” is to specify the VPN gateway. In this case, there is no gateway defined, resulting in a split tunnel-like solution (which is detailed later).
The last rule states nearly the same thing; however the destination is the VPN gateway. In this scenario, all traffic will go to the VPN gateway, resulting in a single tunnel-like solution.
Aventail provides several different types of authentication for remote user access. A major aspect of SSL VPNs, when compared to IPSec, is that there is a lot more flexibility available in the authentication process (see Exhibit 2-22). However, it is important to know that IPSec is designed to be a global protocol that operates regardless of the implementation, and just as TCP/IP typically works between UNIX, Macintosh, Windows, among others, IPSec is vendor independent.
Exhibit 2-22 reveals a couple of interesting options. Available ciphers, a fancy word for encryption, allow the administrator to select DES or RC4 for encryption. Many people who like Aventail more than IPSec solutions typically forget that many more keys are used for IPSec, and DES is the lowest encryption supported. Therefore, per-formance can sometimes be better with SSL-based solutions, but most of the perfor-mance increase is due to the limited negotiation of policy, limited protection of the negotiation, and the size of the keys for the encryption. In short, it can be faster than IPSec due to the reduced communication requirements.
There are several levels of complexity and optional operations supported by IPSec that are not attainable when using modified upper layer security protocols. Many of Exhibit 2-21. The list of rules to be applied to traffic.
the similarities to IPSec revolve around tunneling and providing remote access solu-tions that terminate the connection destined for internal resources, much like L2TP.
The differences begin when it is necessary to nest or combine communication options, or provide identity protection, message integrity, and security levels to various points along the VPN.
Cryptography
It is impossible to discuss IPSec VPNs without understanding the fundamental con-cepts of cryptography. IPSec standards currently define several types of encryption that can be used (DES, 3DES, RC5, IDEA, CAST, BlowFish, 3IDEA, and RC4) to protect information. However, in implementation, DES and 3DES are predominant, with very few solutions providing other encryption technology. TimeStep is one of the few available solutions that provides IDEA, Blowfish, CAST, and RC5.
IPSec also employs message authentication codes (MD5, SHA-1, and TIGER) to provide message integrity. To add to the several layers of complexity that this book delves into, IPSec supports several standards for authentication. There are three primary types of authentication within IPSec: shared secrets, public key cryptography (and a Exhibit 2-22. Configuring the SSL authentication details.
modified version of public key cryptography), and Certificates. Encryption, message authentication, and the authentication process are discussed in great detail in subse-quent chapters; this section simply introduces the foundation behind each of these technologies.
Encryption
Encryption, simply stated, is the conversion of plaintext into unintelligible ciphertext.
Typically, this is achieved using a key and an algorithm. The key is combined with the plaintext and computed with a specific algorithm.
There are two primary types of encryption keys: symmetrical and asymmetrical.
Symmetrical. Symmetrical keys are used for both encryption and decryption of the same data. It is necessary for all the communication participants to have the same key to perform the encryption and decryption. This is also referred to as a shared secret.
Asymmetrical. Public key cryptography is based on a pair of keys, typically referred to as private and public, that are mathematically related. Data can be encrypted with one of the keys, but can only be decrypted with the corresponding key. It is also necessary to know that the exposure of one key does not provide any information to determine the other. Hence, the terms “public” and “private” represent the role of the key pair. One of the keys is provided to anyone who needs or wants it, and the other is confidential and typically passphrase protected.