Some installers make the mistake of treating 802.11 WLANs just like Ethernet, placing access points (APs) in locations that facilitate outsider access to corporate networks. But, from a security perspective, WLANs should be treated like the Internet -- a network composed of trusted and untrusted users. This tip offers network topology and physical positioning recommendations for safer AP deployment.
APs with factory-default omni antennas cover an area that's roughly circular, impacted by RF obstacles like walls. It is therefore common to place APs in central locations, or divide an office into quadrants, deploying one AP per cell.
This approach is straight-forward, but may not optimize cost, performance or security. Actual AP coverage areas not truly circular -- especially for 802.11n APs that use Multiple Input Multiple Output (MIMO) antennas to exploit multipath signal reflections. To fill resulting gaps, you may end up purchasing more APs than you really need and "leaking" quite a bit of signal. Site modeling, directional antennas, and/or 802.11n beamforming can help you avoid this.
- Modeling tools try to satisfy user location, density and throughput requirements by combining building material characteristics, AP capabilities and site survey measurements to predict where APs should be placed and verify results. Up-front planning takes more time and effort, but can pay off in the long run, especially for large WLANs. For example, see AirMagnet Surveyor, AirTight SpectraGuard Planner, and Motorola WLAN Planner.
- Replacing your 802.11a/b/g AP's "rubber ducky" omni antennas with directional antennas can better focus radiated power where it belongs, improving inside coverage and reducing outside signal leakage. On 802.11n APs, transmit beamforming can adjust transmissions to create a similar effect. To learn more about various types of antennas and their coverage patterns, read this three-part Wireless Advisor tip: Part 1, Part 2, and Part 3.
Physical placement, and associated steps like transmit power adjustment, can make it harder for intruders to stay connected to your APs. But you should never count on physical placement alone to stop attackers.
Physical or logical LAN segmentation
Next, prevent wireless LAN traffic from mixing with "other" LAN traffic. Stations connected to your Ethernet LAN form a trusted workgroup. They exchange broadcast/multicast traffic and depend on shared resources like Layer 2 hubs or switches, DHCP servers, DNS servers, and layer 3 switches or routers. Toss untrusted devices onto that LAN and you're putting everyone at risk. Bad actors can cause broadcast storms, poison ARP caches, chew up IP address pools, etc. This risk can be reduced by physically or logically segregating your APs.
- For example, cable all of your APs to a new Ethernet switch, rather than connecting them to an existing Ethernet switch used by nearby wired devices. Better yet, cable "thin" APs to wireless controllers (e.g., Aruba, Cisco, Meru, Belkin/Trapeze) that are responsible for managing and monitoring them. Clumping all APs into one physical LAN is easy to understand, but does not scale. On the other hand, centralized controllers can become bottlenecks in large networks, so consider WLAN architectures that centralize management, not the data path.
- Larger WLANs should create logical workgroups using Virtual LANs (VLANs). VLANs tag packets or ports with identifiers used to control traffic flow. For example, connect your APs to existing Ethernet switch ports, but assign those ports their own new VLAN. To learn more about segregating wireless traffic with VLANs, read our companion tip Using VLANs to compartmentalize WLAN traffic.
Note that segmenting LANs can impact both security and performance. For example, Quality of Service measures can be applied to physical or virtual LANs to give employee traffic priority over guests.
Creating network barriers
At some point, WLAN traffic will encounter a network layer device, where it may be forwarded to the public Internet or other internal subnets. This is where many employee-installed APs wreak havoc. Connecting an untrusted device to a trusted subnet creates an unsecured "back door." Security measures enforced at the trusted subnet's "front door" -- firewall rules, VPN tunnels, network antivirus -- are circumvented by stations connected to misplaced APs.
For this reason, wireless APs should always be separated from trusted subnets using some type of network layer policy enforcement device, like:
- VPN gateways
- Wireless gateways and Layer 3 WLAN controllers
- Network access controllers
For example, your APs could be connected directly to an access router, configured to relay wireless traffic towards the Internet and not your company's network. Or your APs could be connected to a VPN gateway that authenticates VPN clients and blocks all other traffic. Or your APs might be placed on a firewall DMZ, allowing wireless access to a few DMZ-protected servers, but preventing passage through the firewall into trusted networks.
When creating a network barrier, consider functions that device must perform. To enforce security policies, you may need access controls (based on MAC, VLAN, IP, port or application traffic inspection), station or user authentication, VPN tunneling (with or without subnet roaming), session accounting, virus scanning, content filtering, intrusion detection/prevention, and bandwidth limits. A general-purpose firewall can do much of this, but a wireless gateway or Layer 3 WLAN controller may fill this role AND provide 802.11-specific functions like AP discovery, provisioning and RF management.
Different barriers may be appropriate for different users -- for example, a Web-based access controller for guests and a VPN gateway or WLAN controller for employees. Network Access Control (NAC) architectures can help you apply a more consistent security policy, independent of network access type or enforcement device.
Finally, no matter which device you choose, configure incoming and outgoing policies to meet business needs and deny everything else. For example, there's probably no reason that SNMP requests, routing messages, or DNS zone updates should originate from your WLAN. Granular policies may require more effort to maintain, but can reduce the risk of core network compromise by wireless-borne attacks.
This was first published in July 2009