VPNs: in the belly of the beast

 Did you know that a significant number of wireless hotspots in New York are provided by organised cyber-crime syndicates? These hotspots are used to facilitate identity theft and man-in-the-middle attacks against people connecting to them. With the growing use of wireless hotspots across the globe, the risk of a remote user unwittingly connecting to such a hotspot is increasingly likely.

VPNs are a core component of many organisation's standard laptop builds. They're used by thousands of people every day to connect to their offices to download documents, enter a timesheet and check their email. They enable users to connect to the office network from wild and exotic locations and perform tasks as if they were sitting right in the office.....but that's exactly the issue for many security teams; users can and do connect to the office network from just about anywhere - coffee shops, client sites, home, free hotspots around the city and then have full access to their corporate environments.

Another increasing trend is for service personnel to be 'embedded' in a customer organisation's environment whilst still operating on their home networks. In many cases, these personnel will find themselves handling sensitive or privileged information. In both these scenarios, the requirement for the confidentiality of a VPN is of paramount importance. Despite the common perception that all VPNs are the same, just like people, they are not all made equal (at least in regards to security). A certain degree of knowledge about the inner workings of the various options is needed to be able to select the optimal solution for each situation.

The different protocols

There are a wide variety of protocols that can be used to create VPNs. Each of these protocols works in a slightly different manner and has different capabilities There are tunnel-only “vanilla” protocols, such as the old Microsoft PPTP (Point-to-Point Tunnelling Protocol) and L2TP (Layer 2 Tunnel Protocol, which ironically runs at layer 5 of the OSI model!).

There are the hybrid (read 'compromise') protocols, such as L2TP/IPSec, which try to take the best of both worlds approach and the top of the line types, such as IPSec which pretty much does whatever you ask of it, but you need a PhD in Computer Networking to work out how to use it.

(I speak from personal, painful experience on that last point – in the dim and distant past, I studied a MSc course in Computer Networking and Communications in the UK and nothing even touched the level of complexity that the IPSec suite of protocols can create! Andrew Tanenbaum eat your heart out!)

There are also a number of proprietary protocols as well, from vendors like Cisco and Nortel, that sit normally somewhere between L2TP/IPSec and pure, unblemished IPSec. These proprietary protocol are normally tightly coupled to the various companies' hardware offerings, such as the industry standard Cisco PIX and Cisco VPN Concentrator product line.

(For those readers who are pathologically obsessed with the inner workings of tunnelling protocols, key exchange protocols, and the relative merits and challenges of various approaches of deploying them, or are simply curious as to what other considerations might need to be considered in the selection of a particular VPN solution, I have written a slightly more technical whitepaper on VPN security which can be found under our 'Whitepapers' section.)

Authentication

Not surprisingly, most organisations also want to ensure that only their employees or other authorised parties have access to their networks. Each VPN solution provides for various types and strengths of authentication. Some, like PPTP use external protocols such as MS-CHAP to provide authentication and some, like IPSec have strong authentication capabilities built into them. Many organisations will already have a preferred authentication solution, which can range from the weak (such as pre-shared secrets) to the very strong (such as PKI certificates), with options such as OTP (One Time Passwords) ranging in between.

A general rule of thumb is that the stronger the authentication method, the more complicated and involved it becomes to manage and deploy. The cost of the authentication solution similarly scales, from virtually free for simple pre-shared secrets to requiring dedicated, highly skilled resources for large scale deployments at the other end of the spectrum.

Finding an appropriate authentication mechanism needs to consider the environment within which the authentication will occur and the value of the resource being protected (including reputational and other intangibles). Your choices of preferred authentication mechanism may also influence which VPN protocols and / or solutions your organisation may chose to deploy, as not all authentication mechanisms can be supported by all VPN protocols. Best practise is to look at what resources need to be accessed by VPN first, then consider the value / risk associated with those resources. This value/risk equation will drive the solution requirements.

Inter-operation

I was recently engaged to find a VPN solution for an organisation where Windows XP, Mac OS X and Linux desktops were all used. The organisation needed encryption for their VPN traffic and the preference was for authentication by PKI certificates. This combination left three main options:

1. A proprietary solution, such as Cisco PIX or VPN Concentrators,
2. A pure IPSec solution, or
3. L2TP/IPSec.

For various reasons the proprietary solution wasn't really viable. It also turned out that many of the users would use wireless WAN links to connect to their office network, which significantly reduced the attractiveness of the L2TP/IPSec option due to its' tunnel through a tunnel approach, which is highly susceptible to bandwidth fluctuations (read 'it drops out if a butterfly in Turkmenistan flaps its' wings'). That left pure IPSec. The server configuration was relatively simple as the organisation had an existing PKI, but the integration of the various client operating systems constituted the single largest challenge.

I'm sure that if you ask Microsoft and Apple to describe how IPSec and the underlying protocols (such as IKE – the handshaking protocol) work you will get two answers from each company – firstly how they understand it works and then how, in their opinion it should work. Unfortunately, none of these answers are consistent with the various standards and RFCs that describe the IPSec suite of protocols. I believe the euphemism utilised to describe this scenario is 'vendor optimised implementations'. Not that I'm knocking them; Active Directory, for example may not be a proper LDAP implementation and may break various Kerberos standards, but it does a fantastic job of tying the various Microsoft server products together in a single directory....

To cut a very sharp and painful learning curve short (involving protocol analysers and copies of various RFCs), not all vendors implement standard protocols in the same way (please ignore the irony in that last statement). I finally got all the clients connecting with various platform specific additions to the VPN server configuration to handle the differences between each vendors implementation of IPSec. All clients were running pure IPSec, all were AES enciphered, all were authenticating with their PKI certificates. A success!

IPSec is hard. IPSec in a hybrid environment is harder. However if you want to try this for yourselves, don't be surprised if a solution doesn't work at first – ensure you know how your chosen VPN protocol works and be prepared with test plans to ascertain where and how any negotiation is failing. And if the worst comes to the worst, you know a company who can help you out, don't you?