Editor's note: In this two-part series, security expert Dave Shackleford discusses some of the key security and design considerations required to underpin virtual private networks (VPNs). Part one examines some of the most popular VPN configurations and their roles. Part two will discuss the steps enterprises should take to properly secure their VPN implementations.
Most organizations have a need to secure communications sent across the Internet. For many, the easiest way to accomplish this is with a
The most common uses for VPNs include connecting remote workers to a central data center for secure access to internal resources they'd normally have at work, creating a permanent connection between physically separate locations and securing connections between internal systems or network zones.
The vast majority of VPNs fall into two main technology types, although there are many variations. The first leverages Secure Sockets Layer (SSL) technology to facilitate connections using SSL or trusted layer security (TLS) certificates. The second option is an Internet protocol security (IPSec)-based VPN that offers more complex security options.
In most cases, SSL VPNs are focused on connections for workers who need secure access to applications and systems. Many SSL VPN providers have native integration and configuration options for common applications like email and office tools, file sharing and any Web applications normally accessed via a browser. The advantage of these VPNs is that they rarely require any client to be installed on the connecting endpoint, and often make setup and configuration simpler when facilitating access to common applications.
For non-Web applications and more complex security requirements, an IPSec VPN may be a better choice. While there are other remote access VPN protocols, such as point-to-point tunneling protocol and Layer 2 tunneling protocol, IPSec completely encapsulates all IP protocol traffic between an endpoint and a security gateway (or between two security gateways) and offers stronger encryption options. IPSec is a more complex set of protocols, but offers organizations more flexible options for setting up dedicated tunnels between gateways and systems that can carry most types of traffic. While most enterprise-class VPNs are deployed as a hardware appliance from a vendor, smaller organizations may choose to employ VPN software installed on traditional server hardware.
Architectures differ but most rely on server behind a firewall
There are several types of architectures available for deploying VPN platforms. The most common architecture for remote access involves setting up a VPN server behind a perimeter firewall in a demilitarized zone (DMZ), allowing specific ports or URLs to access the server through the firewall. The DMZ can be set up between two distinct firewalls -- or on a single segment that is connected to one firewall -- with the VPN server positioned within this subnet. Clients connect to the VPN server, which then facilitates connections to internal applications and services based on a user's role and authentication credentials. In some deployments, the VPN and firewall may be the same device, as long as the number of simultaneous connections can be managed without a significant impact on performance.
Building a secure VPN
Comparing security risks
Keeping VPNs relevant in an era of cloud computing
Choosing the VPN that's best for you
This architecture has stood the test of time, and most deployment scenarios today adhere to some variation of the "VPN+firewall" or "VPN in DMZ" model. The key drawback to this model is the need to trust traffic from the VPN platform, as it's unencrypted internally in many cases. It can, however, be inspected by traditional network monitoring tools like intrusion detection systems.
The second VPN architecture is site-to-site connection between two physical locations, which is most commonly configured between perimeter gateway devices (often routers). For this architecture, the most crucial security concern is the trustworthiness of the remote VPN platform and network. This is due to the fact that the connection is usually in place permanently.
Finally, there is the so-called internal VPN, an architecture seen most often in today's more progressive security designs. In this approach, VPN servers act as gateways to sensitive network zones and systems within them. Setting up an internal VPN for moderated and controlled access to sensitive data and resources can help organizations meet compliance requirements and monitor privileged user behavior as well.
Good VPN design shares common attributes
Regardless of the architecture implemented, numerous configuration options are available to help lock down VPN platforms and the functions they provide. All VPN implementations should ideally provide some degree of the following:
- Authentication and access control: SSL VPNs authenticate to endpoints using SSL/TLS certificates to create an encrypted tunnel, and then usually provide a Web interface allowing additional authentication via passwords or multifactor methods (tokens, client-side certificates, or one-time passwords or codes). IPSec VPNs are often preconfigured with authentication options between gateways and clients, and remote users can then provide usernames and passwords, token codes, etc.
- Verification of endpoint security and trustworthiness: VPN products have increasingly incorporated endpoint security assessment capabilities in the last several years. Many VPNs can now ascertain endpoint OS, patch levels, browser version and security settings, and whether antimalware software is installed (and what signature versions are in place).
- Confidentiality and integrity: SSL VPNs support both block and stream encryption ciphers, including 3DES, RC4, IDEA, and AES, among others. IPSec VPNs only support block ciphers for encryption. Both types of VPNs support hashing ciphers for integrity verification, and both have varying methods for detecting packet tampering and replay attacks via sequence numbers and hashing or message authentication.
This was first published in February 2014