From our testing, I have observed that, even prior to enabling RDLP, the WCS screen would show the test rogue AP (not client) in under five minutes, often sooner than that. This seems to work pretty well without having to use an AP in monitor mode.
As for as finding the rogue client, this takes much longer than expected and, as we discussed, did not seem to recognize the "rogue" PDA client, though it did find the "rogue" laptop client (the detection mechanisms are listed at the end of this post).
One of my concerns is, in terms of a man-in-the-middle attack, isn't the danger that when the rogue AP appears, the trusted clients will quickly & automatically roam to the stronger signal? It sounds as if the roaming event and the client count could be missed and/or might not be detected for up to four hours after the roam. The attacker would have packed his bags and left by then.
The explanation of the "rogue detector" mechanism only looking at gratuitous arps may explain why it takes so long to find the client, but aren't there other ways to see if a rogue AP has a client? In other words when rogue APs are present, isn't there some kind of diagnostic mode that could devote more time to getting this information (even if only on demand by the admin - but without having to drop a coverage zone by repurposing an AP to be a monitor)? When I run AirMagnet, I can see these clients in a very short time (within a minute or less) so this is technically possible to do.
Changing an AP over to monitor mode means dumping users off since, in most cases, the customer did not have the budget for extra APs. Apparently, at this time, there is no to place a request to the AP to scan for this information more intensively without taking down the AP in monitor mode - such as when the rogue AP is first detected or on demand by the admin.
It would seem that the admin needs to understand the following: The WCS screen shows what has been detected, but not necessarily what is really out there.
This is the case both for On-Network APs as well as for rogue APs / AD HOCs that show "0" rogue clients.
Putting too much stock in these "0" values can give you a false sense of security.
- John
============
Here is some information from Cisco TAC on this:
1. Assuming that there is no AP in monitor mode, it takes 3 to 6 minutes for controllers to detect a rogue client. This is because the AP has to scan off channel and it must see the rogue client at least 3 times before reporting it as a rogue AP.
2. Once the Ap is determined to be a rogue AP on the controller, it will then begin scanning for any clients associated to the AP - not before that.
There are 3 ways to detect rogue Aps:
1. Ap in monitor mode (sits and scans all channels. Can detect rogue Aps under 30 seconds) 2. RLDP (done passively from normal Aps. Can take up to 15 minutes to detect rogue AP) 3. Rogue Detector (looks for broadcast packets from wireless clients on wired network)
Monitor mode is the quickest way to detect rogue Aps. It is constantly scanning the channels. Once the AP is declared a rogue AP, the controller will begin looking for clients associated to it. It can typically detect rogue Aps in under 30 seconds.
RLDP takes the longest amount of time because normally Aps do not go off channel to look for rogue APs. Since the AP must see the rogue Ap 3 times before alerting, this will take the quite some time. Only after the AP has been marked a rogue on the controller, will the controller search for clients associated to the rogue AP.
Finally, Rogue Detector works by looking for broadcast traffic from the rogue AP client. But it does not start looking until the AP has been declared a rogue AP by the controller. Typically the wireless client has already ARPed for the default gateway so it may not detect it again until the gratuitous ARPs occur 4 hours later.
