Rogue Management White Paper

Document ID: 110556

Introduction
Rogue Detection, Classification and Mitigation
Rogue Detection
Rogue Classification
Rogue Mitigation
Related Information

Introduction
This document discusses in detail the rogue device management in the Cisco Unified Wireless Network
solution.

Rogue Detection, Classification and Mitigation

There are three main phases of rogue device management in the Cisco Unified Wireless Network solution:

• Detection Radio Resource Management (RRM) scanning is used to detect the presence of rogue
devices.
• Classification Rogue Location Discovery Protocol (RLDP), Rogue Detectors and switch port
tracing are used to identify if the rogue device is connected to the wired network. Rogue classification
rules also assist in filtering rogues into specific categories based on their characteristics.
• Mitigation Switch port shutting, rogue location and rogue containment are used in tracking down its
physical location and to nullify the threat of the rogue device.

Rogue Detection
A rogue is essentially any device that is sharing your spectrum, but is not in your control. This includes rogue
Access Points (APs), rogue clients and rogue ad−hoc networks. The Cisco Unified Wireless Network uses a
number of methods to detect WiFi−based rogue devices including off−channel scanning and dedicated
monitor mode capabilities. Cisco Spectrum Expert can also be used to identify rogue devices not based on the
802.11 protocol, such as Bluetooth bridges.

802.11n Rogue Considerations

Although 802.11a/b/g APs can detect most 802.11n rogues because their beacons are sent at legacy rates, only
802.11n APs can detect rogues operating in Greenfield mode. Greenfield mode is a configuration parameter of
an 802.11n AP that prevents the device from transmitting at non−802.11n rates. Customers are encouraged to
utilize the Cisco 1140 and 1250 series APs to allow the detection of rogues in 802.11n Greenfield mode.

Off−Channel Scanning

This operation is performed by Local mode and H−REAP (in connected mode) APs and utilizes a
time−slicing technique which allows client service and channel scanning using the same radio. By going off
channel for a period of 50ms every 16 seconds, the AP by default only spends a small percentage of its time
not serving clients. Also, note there is a 10ms channel change interval that will occur. In the default scan
interval of 180 seconds, each 2.4Ghz FCC channel (1−11) is scanned at least once. For other regulatory
domains, such as ETSI, the AP will be off channel for a slightly higher percentage of time. Both the list of
channels and scan interval can be adjusted in the RRM configuration. This limits the performance impact to a
maximum of 1.5% and intelligence is built into the algorithm to suspend scanning when high−priority QoS
frames, such as voice, need to be delivered.

This graphic is a depiction of the off−channel scanning algorithm for a local mode AP in the 2.4GHz
frequency band, a similar operation is being performed in parallel on the 5GHz radio if the AP has one
present. Each red square represents the time spent on the APs home channel, whereas each blue square
represents time spent on adjacent channels for scanning purposes.

Monitor Mode Scanning

This operation is performed by Monitor Mode and Adaptive wIPS monitor mode APs which utilizes a 100%
of the radio's time for scanning all channels in each respective frequency band. This allows a greater speed of
detection and enables more time to be spent on each individual channel. Monitor mode APs are also far
superior at detecting rogue clients as they have a more comprehensive view of the activity occurring in each
channel.
This graphic is a depiction of the off−channel scanning algorithm for a monitor mode AP in the 2.4GHz
frequency band, a similar operation is being performed in parallel on the 5GHz radio if the AP has one
present.

Local Mode and Monitor Mode Comparison

A local mode AP splits its cycles between serving WLAN clients and scanning channels for threats. Because
of this, it takes a local mode AP longer to cycle through all the channels, and it spends less time collecting
data on any particular channel so that client operations are not disrupted. As a result, rogue and attack
detection times are longer (3 to 60 minutes) and a smaller range of over−the−air attacks can be detected than
with a monitor mode AP. Furthermore, detection for bursty traffic, such as rogue clients, is much less
deterministic because the AP has to be on the channel of the traffic at the same time the traffic is being
transmitted or received. This becomes an exercise in probabilities.

A monitor mode AP spends all of its cycles scanning channels looking for rogues and over−the−air attacks. A
monitor mode AP can simultaneously be used for Adaptive wIPS, location (context−aware) services, and
other monitor mode services. When monitor mode APs are deployed, the benefits are lower
time−to−detection. When monitor mode APs are additionally configured with Adaptive wIPS, a broader range
of over−the−air threats and attacks can be detected.

Rogue Identification

If frames or beacons from a rogue device are heard by either local mode, H−REAP mode or monitor mode
APs, then this information is communicated via CAPWAP to the Wireless LAN controller (WLC) for
processing. In order to prevent false positives, a number of methods are used to ensure other managed
Cisco−based APs are not identified as a rogue device. These methods include mobility group updates, RF
neighbor packets and white listing autonomous APs via Wireless Control System (WCS).

Rogue Records

While the controllers database of rogue devices contains only the current set of detected rogues, the WCS
also includes an event history and logs rogues that are no longer seen.

Exporting Rogue Events

In order to export rogue events to a third party Network Management System (NMS) for archival, the WLC
permits additional SNMP trap receivers to be added. When a rogue is detected or cleared by the controller, a
trap containing this information is communicated to all SNMP trap receivers. One caveat with exporting
events via SNMP is that if multiple controllers detect the same rogue, duplicate events will be seen by the
NMS as correlation is only done at WCS.

Rogue Record Timeout

Once a rogue AP has been added to the WLCs records, it will remain there until it is no longer seen. After a
user configurable timeout (1200 seconds default), a rogue in the unclassified category will be aged out.
Rogues in other states such as Contained and Friendly will persist so that the appropriate classification
is applied to them if they reappear.

There is a maximum database size for rogue records that is variable across controller platforms:

• 21XX and WLCM 125 rogues

• 44XX 625 rogues
• WiSM 1250 rogues
• 5508 2000 rogues

WCS Rogue Considerations

By default, the WCS background task for Rogue AP data collection runs in regular intervals, which means
there can be a lag in information between the WLC and WCS. One method to speed up the rogue data
collection process is to enable specific rogue SNMP traps on the Wireless Controller.

WCS Rogue Reports

The WCS allows historical tracking of rogue information through a number of different customizable reports.
The report information is based off of records in the WCS database.

These reports include:

• Ad−hoc Rogue Events

• Ad−hoc Rogues
• New Rogue APs
• New Rogue APs Count
• Rogue AP Events
• Rogue APs

Each report is customizable in terms of which devices are included, the period of time and the columns of
information that are included. In addition, each report can be run on a scheduled basis and exported to CSV or
PDF.
Rogue Classification
Rogue Classification Rules

By default, all rogues that are detected by the Cisco Unified Wireless Network are considered to be
unclassified. Rogue classification rules, introduced in the 5.0 release, allow you to define a set of
conditions that will mark a rogue as either malicious or friendly. These rules can be configured at the WCS or
the WLC, but they are always performed on the controller as new rogues are discovered.

As depicted in this graphic, rogues can be classified on a number of criteria including RSSI, SSID, Security
type, on/off network and number of clients:

An example configuration of a rogue classification rule can be seen here:

In this example, a rogue heard broadcasting an SSID the same as that configured on the controller (managed
SSID) with a signal stronger than −70dBm will be marked as Malicious.

Rogue Detector AP

A rogue detector AP aims to correlate rogue information heard over the air with ARP information obtained
from the wired network. If a MAC address is heard over the air as a rogue AP or client and is also heard on
the wired network, then the rogue is determined to be on the wired network. If the rogue is detected to be on
the wired network, then the alarm severity for that rogue AP is raised to critical. It should be noted that a
rogue detector AP is not successful at identifying rogue clients behind a device using NAT.
Deployment of Rogue Detector APs:

In rogue detector mode, all radios on the AP are disabled and the AP must specifically be configured to Rogue
Detector mode:

On the switch port side, the connection to the AP should be an 802.1Q trunk with the native VLAN being one
that routes to the WLC.

Example Cisco switch port configuration:

interface GigabitEthernet1/0/5
description Rogue Detector
switchport trunk encapsulation dot1q
switchport trunk native vlan 113
switchport mode trunk
spanning−tree portfast trunk

Note: The native VLAN in this configuration is one that has IP connectivity to the WLC.

Scalability Considerations:

A rogue detector AP can detect up to 500 rogues and 500 rogue clients. If the rogue detector is placed on a
trunk with too many rogue devices, then these limits might be exceeded, which causes issues. In order to
prevent this from occurring, keep rogue detector APs at the distribution or access layer of your network.

Physical Location of Rogue Detector APs:

Depending on the layout of the wired network, the number and location of rogue detector APs can vary from
one per floor to one per building. Because a rogue detector AP requires a trunk to all layer 2 network
broadcast domains that should be monitored, placement is dependent on the logical layout of the network.

RLDP

The aim of RLDP is to identify if a specific rogue AP is connected to the wired infrastructure. This feature
essentially uses the closest Unified AP to connect to the rogue device as a wireless client. After connecting as
a client, a packet is sent with the destination address of the WLC to assess if the AP is connected to the wired
network. If the rogue is detected to be on the wired network, then the alarm severity for that rogue AP is
raised to critical.

The algorithm of RLDP is as follows:

1. Identify the closest Unified AP to the rogue using signal strength values.
2. The AP then connects to the rogue as a WLAN client, attempting three associations before timing out.
3. If association is successful, the AP will then use DHCP to obtain an IP address.
4. If an IP address was obtained, the AP (acting as a WLAN client) will send a UDP packet to each of
the controllers IP addresses.
5. If the controller receives even one of the RLDP packets from the client, that rogue is marked as
on−wire with a severity of critical.

♦ The RLDP packets will not be able to reach the controller if filtering rules are in place
between the controllers network and the network the rogue device is on.

Deployment Recommendation:

RLDP can be deployed on local or monitor mode APs. For most scalable deployment and to eliminate any
impact on client service, RLDP should be deployed on monitor mode APs when possible. However, this
recommendation requires that a monitor mode AP overlay be deployed with a typical ratio being one monitor
mode AP for every five local mode APs. APs in Adaptive wIPS monitor mode can also be leveraged for this
task.

This is an example configuration via the WLC GUI:

Caveats of RLDP:

• RLDP only works with open rogue APs broadcasting their SSID with authentication and encryption
disabled.
• RLDP requires that the Managed AP acting as a client is able to obtain an IP address via DHCP on the
rogue network.
• Manual RLDP can be used to attempt and RLDP trace on a rogue multiple times.
• During the RLDP process, the AP is unable to serve clients. This will negatively impact performance
and connectivity for local mode APs.
• RLDP does not attempt to connect to a rogue AP operating in a 5GHz DFS channel.

Debugging:

Here is a trimmed sample of the debug output of a successful RLDP attempt:

(Cisco Controller) > debug dot11 rldp enable

Received Request to detect rogue: 00:1A:1E:85:21:B0
00:1a:1e:85:21:b0 found closest monitor AP 00:17:df:a7:20:d0slot =1 channel = 44
Found RAD: 0x158f1ea0, slotId = 1
rldp started association, attempt 1
Successfully associated with rogue: 00:1A:1E:85:21:B0
Starting dhcp
00:1a:1e:85:21:b0 RLDP DHCP SELECTING for rogue 00:1a:1e:85:21:b0
00:1a:1e:85:21:b0 Initializing RLDP DHCP for rogue 00:1a:1e:85:21:b0
.00:1a:1e:85:21:b0 RLDP DHCPSTATE_INIT for rogue 00:1a:1e:85:21:b0
00:1a:1e:85:21:b0 RLDP DHCPSTATE_REQUESTING sending for rogue 00:1a:1e:85:21:b0
00:1a:1e:85:21:b0 Sending DHCP packet through rogue AP 00:1a:1e:85:21:b0
00:1a:1e:85:21:b0 RLDP DHCP REQUEST RECV for rogue 00:1a:1e:85:21:b0
00:1a:1e:85:21:b0 RLDP DHCP REQUEST received for rogue 00:1a:1e:85:21:b0
00:1a:1e:85:21:b0 RLDP DHCP BOUND state for rogue 00:1a:1e:85:21:b0
Returning IP 172.20.226.246, netmask 255.255.255.192, gw 172.20.226.193
Found Gateway MacAddr: 00:1D:70:F0:D4:C1
Send ARLDP to 172.20.226.198 (00:1D:70:F0:D4:C1) (gateway)
Sending ARLDP packet to 00:1d:70:f0:d4:c1 from 00:17:df:a7:20:de
Send ARLDP to 172.20.226.197 (00:1F:9E:9B:29:80)
Sending ARLDP packet to 00:1f:9e:9b:29:80 from 00:17:df:a7:20:de
Send ARLDP to 0.0.0.0 (00:1D:70:F0:D4:C1) (gateway)
Sending ARLDP packet to 00:1d:70:f0:d4:c1 from 00:17:df:a7:20:de
Received 32 byte ARLDP message from: 172.20.226.24642
Packet Dump:
sourceIp: 172.20.226.246
destIp: 172.20.226.197
Rogue Mac: 00:1A:1E:85:21:B0
 security: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Manual RLDP:

RLDP can also be initiated manually by using this command (enable RLDP debugging first then disable it
after the RLDP process is complete):

(Cisco Controller) > config rogue ap rldp initiate <rogue mac>

Differences in WLC 4.2 code:

• The ability to restrict RLDP to monitor mode APs only is not present.
• The syntax for initiating the manual RLDP process is:

config wps rogue−ap rldp initiate <rogue mac>

Switch Port Tracing

Switch port tracing is a rogue AP mitigation technique first implemented in the 5.1 release. Although switch
port tracing is initiated at the WCS, it utilizes both CDP and SNMP information to track a rogue down to a
specific port in the network. In order for switch port tracing to run, all switches in the network must be added
to the WCS with SNMP credentials. Although read−only credentials will work for identifying the port the
rogue is on, read−write credentials allow the WCS to also shut the port down thus containing the threat. This
feature currently only works with Cisco switches that run IOS with CDP enabled, and CDP must also be
enabled on the Managed APs.

The algorithm for switch port tracing is as follows:

1. The WCS will find the closest AP, which detects the rogue AP over−the−air and retrieves its CDP
neighbors.
2. The WCS will then use SNMP to examine the CAM table within the neighboring switch looking for a
positive match to identify the rogues location.

A positive match can be based on the exact rogue MAC address, +1/−1 the rogue MAC address, any
rogue client MAC addresses or an OUI match based on the vendor information inherent in a MAC
address.
3. If a positive match is not found on the closest switch, the WCS will continue the search neighboring
switches up to two hops away (by default).

Here is an abbreviated WCS log of a successful switch port trace:

 Switch port tracing started for rogue AP 00:09:5B:9C:87:68
Rogue AP 00:09:5B:9C:87:68 vendor is Netgear
Following MAC addresses will be searched:
00:09:5B:9C:87:68, 00:09:5B:9C:87:67, 00:09:5B:9C:87:69
Following rogue client MAC addresses will be searched:
00:21:5D:AC:D8:98
Following vendor OUIs will be searched:
00:0F:B5, 00:22:3F, 00:1F:33, 00:18:4D, 00:14:6C, 00:09:5B
Rogue AP 00:09:5B:9C:87:68 was reported by following APs: 1140−1
Reporting AP 1140−1 is connected to switch 172.20.226.193
Following are the Ethernet switches found at hop 0: 172.20.226.193
Started tracing the Ethernet switch 172.20.226.193 found at hop 0
Tracing is in progress for Ethernet switch 172.20.226.193
MAC entry 00:09:5B:9C:87:69 (MAC address +1/−1) found.
Ethernet Switch: 172.20.226.193, VLAN: 113, Port: GigabitEthernet1/0/33
Finished tracing all the Ethernet switches at hop 0

Once completed, the result can be viewed at the WCS:

In order to disable the port and mitigate the thread, simply uncheck the box next to the Interface and click
Enable/Disable Switch Port(s). The WCS will also allow you to enter an interface description so this
modification to the wired network can be tracked.

Rogue Mitigation
Rogue Containment

Containment is a method of using over−the−air packets to temporarily interrupt service on a rogue device
until it can physically be removed. Containment works by spoofing de−authentication packets with the source
address of the rogue AP so that any clients associated are kicked off.
Rogue Containment Details:

• A containment initiated on a rogue AP with no clients will only use de−authentication frames sent to
the broadcast address:

• A containment initiated on a rogue AP with client(s) will use de−authentication frames sent to the
broadcast address and to the client(s) address:

• Containment packets are sent at the power level of the managed AP and at the lowest enabled data
rate.
• Containment sends a minimum of 2 packets every 100ms:

Note: In the 6.0 release, a containment performed by non−monitor mode APs is sent at an interval of
500ms instead of the 100ms interval used by monitor mode APs.
• An individual rogue device can be contained by 1 to 4 managed APs which work in conjunction to
mitigate the threat temporarily.
• Containment can be performed using local mode, monitor mode and H−REAP (Connected) mode
APs. For local mode of H−REAP APs, a maximum of three rogue devices per radio can be contained.
For monitor mode APs, a maximum of six rogue devices per radio can be contained.
Auto−Containment:

In addition to manually initiating containment on a rogue device via WCS or the WLC GUI, there is also the
ability to automatically launch containment under certain scenarios. This configuration can be found under
General in the Rogue Policies section of the WCS or Controller interface. Each of these features is disabled by
default and should only be enabled to nullify the most damaging threats.

• Rogue on Wire If a rogue device is identified to be attached to the wired network, then it will
automatically be placed under containment.
• Using our SSID If a rogue device is using an SSID which is the same as that configured on the
controller, it will automatically be contained. This feature aims to address a honey−pot attack before it
causes damage.
• Valid client on Rogue AP If a client listed in ACS is found to be associated with a rogue device,
containment will be launched against that client only, preventing it from associating to any
non−managed AP.
• AdHoc Rogue AP If an ad−hoc network is discovered, it will automatically be contained.

Rogue Containment Caveats:

• Because containment uses a portion of the managed APs radio time to send the de−authentication
frames, the performance to both data and voice clients is negatively impacted by up to 20%. For data
clients, the impact is reduced throughput. For voice clients, containment can cause interruptions in
conversations and reduced voice quality.
• Containment can have legal implications when being launched against neighboring networks. Ensure
that the rogue device is within your network and posing a security risk before launching the
containment.

Rogue Location

When a rogue device is heard by multiple managed APs, its location can be estimated and shown in the maps
section of the WCS. Both local mode and all forms of monitor mode APs assist in collecting location
information. The accuracy of this information is dependent on the density and placement of your APs.

Location with WCS−Only:

When the WCS is running without a Cisco Location server or MSE running Context Aware, up to one rogue
at a time can be located on−demand in the WCS. By browsing to the rogue detail record and then selecting
Map, the rogues estimated location will be shown on the floor plan.

This is an example of a WCS displaying the location of one rogue AP:

Location with Context−Aware:

When the WCS is paired with a Location Server or MSE running Context−Aware, it allows multiple rogue
devices to be track in real−time and historically up to the licensed device count. With the 6.0 release,
customers can run both Context Aware and Adaptive wIPS simultaneously on the same Mobility Services
Engine. The real−time location tracking includes rogue APs, rogue ad−hocs and rogue clients which can be
simultaneously displayed on a floor map in the WCS. In addition, the location history is archived for a default
of 30 days allowing playback of past device locations.

This is an example of a WCS displaying location information for multiple rogue devices:

Related Information
• Rogue Detection under Unified Wireless Networks
• Rule Based Rogue Classification in Wireless LAN Controllers (WLC) and Wireless Control
System (WCS)
• Cisco Wireless LAN Controller Configuration Guide, Release 5.2
• Cisco Wireless Control System Configuration Guide, Release 5.2
• Technical Support & Documentation − Cisco Systems

Contacts & Feedback | Help | Site Map

© 2009 − 2010 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.

Updated: Jul 21, 2009 Document ID: 110556