Wireless LANs (WLANs) offer amazing flexibility and ease of use. WLANs let users move from office to conference room while keeping their laptops connected to the corporate IP-based network. These benefits come with a price, however. Current WLAN security standards are flawed, so many administrators must find alternative ways to secure their WLANS. Many security organizations and consultants recommend the use of VPNs to secure WLAN installations, but VPNs can be costly to deploy correctly and can create bottlenecks in your infrastructure. An easier and less expensive alternative exists—IP Security (IPSec) policies. If you administer or are planning to deploy a Windows 2000 WLAN, you can use IPSec and Win2K Group Policy to provide security without the added cost and potential bottlenecks of a VPN. (See the Web- exclusive sidebar "Alternative Means of Securing WLAN Traffic," http://secad ministrator.com, InstantDoc ID 23443, to determine whether IPSec is right for your WLAN environment.)
The Flaws in WLAN Standards
The most cited concerns about WLANs are unauthorized wireless stations' (i.e., wireless-enabled systems) ability to eavesdrop on traffic between legitimate stations and Access Points (APs) and the stations' ability to connect to the WLAN and send and receive data. The WLAN technologies that most corporate environments currently use conform to the IEEE 802.11 and 802.11b standards (which define how wireless NICs communicate with APs to establish and maintain a network) and to the Wired Equivalent Privacy (WEP) protocol. WEP uses the RC4 algorithm to encrypt and secure packets between stations and APs and prevent unauthorized stations from joining the WLAN. To provide additional security, many WLAN equipment vendors let you maintain a list of the legitimate station hardware media access control (MAC) addresses that can join your WLAN. However, researchers have investigated WEP's ability to secure WLAN communications and have found it lacking. (For information about WEP's flaws, see "Security of the WEP algorithm" at http://www.isaac.cs .berkeley.edu/isaac/wep-faq.html, and Mark Joseph Edwards' Security UPDATE article "802.11 Wireless Networks: Is Yours Really Safe?" http:// www.secadministrator.com, InstantDoc ID 22147.) Therefore, you might need an additional way to secure your WLAN—and implementing IPSec is a quick and effective method.
Preparing Your WLAN for IPSec
To ease the process of configuring IPSec and administering WLAN security, follow a few guidelines for the physical and logical organization of your Win2K WLAN. The purpose is to separate your systems so that you can use Group Policy to distribute and maintain IPSec policies instead of configuring each system manually.
- Dedicate IP subnets for your wireless stations.
- Dedicate a separate subnet or subnets for the servers in your network.
- For each domain that contains wireless stations, create an organizational unit (OU) in Active Directory (AD), then place the stations' Computer accounts into the OU.
- For each domain that contains servers with which the stations will connect, create an OU, then place the servers' Computer accounts into the OU. You might want to create an OU hierarchy (e.g., create second-level OUs to separate file and print servers, application and database servers, and domain controllers—DCs) to further categorize each domain's servers.
After you complete these steps, you need to create IPSec policies for your wireless stations and the servers with which those stations need to communicate. You must craft these policies to guarantee encrypted communications between the stations and servers. The simplest way to do so is to create a station policy that responds to requests for secure communications and a server policy that identifies the wireless stations' subnet.
Creating a Station Policy
Create the station policy first, especially if you plan to apply the server policy to your DCs. Otherwise, the server policy will prevent the DCs from communicating with the stations, and you won't be able to use Group Policy to distribute the station policy.
To create the station policy, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and select the OU that contains the stations' Computer accounts. Right-click the OU, select Properties from the context menu, then go to the Properties dialog box's Group Policy tab. You can modify an existing Group Policy Object (GPO), but I recommend you create a new one. After you do so, the Group Policy window, which Figure 1 shows, opens automatically.
Expand Computer Configuration, Windows Settings, Security Settings, and select the IP Security Policies on Active Directory object. This object contains three default IPSec policies. Microsoft recommends that you create a policy rather than modify one of these default policies. To create your station IPSec policy, right-click the IP Security Policies on Active Directory object (or right-click anywhere in the console's right-hand pane), then select Create IP Security Policy from the context menu. This action launches the IP Security Policy Wizard; click Next. The wizard's first step prompts you to name the new policy and provide a description for it. Figure 2 shows a sample name and description. Click Next.
The wizard's next step prompts you to specify whether you want the policy to respond to requests to secure communications. Select the Activate the default response rule check box to configure the stations to respond to, but not initiate, such requests. Click Next.
The next screen, which Figure 3, page 10, shows, prompts you to specify the rule's initial authentication method: Kerberos, a certificate, or a preshared key. (For an explanation of IPSec's authentication process, see the Web-exclusive sidebar "Using IPSec to Secure Communications," InstantDoc ID 23446.) Kerberos is the default method and will work for most organizations. Kerberos won't work when your stations need to communicate with Win2K servers on domains with which no trust relationship has been established, or when you want your stations to communicate with servers running other OSs, such as FreeBSD or Sun Microsystems' Solaris. If your servers run a mix of Win2K and other OSs, select Kerberos—you can add alternative authentication methods later. Click Next to advance to the final screen, which confirms that you've created the policy. You need to edit your new policy to ensure secure communications, so confirm that the Edit properties check box is selected before you click Finish.
When you click Finish, the new station policy's Properties dialog box opens automatically. Go to the Security Methods tab, select the sole entry (for Default Response) in the IP Security Rules section, then click Edit to open the Edit Rule Properties dialog box. I suggest you remove the final four entries and keep only the two entries that list 3DES in the ESP Confidentiality column. (To remove an entry, select it and click Remove, then click Yes when prompted to confirm your action.) Next, go to the Connection Type tab and select Local Area Network (LAN). If you run a mix of OSs and need to add alternative authentication methods, go to the Authentication Methods tab and select the option to use certificates or the option to use preshared keys, enter the required information, then click OK. To save and close the policy, click OK, then click Close in the Edit Rule Properties dialog box.
The policy now appears in the right pane of the Group Policy console but doesn't go into force until you assign it. To do so, right-click the policy, then select Assign from the context menu. Win2K will apply the policy to the stations during the next Group Policy refresh.
Creating a Server Policy
Your next step is to create your server policy. Open the Active Directory Users and Computers snap-in and select the OU that contains the servers' Computer accounts. (If you created more than one OU for this purpose, repeat the following process for each OU.) Open the OU's Properties dialog box and go to the Group Policy tab. Create a new GPO to contain the server IPSec policy.
Follow the steps I described earlier to launch the IP Security Policy Wizard. Step through the wizard, naming this new policy to reflect that it applies to your servers. Because you're applying this rule to your Win2K servers, accept the wizard's default Kerberos authentication method. Complete the wizard (ensure that the Edit properties check box is selected on the final screen).
The new server policy's Properties dialog box opens automatically. This time, you'll use the dialog box to specify new rules for communicating with wireless stations. Click Add to launch the Security Rule Wizard, which guides you through the creation of a new rule. First, the wizard asks whether the rule is for a tunnel. Select the This rule does not specify a tunnel option and click Next. The wizard then asks which connections this rule will apply to. Select the Local Area Network (LAN) option and click Next. When the wizard prompts you to specify the type of authentication, accept the Kerberos default and click Next.
The wizard then prompts you to select or add an IP filter. The IP filter list, which Figure 4 shows, can contain several entries, depending on whether you've configured or used IPSec in the past. (For information about how IPSec uses IP filters, see the Web-exclusive sidebar "Using IPSec to Secure Communications.") Click Add to open the IP Filter List dialog box and create a new filter. Enter a name and a description for the new filter. (I recommend you clearly identify the filter as being for WLAN communications so that you can identify it easily if you need to edit it or create new filters in the future.) Click Add to launch the IP Filter Wizard, which you use to build a filter rule that will apply to traffic to or from your wireless stations.
The IP Filter Wizard first prompts you to select the source IP address. Select My IP Address from the drop-down list, then click Next. The next screen prompts you to select the destination IP address. Select A specific IP Subnet from the drop-down list; two edit controls appear. Enter the IP address of the subnet on which you placed your wireless stations, then enter the Subnet mask, then click Next. The wizard next prompts you to specify which IP protocols to secure. Accept the default of Any to secure all communications between your servers and stations. Click Next, then click Finish on the wizard's final screen.
Your new filter rule appears in the IP Filter List dialog box, which Figure 5 shows. Click Close to return to the Security Rule Wizard's IP Filter List screen, select the new IP filter list, then click Next. The wizard prompts you to specify which actions should occur when your rule fires. This screen displays at least three options (possibly more if you've configured IPSec previously). Select Require Security. Click Next to proceed to the Security Rule Wizard's final screen. Ensure that the Edit properties check box is selected, then click Finish.
The New Rule Properties dialog box opens automatically. Go to the Connection Type tab, select Local area network (LAN), then click OK. This action returns you to your server policy's Properties dialog box. Click Close to save the policy, then apply the policy as I described earlier. After Group Policy is refreshed and the new IPSec policy applied to your servers, your WLAN communications will be secured.
Troubleshooting IPSec can be difficult. If you can't establish communication between a wireless station and a server, first determine whether each end system can communicate with other systems to which your IPSec rules apply and with systems to which the rules don't apply. If only one system appears to have problems, check the obvious causes (e.g., network connection, router, switch, hub, NIC).
If you still can't pinpoint the problem, you can use Win2K's IPSec Monitor (ipsecmon.exe) utility to determine whether the systems have established a Phase II security association (SA—see the Web-exclusive sidebar "Using IPSec to Secure Communications" for information about Phase II SAs). If not, and if the affected systems can communicate with systems that don't require IPSec, the problem probably lies with a Group Policy or an IPSec policy on one of the end systems. You can use Win2K Server's Network Monitor to confirm IPSec negotiation between the end systems. If the end systems negotiate but the negotiation ultimately fails, examine your policies in detail and look for any mistakes (e.g., typing errors) you might have made during their creation. (When you use Network Monitor, you might be surprised to see some unencrypted traffic between your end systems. For information about this traffic, see the Web-exclusive sidebar "Communications That IPSec Doesn't Secure," InstantDoc ID 23447.)
Another common problem occurs when Win2K fails to distribute your station policy to a wireless system before that system attempts to communicate with a server. If you require your DCs to establish secure communications with wireless stations, and if Win2K applied that policy to the DCs before completely distributing the station policy to all your stations, then the stations can't obtain the station policy. In this case, you need to create the policy manually on the wireless station to bootstrap the process. If you didn't apply the server policy to your DCs, check Group Policy to make sure that IPSec policy processing hasn't been disabled, and explicitly enable such processing if necessary. (To enable processing, open the GPO you created to hold the server IPSec policy, then click Edit. In the Group Policy window, drill down to Computer Configuration, Administrative Templates, System, Group Policy. Select and right-click IP Security policy processing in the right pane. Select Properties from the context menu, then go to the Properties dialog box's Policy tab. Select the Enabled option.) You can also review each station's Application log to ensure that the GPO has been applied.
The Future of WLAN Security
The 802.1x standard, which is currently in development, eventually will replace WEP to secure LANs and WLANs. Microsoft has implemented the draft standard in Windows XP and will follow the standard in upcoming Windows .NET Server and other future OS releases. Until 802.1x is ratified and widely implemented, though, you can rely on IPSec to secure your WLANs.