System does not detect a rogue AP on the network.

Unanswered Question

After extensive conversations with TAC, I have come to discover that you cannot rely upon the system to tell you if a rogue AP is on the network. This is true EVEN WITH AN AP CONFIGURED FOR OPEN AUTHENTICATION. I have tested this in-house with a rogue AP through which I could ping my trusted APs (same subnet) while it was briefly connected to our network (as in greater than 15 minutes) and the system does not detect that the rogue AP is on the network.

According to some extensive research on the part of TAC, that is the way it is SUPPOSED to function (MALfunction) unless you want to dedicate an AP as a scanner!

Maybe others have had better success and I would be interested to hear any other experiences pro or con. However, I have been told that this is the way it is supposed to work and the system may NEVER detect that it is on the network.

(not exactly as advertised...)

- John

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
krauskopf.p Wed, 08/08/2007 - 07:35

Hi,

we are experimenting with that rogue feature too. Especially because we want to know, how that works, which type of protocol are used for informing the controller. Because it is annoying to know, that the controller received a packet which indicates an active rogue on your LAN, but you dont know where that packet came from... :-/

Yesterday I took an autonomous AP1240, set up a test WLAN and connected it to a switch. I only got an normal yellow rogue alert. That thingie was online for some hours.

Today I simply turned it on again an I got a red rogue-on-wired-alert within minutes. WTH???

Turned it off, commenced an rogue scan via backgroud tasks, it stayed red. Turned it on but disconnected the connection to the switch, commenced another manual rogue scan, it still stayed red.

Now I want to know, what data sends the rogue AP to your networks which is used to identify it as a rogue-on-wired AP?

We use no additional AP as Rogue detector.

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.

Please note that according to the release notes for WLC ver 4.1.185, it turns out that there has been a known problem with detecting rogue APs on the network. This bug is supposed to be fixed in WLC version 4.1.185:

" CSCsh73667 ? Controllers running software release 4.1.171.0 might not detect a rogue access point on the wire through the Rogue Location Detection Protocol (RLDP)."

I will be performing some testing to see if this is actually detected properly.

- John

It is disappointing to note that the release notes for 4.1.185 (erroneously labled "4.1.181") that RDLP is supposed to be disabled because if you turn it on the WLC can reboot repeatedly 5 minutes after a restart (see bug CSCsi81630). Therefore, Cisco recommends disabling RDLP... presumably until they get the reboot bug resolved.

John

Hey John,

I have had some success in finding Rogues with RLDP and Rogue Detector mode APs. RLDP is an active process: it actually makes the AP act as a client, associating to open auth APs, obtaining an IP and informing the WLC. I have seen this work, as the RLDP client actually uses an incrementing DNS name (rldp, rldp1, rldp2). This however can cause its own issues, as in doing so it can knocks off active clients in the process. This is mentioned (deep) in the release notes. Becuase of this we have turned this "feature" off on all but experimental controllers and APs.

FYI - you can have an AP in Local mode and with WLAN Override have no SSIDs advertised, thereby allowing the AP to perform RLDP in "stealth mode." Of course, you need a separate controller to run these separate from your data-serving APs. Not too convenient, it should be something you can configure on a per-AP basis. Unfortunately you are "locked in" to separate controller hardware to use several one-off fetures until the software is more flexible.

What's been your experience with AirMagnet Enterprise in finding Rogue APs and clients? We're deliberating whether to use more Cisco infrastructure for this purpose, but their sensors offer a lot more overall functionality, including the holy grail of identifying Rogue AP switchports. Please let me know if you would consider discussing this off-channel.

Regards,

--Bruce Johnson

dknov Wed, 02/13/2008 - 17:07

Hi,

This is very interesting discussion. I have a novice question about rogue detection.

Are different modes AP operates in dictate how rogue detection is going to be carried out?

How does legit AP association to rogue AP, ARP packets sniffing, broadcase packets sniffing and SNMP from controller to switches all comes together in this process?

Thank you!

David

Actions

This Discussion

 

 

Trending Topics - Security & Network