APs being contained as rogues by an external system

Unanswered Question
Mar 10th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2.5 (2 ratings)
Loading.
Leo Laohoo Tue, 03/10/2009 - 14:56
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

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.

williamg@otc.edu Thu, 03/12/2009 - 07:31
User Badges:

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


Leo Laohoo Thu, 03/12/2009 - 16:44
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

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

williamg@otc.edu Fri, 03/13/2009 - 07:19
User Badges:

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

dbentley Fri, 03/13/2009 - 09:54
User Badges:

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

williamg@otc.edu Fri, 03/13/2009 - 14:14
User Badges:

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.

Leo Laohoo Sun, 03/15/2009 - 15:18
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

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.

williamg@otc.edu Tue, 03/17/2009 - 07:49
User Badges:

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.

dennischolmes Tue, 03/17/2009 - 10:36
User Badges:
  • Gold, 750 points or more

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.

williamg@otc.edu Tue, 03/17/2009 - 11:15
User Badges:

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?

dennischolmes Tue, 03/17/2009 - 12:01
User Badges:
  • Gold, 750 points or more

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.

williamg@otc.edu Tue, 03/17/2009 - 12:22
User Badges:

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?

dennischolmes Tue, 03/17/2009 - 13:51
User Badges:
  • Gold, 750 points or more

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.

williamg@otc.edu Tue, 03/17/2009 - 14:27
User Badges:

If that is true, then our system is indeed containing its own APs for the MAC address listed is that of one it manages.


leolaohoo mentioned a firmware bug in the controller could be causing this in a previous post. It sounds as though I need to take this issue to TAC.

Leo Laohoo Tue, 03/17/2009 - 14:51
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

I don't remember what firmware or the bug ID but the early versions of firmwares (4.x and 5.0.x) would say something like "... potential Honeypot AP ..." and if you look at the MAC address of this AP, it's actually another one of your LAP.


Regarding your Rogue AP, can you go to Monitor -> Rogues -> Malicious APs and base on the MAC Address see if you have the Rogue AP is in the list. If the Rogue AP is in the list, then your WLC will automatically contain it when the Rogue AP starts transmitting. You have the option to remove the AP from the list.

dennischolmes Tue, 03/17/2009 - 19:52
User Badges:
  • Gold, 750 points or more

I will try to get hold of you tomorrow at work. I suspect what you are seeing might be a man in the middle attack.

mlieber Mon, 03/30/2009 - 08:00
User Badges:

Hi Dennis,

I would like to know if you had found out the reason for the containment.

Actually we have the same issue.


*Mar 26 09:44:42.498: %LWAPP-1-AP_CONTAINED: spam_lrad.c:21271 AP AP3 is being contained on slot 0

*Mar 26 09:43:24.676: %LWAPP-1-AP_CONTAINED: spam_lrad.c:21271 AP AP30 is being contained on slot 0

*Mar 26 09:41:30.437: %LWAPP-1-AP_CONTAINED: spam_lrad.c:21271 AP AP30 is being contained on slot 0


Thanks

Martin

waynesymes Wed, 03/18/2009 - 06:12
User Badges:

William,


I don't know if you've tracked this down to being a bug or not. But earlier this year I was getting the same alerts from one of my sites, intermittent, off and on etc. It plagued us for a few months. Long story short, required a site visit. I went on site and using AirMagnet Laptop Anyalizer was able to trace the deauth frames to one of our Neighbors who it turns out had recently installed CUWN and was containing our AP. They had 2 or 3 AP's participating in the containment. When a AP is containing you it will spoof your AP's MAC so that it looks like the Deauth frames are being sent by your own infrastructure.

mlieber Mon, 03/30/2009 - 03:30
User Badges:

Hello,

we have exact the same problem.

Our LWAPs are being contained.

There are two other Access Point vendors in the environment, one Cisco autonomous AP and one AVM Home Office AP. Both are not able to contain other access points.

Do you have got a solution for your problem?

thanks

Martin

williamg@otc.edu Mon, 03/30/2009 - 08:59
User Badges:

At this point the containment has ceased, but the cause has not yet been determined. The intermittent nature of the issue is making it very difficult to troubleshoot.


Cisco TAC has yet to respond to my inquiry.

Leo Laohoo Mon, 03/30/2009 - 15:18
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

Hi Martin,

Make sure Auto-Contain Rogue AP is not enabled.


Can you verify that your WLC is not manually containing your own AP?

patoberli Fri, 04/09/2010 - 08:32
User Badges:
  • Silver, 250 points or more

I currently have this weird issue too

I have no idea why. It started yesterday and continued today. I know that some people are in that area playing around with some Zigbee RFID tags, but I don't think that should make a problem?


Here from the controller logfile:

wism-1250-2: *Apr 09 14:40:03.582: %LWAPP-1-AP_CONTAINED: spam_lrad.c:25558 AP 1200b-6106-1 is being contained on slot 0


Containment is after around 1 minute over (WCS sends two mails, one with containment and one with CLEAR). I don't know if the users have some issues because of this, so far only one complained, but that could also be because he's using an Apple and not a stadard client.


The controller logfile doesn't show a "resolve" of the containment.

Auto containment of rogues is disabled on the controller.


Any ideas? Or did you ever receive an answer from your tac case?


Thanks,
Patrick

Leo Laohoo Fri, 04/09/2010 - 15:51
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

What firmware is your WLC?  I know that in the 5.X firmwares would report that your own AP is a rogue AP or a honeypot AP.  This is ok because we disabled (by default) auto-contain of rogue APs.  How about you?

patoberli Sun, 04/11/2010 - 23:39
User Badges:
  • Silver, 250 points or more

Oh I somehow forgot to mention the release. It's software version 6.0.188.0.

mlieber Mon, 04/12/2010 - 01:49
User Badges:

We have 17 Access Points in our environment and 2 SSIDs.

As we disabled 10 APs the containment stopped but at the moment we enabled the APs the containment started again.


A few weeks ago we updated the WLC to 6.0.188. and it seems that the containment doesn't happen. Actually all 17 APs are enabled.

The old software was 5.1.


Do you have a dense AP environment?

patoberli Mon, 04/12/2010 - 01:57
User Badges:
  • Silver, 250 points or more

It is a dense setup, but not there where it's happening. I have there only like 2 accesspoints in a wide area with walls between them.

But I do have some RFID tags and scanners there (or actually the company there has) which are also sending in the 2,4GHz range. They do use their own protocoll, so the Accesspoints only see them as noise.

peterjcowley Tue, 12/13/2011 - 12:05
User Badges:

I've been seeing this same problem with one of our APs. The AP is managed on a 5505 WLAN Controller running software version 7.0.116.0.


Message:       ASBN-WLC7: *spamApTask1: Dec 13 13:48:08.641: %LWAPP-1-AP_CONTAINED: spam_lrad.c:27637 AP SFONW-Quad-D is being contained on slot 0


On the WLAN Controller [ASBN-WLC7]

     Security

          Wireless Protection Policy

               Rogue Policy

                    General 

RLDP - disabled

None of Auto Contain option enabled.

Actions

This Discussion

 

 

Trending Topics - Security & Network