Republished with permission from WatchGuard Technologies, Inc.
Security and xDSL
In my previous three
columns on security and xDSL
connections, I discussed the technology of DSL and the vulnerabilities and
issues that DSL connections present. I suggested policies and technologies
administrators can use to control desktops, and explained the importance
of firewalls in home and remote offices having broadband local access
connections. Having accepted the risks and implemented the security
solutions, and now that your remote workers are connecting via DSL, you
will want to secure broadband local access communications using Virtual
Private Networking (VPN). This last column in the series describes several
What Is Virtual Private Networking?
A traditional private
network is composed of dedicated or leased lines that interconnect
routers. In a virtual network, tunnels replace
dedicated lines, interconnecting sites and remote users over the public
Internet logically. A virtual private network (VPN) adds
authentication (trust), access control, confidentiality, and message
integrity among the hosts participating in a virtual network so that the
communications are as secure as the private network it replaces (or if
implemented properly, more secure).
When and Why You Need VPNs
Organizations have successfully used ATM or Frame Relay to create virtual networks instead of building a mesh of expensive dedicated lines between its sites. Today, Internet access is commonplace, so why not use the Internet for virtual networking? Virtual networking over the Internet is straightforward, and is accomplished by using tunneling or encapsulation.
Satisfying the private aspect of a Virtual
Private Network is harder. The public Internet runs on IP, using the same
technologies large enterprises use, and is generally understood to have
the same vulnerabilities, especially with respect to interception of
unprotected traffic. To maintain confidentiality over the public Internet,
you must add encryption.
Choices for VPNs
VPNs come in many flavors, and can be used for secure remote access (Remote User VPN) or site-to-site (Branch Office VPN) connectivity. I’ll briefly describe the following alternatives:
(I’ve posted a chart
summarizing the key features of all these VPN technologies at my Web site.) And in
conclusion, I’ll list a few deployment scenarios and recommend which
flavor of VPN may best suit each one.
Layer 2 VPNs
Point-to-Point Protocol (PPP) supports dial-up Internet access and
enterprise remote access between two endpoints, e.g., a mobile worker’s
laptop and an organization’s remote access server. Layer 2 VPN protocols like the
Layer 2 Tunneling Protocol (L2TP) move PPP packets between two endpoints
over an IP-based internet (private or public) by creating a virtual "modem
link" from a tele-worker’s PC to the corporate LAN.
In one common L2TP scenario, a
user dials up an ISP and establishes a connection. Based on his
authentication credentials (e.g., Caller ID, user@domain name), the ISP recognizes this
customer as being one who requires a
tunnel to a corporate L2TP server. An L2TP access concentrator operated by
the ISP handles authentication on behalf of the corporation. If
authentication succeeds, the L2TP access concentrator passes or “proxies”
the packets between the remote user L2TP client and the L2TP server at the
corporate network. This scenario is referred to as compulsory tunneling. L2TP can
also be used to support voluntary tunnels, similar to Microsoft’s
Point-to-Point Tunneling Protocol (PPTP) a common implementation of a
Layer 2 VPN.
L2TP uses traditional dial authentication protocols (CHAP, PAP, etc.). It allows a tunnel server to enforce access controls at the point where the dial-up session connects to the corporate network. L2TP can encapsulate IP and non-IP protocols within PPP. Remember, L2TP only tunnels; it does not encrypt. L2TP can be carried over a Layer 3 VPN when message confidentiality and integrity are required.
3 (IPsec) VPNs
VPNs provide virtual connections using Internet standard IP Security
extensions (IPsec). IP packets can be exchanged between IPsec-enabled
tunnel endpoints—host computers, firewalls, security appliances, routers,
or servers—over any IP network. The “security association” connecting
IPsec endpoints is typically created using the Internet Key Exchange (IKE)
protocol. Each IPsec endpoint authenticates the far end of the tunnel,
negotiates protocols, encryption and authentication algorithms, and
generates shared secret keys—essentially providing everything needed to
enforce the security policy for the virtual connection. WatchGuard
customers can use Mobile User VPN for secure remote access and IPsec
Branch Office VPN for secure site-to-site communications.
The most common form of IPsec
is tunnel-mode, using the Encapsulating Security Payload (ESP). In this
method, each original IP packet is encapsulated
within another IP packet containing the addresses of the two tunnel
endpoints. An ESP header is added to convey the IPsec parameters. The inner packet may be encrypted to ensure that the
entire original IP packet’s content, even its source and destination,
remain private as the packet traverses a public network. This prevents
eavesdropping, and makes it more difficult to perform traffic analysis or
denial of service attacks by sniffing IP packets. An ESP trailer is
appended to the original (now encrypted) IP packet, for packet
authentication (message integrity).
There are other flavors of
IPsec—for example, an Authentication Header (AH) that provides message
integrity without encryption; and “transport-mode” IPsec, which protects
packet payload end-to-end between hosts, without encapsulation. But these
are deployed far less often than the tunnel-mode ESP I've described
When using tunnel-mode IPsec, you can apply security policies to any IP packet entering or leaving a corporate network, much as you would apply packet filters at a firewall. Initial standards support IKE authentication via preshared secret, raw public key, or digital certificate — methods well-suited for site-to-site VPNs, but not easily applied to large remote access VPNs.
VPNs I’ve described thus far create a secure path for every application
protocol, but their use might not be feasible in some circumstances. If
all you need is to exchange e-mail or perform remote administrative
functions securely, or if your business and e-business needs can be
satisfied by securing all browser-accessible applications, you may be able
to solve your privacy issues by securing individual application streams.
Secure Shell, Secure Sockets Layer, and Transport Layer Security do just
Secure Shell (SSH) is used to secure application streams, and is commonly seen in UNIX environments. You use an SSH client to initiate a TCP connection to an SSH server that sits at the edge of the protected network, serving as a gatekeeper between the untrusted and trusted networks. The SSH client and server create an encrypted session on top of TCP that can be used for host or user authentication. Once authenticated, additional application sessions (for example, POP3) can be multiplexed over the SSH connection. A POP3 stream would be encrypted over the public (untrusted) Internet; then, once it reaches the SSH server gateway, can be forwarded as clear text to a private enterprise mail server located behind the SSH server.
Secure Sockets Layer (SSL) is commonly used to secure Web traffic (HTTP). When you use a Web browser to secure a transaction, the browser's SSL client initiates an encrypted session on top of TCP. One of the many things you can do over an SSL connection is perform sub-authentication, where the client authenticates to the server. SSL sub-authentication at a proxy host is commonly used for single sign-on environments and for Web-based extranets. Since the SSL session itself is encrypted, anything else that you pass over the connection (e.g., user IDs, authentications to an ftp server) can be safely passed in clear, unencrypted text.
The Transport Layer Security (TLS) protocol is another Internet standard like IPsec, but is based on SSL. As with SSH, you can use TLS to secure non-Web application protocols (POP3, SMTP, IMAP, Telnet). There are two ways you can use TLS to secure application streams. The first way is to assign a new port number used by TLS connections for each client/server application, e.g., mail. The existing "well known" port is used for unencrypted traffic, and encrypted traffic is sent through the new port. An alternative is to modify both the client and server software of an application so that they negotiate or upgrade to communicate using a secure TLS channel.
SSH, SSL, and TLS operate end-to-end (client/server) or as proxies on firewalls or security appliances. They are useful alternatives when:
Scenarios at the Teleworker’s Small Office
A VPN is the final element of securing DSL connections. In cases where your traffic travels over the public Internet, you should consider some form of VPN between a teleworker and the corporate network.
If you are connecting a remote
user’s single PC to the
corporate network, consider using a remote user IPsec (Layer 3) VPN to a
Firebox firewall, or an IPsec capable router. However, if your teleworker
requires multi-protocol support (that is, other than TCP or UDP IP), run
L2TP over IPsec. Where your remote user shares a household (e.g., user has
a roommate or spouse that works for a competitor), add additional security
to the connection by requiring your user to authenticate. (Requiring
authentication for a remote user in a shared household should also be
applied with Branch Office VPNs.)
If you take the IPsec route on Windows 2000 PCs, be sure to check for interoperability between your security gateway and the Windows 2000 IPsec/L2TP implementation . If your employees are using Windows 95/98, you will need either a third party or vendor-provided IPsec adapter (such as WatchGuard’s Mobile User VPN). One caveat: some clients can be troublesome to install on certain PCs and laptops, and are not compatible with all NIC and modem cards.
If your remote user’s PC only
requires browser access to corporate servers, you can take the current
path of least resistance and use SSL. This (or a TLS-protected application
like e-mail) may also be attractive if you must tackle both the problem of
securing e-business transactions, and the problem of securing branch
office remote access.
Teleworker and small offices
that employ SOHO firewall appliances, such as the WatchGuard SOHO, can
operate IPsec site-to-site. I believe site-to-site (from teleworker
firewall to a corporate firewall) is the simplest, most secure deployment
you could ask for. Look for a teleworker firewall that supports IPsec and
can be centrally administered through the same management interface as
your corporate, IPsec-capable firewall. In this scenario, you can assert
security policy uniformly and transparently across all teleworker DSL
connections, and you avoid help desk issues for desktops in teleworker
Central administration of your VPN topology will quickly become a top priority when choosing a corporate VPN server. Look for products that provide effective means to administer pre-shared keys today, and that have a viable approach for managing digital certificates and any legacy authentication method you may have already implemented across your enterprise (e.g., 2-factor, token-based authentication).
Closing Remarks on This Series
Broadband local access forces IT administrators to consider on a much grander scale than before the security of systems, information, and communication outside an organization’s core networking environment. It also forces administrators to reconsider some existing security policies and practices for remote access in general. These are Good Things. You may wonder whether it’s necessary to implement all the suggested practices I’ve mentioned in this series. You may also wonder which of these solutions is best for your organization. The only way to answer these questions is to consider policy first, understand the risks broadband local access introduces, and assess which risks you can mitigate or reduce most effectively given available budget and expertise.