Chapter 11: Wireless Network Security

The very first time I used a wireless card in my laptop, I knew that I had seen the future of computing. Being part of that group that marketing departments all over the world call the "early adopters," I had set up a wireless node as part of my test network. From there it was a short leap to apply it to my own home network. Honestly, there is nothing like sitting out on the deck with a nice iced tea answering e-mails.

The allure of wireless networks has always been their ease of use. In Vermont there are many old farmhouses and Victorian mansions that eventually are converted into small business offices. For years, the standard operating procedure was to either remodel the building to support cat 5 wiring or to run the wiring in exposed conduit — or even worse, along the floor. Wireless networking changed all that. Install a single access point and the entire building is network enabled.

Not only is the entire building network enabled, but many times you have also just network enabled the other tenants in the building and half of the parking lot. Unlike modern switched cat 5, the 802.11 IEEE standards that define wireless LAN communications act like a big repeater. Anyone within range of the access point is able to intercept network communications or utilize network resources.

From the security perspective, there are two different problems that must be overcome. The first is one of confidentiality; the second is one of availability. When network information is available for reading, this is a concern. When the other businesses in your building are able to use your network resources, there are fewer resources available for your users.

The original 802.11 standards attempted to address the confidentiality issue. Known as Wired Equivalent Privacy (WEP), the goal of WEP was to provide privacy equivalent to a wired network through the use of encryption. The story of how this fell short of the goal is a study in security and how good marketing cannot make up for a bad implementation. This is not to say that somehow WEP was "sold" to an unsuspecting public. On the contrary, the developers of WEP believed they had a secure solution to the problem of confidentiality on wireless networks. When I say "sold," I mean that WEP was designed with two default key lengths (40-bit for WEP version 1.0 and 128-bit for WEP version 2.0). The public has been taught that the longer the key, the more secure the encryption. In this case, this is simply not true.

Rather, this is a case of how key length is not the whole story when considering the overall strength of an encryption scheme. Just as an overview, WEPv1 uses 40-bit RC4 encryption, a popular secret key algorithm that operates as a stream cipher; that is the actual key is a stream of bits that is XOR'd with the plaintext to produce ciphertext. The advantage of RC4 and stream ciphers in general is that they are very fast encryption algorithms. From the beginning, the 802.11 community admitted that the 40-bit encryption may have not been adequate. To increase the security, the key length was increased to 128 bits, the standard for most commercial-grade encryption. This is the same encryption strength that you are most likely to use when shopping online over an encrypted session.

Unfortunately, increasing the key length did nothing to improve the security of WEP. This is because the primary flaw with WEP is not the length of the key at all; rather, it is the encryption key, called the initialization vector (IV), which is flawed. The IV is a 24-bit value that is appended to each packet that is sent between an access point and a wireless host. The combination of IV and the key stream generated by RC4 creates a perpacket key that is used by the remote host to decrypt the incoming packet.

The WEPv1 IV key space of 24 bits only allows a rather limited number of unique IV keys. This allows an attacker to sniff the network and, when enough packets have been sent to cover all the possible combinations that 24 bits allow, the attacker has essentially created a dictionary of keys (IV and RC4 streams) that allow them to decrypt the traffic on the network in real-time. Depending on the size of the packets and the activity of the access point, this amount of traffic can take an hour or less to collect from a single access point. Information collected from a multi-access point network takes even less time than this to collect the required number of packets.

The ability to decrypt the information from a collection of IV and RC4 key streams is due to the ability to employ a common method of compromising cryptographic algorithms. Using what is known as a known plaintext attack, attackers can compare what they know the unencrypted data should look like with what the encrypted data is and thus derive the key. For example, a PING packet has a fairly standard structure to it. Attackers could send a number of PINGs and record their own encrypted ICMP traffic. Knowing what the unencrypted data should look like allows them to determine the key for that packet. This normally would not be such a huge crisis; plaintext attacks are well-known cryptographic attacks, but the fact that the same key that encrypted that traffic will be reused in the future will allow attackers to create a dictionary of keys and decrypt traffic in near real-time. Each time the reused IV is detected, the attack can correlate that with the associated key for that IV. If attackers are unable to send their own traffic, they can also perform a partial known plaintext attack. After all, protocol headers are fairly constant in appearance.

The solution would be to change the base key (typically a password) frequently. The problem with the WEP implementation is that there is no way to perform this operation. First, the base key would have to be changed very frequently; and second, this is infeasible to do on a large network with many remote stations, given the manual key changing requirements that WEP currently has. WEPv2 attempts to use a larger IV value but this is of limited use. WEPv2 remains ineffective in the changing of base keys and allows plaintext attacks to succeed.

While WEP has problems assuring the confidentiality of data, it also has issues that need to be addressed regarding availability. Under normal circumstances, anyone with the proper service set identifier (SSID) can join the network via a wireless access point. The SSID is simply an identifier for the access point. Unfortunately, the SSID itself is often broadcast, allowing anyone with a wireless sniffer to read and use the SSID. In short, it is difficult to prevent unauthorized users from using an access point, especially if the network is configured to provide DHCP addressing for all requests and WEP encryption is not enabled on the wireless portion at all.

Given these problems, the prospect of installing wireless on your network and maintaining the goals of your information security policy seem to be at odds. There are, however, many ways that 802.11 can be included in your network infrastructure, as long as the risks are understood and compensated for. Let us examine our options.

The first option is to ignore WEP and design your wireless installation around the insecurities that are inherent in wireless communications. This would allow several options. The simplest solution would be to place the access point in your company where the ability for outsiders to access the signal is limited. Instead of placing the access point on outside walls, simply place it toward the interior of your building. Other simple steps include enabling WEP. We have established that it does not protect the confidentiality of information very well, but it is a small incremental step that may persuade the curious to move on to another target.

Be sure to change the SSID and access point key from the manufacturer's default. Based on MAC addresses, most wireless sniffing software can quickly identify the manufacturer of the access point and compare that with well-known default values for both. While DHCP is convenient, you might also consider disabling DHCP and using static IP addresses. These steps at least prevent someone from casually connecting to your access point, but will not stop the determined.

Many access points, like switches, also allow the network administrator to restrict access to the device on a MAC address basis. For each allowed remote device, a corresponding MAC address entry would be added to the access point database. This too can be effective in preventing casual use; but practically speaking, most hosts can change their MAC address and it is easy enough to sniff a MAC address out of a packet. Attackers can simply find a MAC address that is being allowed and reconfigure their host with the same MAC address.

The above options do not provide much with respect to guarding your network against misuse. Even placing the access point in the middle of the network will not do much to deter a determined individual. Directional wireless antennas can be built from Pringle's cans for a couple of dollars worth of parts. This greatly extends the range of 802.11 reception. One of the workshops I offer focuses on wireless technology and, as a demonstration, I use a homemade directional antenna and simply point it at nearby buildings and observe the signal strength increase as the antenna focuses on the wireless LANs in the remote office buildings. Because security is about reducing risk in a cost-effective manner, it can be argued that the risk is indeed reduced using the above options — just not very much.

Configuring the wireless network to be a distinct subnet from the rest of the network can increase the security provided to a wireless network (see Exhibit 1). Traffic from the wireless network is then filtered through a firewall as if the entire wireless subnet were untrusted (which it should be considered). If your corporate firewall will accommodate an additional port, this is a fairly straightforward option to consider. It will not address the confidentiality of encrypted data or the ability for the determined to gain access to the wireless network, but it would at least reduce the risk of your internal network being attacked via the wireless subnet.

Exhibit 1: Treat All Wireless Communications as Untrusted and Plan the Network Design Accordingly

It is also possible to disregard the protection offered by WEP and utilize higher layer encryption protocols. In most networks, it is a simple matter to configure common services such as POP3 and SMTP to be encrypted via SSL/TLS. Encrypted access to your company intranet may also be possible via HTTPS, the same protocol used to secure online transactions. If the infrastructure has already been created to support these protocols, then the threat of somone intercepting important company information is further reduced.

In some cases, it is possible to utilize the company VPN to encrypt all traffic from the wireless LAN using IPSec. Consider the case of a number of mobile users coming in from the field and setting up in a conference room for a meeting. These mobile users will have any host-based VPN client already installed on their laptop. The firewall protecting the wireless network will only allow traffic to the VPN gateway from the wireless LAN. Wireless users would then establish a VPN session to the corporate VPN gateway, and all traffic sent from their hosts would be encrypted using IPSec, a much more secure and reliable encryption algorithm. This reduces the risk of unauthorized access and loss of confidentiality the most, but admittedly requires proper network design and implementation.

Instead of licking their wounds received from the WEP problem, Internet engineers in conjunction with the IEEE have begun working on a number of new solutions that address the problems of WEP encryption. Although the IV length is an issue, the real problem stems from the fact that there is no easy way to change keys in WEP. Recall that it was only long-lived keys (long-lived being a number of minutes in this case) that allowed the encryption to be easily defeated. The IEEE, in response, has drafted the 802.1x protocol. This protocol uses the Extensible Authentication Protocol (EAP), a protocol designed by the IETF to authenticate users to a RADIUS server and provide key management functions for users. EAP itself is very similar to PAP and CHAP, which are currently used to authenticate dial-up clients all over the world. The major difference is that EAP, as the name suggests, allows the inclusion of user-defined extensions, essentially allowing vendors and standards bodies to increase the authentication options of the protocol beyond that of CHAP or PAP.

The 802.1x standard is officially known as the Port Authentication Protocol (PAP) and is intended to only allow network access to a device that has authenticated itself on the network. From a security standpoint, this is significant because it would reduce the risk of sniffers and unauthorized network hosts. This application also makes it attractive to wireless networks. An 802.1x-enabled device would not allow any access to a device on a port-by-port basis until the device has authenticated with a remote server. Only then would users be able to surf the Web or check their e-mail.

802.1x is an attempt to overcome the inherent weaknesses of the WEP protocol. Using 128-bit encryption with the larger IV value, EAP passes an authentication request to a RADIUS server that authenticates the user and then provides a temporary WEP key on a per-user basis. This alone is a great improvement over the earlier WEP implementations in that the WEP key was shared between all users. It is only after the user is authenticated that an IP address and access through the access point is granted. Furthermore, a new key is provided at regular intervals, most often every ten minutes. This prevents someone from collecting enough data to be able to decrypt large amounts of data.

While this would seem to be just the solution required to solve the wireless problem, and indeed address a number of other network security risks, 802.1x has some issues of its own that need to be considered. Some have criticized 802.1x authentication as being too limited, in that only the client is authenticated, not the access point as well. Furthermore, although 802.1x can be used to provide key management, the standards do not define how that key management is to occur, thus allowing vendors to implement their own solutions. The use of EAP is also flexible, meaning that the method of authentication while using EAP can vary from vendor to vendor. In the real world, this means that incompatibilities between vendors are going to exist.

Despite these shortcomings, 802.1x is gaining acceptance in the networking community. I would not recommend trusting your entire wireless infrastructure to this standard at this point and would continue to advise segmenting the wireless subnets and filtering traffic with a firewall, but it seems that 802.1x will become more common in the reduction of risk for wireless networking.