Wireless LAN 101

Installing a wireless LAN goes beyond purchasing an AP and wireless cards. As with any technology, it is important to understand how it works under the hood.

Service Set Identifier (SSID) Broadcasts

On a regular basis—typically every 100 milliseconds—APs broadcast management beacons to advertise their presence. (See Appendix B for more information about management frames.) The beacons contain information about the AP such as the SSID (network name), supported data speeds, and signal strength. You can think of these beacons as Wi-Fi mating calls. Like the siren's lure, they shout, “Here I am, wireless client! Come and get me!”

At first glance, this may seem like a great feature and, for some environments, it may be. When you click View Available Networks in Microsoft Windows XP, that list of network names is compiled from listening to beacons (and probe requests, described later). That's a very convenient feature if you're in a public hotspot because you need to know the SSID in order to associate with the network.

On the other hand, from a security perspective, broadcasting the SSID name is bad news because you've now made it easy for an attacker to locate and identify your network. Some hardware vendors have implemented a proprietary solution to this problem, often called Closed Network. In this mode, the AP will still broadcast management beacons, but the SSID will be blank. This will make you invisible to some AP discovery tools, such as NetStumbler.

However, if the attacker is using a sniffer, your other wireless traffic (data frames) will still be observed and the existence of a wireless network will be detected. However, the point of disabling SSID broadcasts is merely to reduce the likelihood that you will get picked up by war drivers (see Chapter 4), or inadvertently by Windows clients who happen to be passing by. Disabling SSID broadcasts also means that you are not giving away the SSID name, which, again, is required in order to associate with the network.

In Figure 1.1, when the SSID is broadcast, notice that the SSID appears in the management beacon as HomeLAN2. In Figure 1.2, when the SSID is not broadcast, the SSID does not appear.

Note that even in closed mode, a sniffer could pick up the SSID name if the attacker happens to capture the association handshake from an authorized user. A more sophisticated attacker could even forge a frame that causes a client to disassociate. When the client reassociates, the SSID name could be observed. (See Chapter 4 for more details on probe requests/responses and this kind of attack.) Most attackers, however, will not detect your network and simply move on to easier targets.

While many Wi-Fi environments (such as public hotspots) will want to broadcast their SSID, there are some instances where disabling SSID broadcasts makes sense; after all, it's easy to configure the SSID name in the AP and in each client configuration. (However, since it's in clear text, please do not think of it as being another password or shared secret.) The problem is that by removing the SSID from the management beacon, you are effectively breaking the ability for clients to roam from one AP to another.

Wireless clients utilize management beacons to detect when they are closer to another AP with a stronger signal. Without the SSID, there's no way for the client to know that it should reassociate with the stronger AP. Keep in mind that disabling the SSID broadcasts is a completely proprietary feature and not part of the 802.11 protocol. Therefore, not all APs have the ability to disable SSID broadcasts.

MAC Filtering

Just as wired Ethernet cards employ a unique hard-coded media access control (MAC) address (sometimes called a hardware address), so too do wireless Ethernet cards. The idea behind MAC filtering is to keep a list of authorized MAC addresses in the AP and allow traffic from only those approved cards.

The problem, however, is that many wireless cards include drivers which allow the user to spoof their MAC address. Third-party tools are also available to let users change their MAC address, such as Spoof MAC available from http://www.klcconsulting.net/smac. Since source and destination MAC addresses travel in clear text (even in WEP-encrypted packets), an attacker could simply capture a valid MAC address and configure their wireless card to spoof that valid MAC address. By impersonating a valid MAC, the card could fool the AP into thinking that the traffic is legitimate.

In addition to the spoofing risks, the management burden of keeping track of MAC addresses can become overwhelming in a larger environment. Imagine trying to keep track of every single wireless card that comes into or out of your company; propagating that list out to every single access point can be very time consuming. It's simply too much work for any environment with more than a handful of clients.

In a small office or home environment, MAC filtering is easy to implement since there is a small and consistent number of clients. MAC filtering, therefore, can be used to enhance security. Again, the point here is that many attackers will not bother with the extra work required to spoof a MAC address and will simply move on to other, less protected targets.

Wired Equivalent Privacy (WEP)

Much has been said in the media about the cryptographic weaknesses inherent in the WEP protocol. Much is also covered in this book. (See Chapter 3 for more information about WEP vulnerabilities.) However, from a home/small company perspective, WEP remains a valuable tool. If nothing else, WEP provides a way for you to indicate that the network is private. At this point, the 802.11 protocol does not include any way for a wireless network to identify itself as “free” or “open.” The only piece of information that a user has is the SSID. Turning on WEP is like putting a big Do Not Disturb sign on your network. This can be extremely important from a legal perspective. With WEP enabled, an unauthorized user cannot claim he accidentally associated with your network.

Cryptographers love to talk about things in absolute terms. The encryption is either perfect or broken. In this case, I agree that WEP has been proven to have flaws. However, I still recommend it be used if you don't have any other options. (It's better then nothing.) In addition, many of the attacks described in this book rely upon capturing a large volume of traffic. For many homes and small companies, the traffic generated is small enough that WEP attacks could take days or even weeks to capture enough data to crack the keys. With certain techniques, however, you can artificially generate enough traffic to crack the key in about an hour. (More on this packet injection technique in Chapter 3.)

The biggest problem with 802.11's implementation of WEP is that key management is overlooked in the protocol. The shared secret password has to be disseminated to all of your users, but the protocol doesn't tell us how to accomplish this. Do we email it to the users and ask them to configure the clients themselves? Do we leave it on their voicemail? Perhaps write it down on a little piece of paper? There's simply no guidance for managing key distribution. That's fine if you only have a small group of clients, but what do you do in a larger organization?

This problem is compounded by the fact that keys need to be changed on a regular basis. It's like the lock on the front door of an apartment building. If one person moves out, the lock needs to be replaced and everybody needs to get a new key. In a Wi-Fi deployment, keys need to be changed every time an employee leaves the company. Worse yet, if a laptop is lost or stolen, you must assume that the key has been compromised.

It's not perfect, but turning on WEP is just another way to raise the bar and keep attackers moving on to the next target. As the saying goes, “I don't need to be faster than the bear. I just need to be faster than you.”