|
|
The hardest thing about wireless security is that it occurs at the link layer. Many protocols and tools have been designed and created to secure higher-layer traffic in the past. Until the proliferation of wireless, many people didn't worry about securing the link layer because it was too difficult and they assumed anyone with access to link layer communications was an insider anyway.
That means there are quite a few link layer-agnostic technologies around that will secure your IP-based traffic. The most common are IPsec-based VPNs. VPNs can provide integrity and confidentiality features that are on par with those available in 802.11i. The right VPN technology can also be deployed across many different platforms. This may help if you have a very heterogeneous network and getting up-to-date wireless support is difficult.
VPNs also provide various levels of authentication. Of course, all VPN software includes some form of user authentication, but how strong is it? Does it also provide mutual authentication of the network to the user? When dealing with wireless, the ability to authenticate the network to the user is a crucial feature. If users are unable to authenticate the wireless network they are connecting to, defending against rogue APs is nearly impossible.
VPNs are generally designed to authenticate clients attempting to connect to the network, and all modern protocols do a good job of this. Before wireless exploded in popularity, the issue of authenticating the network to the client was much less important. While most VPN protocols try to address this as well now, it was always a very important goal in the design of WPA/802.11i.
Another problem with VPNs is that there are so many to choose from. While 802.11i does have some choices (TKIP with RC4 vs. CCMP with AES) and various EAP types, these decisions are pretty easy to make and it is clear which choice offers better security (CCMP is better than TKIP, dynamically generated keys better than PSK, and so on). The quality of authentication and confidentiality provided by different VPN technologies varies dramatically, though this section aims to provide a quick overview of the advantages and disadvantages of popular choices.
VPNs work by encapsulating a lower-layer protocol inside a higher layer, for example, Ethernet over TCP. Another possibility is IP over IP, commonly implemented via IPsec. The reason this encapsulation is done is because encrypting higher-layer payloads (such as that of a TCP packet) is easy relative to link layer encryption. By embedding a lower-layer protocol in a higher layer, you can have most of the security associated with link layer encryption, along with the convenience of encrypting at a higher layer in the protocol stack.
VPNs can be configured in different modes: site-to-site or remote access. Unless you are trying to secure a long-haul wireless link between offices, you are probably interested in remote-access VPNs. Examples of popular VPN protocols are PPTP, L2TP, IPsec, GRE, and SSL-based VPNs.
The biggest difference between VPN protocols is the layer at which they operate. Do you want to be able to transmit anything that goes on top of the layer two Ethernet protocol into the corporate office? In that case, you need a layer two VPN protocol. The biggest advantage of these protocols is that you can tunnel various layer three protocols, although if you still have IPX or AppleTalk tucked away on your network, you may have bigger problems than wireless security. Protocols that operate at this layer include Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP).
If you only need to be able to transmit packets that sit on top of IP, then you should use a layer three protocol. Layer three VPNs are almost universally implemented by using IPsec.
PPTP stands for Point-to-Point Tunneling Protocol. It is a Microsoft-developed technology, and like most Microsoft technology, it is not an open standard. Also like most Microsoft technology, it is less secure than other standards. There are actually two versions of PPTP, PPTPv1 and PPTPv2. PPTPv1 was cracked in 1998, and Microsoft responded with PPTPv2. PPTPv2 is a significant improvement over v1, but it still is not as secure as L2TP. The reason PPTP is less secure than other solutions is largely centered around the fact that it employs usernames and passwords to authenticate users. This makes PPTP VPNs relatively easy to set up on Microsoft platforms, but not advisable with other more secure, standardized protocols available.
L2TP is a combination of PPTP and Cisco's Layer 2 Forwarding (L2F) protocol. One of the biggest advantages that L2TP has over PPTP is that L2TP uses IPsec's Encapsulating Security Payload (ESP) for data encryption instead of Microsoft's much weaker Microsoft Point-to-Point Encryption (MPPE). L2TP also supports more advanced authentication techniques than PPTP. The biggest downside to L2TP is that to get the stronger authentication it offers, you must install certificates throughout your organization.
IPsec is an open standard for protecting IP traffic at the network layer. A popular use for IPsec is to employ it to set up a layer three VPN. A typical situation is shown here.
Notice that in the preceding illustration, the shaded area of the packet is encrypted by IPsec. The rest of the hosts in-between the two VPN endpoints don't know what is going on, except that someone on the left side of the VPN is talking to someone on the right side.
IPsec can protect the encapsulated data using two different mechanisms, Authentication Header (AH) and Encapsulating Security Payload (ESP). ESP is what most people think of when they think of VPNs. It encrypts the contents of the payload and has optional (highly recommended) authentication checks as well.
If, for some reason, you want to set up a VPN that doesn't encrypt the contents of the encapsulated data, you could use Authentication Header (AH) mode. AH mode provides integrity checks that ensure the packets are not modified or replayed, but it doesn't actually encrypt them. While this might make sense in some cases (such as when you expect the data to be encrypted at a higher level), it's probably not what you want to use for securing wireless communications. It should be mentioned that ESP and AH are not mutually exclusive; you can have packets protected by both.
There are currently a lot of products billing themselves as SSL VPNs. These products vary considerably in features and implementation details. Vendors are doing a miraculous job at abusing VPN terminology in this arena. Many products billing themselves as SSL VPNs are nothing more than SSL wrappers to specific applications (think https, but without the http). This is not a VPN. Many people falsely assume because these companies mistakenly bill their solution as a VPN that a true VPN over SSL is impossible. This is quite false. There is no reason you cannot encapsulate IP (or even Ethernet) packets inside a SSL/TLS-based tunnel.
The most popular implementation of a true SSL-based VPN is OpenVPN. The biggest problem with IPsec is the complexity of its configuration, and its tight integration with the OS kernel. While a talented staff can configure IPsec correctly, no amount of skill will allow the decoupling of IPsec from the OS's kernel.
Many people overlook the coupling of IPsec with the kernel. This is not something to be downplayed. IPsec is a complex system of protocols. Though much of the complexity of the key exchange can be done in userland, this doesn't entirely mitigate the fundamental issue. Complex protocols lead to complicated implementations. Complicated implementations lead to bugs, and bugs lead to remote code execution. If the complexity (and the bug associated with it) falls inside your kernel, you are in serious trouble. Even if an attacker doesn't succeed in remote code execution against a poorly implemented IPsec stack, the possibility for a complete kernel panic is there.
Personally, I feel that the best thing SSL-based VPNs have going for them is that they are inherently less complex than IPsec, and what complexity they do have is strictly a userspace affair. A side effect of this is that SSL VPNs are much easier to configure correctly than IPsec. Many people working on standards forget that at some point a human being will implement their standard. The most secure protocol in the world is useless if nobody can implement it correctly. IPsec isn't impossible to implement correctly, but it is a lot harder to implement than SSL.
One popular technique to authenticate wireless users is to make them log in to some sort of captive portal before they can continue. People routinely see this setup in hotspots. It can be used to provide another layer of defense in your wireless security at work as well.
It's important to realize that although this sort of authentication can reliably authenticate users, it happens at too high a level to secure the link layer (in order to do this authentication, the user must already be using the link layer). The most likely scenario to deploy this setup is one where the organization doesn't already have a RADIUS server setup to do user authentication, but they do have some database of usernames and passwords.
In this setting, the users are all given a shared WEP/WPA key. This is better than nothing, but the administrator assumes that it will fall into the wrong hands eventually. Therefore, before a user can move any traffic, they are required to authenticate to the web-based captive portal with their username and password. This web-based authentication should take place over https.
When using this type of authentication, the attacker's job of attempting to recover the WEP or WPA key is no more or less difficult. This sort of authentication scheme is a good way to provide defense-in-depth, but it is important to realize it has nothing to do with link layer security. Once an attacker recovers the WEP/WPA key, she will be able to read the link layer traffic. She will even be able to associate with the network. Once on the network, however, the higher layer authentication will stop her from reaching further inside.
The problem with this is that the attacker can still read all the packets on the network. She can even set up a rogue AP with the cracked WPA/WEP key and attract users to her own look-alike web portal and steal their authentication credentials. At this point, unless you have also deployed some sort of VPN with another form of authentication, the attacker has compromised your network.
The biggest problem when trying to secure your wireless network via a VPN or some sort of web-based authentication is ensuring that your clients are not vulnerable to rogue APs. Unless your VPN protocol provides strong mutual authentication, your clients are probably susceptible to the attacks just described. WPA/802.11i was designed with mutual authentication in mind throughout the entire process. If you already have a very robust, well-maintained VPN setup and a lot of legacy wireless equipment that can't be upgraded to WPA, using a VPN for authentication and confidentiality may be an acceptable alternative. Most VPNs were not deployed with the unique threat that rogue APs pose in mind, however, and getting strong mutual authentication will require the use of extensive PKI, something that can be avoided with WPA when using the right EAP authentication type.
|
|