Access Denied: Securing Crucial Servers in a WLAN Environment

For wireless networks in which it isn't possible to use typical wireless security technologies (e.g., a shared Wired Equivalent Privacy—WEP—standard passphrase, 802.1x, Wi-Fi Protected Access—WPA), what other options can we use to secure the information stored on a few crucial servers? Our company decided to roll out Wi-Fi, the 802.11b wireless standard, throughout our offices without any security to keep things simple for the many clients and freelancers that work on site with us at any given time. For the most part, we all just use the wireless LAN (WLAN) to access a Web-based collaboration tool that provides encryption through Secure Sockets Layer (SSL). However, we're concerned about one server that hosts our accounting system, human resources (HR) information, and other proprietary information. How can we protect this server so that only employees can access it and traffic with the server is encrypted?

There are four ways to set up your network—ranging from the sophisticated and complex to a more simple approach. The first and most sophisticated way to provide unauthenticated and unencrypted wireless Internet access to your business partners and authenticated, encrypted wireless access to your internal network to your employees is ruled out in your question, but I include it for comparison purposes. The method is to implement Access Points (APs) that support 802.1x and Virtual LANs (VLANs). You would set up a Windows Server 2003 Internet Authentication Service (IAS) server with two remote access polices—one for your employees that requires authentication and encryption and the other for your business partners that lets them connect without any restrictions but then confines them to a special visitor VLAN. This visitor VLAN would limit them to accessing the Internet through your firewall and prevent access to other computers on your internal network. For more information about using VLANs with wireless networks, see "Wireless access example" at http://www.microsoft.com/resources/documentation/windowsserv/2003/enterprise/proddocs/en-us/default.asp?url=/resources/documentation/windowsserv/2003/enterprise/proddocs/en-us/sag_rap_scen_wap.asp.

A variation on option one is to use IP filtering instead of a VLAN. The visitor remote access policy would specify an IP filter to the AP that would limit visitors to just your firewall and keep them from accessing other computers on your wired LAN. The advantage of IP filters is that they don't require a VLAN-compliant switch. But chances are that if you've already purchased low-end APs, they don't support VLANs or IP filtering, so let's look at the second option.

Option two is to use VPN technology to provide employees with secure wireless access. In this case, you would put all your APs on a second wired network connected to your firewall and an internal VPN server. Your visitors would simply connect to your WLAN and access the Internet. To access your internal servers, your employees would have to establish a VPN connection to the internal VPN server, which would provide authenticated and encrypted access to your internal servers. Any clients plugged into the internal wired LAN would have direct access to the internal servers. The disadvantages to this approach are that your wireless employees must remember to establish a VPN connection and you must run a separate wired network for your APs, which might or might not be problematic, depending on how many APs you have and how difficult it is to run additional cables in your buildings.

The third option leverages Windows IP Security (IPSec) support and eliminates the need for a separate wired LAN for your APs. In this case, you simply deploy your APs anywhere you need to on your current wired LAN and let your visitors connect to and access the Internet. However, on your servers, you deploy an IP security policy that requires Encapsulating Security Payload (ESP)­level IPSec security from any wireless client trying to connect. Setting up such a policy that distinguishes between wired and wireless clients is simple if you can manage to assign IP addresses to your wireless clients from a different range than those assigned to your wired clients. Check whether you can configure your APs as DHCP servers and whether you can configure them to ignore DHCP clients on the wired LAN and lease addresses only to wireless clients. If you can't arrange a way to distinguish wired clients from wireless clients by their DHCP server­assigned IP address, you have two workarounds. First, if you have few wired clients, you could configure them with static IP addresses from a range that your servers would recognize as wired—thereby preventing the servers from negotiating ESP IPSec security for those (wired) clients. Second, you could drop trying to distinguish between wired and wireless clients and configure your servers to require ESP security from all clients. The latter workaround would actually yield better security because requiring ESP for all connections would protect the servers from visitors that plug into your wired internal network or an attacker who tries to pose as a wired client by using a static IP address.

The fourth option would be to set up two WLANs—one for your employees and one for your visitors. The APs for the employee WLAN would be connected to your current wired LAN, and the APs for your visitors would reside on a separate wired LAN connected to your firewall.

Notice that in options two and four, you would either need to implement a router directly behind your firewall to aggregate Internet traffic from your two wired LANs, or your firewall would need to have two internal network interfaces, one for your internal wired LAN and one for your visitor LAN. Option one with a VLAN would carry the same caveat, but option one with IP filters would not.

All in all, I prefer option one with IP filters or option three with your servers requiring ESP for all client connections. Both options offer good security without any wiring changes. Option one requires higher-end APs and an IAS server but doesn't require any configuration to your clients or servers. Option two lets you use low-end APs and doesn't require an IAS server, but it does require you to configure your servers and clients with an IP security policy (you can, however, deploy IP security policies centrally via Group Policy). Option four requires more APs, a router, and more wiring.