Wireless LANs

WLANs are popping up everywhere. This is unfortunate, considering that the security protocol for IEEE 802.11 WLANs (Wired Equivalent Privacy[WEP]) has been proven insecure. The productivity gains WLAN offers are significant enough that people are deploying WLANs despite this weakness, and I can't say I blame them.

This section details design considerations using WLANs in general to mitigate risk as much as possible while still keeping the network usable. The section describes three primary deployment options:

• Basic 802.11b
• 802.11 security enhancements
• L3+ security solutions

General Considerations

The main security problems around WLANs stem from the fact that 802.11 is not only a shared media but a shared media that anyone with rough geographic proximity can access. Any user (authorized or unauthorized) can therefore see all frames for all stations. The goal of WLAN security is to ensure that only authorized users can gain access to the network by authorized devices and that unauthorized users are unable to decipher the messages sent on the WLAN. Many of the basic design considerations discussed in this book apply to WLANs, sometimes with a unique twist.

Access Point Hardening

Like most devices on the network, access points (APs) must be hardened. Out of the box, they typically have no security features enabled. An unauthorized deployment of an AP in an organization can eliminate the validity of any increased trust provided by having physical access to the network. This is particularly troubling for teleworker home deployments because the average user that purchases an AP from a consumer electronics store will never enable security features. If you have a site-to-site VPN device at that teleworker location, outsiders will be able to access the central site over the VPN. In addition to the hardening tasks identified in Chapter 5, the following considerations are AP specific:

• Secure management Ensure that management traffic is encrypted and authenticated. When this is not feasible, at least ensure that management access is enabled only from the wired side of the network.
• Cryptographic traffic protection Because traffic is sent over the air, it is essential to provide cryptographic protections for all traffic sent over the wireless side of the AP. This can be done in a number of ways detailed later in this chapter.

This lack of default security functions in an AP leads to the next consideration, rogue APs.

Rogue APs

As mentioned earlier, a rogue AP can provide an attacker with truly anonymous access to your network. Whether inadvertently installed by an unaware user or deliberately placed by a malicious attacker, rogue APs are a constant source of concern for any organization. Many client OSs connect to whichever WLAN offers the best signal, which can lead to users inadvertently accessing the network via an AP controlled by an attacker. This allows man-in-the-middle (MITM) attacks, among others. As discussed in Chapter 5, there is no magic solution to this problem. Beyond the methods discussed in that chapter, there are four WLAN-specific techniques.

First and most comprehensive is to physically roam your organization's locations, checking for the existence of unauthorized APs. Many WLAN sniffers are available in the market to facilitate this. NetStumbler is a popular free offering available at the following URL: http://www.netstumbler.com. By using a tool to look for these rogue devices, you can identify their physical location and remove them from the network.

Second, there are tools designed to automate the detection process. For example, APTools allows a network administrator to query Address Resolution Protocol (ARP) and Content Addressable Memory (CAM) tables for AP Media Access Control (MAC) addresses. It relies on the IEEE organization unique identifier (OUI), which is assigned to various hardware vendors. Attackers can easily modify their MAC address, however. In addition, a single vendor's OUI can apply to wired and wireless devices, making detection difficult. APTools can be downloaded here: http://winfingerprint.sourceforge.net/aptools.php.

Third, port security (as discussed in Chapter 6) can be used to limit the number of MAC addresses on a port. By setting that limit to a small number, you won't necessarily prevent the rogue AP, but you can stop it from being widely used.

Finally, 802.1x on switches (as discussed in Chapter 9, "Identity Design Considerations") can be used to prevent a rogue AP from easily attaching to a protected port.

NOTE

By far, the easiest way to prevent rogue APs is to install an IT-supported WLAN network. Most rogue APs are installed by an organization's own users, who are looking for the productivity benefits of WLAN whether IT will support them or not. By providing a more secure, supported WLAN offering, you prevent users from installing it themselves because they have no motivation to do so.

 

Denial of Service

WLAN networks are vulnerable to denial of service (DoS) attacks through two mechanisms. First, an attacker can flood the network with legitimate WLAN traffic. Authentication requests, disassociate messages, and so on can all exhaust bandwidth on the WLAN and can knock off legitimate users. Second, WLANs are subject to Layer 1 (L1) jamming attacks from a wide variety of valid and invalid devices that use the same frequency range as 802.11 (2.4 gigahertz): Bluetooth devices, microwave ovens, cordless phones, and so on.

Physical Isolation Issues

Unlike wired networks, physical isolation cannot be used as a security technique. Even though the typical usable range of WLAN technology is in the hundreds of feet, homegrown antennas can get the signal to travel several miles. One such antenna, developed by Rob Flickenger at O'Reilly, uses a Pringles can: http://www.oreillynet.com/cs/weblog/view/wlg/448.

Technology Options

This section covers the various technology options for WLANs: IEEE 802.11, 802.11 security enhancements, and L3+ security techniques.

802.11 WEP

The default WLAN security option is 802.11. Using an RC4 cipher with 40- or 128-bit key length, WEP can be cracked very quickly on a busy network. One such tool, AirSnort, allows you to automate the attack and is available at http://airsnort.shmoo.com/.

In addition to the cryptographic weaknesses of WEP, key management is very difficult. WEP only offers provisions for static WEP keys and, as such, requires that the keys be provisioned in advance on each device requiring connectivity. In the event tht a device is compromised, the keys must be reconfigured on all devices.

Because of the security considerations of WEP, it is really a security-through-obscurity feature as opposed to one providing a real security benefit. It is, however, better than nothing. If you absolutely must use WLANs and cannot rely on one of the more secure alternatives discussed later, use 128-bit WEP and change the keys as often as you can.

From a security perspective, you should consider any data transmitted on a network running basic WEP untrusted and should limit that network's access accordingly. This can be done with firewalls, ACLs, or some form of identity control.

Some cases that require the use of static WEP include devices with no support for security alternatives. A retail bar code system, for example, might need to run over 802.11 but might not have the ability to run any security extensions. In this case, the security of those transactions falls completely on the application. This is unfortunate because the same hardware limitations that prevent the use of security extensions on a low-power WLAN device often prevent the use of application security because of the computational complexity. The section on L3+ security techniques later in this chapter provides more detail on this option. Figure 11-7 shows the basic WEP design.

Figure 11-7. Basic WEP Design

TIP

One weak but useful security technique, if you have no other options, is to filter WLAN access by MAC address at the AP. Although this isn't manageable in large networks, it can be useful in smaller networks. Changing your MAC address is easy, though, so this shouldn't be considered anything other than doing the best with what you have.

Key design considerations for the basic WEP design are as follows:

• Since WEP is insecure, your top priority is to partition the WLAN as much as possible to prevent any unauthenticated connection to the main network. Connect it to a separate IP subnet on a dedicated router interface. If using VLANs is necessary, the same separation can be achieved, but keep in mind the L2 design considerations discussed in Chapter 6.
• Filter incoming WLAN traffic at the router port or, for added security, configure a firewall and other security technology such as NIDS. The extent of the filtering will vary based on the deployed design. The most preferred configuration is to stop any application that isn't secured through some higher-layer function.

802.11 Security Enhancements

The IEEE is not blind to the security issues with 802.11, nor are the vendors that sell WLAN technology. As such, several enhancements are available today or will soon be available to improve the security and key management of 802.11. As a rule, these enhancements to 802.11 offer the following major improvements:

• Dynamic key management Keys are determined for each individual client based on the authentication information gathered at first connect.
• Improved cryptographic mechanisms All of these enhancements support improved crypto mechanisms. This includes improved encryption and improved packet integrity/authentication checks.

WARNING

The IEEE 802.11 Task Group I described in the next section is not finalized as of this writing. Although the core elements of this enhancement are not expected to significantly change, the standards will continue to evolve as needed to address all known issues regarding WLANs. With this in mind, what is represented in the following text might differ from the standard that is ratified by the IEEE.

 

802.11 Task Group I

The IEEE has formed Task Group "I" inside the 802.11 Working Group. This group is developing the standard to replace 802.11's current security solution (WEP). The new standard will use 802.1x and EAP as a method of authenticating clients and APs and providing key material to both. Encryption options will be done using two WEP alternatives: Temporal Key Integrity Protocol (TKIP) and Counter Mode with CBC-MAC (CCMP).

TKIP

TKIP, like WEP, uses RC4, which allows compatibility with existing WEP hardware devices. Unlike basic WEP, TKIP is designed to prevent key compromise, replay attacks, and other malicious use of the crypto functions. Because TKIP is based, in part, on WEP, it has countermeasures designed to thwart an active attack against a connection. If under attack, TKIP will rekey and then limit the rekey process for the duration of the attack.

CCMP

CCMP is an Advanced Encryption Standard (AES)based protocol designed from the ground up as the ultimate replacement for WEP. It uses a 128-bit AES key and does not require active countermeasures because the cryptography employed is much stronger.

Authentication

Although several Extensible Authentication Protocol (EAP) methods can be used with the work done by Task Group I, it is expected that EAP/TLS or Protected EAP (PEAP) will be used. EAP/TLS requires client-side certificates, while PEAP uses only server-side certificates with the client authenticating by using a username/password credential of some kind.

Other Considerations

In addition to the security improvements to the base operation of WLANs, Task Group I defines three additional security mechanisms of interest. First, there's a method for ad-hoc networks (client to client) to achieve basic security through negotiated group keys. Second, and more important, is a method for clients to preauthenticate with multiple APs. This allows fast roaming between APs without incurring a significant delay for reauthentication. Finally, Task Group I will define mechanisms for the secure handling of management frames such as the "disassociate" message, which can cause a DoS in today's WLAN networks.

Wi-Fi Protected Access

Although the industry waits for the finalized 802.11 Task Group I specification, a clear need exists to offer a short-term solution that addresses the weaknesses of WEP and provides interoperability. The Wi-Fi Alliance (http://www.wi-fi.org) is beginning the certification process of a security suite called Wi-Fi Protected Access (WPA). WPA is a security fix utilizing TKIP, 802.1x, and EAP. It will be forward compatible with the Task Group I work because it uses a subset of the mechanisms Task Group I will specify. It does not contain many of the advanced security functions of Task Group I, such as secure management frames, preauthentication, secure ad hoc, and AES CCMP. The major benefit of WPA is that it is available as of early 2003 with the Task Group I specification not expected until early 2004, with implementations to follow afterwards.

Vendor Proprietary

Although WPA was made available in 2003, the weaknesses in WEP have been known since early 2001. Vendors that manufacture 802.11 gear required solutions to meet the market's needs immediately. As a result, proprietary security improvements are available from a number of vendors. Cisco Systems, for example, offers an 802.1x implementation with a proprietary EAP type often called LEAP.

LEAP operates in much the same way as the WPA solution except that it works only with Cisco gear or vendors that have licensed the technology (such as Apple). Be sure to closely examine the security aspects of any vendor-proprietary solution before deploying. Technologies that are at least based on standards that have yet to be ratified (such as LEAP) offer the best option.

Sample Design

Despite the specific differences between the three options for 802.11 enhancements (802.11i, WPA, vendor proprietary), the designs for all these options are remarkably similar. All are loosely based on 802.1x and EAP in some form or another. Figure 11-8 shows the recommended design for most networks.

Figure 11-8. Basic 802.1x/EAP WLAN Design

As you can see, with the exception of an added RADIUS server, the basic design remains the same as basic 802.11. It is no longer essential to perform filtering at the router, although some policies might still dictate its use. In addition, although the WLAN devices could be put on the same subnet as the user traffic, it makes good sense to keep the separation. Using VLAN trunks and L3 switching is fine with consideration of the same caveats as described for the basic WEP design.

WARNING

Be sure to read about AAA deployments in Chapter 9. If your AAA infrastructure goes down, so does your wireless network. If deployed in a remote location, these 802.11 enhancements must use static keys (something that should be available with WPA and 802.11i), make AAA requests over a WAN/VPN, or have a local AAA server.

 

L3+ Cryptography

A final option for WLAN deployment is forgoing any significant security at L2 and instead ensuring adequate security for L3 or higher. IPsec VPNs, SSL, or Secure Shell (SSH) can be used to provide this security, though there is a management and user experience cost. In addition, although security at L3+ can ensure that your data is not manipulated or captured, DoS attacks at the WLAN layer are still possible using such mechanisms as spoofed disassociate messages. This section outlines the considerations and topologies associated with these deployments.

IPsec

For organizations seeking full unicast IP connectivity, IPsec is the preferred L3+ choice for the same reasons it is preferred in Chapter 10. By installing an IPsec client on the WLAN-connected PC, users can establish a VPN to the wired network and are able to communicate securely with a VPN gateway on the wired portion of the network. Figure 11-9 shows the building blocks of this design.

Figure 11-9. Basic IPsec WLAN Design

There are several considerations with this design:

• Because IPsec is an L3 mechanism, you need IP connectivity before the IPsec tunnel can be established. This requires that a DHCP server be reachable by the entire network before IPsec establishment. This DHCP server should be hardened with HIDS, firewalls (network/host), and any other mechanism appropriate because it is directly reachable by anyone on the network.
• Filtering can be enforced either at the first L3 port, the AP, or both to stop traffic types not needed for the establishment of the VPN. The following ACL configuration assumes a WLAN VPN network of 192.168.1.0/24 and a wired campus network of 10.5.5.0/24, as shown in Figure 11-10. The DHCP server receives requests through the ip helper-address command:

  Figure 11-10. Basic IPsec WLAN Topology

  

! These ACLs are for user traffic only, management access control options
! are discussed in chapter 16
! Inbound ACL on R1 Fa0/0
! Permit IPsec traffic to the IPsec gateway
access-list 101 permit esp 192.168.1.0 0.0.0.255 host 192.168.2.1
access-list 101 permit udp 192.168.1.0 0.0.0.255 eq isakmp host 192.168.2.1
 eq isakmp
! Permit DHCP requests
access-list 101 permit udp host 0.0.0.0 eq bootpc host 255.255.255.255 eq bootps
! Permit DCHP release
access-list 101 permit udp 192.168.1.0 0.0.0.255 eq bootpc host 10.5.5.50
 eq bootps
! Deny all other traffic
access-list 101 deny ip any any log

! Outbound ACL on R1 Fa0/1
! Permit IPsec traffic to the WLAN from the IPsec gateway
access-list 102 permit esp host 192.168.2.1 192.168.1.0 0.0.0.255
access-list 102 permit udp host 192.168.2.1 eq isakmp 192.168.1.0 0.0.0.255
 eq isakmp
! DHCP responses do not need to be permitted to the subnet since all traffic
! will be from the router to the clients. Since ACLs don't apply to the router
! itself, you can just deny all remaining traffic.
! Deny all other traffic
access-list 101 deny ip any any log

! Apply the ACL to Fa0/0
interface FastEthernet0/0
 access-group 101 in
 access-group 102 out

• The IPsec design shown in Figure 11-9 allows your users to have similar connectivity options as they might have in a remote user VPN. This can be a bit confusing to locally connected users because they might expect full connectivity when on-site.
• Because IPsec is IP based, non-IP protocols do not function. In addition, multicast does not work.
• As users move from one AP to another, they lose their IPsec sessions unless the APs in question are on the same subnet. This might be reasonable in a small network, but it is unlikely in larger networks that span a larger geographic region and have more users.
• Although both IPsec and the 802.11 enhancements will require user authentication, the IPsec option is currently not automated and requires a user to manually start a client to connect. Some vendors have proprietary workarounds for this problem in single-vendor WLAN and VPN deployments. Cisco, for example, has the WLAN "auto initiate" feature. You can read more at http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_administration_guide_chapter09186a008015cfda.html.
• Because the WLAN portion of the network is considered untrusted, you should plan on adversaries attacking the clients connected to this network. As such, the devices should be hardened with appropriate host security technology and hardening best practices as discussed in Chapters 4 and 5. Since split tunneling should be disabled, the options of adversaries will be limited while the IPsec connection is active. When first connecting to the network or after being knocked off the WLAN (potentially maliciously), these systems are vulnerable in the same way they might be if connected to a hotel or airport network.
• Depending on your level of trust for your IPsec clients and their authentication options, you might wish to augment the IPsec gateway with additional security measures after decryption. Firewalls and NIDS are obvious choices. At a minimum, the filtering on whichever device you enforce your access control for your WLAN users is critical. Treat it like any other security device in your network. Monitor the logs and harden the device.
• In large networks, you should be aware that several IPsec gateways often are needed. Centralizing this resource is the most likely option that allows for load balancing and HA. This requires that you do ingress filtering at each L3 point where you have APs to ensure that all non-IPsec traffic is blocked. Also remember that your WLAN users consume more bandwidth than regular remote user VPN clients connecting over the Internet; 802.11b is 11 MBps, for example. It doesn't take a large number of users and APs to exhaust a 100 MBps IPsec gateway.

NOTE

If you are running IPsec for your WLAN, you can optionally add static WEP keys to keep script kiddies and curious passersby from connecting to your network. Be aware of the key management issues and that this option is really a security-through-obscurity decision. As discussed in Chapter 1, "Network Security Axioms," if the obscuring takes effort, it probably isn't worthwhile. You might consider ignoring the key management issues and instead leaving keys alone if a portable computer is lost or stolen. After all, you are running IPsec as the main encryption mechanism. If it were my network, I would probably use static WEP in small deployments and not bother in larger networks because the security gained is almost zero.

As an alternative to the previous design, because you are treating the WLAN network as an untrusted entity similar to the Internet, you can consider using the same IPsec gateway for your WLAN users. This allows you to save money on your upfront capital costs, assuming your network is small enough. This design is shown in Figure 11-11. Remember that your WLAN users consume much more bandwidth than your Internet users. As such, you should consider bandwidth limits for each user to ensure adequate resource sharing. Also remember that you must somehow get the APs to logically connect through this aggregation device. This is easier in smaller networks than larger ones.

Figure 11-11. Alternative IPsec WLAN Design

For all but very small networks, you are probably better off using separate IPsec gateways for your WLAN users. This gives you more options in your design and scales much better as you grow.

NOTE

One interesting issue when connecting PCs to public Internet WLANs is the potential for information to "leak" prior to VPN establishment. Care should be taken to ensure that no confidential information is sent by default when a PC starts up. Sending your instant messaging (IM) password in the clear is one thing; sending authentication for internal applications is another.

 

SSH/SSL

An alternative design to IPsec moves the security even higher in the stack to an SSL/SSH tunnel. In this design, no connectivity is provided to the campus network without first establishing a connection to an SSL/SSH-enabled server. These servers either could offer a limited VPN service for specific applications or could be configured to allow only a single application to function. In the retail bar code example discussed earlier, the bar code readers could be configured to send their communications using SSL/SSH to avoid interception while traversing the WLAN network. Figures 11-12 and 11-13 show this design. In Figure 11-12, the SSH/SSL device is configured much like the IPsec gateway in the previous design. Here, the SSH/SSL gateway can be forwarding traffic for a number of applications that need security while traversing the WLAN. In Figure 11-13, the server is residing on the campus network and providing security for a specific application.

Figure 11-12. SSH/SSL Gateway WLAN Design

Figure 11-13. SSH/SSL Application WLAN Design

Use the design in Figure 11-12 when you must support legacy applications without built-in SSH/SSL support. IPsec is generally preferred here, but some small devices offer SSH/SSL but not IPsec. The design in Figure 11-13 should be used in all other cases. Holes can be put in the ACLs on the router to permit access to any number of application servers.

The considerations with this design are similar to those for the IPsec design. Some users might be confused by their inability to use some applications that are usually available when connected to the wired network. This can be worse than it might be with IPsec, which generally has more extensive application support than an SSL tunnel. The configuration of the ACLs on the router or firewall that provides the filtering is crucial. This device should be monitored closely, like any other critical network device. DHCP is necessary before connecting to the SSH/SSL device, and finally, the WLAN users will be subject to DoS attacks in the same way they might be when connected to the IPsec network.

WLAN Security Recommendations

Now that you have a good foundation in the technology options for using WLANs, this section provides specific recommendations that should apply to most networks.

For most organizations, the security provided by the 802.11 enhancements is sufficient. These technologies offer the lowest barrier to entry, requiring only an authentication server in addition to the APs. The user experience is the best of the choices, and with more advanced options such as 802.11i, management frames are secured and preauthenticated roaming is enabled.

WARNING

The previous recommendations assume no new vulnerabilities are discovered with these mechanisms. The security appears sound, but further analysis is necessary. Having been burned by flaws in 802.11b, I fully expect 802.11i to have been analyzed much more from a security perspective before release.

The IPsec option is for organizations that either have mandated IPsec as the cryptography solution or cannot make use of the 802.11 enhancements because they are lacking software or hardware support. Because of the roaming, protocol, management, and performance limitations, it should be considered only in cases in which the 802.11 enhancements are ruled out for some reason.

SSH/SSL should be used when only a small number of applications require security services and the devices that use those applications are unable to take advantage of the 802.11 security enhancements or IPsec. It can also be used when there is no ability to mandate a particular client type that supports IPsec or 802.11 security enhancements. If SSH/SSL supports all the applications needed by your organization, it can often be a less expensive option than IPsec, which requires a separate client and key management.

If your users are taking advantage of WLANs in public locations, be sure their PCs are adequately secured and any communications sent back to your organization are cryptographically protected.

Unique Deployment Options

WLAN technology is used in many different ways in organizations. This section outlines two deployment options that deviate slightly from the norm. Understanding how these two options work can give you ideas on how to handle your own unique WLAN requirements when designing your network.

Direct Internet Access WLAN

For any of the preceding options, it is possible to offer Internet access to WLAN users without providing them access to your organization's network. Figure 11-14 shows the basic design.

Figure 11-14. Direct Internet Access WLAN Design

By implementing an IPsec gateway or other security device to provide access to the corporate network, you can allow your organization's users and guests to both make use of the same network. The same security considerations as for the basic IPsec design apply, only now there is another route out of the network that requires some basic security. Generally, a firewall is appropriate here. Depending on your policy, you can use a dedicated WLAN Internet firewall, as shown in Figure 11-14, or you can route the traffic through the main corporate firewall. In either case, be sure to filter out any internal access by the IP subnet used in the WLAN. IPsec users will have their own address assigned by the IPsec gateway by Mode Config (see Chapter 10).

Differentiated Groups WLAN

In some networks, the WLAN network must serve several different functions. It might provide basic restricted access to specific applications to one group while providing full access to another. This design is discussed in Chapter 9 and is sometimes called user differentiation. WLANs generally have no means of differentiating users. Everyone is on the same flat network, and any differentiation must occur at the application level, not at the network level.

By using IPsec, user differentiation becomes easy because specific IPsec access control policies can be applied to different groups on your authentication server. The group requiring limited access can contact the applications directly using SSH/SSL, and users requiring full access establish an IPsec tunnel.

As an alternative, some WLAN devices now offer the capability to establish VLANs much like you would in a wired network. In this design, users are differentiated by which VLANs they have access to. One VLAN might run basic WEP and require an L3+ security mechanism for access, while another could use something like 802.1x with TKIP. Access policies can be unique to each VLAN based on the access control policy in force as the WLAN crosses into the wired network. Figure 11-15 shows this design using an L3 switch and three different user groups. The access control policies can be implemented at the L3 switch as shown or at an upstream firewall. In either case, RFC 2827 filtering is essential at the first point of L3 access (in this case, at the switch).

Figure 11-15. Differentiated Groups WLAN Design

Users do not tag traffic because they are not VLAN aware. The VLAN mapping occurs based on the security options enabled at the AP. For example, three different keys can be statically configured on a single AP. Each can then map to a specific VLAN.

NOTE

VLANs and WLANs are new concepts. If my network had a user differentiation requirement, I would look to fill it with IPsec as my first option because it is a more mature technology. Much like wired VLANs have over time become better understood regarding security, the same is likely to happen with wireless VLANs.

 

WLAN Conclusion

In the end, the best WLAN decision you can make is to offer an IT-supported solution for your organization. Rogue APs are a significant threat to an organization's internal network, and providing a supported solution is the best first step in mitigating that risk. By evaluating the design options and considerations in this section, you should be able to make a sound technology decision. Talk with your WLAN vendor to better understand which capabilities are available when you decide to deploy.