The Wireless Jail

While there are many mechanisms available to secure wireless networks, numerous vulnerabilities have made those mechanisms obsolescent. This section serves to outline one popular method, termed the "wireless jail," to secure a wireless LAN, while pointing out that vulnerabilities still exist, even with diligence in designing the wireless LAN.

In many cases, an enterprise deploys wireless LAN equipment directly on the enterprise LAN infrastructure. Typically, the wireless bridges are connected directly to the core -switching infrastructure. This method assumes wireless users can/should be trusted. However, many tools exist today (which we have already discussed) that allow attackers to capture wireless network SSIDs and in many cases to attack and defeat wireless encryption keys. These tools can brute-force attack WEP, EAP, and a variety of other wireless encryption mechanisms.

Administrators should assume wireless users cannot be trusted, and instead deploy wireless access points outside the firewall of the enterprise LAN, subsequently creating a wireless jail. The goal of the jail is to make it easy for wireless clients to access the wireless network, but harden this network in such a way as to make this layer-2 access insufficient for accessing any of the organization's resources. Therefore, accessing the wireless LAN is merely a prerequisite to utilizing more sophisticated and secure methods of access to organizational resources. Once layer-2 access has been achieved (gaining wireless LAN access), the only options available to the client on the wireless LAN should be as follows :

• Finding the address of the organization's virtual private network (VPN) concentrator

• Routing to the VPN concentrator

• Securely authenticating to the VPN concentrator

• Establishing a VPN tunneling protocol allowing the client access to the organization's internal networks over an encrypted channel

The wireless jail described above may be easily constructed using the following steps:

1. Deploy wireless access points on an untrusted ethernet segment/VLAN and IP network block (using RFC 1918 or routed Internet addresses) outside the organization's firewalls (between the firewall and the Internet border router, for example).

2. Configure an SSID but do not broadcast the SSID (requiring wireless users to at least know the SSID before connecting).

   Tip 

   Attackers can find the SSID with freely available tools as discussed earlier in the chapter. Therefore, you may wish to broadcast the SSID anyway for interoperability with various wireless cards and for convenience.

3. Configure the wireless access point to assign wireless clients IP addresses (from inside the jail segment) and DNS servers.

4. These DNS servers should be either located directly inside the jail, thereby unable to perform recursive queries, or they must be configured and routed in such a way as to deny recursive queries and essentially only respond to requests for the address record of an organization's VPN concentrator. This is convenient so that wireless clients may enter the name of their VPN concentrator instead of its IP address.

   Tip 

   By configuring wireless clients with the IP address (instead of a hostname or fully qualified domain name) of their VPN concentrator, the need for jailed DNS servers may be eliminated.

5. Create security policies for the jail's IP address block on the border router, switch, or the organization's firewall, preventing clients inside the jail from routing to the global Internet or to the internal networks of the organization. The organization's firewall should deny access to any request originating from the jail other than PPTP, L2TP, or IPSec protocols and other necessary protocols such as GRE, AH, and ESP.

The following illustration depicts the untrusted user in the wireless jail. Access is blocked to both the Internet (through the border router) and the corporate LAN (through the firewall). The only way a user can access the Internet or corporate LAN is to authenticate to the firewall and/or VPN concentrator and establish an encrypted VPN tunnel.

The next step provides the authentication and encryption mechanism (PPTP or IPSec tunnel) whereby the user gains full access to the Internet and corporate LAN.

At this point, one might assume the wireless LAN is completely secure; however, there is still one significant and easily overlooked vulnerability apparent to educated attackers.

Remember that the wireless users are assigned an IP address once they connect to the wireless access point. Granted, the clients are assigned a new address once a tunnel has been negotiated using secure VPN mechanisms. However, the primary address is still active on the network interface and because of the nature of Ethernet it may still be used. Many a network engineer would argue that if the VPN concentrator delivers a default route to the wireless client, all traffic will route through the concentrator, but we would ask them to keep in mind that a "connected" network is always given a lower (more specific) routing metric. This means that, on Ethernet, connected networks route without consideration being given to the default route. Therefore, this presents two technical vulnerabilities:

• Wireless clients that have not yet authenticated to the organization's VPN concentrator are vulnerable to attack from other wireless clients in the jail.

• Wireless clients that have already established a tunnel to the organization's VPN concentrator are vulnerable to attack from other wireless clients in the jail, potentially risking the entire organization protected on the other side of the VPN concentrator.

An attacker could port-scan the wireless users to find vulnerabilities on their systems, then attack those systems, and potentially propagate worms or Trojan programs through that system. Given that a legitimate user is now authenticated and authorized to access the corporate LAN behind the firewall, this potentially opens the corporate LAN to further attack through this trusted system.

The most obvious form of attack would be some sort of propagating worm. To describe a real-world attack: a wireless client that has been configured perfectly and has securely established a connection through the jail into an organization's VPN concentrator may then be attacked (using a worm) by a random client also attached to the wireless jail (not necessarily a legitimate user). Then, the authenticated client may spread the worm throughout the organization's internal networkall within a matter of seconds.

The illustration at right depicts the wireless jail with an authorized user being attacked from within the wireless jail.

While the wireless jail might seem like a completely secure wireless security method, due to the requirement of encrypted tunnels for access to the corporate LAN, this section demonstrates attacks are still possible due to the nature of IP addressing and IP routing.

There are some obvious solutions to the vulnerabilities discussed herein:

• Configure access points to echo (forward) only specifically required traffic instead of acting as a general Ethernet switch. DNS, DHCP, and VPN protocols are the only necessary transactions that should be taking place on your wireless LAN.

• Utilization of host-based firewalls provides additional security. Security for remote endpoints is a necessity in combination with an infrastructure that ensures anti-virus programs are up to date and compares local access control lists (ACLs) with corporate templates to ensure minimum requirements are met. If these do not meet corporate policies, the user only gets access to a quarantined network with appropriate patches, anti-virus databases, and so on. One product on the market that can meet most (if not all) of these requirements is Sygate Enforcer (http://www.sygate.com/index.htm).

• Utilization of pre-layer-2 "media negotiation authentication" mechanisms such as 802.1x (network port authentication) may solve this problem, though many of these mechanisms have proven vulnerable to intrusion.