One of the primary concerns that security professionals express with regard to WLANs is rogue APs. Rogue APs can be APs that are connected to the enterprise wired LAN without authorization or APs that are not connected to the wired LAN but that accept associations from clients. Rogue APs can even be APs with a wireless card and a special software package that makes them act as an AP. The rogue APs that are connected to the wired LAN are a security concern because they might not be secured according to a corporation's security policy; this in turn creates a vulnerability in the enterprise network. The rogue APs that are not connected to the wired LAN might accept association requests from clients, which can hamper or deny enterprise clients' access to the corporate WLAN. Also, rogue APs can be classified into two security categories: nonmalicious and malicious.
In the case of nonmalicious APs, the majority of the cases consist of someone installing a rogue AP with the intent being not to bypass the corporation's security policy but to deploy wireless as a convenience or productivity enhancer. The rogue AP installer does not intentionally try to evade detection and uses the default configuration of the AP. The network administrator can often rely on these defaults to identify if there is a conflicting Service Set Identifier (SSID) after the SSIDs are compared to the enterprise WLAN and the Media Access Control (MAC) addresses matching the IEEE OUI for an AP manufacturer.
In the case of malicious APs, the attacker sets up the AP to gain access to the wired network or to disrupt the performance of the WLAN. The attacker can spoof a MAC address to match a legitimate AP, or the attacker can set power, channel, and SSID on the rogue AP to limit its effective coverage area, which in turn minimizes the likelihood of the rogue AP being detected.
Significant technology and manual effort must be expended to mitigate the threat of rogue APs. The primary methods of rogue AP detection are as follows:
WLAN infrastructure reporting
Manual rogue AP scanning
Wired network auditing
This section focuses on these three approaches and covers the pros and cons of each. In most environments, the use of two or all three methods might be appropriate.
Chapter 9, "SWAN: End-to-End Security Deployment," discusses SWAN rogue AP detection. However, the network administrator needs to address additional considerations when deploying SWAN rogue AP detection.
The first consideration is covering areas that currently do not have approved WLAN coverage. The network administrator must make a decision about how to best scan these areas for rogue APs. There are two primary options. The first is to do manual rogue AP detection, which is covered in the following section. The second option is based on SWAN and utilizes an AP that is deployed in scan-only mode. In this mode, the AP is not configured to accept WLAN client connections but scans only the frequency channels for AP or client activity. It might transmit beacons, but it will not interfere with the client-to-AP communication. In addition, it will not respond to probes. Finally, scan-only APs are capable of detecting unassociated clients. It is important to detect unassociated clients in areas without authorized WLAN infrastructure because you do not want them to potentially associate to an unauthorized AP. For both options, the network administrator should use a high-gain antenna to maximize the range of the radio for rogue AP detection. For instance, with scan-only APs, you might want to deploy with an omnidirectional, high-gain antenna to get maximum coverage.
Bug lighting is a term sometimes used to describe attackers' efforts to get unsuspecting clients to associate to a rogue AP. The analogy is that attackers set up a rogue AP and fire up a valid SSID in an attempt to lure unsuspecting clients to their rogue AP, much like a bug light is set up to lure unsuspecting bugs.
The second consideration covers both the 2.4-GHz and 5-GHz frequency ranges when the enterprise has approved only deployments in single frequency ranges. In these deployments, the network administrator must choose a method by which to scan the other frequency range to make sure rogue APs do not utilize that range for unauthorized access. Again, the network administrator needs to choose whether to use manual rogue AP detection or a scan-only AP to provide this coverage. In many cases, network administrators might choose to deploy dual-mode APs with high-gain antennas just to enable the ability to monitor the secondary frequency for rogue APs.
The third consideration is to detect 802.11 ad-hoc mode WLANs occurring within a building. The 802.11 ad-hoc WLANs allow clients to set up a local network in which participants communicate directly with each other. This is known as an independent basic service set (iBSS) network configuration. A member of a wired or infrastructure WLAN that participates in an ad-hoc could potentially provide unwilling and unauthorized access to the enterprise network. For this reason, the network administrator might find it necessary to detect these ad-hoc networks. Ad-hoc network detection leverages the SWAN architecture and its radio management (RM) features.
For an ad-hoc network to be created, the participants must issue beacons that synchronize their communication. APs deployed in an infrastructure WLAN can detect these beacons and report them to the Wireless Domain Services (WDS) in their RM messages. The WDS then puts the relevant information into the RM aggregator messages that it sends to the Wireless LAN Solution Engine (WLSE). Figure 11-1 shows this detection and reporting mechanism.
The WLSE then presents several options for displaying the ad-hoc detection information. The WLSE administrator has the option to specify the severity of the ad-hoc detection notification and can choose to determine in what part of the WLAN the ad-hoc network was detected. The WLSE presents the administrator with a list of all the APs that have detected and reported the ad-hoc WLAN and provides the building and floor of the AP, if available.
The primary technique that has been employed to detect rogue APs has been the manual rogue AP sweep. The network administrator should make manual sweeps for rogue APs because the "supported" infrastructure might not cover the entire geographical area of an enterprise that has network connectivity. For instance, a manufacturing environment typically leverages a wireless environment, but it might not cover the same area as the wired network. For this reason, network administrators are required to use some sort of portable device with a high-gain antenna that actively probes and passively monitors for WLAN activity to detect a rogue AP.
If the enterprise has not deployed both 2.4-GHz and 5-GHz WLAN technology (either client APs or scanning-only APs), the network administrator should perform a manual sweep with the alternate 802.11 WLAN technology to detect any rogue APs that might have been put up by offenders using the alternate technology. The network administrator needs to make sure that the tool he uses for manual rogue AP detection also incorporates the use of an active probing component. This is necessary because a rogue AP might turn off its broadcast SSID and "cloak" itself. The network administrator must use an active probing scanner to make the rogue AP respond.
In addition to auditing via the WLAN media network, administrators should investigate ways to integrate several authentication and auditing techniques that leverage the wired LAN to detect or prevent rogue APs.
The first technique is to leverage the existence of 802.1x in all recent model switches and operating systems (OSs). The network administrator must create a policy that states that no client device can connect to the wired network unless it successfully authenticates itself to the network via 802.1x. In this way, the network administrator eliminates a majority of rogue APs because, in many cases of the rogue AP being a nonmalicious installation, the rogue AP is a consumer-brand AP that does not have the ability to act as an 802.1x supplicant.
Note that a determined malicious attacker can circumvent this prevention technique in a variety of ways. For instance, if the attacker has access to a valid set of credentials for 802.1x authentication (such as username and password), he can use an Ethernet hub and a normal client device to authenticate to the infrastructure. After an attacker is authenticated, he can substitute the rogue AP for the "authenticated" client device. Switch security features such as port security, which can limit the number of MAC addresses an Ethernet switch port allows, can make this attack more difficult but not impossible because the attacker can use an advanced client operating system (OS) configuration either to spoof the AP's MAC address or to make an intelligent client device (like a small Linux box) the rogue AP.
The second technique leverages the published IEEE OUI for AP vendors. Several tools, such as APTools (http://winfingerprint.sourceforge.net/aptools.php), allow you to pull the MAC addresses that have been seen on an Ethernet switch and compare them against a list of "approved" AP MAC addresses. If the tool sees a MAC address that is not on the approved list, it prints out the MAC address, which can then be correlated with information from other Cisco network management tools, such as User Resource Tracking, to find the switch name and the switch port to which the AP is attached. Note that this mitigation technique is also vulnerable to an attacker changing the OUI to match a desktop NIC vendor or to spoof the MAC address of an approved AP or desktop.
The final technique involves scanning the network for signatures that identify the rogue AP. The most common scanning techniques include OS fingerprinting and Simple Network Management Protocol (SNMP) scanning. The more prevalent option is the OS fingerprinting technique because it typically is easier to conduct and is more accurate. OS fingerprinting observes characteristics of the individual OS of the AP, such as the way the OS responds to TCP packets with obscure TCP flags and options enabled. OS fingerprinting depends on there being a fingerprint match for the AP point vendor OS. SNMP scanning relies on the rogue AP having SNMP enabled and accessible from the enterprise network. In the case of the malicious rogue AP, this is a highly unlikely scenario. In the nonmalicious rogue AP instance, SNMP scanning is typically effective for detecting rogue AP installations that might be larger than normal and managed by the user or a rogue AP that has SNMP on by default with public and private settings for its read-only and read-write community strings.