Securing 802.11 Wireless Networks

Use Win2K Routing and Remote Access and PPTP or IPSec to tighten security

Wireless networking has quickly become the most exciting networking technology of this decade. No longer limited to propeller heads and weekend data warriors, wireless networks have hit the mainstream. Anyone who's explored wireless security features, though, knows how little security such networks inherently provide. Frequent warnings and white papers demonstrate the security weaknesses in the Wired Equivalent Privacy (WEP) standard, which is a part of the 802.11b and 802.1x wireless LAN (WLAN) protocols. Yet many administrators assume that their wireless network signal is too remote or too contained (e.g., within a building) to be open to attack. However, resources such as NetStumbler.com (http://www.netstumbler.com) and Peter Shipley's "Open WLANS" presentation (http://www.dis.org/filez/openlans.pdf) give accounts of accessing thousands of wireless Access Points (APs) while war driving (i.e., automatically scanning for wireless networks while driving through an area).

The 802.11b wireless standard (the most popular and most widely available standard) has two general configuration settings that don't provide the protection some administrators think they do. First, systems administrators sometimes have the mistaken impression that Service Set Identifiers (SSIDs) relate to security. SSIDs aren't security related, although you can use them to administratively segregate wireless users into smaller, more logical networks. SSIDs aren't meant to be kept secret or private, hence using them won't contribute to the security of your wireless network. To facilitate connections by users, OSs such as Windows XP report all the SSIDs they find. Second, many administrators use WEP keys to configure rudimentary wireless encryption. These keys come in two sizes: 40-bit and 128-bit. (For information about WEP encryption, read Eric Janszen's article "Understanding Basic WLAN Security Issues" at http://www.80211planet.com/columns/article/0,,1781_937241,00.html.) Obviously, the 128-bit key is the stronger choice, but WEP has substantial weaknesses, so I suggest that you instead rely on a VPN tunnel to provide all the encryption you need. This solution works well in a Windows 2000 network.

Three Models of Connectivity
You have three models that build on each other to provide wireless network connectivity in a Win2K network. First, you can use the Internet Connection Sharing (ICS) service and create a DHCP scope on a Win2K server to set up a basic wireless gateway. To secure wireless traffic and provide minimal encryption protection, the second model adds Win2K's Routing and Remote Access service and PPTP to the first model. To take advantage of the strongest security commercially available today, the third model replaces PPTP with IP Security (IPSec) as an encryption option.

In the first and simplest model, you connect your AP to a Win2K computer running the ICS service. (For more information about ICS, see "Related Articles in Previous Issues" at http://www.winnetmag.com, InstantDoc ID 24873.) You install the DHCP service and create a DHCP scope for your wireless clients, then run the ICS Wizard on the Internet-facing computer. The result is a wireless Internet gateway for your users (and anyone else within a short distance of your AP).

However, this model provides no security to your wired network or wireless clients. To secure your new wireless connection, you need to make a few changes to your environment, such as installing a VPN server and adding encryption. You want to make sure that any data transmitted across your wireless networks remains confidential and that would-be intruders can't arbitrarily connect to your network or observe the data you're passing.

The second model uses PPTP to encrypt your wireless data. Using the 128-bit Microsoft Point-to-Point Encryption (MPPE) that comes with Win2K's Routing and Remote Access implementation might be ample protection for your network. Encrypting data with 128-bit MPPE inside a Generic Routing Encapsulation (GRE) tunnel provides enough protection to stop the casual or unskilled war driver. However, MPPE doesn't provide mutual authentication of client and server or the strong 168-bit Triple DES (3DES) encryption that you get through Microsoft's implementation of IPSec over Layer Two Tunneling Protocol (L2TP).

The majority of security researchers agree that IPSec currently offers the best protection for wireless encryption. Therefore, the third (and most secure) model uses IPSec rather than PPTP.

To set up a wireless network that uses IPSec, you first need to plan a stub network (i.e., a child network that uses a subset of the parent network's IP addresses but is segregated from the parent network by a router or gateway device) and set up DHCP and Routing and Remote Access. You need the stub network to give clients a means to connect to your wireless network. The wireless clients can use a statically assigned IP address to attach to one of your wireless network's APs; to assign addresses dynamically, you can offer a DHCP service in the stub network. The only resource available to clients on the wireless network is a Routing and Remote Access server. Any wireless clients that want access to your internal network must first connect, encrypt, and authenticate, similar to any Routing and Remote Access client that connects from across the Internet.

To provide an example of this type of implementation, I set up a simple wireless AP (Cisco Systems' Cisco Aironet AP4800) in its default configuration, then I set up an SSID for wireless-segmentation purposes. The device's default SSID was TSUNAMI; I set my SSID to JONES. I connected the AP by crossover Ethernet cable to the Routing and Remote Access server, which I used as my VPN server. This system was a Compaq Pentium III 650MHz machine running Win2K with Service Pack 2 (SP2) with the DHCP service and all available security patches. The server had a second Ethernet connection to an intranet, which also provided Internet connectivity through the default gateway. My wireless clients ran XP, build 2600 with all available security updates. These clients used a variety of wireless access cards, including Cisco Systems' Aironet 350 and Aironet 340, Compaq's WL100, and Dell's PC Card­based TrueMobile 1100 series. I gave each of my clients a statically assigned IP address in the stub 10.1.1.x network, but I could have let each client run the DHCP client to allow automatic IP address assignment in the 169.254.x.x network. (If you prefer to do so, replace the 10.1.1.x addresses in this article with addresses in 169.254.x.x.) Figure 1 shows the server, wireless AP, and stub network (i.e., 10.1.1.x). The Routing and Remote Access server prevents any unauthenticated entry into your network.

To simplify this demonstration, I didn't install Active Directory (AD). If your network is AD-enabled, you can use Group Policy and Win2K Certificate Services to provide even greater protection. (Users must possess a valid certificate, in addition to a username and password, before they can connect to the network.) Using DHCP has significant implications and creates additional complications in an AD-enabled network. For more information about DHCP and AD, see "Related Articles in Previous Issues."

I caution you: Set up a test wireless network to thoroughly work out any kinks, minimize potential risk, and ensure that encryption works properly before you put this plan into action in your production environment. Before you begin, be sure to look for any existing wireless infrastructures (e.g., wireless APs) that might already be running at your site. Many wireless manufacturers include simple site-survey tools with their wireless card and AP installation disks. You can use these utilities to determine whether any existing wireless infrastructures are operating in the area.

Setting Up the DHCP Server
To create your wireless network, you first need to set up the DHCP service on the Routing and Remote Access server. Select DHCP under Administrative Tools to open the Microsoft Management Console (MMC) DHCP snap-in. To configure a scope for your wireless clients, right-click the server object in the console's left-hand pane, then select New Scope from the context menu to launch the New Scope Wizard. Click Next to move past the introductory screen. Provide a name for your scope; I suggest a descriptive name such as Trusted Wireless Clients. Click Next.

The wizard prompts you to define an IP address range. Most APs can't handle more than a couple dozen simultaneous clients, so assigning a full class C to one AP is a little wasteful. I used 192.168.0.33 through 192.168.0.46 and a subnet mask of 255.255.255.0. Enter the appropriate starting and ending IP addresses for your network, along with a length or subnet mask, then click Next.

On the wizard's Add Exclusions screen, add any IP address ranges that you want to exclude. Click Next. The wizard's Lease Duration screen offers a default lease time of 8 days. However, wireless users—who frequently are mobile users—rarely need to lease an address for that long. I suggest a starting lease time of 30 minutes. If you find yourself running out of addresses, you can shorten the lease time. Make the appropriate selection, then click Next.

In the Configure DHCP Options screen, accept the default answer of Yes, I want to configure these options now, then click Next. In the Router (Default Gateway) screen, the wizard prompts you to supply the default gateway that your wireless clients will use. In my sample network, 192.168.0.1 was the default gateway. Enter the appropriate default gateway for your network, click Add, then click Next.

In the Domain Name and DNS Servers screen's IP Address field, enter the appropriate DNS server IP addresses for your network. (I also pointed my wireless clients to my default gateway to resolve DNS names, so I specified 192.168.0.1.) Click Add after you enter each address. You can use the Up and Down buttons to adjust the servers' preference order. Click Next after you've added and prioritized all the addresses.

You don't need WINS in your test wireless network, but some of your wireless clients might run applications that require it. If so, enter your WINS server IP addresses on the WINS Servers screen, using the same method you used to enter the DNS server IP addresses. Use the Up and Down buttons to adjust the WINS server order according to your preferences. Click Next when you've finished entering all your WINS Servers.

The wizard then asks whether you want to activate the scope. You must activate the scope to serve clients with IP addresses from your scope. Accept the default Yes, I want to activate this scope now, then click Next. Click Finish to close the wizard. You can assign IP addresses to your wireless clients almost immediately, but you still need to set up your Routing and Remote Access server to properly encrypt, authenticate, and route your Internet traffic.

Setting Up the Routing and Remote Access (VPN) Server
After you use the next wizard, you won't be able to ping the external interface of the VPN server. Therefore, if you need to test for connectivity through your wireless infrastructure, you need to do so before completing the next step.

Select Routing and Remote Access under Administrative Tools to open the MMC Routing and Remote Access snap-in. Right-click the server object, then select Configure and Enable Routing and Remote Access from the context menu to launch the Routing and Remote Access Server Setup Wizard. Click Next to proceed to the Common Configurations screen, select the Virtual private network (VPN) server option, then click Next. Click Next to accept the default protocol of TCP/IP.

In the Internet Connection screen, you must make an important distinction. When you add wireless capabilities to your network, you make a dramatic change to the perimeter. Therefore, you need to take as many precautions with wireless users as you do with users who connect over the Internet. As Figure 1 shows, any wireless clients (including untrusted ones) can connect to the 10.1.1.x network. Therefore, your VPN server's external interface should be connected to the 10.1.1.x network. So in effect, your new Internet (untrusted client) connection is on the 10.1.1.x network. Select the adapter that connects to this network, then click Next. Note that the wireless clients in my sample setup have statically assigned IP addresses. If you need DHCP support for external clients, you need to add additional DHCP scopes or a second DHCP server for the network.

In the IP Address assignment screen, accept the default to automatically assign IP addresses to clients, then click Next. In the Managing Multiple Remote Access Servers screen, accept the default answer of No, I don't want to set up this server to use RADIUS now, then click Next. Click Finish to prompt the wizard to complete configuration of the VPN server. Click OK to acknowledge the warning regarding DHCP relay. The new Routing and Remote Access server starts, and the server's icon in the Routing and Remote Access console turns from red to green.

You now have a functional Routing and Remote Access server that uses PPTP for your wireless network. This server provides your wireless clients a minimal level of encryption and reasonable assurance that your data is secure. If 128-bit MPPE encryption is satisfactory in your environment, you can stop here: Your network is already more secure than wireless networks that depend solely on WEP encryption. (And if your wireless clients include Pocket PCs and Windows CE­based devices, PPTP is currently the only supported protocol for those devices.) To verify that your wireless traffic is indeed encrypted with MPPE, install the Network Monitor tool as the sidebar "Monitoring Encrypted Traffic," page 28, describes.

The ultimate goal, however, is to move from MPPE running over PPTP to an IPSec over L2TP solution that uses 3DES. To do so, you need to configure a few more settings.

Setting Up IPSec over L2TP
To communicate securely using IPSec, you need to create a set of policies (i.e., a predetermined set of agreements) to let you securely create a communications channel (aka a security association). Because this article discusses a configuration that doesn't involve a domain controller (DC) or AD, you can set up your IPSec policies through the MMC Local Security Policy snap-in. Before you begin this part of the configuration, be aware that because I assume that you're working in a non-AD environment and your clients could be members of any domain, your authentication options are limited to Win2K Certificate Services­issued certificates and a preshared key (i.e., a shared secret key known only to the VPN server and the wireless client). However, because preshared keys are the least attractive (and least secure) of the options for establishing IPSec communications, I describe the use of certificates. (For more information about IPSec, see "Related Articles in Previous Issues.)

Select Local Security Policy under Administrative Tools to open the MMC Local Security Settings console. In the console's left-hand pane, right-click IP Security Policies on Local Machine. Select Create IP Security Policy from the context menu to launch the IP Security Policy Wizard. Click Next, then give the policy a descriptive name such as WLAN Security Policy. Click Next, then clear the Activate the default response rule check box. (You're creating a specific rule for wireless clients, so that rule won't be suitable as a default rule for all IPSec clients.) Click Next, then click Finish to open the Properties dialog box for your security policy. Confirm that the Use Add Wizard check box (in the dialog box's lower right corner) is selected. Click Add to launch the Create IP Security Rule Wizard.

The Create IP Security Rule Wizard helps you configure the IPSec filters that your VPN traffic must pass through. Click Next three times to get to the Authentication Method screen, which offers three authentication options: Kerberos, certificates, and preshared key.

The safest method of securing IPSec (and the one I describe) uses certificates issued by Win2K Certificate Services running a standalone or enterprise Certificate Authority (CA) policy. Unless you already run an internal certificate infrastructure, this method adds an entirely new management element to your wireless clients. For more information about setting up your own CA and using certificates, see Ken Spencer, "Using Win2K Certificate Services to Configure a Standalone CA, Part 1" (http://www.secadministrator.com, InstantDoc ID 23373) and "Using Win2K Certificate Services to Configure a Standalone CA, Part 2" (http://www.secadministrator.com, InstantDoc ID 23654). You'll need to issue machine certificates (rather than user certificates) to your clients and your VPN server—a task I assume you've already completed. From that point forward, new wireless clients will need to acquire a machine certificate through the Certificate Services Web interface before joining your WLAN. For maximum security, keep the Web server that hosts this interface on your intranet.

In the Create IP Security Rule Wizard's Authentication Method screen, select the Use a certificate from this Certificate Authority (CA) option. Click Browse to see a list of trusted CAs, select the appropriate one, then click OK.

In the IP Filter List screen, specify the IP addresses, ports, and protocols that can use your IPSec policy. Click Add to open the IP Filter List dialog box. Give the filter a descriptive name, such as WLAN Filter. Make sure that the Use Add Wizard check box is selected. Click Add to launch the IP Filter Wizard.

Click Next twice. In the IP Traffic Destination screen, select A specific IP Subnet from the drop-down box. Enter the IP address and subnet mask that best represent your WLAN. This range should include the IP addresses you assigned to your wireless clients, rather than the available address pool that you supplied to the DHCP server. (I used an IP address of 10.1.1.32 and a subnet mask of 255.255.255.224 to permit clients from 10.1.1.33 through 10.1.1.62 to use this rule.) Click Next twice, click Finish, then click Close. The IP Filter List screen now shows your new IP filter (e.g., WLAN Filter). Select the filter, then click Next. In the filter Action screen, click Add to launch the IP Security Filter Action Wizard.

Click Next to pass through the wizard's introductory screen. Provide a descriptive name, such as WLAN IP Sec Filter Action, for the filter action. Click Next. In the Filter Actions General Options screen, ensure that the Negotiate Security check box is selected, then click Next twice. In the IP Sec Security screen, click Next. In the IP Traffic Security screen, choose Custom, then click Settings to open the Custom Security Method Settings dialog box. Note that the encryption algorithm is set to DES. If you're licensed to use 3DES and want this higher level of encryption, select 3DES from the Encryption Algorithm drop-down box. (Data Encryption Standard—DES—is a 56-bit algorithm, whereas 3DES offers higher 168-bit encryption.) After you select your encryption algorithm, select both check boxes under Session Key Settings, then click OK to close the dialog box. Click Next, then click Finish to close the IP Security Filter Action Wizard.

Select the new filter action (e.g., WLAN IP Sec Filter Action), then click Next. Ensure that the Edit Properties check box is cleared, then click Finish. Click Close to close the Security Policy Wizard. Congratulations, you've configured your first IPSec policy.

The final step is to assign the new policy to your wireless clients. Right-click the policy (e.g., WLAN Security Policy) in the Local Security Settings console's right-hand pane, then select Assign. Note that after you assign the policy, the Policy Assigned column specifies Yes and the policy object's icon displays a green mark.

Setting Up the VPN Client
You can now configure your VPN clients to point to your Routing and Remote Access server and to use IPSec encryption. On an XP client, such as the one I used, select Start, Connect To, Show All Connections. Click Create a New Connection to open the New Connection Wizard. Click Next. Select the Connect to the network at my workplace option, then click Next. Select the Virtual Private Network Connection option, then click Next. Provide a descriptive Company Name, such as WLAN Network. Click Next. Select the Do not dial the initial connection option. In the VPN Server selection screen, enter the external IP address of the VPN server (e.g., 10.1.1.1). Click Next. If you don't want the client to share this connection with other users, accept the default, My Use Only. Click Next, then click Finish to complete the connection setup and to automatically open the Connect WLAN Network dialog box.

In this dialog box, enter the appropriate network credentials, then click Properties and go to the Properties dialog box's Security tab. Select Advanced (custom settings), then click Settings. Under Logon Security, select Use Extensible Authentication Protocol (EAP). Ensure that Smart Card or Other Certificate is selected from the drop-down list, then click Properties. In the resulting dialog box, open the drop-down box for the trusted root certificate authority. Select the root CA of the certificate infrastructure that you'll use for wireless clients. Also select Use a certificate on this computer. Click OK twice to close the dialog boxes.

Go to the Networking tab. In the Type of VPN drop-down box, select the appropriate protocol (i.e., PPTP or L2TP over IPSec). Click OK to return to the Connect WLAN Network dialog box, then click Connect to make a VPN connection. After you've connected, use Network Monitor again (see "Monitoring Encrypted Traffic") to ensure that traffic is indeed encrypted.

Feel Safer
I've shown you how to use currently available technology to create a safe environment for your wireless clients. Your end users' experience will vary greatly depending on your geography, architecture, distance from the APs, number of users, and other wireless installations that might be present. But by using this architecture, you can feel safer about deploying wireless networking in your environment.