Wireless Networking Security

Article
09/11/2009

By Chris Weber and Gary Bahadur

Chapter 9 of Windows XP Professional Security reprinted with permission from the McGraw-Hill Companies. The text reproduced here is slightly altered from the text as it appears in the book, insofar as there are live links in the book but not in this excerpt.

ISBN: 0-07-222602-1

Reprinted with permission

Introduction

Wireless technology releases us from copper wires. A user can have a notebook computer, PDA, Pocket PC, Tablet PC, or just a cell phone and stay online anywhere a wireless signal is available. The basic theory behind wireless technology is that signals can be carried by electromagnetic waves that are then transmitted to a signal receiver. But to make two wireless devices understand each other, we need protocols for communication.

In this chapter we will first take a look at what Windows XP Professional has promised to bring to you in wireless technology. Then we will discuss the current security problems with wireless networks and your options for dealing with them. Last, we will present two methods that you can use to secure your wireless networks.

You will see two concepts heavily reinforced: authentication and encryption. These concepts will be the glue for our two recommended methods of secure wireless networking. If you just cannot wait, the first method is a solution using an IPSec VPN located on (or behind) a dedicated firewall that separates the wireless network from an intranet. The other method uses a combination of 802.1x authentication with a back-end Internet Authentication Server and dynamic WEP keys for encryption. Both methods use strong authentication, which can be based on client certificates. For a clearer understanding, read on.

Note: Refer to the "Blueprints" section of this book for network maps of the two recommended wireless network architectures.

It is easier to understand wireless technologies by categorizing them into three layers, as shown below. The three layers are device, physical, and application and service (protocol).

Table 1 Different Layers of Wireless Technologies

Layer	Technologies
Application and service	Wireless applications: WAP, i-mode, messaging, Voice over Wireless network, VoIP, location-based services
Physical	Wireless standards: 802.11a, 802.11b, 802.11g, AX.25, 3G, CDPD, CDMA, GSM, GPRS, radio, microwave, laser, Bluetooth, 802.15, 802.16, IrDA
Device	Mobile devices: PDAs, notebooks, cellular phones, pagers, handheld PCs, wearable computers

In the device layer (mobile devices) are gadgets ranging from the smallest cell phone to PDAs and notebook computers. These devices use wireless technologies to communicate with each other. The physical layer contains different physical encoding mechanisms for wireless communications. Bluetooth, 802.11x, CDMA, GSM, and 3G are different standards that define different methods to physically encode the data for transmission across the airwaves. In this chapter, we will focus on networks built upon the 802.11x and Bluetooth standards. The application and service layer, also referred to as ISO layers 2 to 7, contains the protocols that enable wireless devices to process data in an end-to-end manner. Protocols like Wireless Application Protocol (WAP), Voice over IP (VoIP), and i-mode reside in this layer.

Many security problems can be traced back to the end user in wired networks. Wireless networks are no exception, and it is typically the IT department's responsibility to protect the end user. Before your enterprise adopts the latest wireless network technologies, you will need to

Understand the capability of current products
Understand your networking needs
Understand the potential risk you are facing
Find a solution tailored to your environment

Windows XP's Support for Wireless Technologies

Wireless Infrared Data Association (IrDA) devices have been supported across many Windows operating systems, including Windows 9x/NT/2000. Windows 2000 natively supports some 802.11 wireless network devices, such as the original Lucent Wavelan card. Windows XP continues the support of IrDa and enhances the support of 802.11b (Wi-Fi) wireless network devices natively. Bluetooth support might be enabled in the near future.

There are two categories of wireless technology, distinguished by the distances they can cover: wireless personal area network (WPAN) and wireless local area network (WLAN), as discussed in the following sections.

WPAN

As the name "personal area network" suggests, such a network is small—in the range of about 10 meters (30 feet). Infrared Data Association (IrDA) and Bluetooth are the main WPAN wireless technologies; they exist in the physical layer (see Table 9-1). The devices that take advantage of a WPAN include PDAs, printers, cameras, cell phones, and access points, to name a few. The support of IrDA enables a user to transfer data between a computer and another IrDA-enabled device for data synchronization, file transfer, or device control. The speed for IrDA is up to 4 Mbits per second (Mbps) and the distance is usually less than 30 feet in an unobstructed line of sight.

Bluetooth uses radio waves to transmit data and therefore doesn't have the line-of-sight restrictions of IrDA. Bluetooth also supports higher data transmission rates (11 Mbps) and uses the 2.4 GHz ISM bandwidth. Support for Bluetooth, however, has not yet been integrated into Windows XP.

WLAN

The range of a wireless local area network (WLAN) is, of course, greater than that of a WPAN. For example, most 802.11b implementations will have a speed of 1 Mbps and a range of about 500 meters (1500 feet). With a closer proximity to the access point (AP), speeds of up to 11 Mbps can be reached. Windows XP supports the IEEE 802.11b standard natively; this standard uses Direct Sequence Spreading Spectrum (DSSS) to transmit the data in the bandwidth of 2.4 GHz—the ISM band. Since this bandwidth is free for public use, other devices such as cordless phone can cause problems and interference.

Windows XP's native support for 802.11x simplifies the implementation process for hardware and software vendors. As we will demonstrate later in this chapter, one of the most secure designs for a wireless network has users perform mutual authentication with a back-end server like Internet Authentication Service (IAS) before they are authorized to use the wireless network.

For questions about Windows XP hardware support, you can always consult the detailed Hardware Compatibility List (HCL) at https://www.microsoft.com/hcl. The next step is to figure out what other products and services you will need to set up your wireless network. Before we delve into solutions, however, let's have a look at the potential problems.

CHALLENGE
Your manager demands the integration of a wireless network into your existing corporate network. You have spent years perfecting the security of your wired network. Now you have to integrate a new technology that has new holes popping up all the time. What choices can you make that will keep your wired and wireless networks secure yet usable? Can you anticipate future attacks against wireless and be prepared for them? Any new technology poses challenges in security. In this regard, wireless networks have to be treated the same as wired networks. There is some security built in to 802.11x, but as we've seen with wired technologies such as OSs and applications, the standard security always needs beefing up. One option is to implement peripheral technologies such as IPSec with mutual authentication and encryption to make your wireless network secure. Another strong solution is to require client certificates in combination with dynamic WEP encryption keys. It's easy to allow unauthenticated access to wireless networks, and most people actually do. There are also other, more insecure methods of authentication for wireless networks, which end up being the same as letting anyone plug into your corporate LAN. Restrict your wireless as you would your wired networks.

Your manager demands the integration of a wireless network into your existing corporate network. You have spent years perfecting the security of your wired network. Now you have to integrate a new technology that has new holes popping up all the time. What choices can you make that will keep your wired and wireless networks secure yet usable? Can you anticipate future attacks against wireless and be prepared for them?

Any new technology poses challenges in security. In this regard, wireless networks have to be treated the same as wired networks. There is some security built in to 802.11x, but as we've seen with wired technologies such as OSs and applications, the standard security always needs beefing up.

One option is to implement peripheral technologies such as IPSec with mutual authentication and encryption to make your wireless network secure. Another strong solution is to require client certificates in combination with dynamic WEP encryption keys. It's easy to allow unauthenticated access to wireless networks, and most people actually do. There are also other, more insecure methods of authentication for wireless networks, which end up being the same as letting anyone plug into your corporate LAN. Restrict your wireless as you would your wired networks.

Current Security Problems in Wireless

The most mature wireless network technology today is 802.11b, which is what we will focus on. Let's briefly go over the IEEE 802.11b standard.

IEEE 802.11b makes use of the 2.4 GHz ISM band and provides speeds from 1 Mbps up to 11 Mbps, with the range about 1500 feet. (Although in reality, you are hard-pressed to get this range out of products on the market today.) This standard uses Direct Sequence Spread Spectrum (DSSS) to encode data before transferring it. IEEE 802.11, 802.11a, 802.11b, and 802.11g use Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) as the protocol in the data link layer.

There are two names you need to know in a wireless network:

Station (STA)
Access point (AP)

STA is a wireless network client—a desktop computer, laptop, or PDA. The AP is the central point (like a hub) that creates a basic service set to bridge a number of STAs from the wireless network to other existing networks.

There are two different modes of wireless networking:

Ad hoc mode, or independent basic service set (IBSS)
Infrastructure mode, or basic service set (BSS)

Ad hoc and infrastructure modes are illustrated in the network blueprints. The ad hoc mode is equivalent to peer-to-peer networking. That means an ad hoc wireless network does not have an AP to bridge the STAs together. Every STA in an ad hoc wireless network can communicate with any other STA in the same network directly.

The infrastructure mode will have at least one AP to form a BSS. If there are multiple APs, they will form an extended service set (ESS). All traffic from or to an STA will go through the AP first. The AP in turn could be connected directly to another network, such as your wired intranet. In such a case, we recommend placing a firewall between them, as we describe in more detail later.

Almost every protocol set has some mechanism to protect the data, and the same is true for IEEE 802.11b. An encryption mechanism called Wired Equivalent Privacy (WEP) protects the data as it travels through the airwaves.

Security Alert After the WEP encryption mechanism was released, it was proved (by Nikita Borisov, Ian Goldberg, and David Wagner, in 2001) to be vulnerable to multiple forms of attack. WEP uses the symmetric cryptography system called RC4 with a user-specified key (64 bits and 128 bits) to protect the data. As a result, WEP alone is not enough to protect your data, and coming sections will address this fact with practical solutions such as dynamic WEP, IPSec, and 801.1x authentication.

The problems we focus on concern how a hacker could attack your network. The attack methodology is as follows:

Footprint the wireless network Locate and understand your target.
Passive attack Analyze the network traffic or break the WEP.
Authentication and authorization Determine what methods are enforced and how they can be circumvented.
Active attack Launch denial of service (DoS) attacks.

Footprint the Wireless Network

Attacking a wireless network begins with finding it, and that hinges on the interaction between the STA and AP. This section introduces the interactions between an STA and AP and then goes on to the methods for discovering and footprinting the wireless network in an active or passive way.

The Interaction

Because there are no physical wires between an STA and AP, they have to establish what is termed an association (a virtual wire) to communicate. The procedures are

Make sure an AP is available.
Authenticate with the AP.
Establish an association with the AP.

The first requirement is to identify the BSS provided by the AP. The service set ID (SSID) is the identifier that serves the purpose of identifying a BSS or IBSS. Then an STA can use the SSID to establish an association with an AP. So how does an STA know which SSID to join? There are two ways:

Active method In the active method, the STA sends out a probe request with the SSID inside to see if an AP responds. If the STA doesn't have the SSID in the beginning, the STA will send the probe request with an empty SSID. The empty SSID is useful, because most APs will respond to it with their own SSID in a probe response packet. At this point the STA knows the correct BSS with which to associate. You can think of it as walking into a house and yelling "Anyone home?"— the people in the house might respond with their names. Luckily, an AP can be configured to ignore a probe request with an empty SSID.
Passive method An attacker can still use the passive way to detect the existence of an AP by sniffing the packets from the airwaves, which will reveal the AP, SSID, and STAs that are live.

The Trace

The passive way to identify an SSID is to sniff the network traffic and look for three kinds of packets. The first one is called a beacon. An AP sends out a beacon periodically, usually once every 100 milliseconds. With this beacon, the STA will know there is an AP available. The beacon could contain the SSID as part of its information. The second packet is the probe request and response, and the third packet is the association request and response. All of these packets contain an SSID to identify a BSS or IBSS nearby. As long as the hacker is within the proper range, you basically cannot hide your wireless network. Some extreme methods do, of course, exist, such as surrounding the perimeter with metal or other substances that contain the wireless signals.

The Tools

Windows XP supports the active method of finding a nearby AP. Just open the property of your wireless network card, and click the Wireless Network tab, where you should see a list of currently available wireless networks. From there you can choose any available access point to connect to.

There are also other tools you can use specifically for the purpose of discovering wireless networks, such as NetStumbler (http://www.netstumbler.com). For the passive method of discovering a wireless network, you can use AiroPeek (commercial software found at http://www.wildpackets.com) to sniff the traffic and find nearby wireless networks. After you identify a wireless network, you then proceed with traffic analysis. Traffic analysis allows you to determine which attacks to launch against the wireless network.

Passive Attack

A passive attack is the method of analyzing the intercepted network traffic and extracting useful information from the collected raw information. The common tool we use for this is a sniffer such as AiroPeek. Due to the physical properties of a wireless network, you can perform traffic capture at any location as long as the signal reaches your system. You probably have heard of a "parking lot attack" or "war driving." As you might guess, these methods illustrate that people can perform traffic analysis in a car by either parking near your building or just driving the surrounding streets.

Clear Text Traffic

Probably the best scenario for a hacker and the worst for you, the system administrator, is clear text traffic. If there is no protection on the data being transmitted over wireless, then an attacker can easily sniff the traffic and perform protocol or data analysis later to crack into your information gold mine: credit card information, passwords, and personal emails. If the data is not protected, then the odds are high that the rest of the network setup is also insecure.

Problems with WEP

If the wireless network has WEP enabled, the hacker's game is still not over. The following problems exist in the WEP algorithm, and can potentially be exploited.

Brute Force Attack

WEP makes use of a symmetric cryptography system called RC4. The user can use a shared secret key. The real key to encrypt the data with RC4 algorithm is generated by a pseudo random number generator (PRNG). But flaws in PRNG can cause the real key space to be less than 64 bits or 128 bits. The flaw actually reduces the key space of the 64-bit key to 22 bits. Therefore, it is possible for an attacker to collect enough information to try to discover the key offline.

Duplicate IV

Initiation vector (IV) is a 3-byte random number generated by the computer. It is combined with a key chosen by the user to generate the final key for WEP encryption/decryption. The IV is transmitted with the encrypted data in the packet without any protection so that the receiving end knows how to decrypt the traffic. When your wireless network is using the same user-chosen key and duplicate IV on multiple packets, you might be in trouble. The attacker would know that all those packets with the same IV are being encrypted with the same key, and can then build a dictionary based on the packets collected. By knowing that the RC4 cryptography system uses the XOR algorithm to encrypt the plaintext (user data) with the key, the attacker can find the possible value of the packets. The attacker can do this because the XOR result of two different plaintext values is the same as the XOR result of two ciphertext-encrypted values with the same key. If the attacker can guess one of the plaintext packets, then they can decrypt the other packet encrypted with the same key.

Chosen/Known Plaintext

On the other hand, if you know the plaintext and ciphertext of a WEP-protected packet, you can determine the encryption key for that packet. There are several methods of determining the key, including sending an email or generating ICMP echo request traffic (ping). An attacker who knows the corporate intranet pretty well could send in an email to the network. Knowing the contents of that email, the attacker could then capture the traffic on the wireless side, identify the packets related to the email, and find out the key, eventually building a dictionary for a real-time decryption attack.

Weakness in Key Generation

A weakness in the random key generator of the RC4 algorithm used in WEP can permit an attacker to collect enough packets with IVs that match certain patterns to recover the user-chosen key from the IVs. Generally, you would need to sniff for millions of packets to get enough "interesting" IVs to recover the key, so it could take days, if not weeks, to crack a moderately used wireless network. This is just a very basic attack, with several tools available to do the sniffing and decoding for you. Airsnort is the famous one: it runs on Linux and tries to break the key when enough useful packets are collected.

Bit-Manipulation Attack

WEP doesn't protect the integrity of the encrypted data. The RC4 cryptography system performs the XOR operation bit by bit, making WEP-protected packets vulnerable to bit-manipulation attack. This attack requires modification of any single bit of the traffic to disrupt the communication or cause other problems.

Authentication and Authorization

Once the attacker knows information such as the SSID of the network, MAC addresses on the network, and maybe even the WEP key, they can try to establish an association with the AP. There are currently three ways to authenticate users before they can establish an association with the wireless network.

Open Authentication

Open authentication usually means you only need to provide the SSID or use the correct WEP key for the AP. It can be used with other authentication methods, for example, using MAC address authentication. The problem with open authentication is that if you don't have other protection or authentication mechanisms in place, then your wireless network is totally open, as the name indicates.

Shared Secret Authentication

The shared secret authentication mechanism is similar to a challenge-response authentication system. It is used when the STA shares the same WEP key with the AP. The STA sends the request to the AP, and the AP sends back the challenge. Then the STA replies with the challenge and encrypted response. The insecurity here is that the challenge is transmitted in clear text to the STA, so if someone captures both challenge and response, then they could figure out the key used to encrypt it.

802.1x Is Not 802.11x

Not to be confused with the 802.11x wireless standards, the 802.1x authentication standard handles the authentication process and key management while utilizing Extensible Authorization Protocol (EAP) to integrate with other back-end servers for authentication, authorization, and accounting (AAA). Wireless network users must authenticate themselves to the authentication server (e.g., a RADIUS server) at the other end of the wireless network to get authorization. The only known security problem is that if there is no mutual authentication (only the server authenticates the user), then the whole protocol is vulnerable to the famous "man in the middle" (MITM) attack. That means someone can intercept the traffic between the STA and AP, steal the authentication information, and use the wireless network. If there is mutual authentication between the user and the server (EAP-TLS or EAP-MD5), then 802.1x can be one of the most secure means of authentication available.

Active Attacks and Denial of Service

We just introduced most of the security problems using passive attacks; however, there are some active attacks to consider, too. One of the most interesting attacks is to set up a fake access point and let valid users establish associations, then collect information or perform a MITM attack. In a corporate environment, if a malicious employee installs a rogue AP on the corporate intranet, then they are creating a security hole—someone in the parking lot can easily hook on and surf your intranet. Another known attack is to try and steal the key for WEP from a wireless network user's laptop. A tool called Lucent Orinoco Registry Encryption/Decryption (http://www.cqure.net/tools.html) can break the encryption and extract the WEP key for Lucent Orinoco card users from the registry.

If an attacker tried all the above methods and failed, then the final choice might be denial of service attacks. Such attacks might bring down the wireless network and disrupt the service. We will describe the attacks from two different levels: physical level and protocol level.

Physical Level

There are two ways to disrupt the service of a wireless network physically:

Physical destruction To physically destroy an AP, you have first to locate the AP. You can also try to find the antenna, since destroying the antenna probably has the similar effect as destroying the AP.
Interference Even if the attacker does not have an electromagnetic pulse gun, that doesn't mean you are safe from such attack. Remember we mentioned that 802.11b uses the 2.4 GHz ISM band, which is open and free for public use. So the signal of the 802.11b wireless network can be disrupted by the microwave in the kitchen or the new 2.4 GHz digital cordless phones.

Protocol Level

An attacker can disrupt service from the protocol level. Remember that we talked about establishing associations to use the wireless network? If you can build an association, then there must be a way to disassociate. If you can authenticate, then there must be a way to unauthenticate. Unfortunately, in the IEEE 802.11b standard, both methods exist, and both methods do not require any authentication in the message. That means the attacker can send out a disassociate or unauthenticate message to an arbitrary wireless network user and disconnect them. This is a bad design from the protocol's perspective.

From the Wired Side

Do not assume that just because a hacker cannot get access to the wireless network that there is no other way to attack it. Suppose you have a wireless network connected to the intranet and configured only for a few users. Another employee in the company discovers the AP from the internal network and accesses the management interfaces on the AP. He breaks in through a default SNMP community string and changes the configuration, so he is now part of the list of allowed users.

This situation points out a problem: every AP has its own management interface(s). The most commonly seen management interfaces are Telnet, FTP, web, and SNMP. If any of these management interfaces are not secured, there is always a chance that someone can take advantage of the default setup.

Current Countermeasures to Wireless Insecurity

Before you decide to convince your boss not to build a wireless network for your intranet, think through how you can solve the problems we have outlined. The problems may be scary, but that's why you are reading this book. Once you know the methods a hacker can use to attack the wireless network, you can protect yourself by closing those holes. If you have read The Art of War by Sun Tzu, then you should know this saying: "If you know the enemy and know yourself, you need not fear the result of a hundred battles."

The rest of the chapter focuses on principles that you can adopt when designing your wireless network. But the single principle you should bear in mind at all times is "Defense in Depth"—the philosophy that you should never depend on a single mechanism to protect your valuable assets. Now that we have used the obligatory Sun Tzu quote, we can discuss several options for protecting your wireless network:

Change the SSID. A wireless STA uses the SSID to identify the wireless network. There is currently no way to hide that from a potential attacker. The only thing you can do is change the SSID so it doesn't make immediate association to your company. For example, if you work for IBM, do not name the SSID "IBM_WN20." This technique is more obfuscation than protection.
Configure the AP correctly. Make sure you change the default SSID, default password, and SNMP community string, and close down all the management interfaces properly.
Do not depend on WEP. Use IPSec, VPN, SSH, or other substitutions for WEP. Do not use WEP alone to protect your data. You know it is broken!
Adopt another authentication/authorization mechanism. Use 802.1x, VPN, or certificates to authenticate and authorize your wireless network users. Using client certificates can make it nearly impossible for an attacker to gain access.
Segment the wireless network. The wireless network should be treated as a remote access network and separated from the corporate intranet. A firewall, packet filter, or similar device should be in between the AP and the corporate intranet. This can prevent the damage caused if the wireless network gets broken into.
Prevent physical access. You can use directional antennas on your APs to restrict the directions of the signal. Shield your building or facility from electromagnetic interference as well. These methods can protect your wireless network and other electronic devices, but must often be weighed against the actual risk. MAC address filters can be implemented, but by sniffing the wireless traffic, the allowed list of MAC addresses can be easily determined.

Now you are ready to enter the next phase—designing a secure wireless network with Windows technologies for your corporate intranet.

Designing a Secure Wireless Network

This section goes into detail about the design of two different security architectures using Windows technologies. There are similarities between the two; for example, both rely on client certificates and both use WEP to some degree. Here we assume that you are using an environment full of Windows 2000/XP/.NET machines and with Windows 2000 domain controllers to manage your forest, although Windows .NET DCs would work just as well.

The first method simply uses an IPSec VPN, while the second uses the 802.1x Extensible Authentication Protocol (EAP). The purpose of both is to guarantee the user authentication and authorization and to protect the data's confidentiality and integrity.

Both of these architectures are illustrated in the "Blueprints" section of this book. Table 9-2 lists some of the pros and cons of each method.

In the rest of this chapter, we first look briefly at the IPSec VPN architecture. Then we'll delve into the details of setting up the 802.1x architecture.

IPSec VPN: A Simple and Secure Method

Referring to the "Blueprints" section of this book will help you picture the architecture we are describing here. The basic structure is this: the wireless clients, or STAs, connect to the open wireless AP and then authenticate with the IPSec VPN for access to the organization's protected intranet.

Table 2 IPSec VPN Versus 802.1x with EAP

Method	Pros	Cons	Notes
IPSec VPN	Controls access to the intranet Strong encryption Strong authentication Simple design Less server setup	Does not control access to the Wireless LAN Can be expensive to scale (bigger hardware, more devices) Doesn't support dynamic WEP	IPSec authentication starts at the network layer.
802.1x EAP	Controls access to the intranet Controls access to the wireless LAN Strong encryption through dynamic WEP Strong authentication	Requires more servers (CA, IAS/RADIUS, DC) More complex design	802.1x authentication starts at the data link layer.

This scenario provides an easy-to-manage, secure solution with strong authentication and encryption of network traffic. The downside is that authentication happens at the network layer with IPSec, meaning that the lower layers are still unprotected. Essentially, the wireless network will be wide open, while the intranet will only be accessible with strong authentication and encryption. This may be a fair trade-off for someone looking for a good solution with less overhead.

Architecture

Start this design by placing a firewall on the perimeter of your intranet, to securely segment the wireless network. At this point the intranet is considered to be "behind" your firewall. Then you need to decide whether to run an IPSec VPN on the firewall or on a system behind the firewall.

You can configure your firewall to deny all traffic going outbound to the wireless LAN except that which originated from the wireless side. Of course, if you need to access management interfaces, you will need to add appropriate rules. The firewall will serve to minimize broadcast traffic and prevent intranet users from poking around at the wireless AP and STAs.

IPSec can be used to build up security associations between a wireless client (STA) and the internal network/intranet. The method for authentication can be either Kerberos (which is easier to implement and manage) or client certificate-based authentication (which is more difficult to set up but more secure). In our example diagrams we use client certificates for authentication.

Authentication, data confidentiality, and packet integrity are provided through IPSec's industry standard protocols, such as IKE and ESP, described in detail in Chapter 7. Because broadcast traffic is not protected by IPSec, we recommend also using WEP.

Security Alert! As noted in Chapter 7, broadcast traffic is exempt from IPSec filters, so WEP must still be used with this method to protect broadcast traffic.

L2TP/IPSec VPN

When setting up your VPN gateway, be sure to configure your clients and gateway to negotiate strong encryption. You can use a Windows 2000/.NET server as the VPN, or you can choose a server from another vendor. As noted in Chapter 7, L2TP is the protocol that must be used to provide a remote access VPN solution with IPSec. The L2TP headers will be encapsulated and encrypted when using IPSec ESP, and the outer IP headers and lower layer headers will transmit unencrypted.

While we were writing this book, Microsoft released public beta software that allows legacy Windows 9x/Me/NT machines to use the L2TP/IPSec protocols. This means that all your Windows clients can now be outfitted for the secure VPN. The software and Microsoft's L2TP/IPSec implementations are based on industry standards and should work well with other vendors' VPN solutions. However, you could just as easily implement the remote access VPN on a Windows 2000 server behind the firewall. As a plus, Microsoft's L2TP/IPSec VPN client software also provides support for traversing NAT. Download the Microsoft L2TP/IPSec VPN client from https://www.microsoft.com/windows2000/downloads/tools.

Note: Several of the upcoming sections can be applied to this IPSec VPN architecture. For example, if you decide to use client certificates for authentication, then the Certificates and "Certificate Service" sections will apply. Also, for most IPSec VPN deployments, the "Wireless Zero Configuration" section will apply, as well as the sections on network policies and Active Directory.

802.1x—Secure Authentication Through EAP

Another strong wireless solution uses 802.1x with EAP-TLS and machine certificates to authenticate both the STA and the server. It also manages the WEP key by periodically and automatically sending a new key, to avoid some of the known WEP key vulnerabilities. The data confidentiality will be protected by these dynamic WEP keys.

To use 802.1x, both the Internet Authentication Service and Certificate Authority are needed to provide authentication and authorization. Refer to the "Blueprints" section of the book for the architecture utilizing 802.1x.

Architecture

Similar to the IPSec VPN solution, 802.1x gives you a wireless network separated from the intranet by a firewall/packet filter. Behind the firewall/packet filter is a network that contains a domain controller, Certificate Authority, and Internet Authentication Service. You can put all these services on a single machine or, more preferably, put them on separate machines with additional backup or standby servers. It really depends on your need for scalability. Again, the purpose of this architecture is to use certificates (computer or user) and the 802.1x protocol to authenticate to the IAS server in the back end and provide the security of dynamic WEP keys and secure communications.

A new WEP key will be periodically transmitted from the AP to the STA and encrypted by the public/private key pairs contained in the certificates. The frequency of change to a new key depends on the configuration of the AP. Of course, the AP has to support the dynamic WEP keys (e.g., Cisco AP 350) and the client has to support them as well (Windows XP does so natively). You just need to check the option to receive the WEP key from the AP when configuring your wireless network card on Windows XP. You can also set your group policy to allow certain users intranet access only while other users have Internet access on your IAS server.

WEP

You know that WEP doesn't protect your data well enough, but if you remember the "Defense in Depth" principle, you still want to enable WEP. To configure your WEP securely, follow these suggestions:

Use the highest security available If your devices support 128-bit WEP, then use it. It is extremely hard to brute-force a 128-bit WEP key. If you cannot dynamically change WEP keys, then set the 128-bit policy and change the key periodically. The length of this period depends on how busy your wireless network traffic will be.
Use dynamic WEP keys If you are using 802.1x, you should also use dynamic WEP keys if possible. Some of the wireless network device vendors also implement their own solutions similar to dynamic WEP keys. Evaluate them before you deploy.

Note: Using dynamic WEP keys will provide a higher level of security and will counter some of the known WEP insecurities. To use dynamic WEP, however, you must purchase an access point that can provide them and use clients that support them. Luckily, Windows XP provides this support natively when you check the WEP option "This key is provided for me automatically."
Use MIC when available We also mentioned that the WEP key does not protect the integrity of the packet. Currently IEEE is working on 802.11i both to fix the problem in WEP and to implement 802.11x and Message Integrity Checksum (MIC) for data confidentiality and integrity. MIC will generate checksums for the encrypted data to ensure the integrity of the data. To date, however, no product supports this capability.

Authentication/Authorization

Because of the limited functionalities of an AP, wireless network users do not usually authenticate themselves to the AP directly. The SSID serves only to identify the access point and does not identify the user or machine connecting to it. The information for authentication and authorization has to be processed by a server on the back end of the wired network.

802.1x supports Extensible Authorization Protocol (EAP). It can be combined with TLS (EAP-TLS) or MD5 (EAP-MD5) to provide high security during the authorization procedure. The wireless network user uses a certificate to authenticate himself to an authentication/authorization server in the back end of the AP. The AP that supports EAP will forward the messages from both ends. The communication between the wireless STA and the backend authentication server will be encrypted by the public keys on the user certificate and server certificate.

The backend authorization server (usually RADIUS, as with IAS) then authorizes an authenticated user to use a port of entry. In a wireless network, a port means establishing an association (virtual network cable) between the STA and the AP. So users must first authenticate themselves to the backend authorization server to be able to use the wireless network. In our example network, we will authenticate via a user certificate from the Certificate Authority of your enterprise.

Certificates

In order to let your users use certificates to authenticate themselves, you have to build your own certificate infrastructure that is capable of generating "user" certificates. Machine certificates would actually work just as well. The choice of whether to tie authentication to a machine account or a user account is yours. We will cover both types of certificates here. If you don't have a third-party CA installed already, you can install the Certificate Authority service available with Windows 2000 Server. Make sure you do the following things (assuming the CA and IAS are on the same machine):

Generate your enterprise root certificate.
Generate the computer certificate and user certificate with their private key.
Verify that the computer certificate includes the FQDN name of the computer.
Verify that the computer certificate is installed in the local computer

certificate store.
Verify that the user certificate is installed in the local user certificate store.
Verify that the root CA certificate is installed in the Trusted Root Certification Authorities store.

You can also use group policies to perform these functions automatically. With all these things done, you can let your users use the certificate (user or computer) to authenticate, using 802.1x to communicate with your intranet.

As mentioned in Chapter 5, a secure method of distributing certificates is to give users smart cards and enable autoenrollment on the certificate server.

Wireless Zero Configuration

Wireless Zero Configuration is necessary for the method we are describing, and luckily, Windows XP supports it natively. Wireless Zero Configuration refers to the capability of Windows XP to use information broadcast from the AP to automatically configure the client side.

Note: In general, we recommend that you turn off Wireless Zero Configuration as part of a baseline build. However, based on your needs, services should be turned on or off, and in this case it must be turned on.

To enable Wireless Zero Configuration, just open your Network Connections and select Properties for your wireless network connection. Then click the Wireless Networks tab and check the "Use Windows to configure my wireless network settings" option, as shown below. As we are writing this, this feature is not yet working for all wireless network cards. For example, if you are using Prism II chip-based cards (made by Linksys, SMC, D-Link, and other OEM vendors), you will need to do extra work to make the device work under Windows XP.

Figure 1: Enabling Wireless Zero Configuration in Windows XP

Authentication

As we have stated again and again, you will need certificates to authenticate your users. In this section, we are going to cover the main procedures for configuring your certificate server and other related services to build your own authentication infrastructure. First, we begin with the Certificate Services on your Windows 2000 Server. Second, we will go through what you should do with your Internet Authentication for 802.1x-based security. Third, we will discuss the configuration of Active Directory and several policy issues.

Certificate Service

We will start by looking at the installation of the Certificate Service and the generation of a certificate for your users. Next, we'll go through how to import and export those certificates. Lastly, we will walk through how to use the certificate for authentication.

Install Certificate Service

In general, to install the Certificate Service on your Windows 2000 Server, go to Settings à Control Panel à Add/Remove Program à Add/Remove Windows Components, and then select the Certificate Services check box. Choose this CA to be your Enterprise Root CA. Enter the appropriate names and information to identify your organization. After you install the Certificate Service, you can generate a root certificate for your own enterprise, and this certificate will be the root of every other certificate you generate in the future. The installation can be more complicated than this. We suggest that you read Microsoft's documentation and white papers on setting up a Certificate Server.

Generate Certificates

You can have certificates generated directly by having the user request a certificate, either through the Certificates MMC snap-in or through the intranet at http://your_*ca/*certsrv.

You still need a copy of the user certificate public key (no private key needed) as a file to map the certificate with the corresponding user account. This is because you will need to associate the certificate to that user or computer account under Active Directory. To do that, simply open the Active Directory Users and Computers snap-in, choose the user, right-click on that user account, and then click Name Mapping. Map the saved user certificate to this user account.

Note: Note that for Name Mapping to be available, you must first select Advanced Features on the View menu.

Import Certificates

After the certificate is generated, you need to transfer it to the user in some way. If the user generated the certificate from the Certificates MMC snap-in or the CA's web interface, then the user should do the exporting and send you the certificate public key.

If you generated the certificate for the user, you can export it from the certificate store on the CA and save it to a file. Then the user will have to import it to their Windows XP computer. To do this they simply right-click on the certificate file (we assume it's a .pfx file for personal information exchange format) and choose Install PFX, as shown here.

60209f02

If the certificate is generated via a group policy, you can just view it from the server (or from any Certificate Authority MMC plug-in), and invoke the Export Wizard from the Copy to File button.

As a user, you can choose a passphrase to protect your private key. Whenever you need to use the certificate for authentication, you will be prompted for your password, which is used to unlock the private key and encrypt/decrypt information. You can also allow the private key to be exported again for backup purposes—however, managing security of backup certificates can get out of control. The following figure shows protection of the private key with a password.

Figure 2: Choosing a password to protect a private key

The next step is to save the certificate to the current user's certificate store. You can just accept the default option to automatically let the software choose a certificate store for you, as shown

Figure 3: Automatically choosing a certificate store to save a certificate

That's it. Now you have a user certificate on your computer. If you want to install computer certificates automatically, nearly the same process can be used, but you would import the certificate to the local computer's certificate store rather than the user's store.

Configure a User Certificate with EAP

With the certificate installed, you are ready to begin authentication with the wireless network.

Even though we don't discuss the setup of IAS until later in this chapter, we are going to assume here that you already have both your AP and IAS configured. The first step now is to open Properties for your wireless network connection. You should see your preferred network. Next click the Authentication Method tab; you should see 802.1x enabled by default, as shown in below:

Figure 4: 802.1x enabled for your wireless client

On the EAP type, choose "Smart Card or other Certificate." You can also click the Properties button and then choose "Use a certificate on your computer" and "Validate the server certificate." These options will allow you to perform mutual authentication with your server, to prevent the MITM attack mentioned earlier. If you choose these options, you should also choose your trusted domain name and trusted root certificate authority.

Now you are ready to use the wireless network by authenticating via 802.1x with the IAS, which is finally covered in the next section.

Internet Authentication Server

To use 802.1x authentication, you begin by setting up the Internet Authentication Server (IAS) on a Windows 2000 Server. Quite simply, IAS provides authentication and authorization service for remote access. (See the "Blueprints" section of this book for the network architecture.)

First you install IAS through Add/Remove Programs in Control Panel. Then in Add/Remove Windows Components, highlight Networking Services, then click Details, and select the Internet Authentication Service check box. Install Service Pack 2 and apply hotfix 304697 (at the time of this writing). After you install IAS, you need to decide where the service will be in your network architecture. With our example, you can choose either to have a separate domain outside your intranet or to just use an IAS as your current domain. After you figure this out, do the following:

Enable IAS to read objects in the Active Directory by registering the IAS to your Active Directory.
Turn on file logging for accounting and authentication events. It could help you when you need to do some troubleshooting.
Use the Internet Authentication Service snap-in to the MMC to add your AP as a client of your IAS and configure the shared secret between your AP and your IAS.
Use the snap-in to create a Remote Access policy.
Set up a backup IAS server if you want to enhance the survivability of your wireless network service.

IAS is now ready to process requests from the wireless network users for 802.1x authentication.

Active Directory and Authentication

Active Directory manages all objects in a "forest," and lets you apply policies at the Domain level, and at the Organizational Unit level. It is therefore a critical component in our network of Windows technologies. For our 802.1x-based method of security, you will need to apply hotfix 306260 and 304347 after you install Windows 2000 Server Domain Controller with Service Pack 2, or you can just install Service Pack 3. You are almost ready to deploy your secure wireless network.

Now you need to do the following:

Design different groups and organizational units for access from wireless networks to either intranet or Internet. For example, you might have a group name "Wintrausers" for users allowed access to your intranet, and "Winterusers" for users allowed Internet access.
Ensure every wireless network user belongs to at least one group.
Ensure every computer has a computer account.
Ensure every user account maps to the corresponding certificate.
If a user is allowed to use wireless networks, they should be granted remote access rights, an option on the Dial-in tab.

We will discuss Active Directory in more detail in Chapter 10. The only thing not yet prepared is the policy. The next section will describe what kind of policy you should set up for your wireless network users. Remember that the policy will not be useful if it does not conform to your organization's requirements.

Wireless Network Policies

If we had to make a single recommendation for whether to use the IPSec VPN or the 801.x infrastructure for a secure network, it would be to use both. Perhaps the best solution is to combine both architectures. This would mean that your wireless network would be protected at the low data link layer through 802.1x authentication, and access to your organization's intranet or Internet gateway would be strongly authenticated and encrypted at the network layer by the IPSec VPN.

Before we discuss specific policies, and before you set up your own policy, ask yourself two questions: What are the goals of these policies? and How do I enforce them? A policy without enforcement is useless.

Important Policies to Configure

In devising good network access policy, you want to make sure that you think about the "4W1H" rule: who, where, when, what, and how. You need to configure the following:

Restrict access by user or computer identity (e.g., Joe has access while Jane does not).
The domain or group the user belongs to (e.g., set up Wireless_Intranet and Wireless_Internet user groups and organizational units).
Where you want to restrict connections, the authentication services behind the firewall should only allow connections from the AP.
When the user is allowed to access resources, what access do you want your user to have: intranet only, Internet only, or both?
How do you want your network traffic to be secured: with dynamic WEP, using IPSec, or with no protection?

After you decide what restrictions you need and turn them into policy, you are ready to define them in your Active Directory.

Define Active Directory Group Policy or IAS Policy

You can define group policies in Active Directory or IAS to control various things, including

Wireless Network (802.11) configurations
IPSec policies
User accounts
Groups
Remote access rights
EAP type
Access time
Authentication methods
Encryption grade

Make sure that you design your policy well, and make use of the full capability of Windows 2000 and Windows XP. There is a new Group Policy setting in Windows .NET called Wireless Network (IEEE 802.11) Policies. You can use this to configure the wireless client settings for Windows XP computers such as 802.1x and preferred SSID networks and apply them to an entire organizational unit of your wireless computers. At the time we are writing this, a Windows .NET domain controller is necessary to create these policies and implement them through AD.

Remember to apply these Windows XP–specific GPO settings to an organizational unit that contains only Windows XP computers. (In most cases, GPOs should be separated for Windows 2000 and Windows XP computers, as described in Chapter 11.)

Tools of the Trade

In this chapter, we have discussed the many security issues of wireless networks. Let's review the tools you can use to secure and test your wireless network.

AiroPeek

WildPackets' AiroPeek (available from http://www.wildpackets.com) is a commercial sniffer for wireless networks. It uses the passive technique we spoke of earlier for identifying wireless networks.

NetStumbler

NetStumbler is a free and publicly available tool. It runs on Windows platforms. In the "Footprint the Wireless Network" section of this chapter, we talked about two different ways to identify a wireless network. NetStumbler uses the active method: sending out "probe requests" with an empty SSID, expecting the AP to respond with its SSID. You can also hook up a GPS device to the computer, and NetStumbler will be able to read the signal to associate the coordinates with the AP. There are actually a lot of people using such information to build a database of publicly accessible APs. The following illustration shows NetStumbler in action.

Figure 5: NetStumbler

.NET Wireless Monitor

Wireless Monitor is the new functionality added into the Windows .NET server beta builds we used. Hopefully, it will make it to final release. It is capable of monitoring two targets: AP and client. To monitor an AP, the wireless monitor acts like NetStumbler, and it keeps a record of APs that respond with SSIDs. The wireless monitor also catches the signal strength for your information. On the client side, the wireless monitor is capable of showing you the action your wireless network client is performing. Action here means Probe, Associate, Authenticate, and other related actions defined in the standard. It is a good tool for helping you identify problems in your wireless network. To use it, open your MMC and add the Wireless Monitor snap-in.

Checklist: Wireless Security

In this chapter, we described various wireless technologies and focused on designing secure wireless networks using either IPSec or 802.1x authentication. You can create an even better design, albeit more complicated, by combining both 802.1x and IPSec. As you know by now, the key words throughout this chapter have been authentication and encryption.

You should know what Windows XP supports in the field of wireless technologies, and stay aware of the current security problems in the IEEE 802.11b wireless network (Wi-Fi). This chapter has provided you with questions and answers for planning to work with and implement wireless technologies, as well as steps for securing Windows XP in a wireless world.

We have also illustrated two scenarios that can be used separately as secure wireless network solutions, or together for an even stronger solution. A network built on 802.1x authentication will maintain authorized access at the data link layer, while IPSec will provide even stronger authentication and encryption at the higher network layer.

Answer important planning questions before setting up a WLAN: Do you really need a wireless network? What is the purpose?
Understand Windows XP's support for wireless technologies.
Understand the current security problems of 802.11b/Wi-Fi.
Understand the types of attacks that can be made on wireless networks: active and passive, WEP, authentication, client side, and DoS.
Decide whether to use IPSec or 802.1x for client authentication (or a combination of both).
To use IPSec for wireless security, set up an IPSec gateway that connects wireless clients to the intranet with strong authentication and encryption. The gateway can be either behind the perimeter firewall or a part of it.
To use 802.1x to protect your wireless network, set up dynamic WEP with the strongest keys possible (128-bit), use Message Integrity Checksum (MIC) when available, and use client certificates for authentication. Configure the server with RADIUS and IAS for back-end authentication, and use Certificate Server for creation and management of client certifications. Use Wireless Zero Configuration for clients' wireless cards.
With either IPSec or 802.1x: Physically protect your AP. Configure your AP well, changing its SSID and default settings (SNMP strings and usernames). Secure your wireless clients (use the rest of this book to harden your Windows XP client operating systems). Separate your wireless network with a firewall between the AP and wired network—and don't allow wired intranet users to poke around at the management interfaces.
Specify policy for your wireless network: Design different groups and organizational units for access from wireless networks to either intranet or Internet. Enforce a group policy for use of IPSec and 802.1x.