cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7670
Views
5
Helpful
28
Replies

APs being contained as rogues by an external system

williamg
Level 1
Level 1

A rogue containment policy is being initiated against my organization's APs and I do not have the tools/knowledge necessary to track down its point of origin. What tools or steps are required to identify who is containing an AP?

Thanks

28 Replies 28

Leo Laohoo
Hall of Fame
Hall of Fame

Look at your logs. You should be able to see what SSID/MAC address is attempting to contain your AP/SSID.

Find out who they are and see them to see if they can lift the blockade.

Either I don't know what I'm looking for (possible) or the information you suggested to look at is not being included my logs.

I have the log entries that indicate when an AP is being contained, but it does not provide much useful info.

Sample Log entry:

Mar 11 20:25:03 xxx.xxx.xxx.xxx WLC: Mar 12 08:29:56.527 spam_lrad.c:20045 LWAPP-1-AP_CONTAINED: AP ABC123 is being contained on slot 0

Errr ... this means that YOUR AP is containing AP ABC123. I hope your AP is NOT ABC123.

Actually, it is. Why would a wireless controller be containing an infrastructure AP that it manages? That just doesn't make sense.

I agree. I see this on our networks as well. I am interested to see what everyone says about it. Are you doing containments?

Rogue identification and containment is discussed in detail at the link below.

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080722d8c.shtml

look this over and ask any questions you might have. This document explains how rogues are identified and how they are contained once they are identified as a threat.

Mr. Bentley,

For rogues connected directly to our physical network, yes. Otherwise, there are legal ramifications about interfering with neighboring wireless systems and we do not want to make that mistake. Therefore, we simply have our system monitor and report rogues then act on them *manually* if necessary.

William,

I totally agree that one must MANUALLY contain rogue AP/Client/Ad-Hoc.

However, I've seen in previous firmware of a bug that even your own AP connected to the same WLC was classified as a "honeypot" and thus a potential threat.

Look at your Wireless Protection Policies and make sure that auto-contain of Rogues are disabled. (Security, Wireless Protection Policies, Rogue Policies, General)

Just in case someone from your organization acted upon this, go to Monitor, Malicious AP and click on the Remove option found on the right.

leolaohoo,

To which platform and software version are you referring with regards to the bug? We have a 4402 running IOS version 4.2.x and a WCS server running 5.1.x

I've verified that auto-containment has been disabled and there are no disabled APs. Also, there are only two individuals that have access to the system; one of whom is me (obviously).

Finally, the APs being affected are not being contained all the time. They are only intermittently contained--sometimes for a few hours--then are accessible once more. I don't believe it is a coincidence that one of our most heavily utilized APs is also the one that is most frequently affected. For this reason, I do not believe the issue is internal to the system. I still have a nagging feeling that the containment is malicious in nature.

Pull the mac address of the malicious rogue. Send the log over to me and Ill look at it direct. You might be running into a duration value issue in conjunction with a Meru deployment close by.

Mr. Scholmes,

This is where I show how much I DON'T know about the wireless controller. None of the log entries pertaining to this issue (that I can identify) indicate a MAC address of any kind. Would you mind providing a sample entry so I can get an idea of what to look for?

under the event logs on the summary page of the controller. You should see a message something like Alert: IDS 'Disassoc flood' Signature attack detected on AP '' protocol '802.11b/g' on Controller 'x.x.x.x'. The Signature description is 'Disassociation flood', with precedence 'x'. The attacker's mac address is 'hh:hh:hh:hh:hh:hh', channel number is 'x', and the number of detections is 'x'

If this is what you are seeing it was a known bug in early versions of 4.0 code.

Thank you, Mr. Scholmes.

I see that message quite often in the log entries and knew they were caused by a software bug, but I did not know it was associated with containment entries looking like this:

"AP '00:00:00:00:0:00' with protocol '802.11b/g' on Controller 'xxx.xxx.xxx.xxx' is contained as a Rogue preventing service."

According to our logs, there were no disassociation floods within four hours of the containment event.

I am gathering from this discussion and the material you provided earlier that upgrading to 5.2.x would help reduce false positive event entries, and thereby help us determine whether containment events are "authentic". Is this correct?

I am getting confused here. The AP that is contained is not yours right? When an AP is marked as a rogue its mac address is listed on the controller as an AP heard wirelessly that has no bvi mac regisitered on the controller. This message tells me you have contained a rogue device your network is seeing. Not the other way around.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: