WLC "rogue containment" - What does it actually do?

Unanswered Question
May 8th, 2008

Hi All,

I have read the part of the WLC config guide about rogue containment, but what does it actually do?

It says it sends deauth and deassoc frames to clients of rougue access points. This to me actually seems like we are performing a DOS on another neighbors WLAN?

Can anyone confirm what it actually does in detail?

Does it send deauth messages to a "neighbors APs clients" dis-authenticating it from the "neighbors AP", thus causes the client to lose his own connection to his legitimate AP, or does it send de-auths that say, just dont come near my AP (on my network) ????

What is the frequency of packets that get sent to the neighboring APs clients?

Does it send these frames to a broadcast or unicast MAC?

Does it send these frames to other neighbor rougue APs or just clients?

Is there any legal ramifications of doing this, ie, can you be prosecuted?

Is this the only containment method that Cisco Support?

And, any other info/documentation that anyone may have on this?

Many thx indeed, for all the kind help so far :))

Ken

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.7 (8 ratings)
Loading.
ericgarnel Thu, 05/08/2008 - 11:11

A lot of good questions, some of which may require the use of a sniffer to answer.

Here is some good info though,

from:

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

I have been lazy and just pointing at urls, but, hey, an answer is an answer.

Rogue Location Discovery Protocol (RLDP)

RLDP is an active approach, which is used when rogue AP has no authentication (Open Authentication) configured. This mode, which is disabled by default, instructs an AP to move to the rogue channel and connect to the rogue as a client. The AP then tries to obtain an IP address and forward a User Datagram Protocol (UDP) packet (port 6352) that contains the local AP and rogue connection information to the controller through the rogue AP. If the controller receives this packet, the alarm is set to notify the network administrator that a rogue AP was discovered on the wired network with the RLDP feature.

Note: Use the debug dot11 rldp enable command in order to check if the Lightweight AP associates and receives a DHCP address from the rogue AP. This command also displays the UDP packet sent by the Lightweight AP to the controller.

A sample of a UDP (destination port 6352) packet sent by the Lightweight AP is shown here:

0020 0a 01 01 0d 0a 01 .......(.*...... 0030 01 1e 00 07 85 92 78 01 00 00 00 00 00 00 00 00 ......x......... 0040 00 00 00 00 00 00 00 00 00 00

The first 5 bytes of the data contain the DHCP address given to the local mode AP by the rogue AP. The next 5 bytes are the IP address of the controller, followed by 6 bytes that represent the rogue AP MAC address. Then, there are 18 bytes of zeros.

Passive Operation:

This approach is used when rogue AP has some form of authentication, either WEP or WPA. When a form of authentication is configured on rogue AP, the Lightweight AP cannot associate because it does not know the key configured on the rogue AP. The process begins with the controller when it passes on the list of rogue client MAC addresses to an AP that is configured as a rogue detector. The rogue detector scans all connected and configured subnets for ARP requests, and ARP searches for a matching Layer 2 address. If a match is discovered, the controller notifies the network administrator that a rogue is detected on the wired subnet.

Active Rogue Containment

Once a rogue client is detected on the wired network, the network administrator is able to contain both the rogue AP and the rogue clients. This can be achieved because 802.11 de-authentication packets are sent to clients that are associated to rogue APs so that the threat that such a hole creates is mitigated. Each time there is an attempt to contain the rogue AP, nearly 15% of the Lightweight AP's resource is used. Therefore, it is suggested to physically locate and remove the rogue AP once it is contained.

I believe it only sends de-auths

The frequency should be the same as the one the rogue is detected on

I believe it is just to the clients

Yes, there are legal ramifcations for everything

It is the main type of "automatic" containment on the wireless. You could make use of manual forms of containment and/or prevention

dennischolmes Thu, 05/08/2008 - 14:01

Eric is correct here. There is one other caveat to be considered. When containing either through RLDP or manually, the number of APs performing the containment make a significant difference in the effectiveness of the containment. A 4 AP containment sends deauths from 4 APs and mathematically insures that client will not attach to the rogue AP. Always remember the FCC good neighbor policy and be sure that the rogue is actually a threat to your network (hardwired to your network). All those rabid coffee drinkers at Starbucks would be pretty ticked off if you blocked their mrning emails with coffee.

Ken:

Let me share one other caveat which was a surprise when I learned about it:

According to Cisco TAC, containment is a tool for the PREVENTION of new associations of clients with rogue APs. Clients that are ALREADY connected to the rogue AP will not be affected by containment.

Also, unless there is a sufficient level of traffic between the associated client and the rogue AP, the wireless system will not be able to detect the presence of the client on the rogue AP.

Therefore, just because the system says that a rogue AP has no clients attached to it - you can't accept that as absolutely true.

While containment will not force associated clients off of a rogue AP, it can still be a valuable tool to prevent future clients from attaching to rogue access points / adhocs.

- John

(Please remember to rate helpful posts)

dennischolmes Tue, 05/13/2008 - 14:57

Somebody at TAC is mistaken. Deauthentication packets are sent to the clients with the spoofed mac address of the rogue AP. I do this in the lab and on demos weekly. Get yourself a linksys, set a laptop to a constant ping on that linksys, and then contain it with 4 APS. You will clearly see the packets drop and until you stop the containment you will see no ping replies. Deauth packets are just that. They tell the client it has been deauthenticated. Containment has no other methodolgy to contain. Let me know the TAC Engineer's contact info please and I will clarify that with them.

kfarrington Wed, 05/14/2008 - 08:50

Hi all Again :)

So, I have found myself a little linksys and put it in range of one of my LWAPs on my wireless network. I will sniff this tomorrow as I have left my airmagnet at home, but can we clarify that this diagram is correct?

Many thx indeed,

Ken

jeromehenry_2 Wed, 05/14/2008 - 10:22

Your diagram looks correct... 2 tiny things to keep in mind:

1. Your client needs to be in range of your valid AP. You spoof the rogue AP's MAC, but of course your valid AP is at at different physical location. Sometimes if your AP is too far from the client, you hear the rogue, but the client doesn't hear your deauth...

2. You have to manually deauth, it's not automatic...

Have fun

Jerome

dennischolmes Wed, 05/14/2008 - 14:13

One other little tid bit I mentioned earlier. Do NOT contain local businesses that are not a direct threat to your network. This is a direct violation of the FCC good neighbor policy. When you send deauth packets all clients attached to the rogue get those and are dropped. Not just your clients. Contain with care my friend. If the local coffee shop is a problem then set your clients to only attach to a particular list of APs by mac address. This will keep them home where they need to stay and will not get the FCC and a bunch of lawyers on your case.

kfarrington Wed, 05/14/2008 - 23:28

Thanks to both of you for your kind comments.

The "FCC good neighbor policy" for the USA.

I am looking on the http://www.fcc.gov/telecom.html

But is very hard to find the document. I assume this is just an advisory, and does anyone know of any such other policied in other regions?

Once again, many thx indeed for all the help thus far :)

Ken

kfarrington Thu, 05/15/2008 - 00:47

Hey guys, just tested this.

It does exacly what you guys say :))

When I just use no authentication (open network) it just drops a couple of packets here and there. When I enable wpa2 on the linksys, it eventually disconnects the connect client (about 3-5 minutes) and then the client cannot connect to the linksys anymore.

Cool stuff guys :)))))

Scary tho......

Does this sound about right to you guys as you are the subject experts?

Many thx

Ken

kfarrington Thu, 05/15/2008 - 01:26

Correction: When you enable WPA2, it only takes about 30 seconds or less to disconnect the client after further tests.

All de-auth packets coming from the WLC (via the AP) have the spoofed mac address of the linksys :))

Thx

Ken

jeromehenry_2 Thu, 05/15/2008 - 02:52

Hihi, glad to see it works!

Usually, the stronger the encryption mechanism, the more often client renews its key, the easier the containment...

Each regulatory domain has different sets of rules, but most of them condemn blocking other people's network if they are legitimate networks... so yes, use with caution, only for direct threats...

With CCX5 and the Cisco MFP, Cisco clients in Cisco networks will be immune against this type of containment...

Jerome

ericgarnel Thu, 05/15/2008 - 05:01

Just an observation....

We see a lot of linksys wifi routers that exhibitors bring in for their booths during events at the convention center.

We will get a call on the radio that they are having trouble with their connection and sure enough, they have their wireless enabled on their router.

The linksys router will bog down to a crawl and even become completely unresponsive from either the wireless or wired side.

We have them turn off their wireless and the router is fine for the rest of the time. The more recent linksys routers seem to be affected more. We will occasionally see other retail brands, but for the most part, the majority of wifi routers are linksys.

We do not make use of containment at it takes away from radio performance, but the default effect of our high density wireless upon linksys routers does help "contain" rogues!

elemzy Thu, 08/27/2015 - 09:57

Hi Eric,

Sorry to wake this thread after 7years. Im wondering "how do I stop a wireless containment war".

Imagine this scenario, company A has its client a and company B has client b, both companies sharing the same building. So coy A sends de-authenticate packets to B because it doesnt want its users to connect to B or it just does not tolerate other SSIDs in its environs.Coy B does the same thing. So both company ends up with non-working wireless.

Another situation is that a crazy staff brings in this smart device that can send de-auth packet to my company's AP.

Question is, does Cisco WLC have a feature to ensure that legitimate client stay connected irrespective of de-auth packet from another AP?

Jerome Henry Thu, 08/27/2015 - 15:36

Hi Elemzy,

 

Few comments to clarify the behavior:

- when you choose to contain a "rogue SSID", a message warns you that this could have legal consequences. What this means is that you do not have the right to contain a legitimate network. In the scenario you describe, both companies would be at fault, because each is trying to block a legitimate other network. Recent examples with various brands show that when the FCC is called for help for such illegal behavior, the fine can be expensive for the offender. Containment is solely for situations where the rogue is in your facility (and if you are not sure... well you should make sure before you contain :-)). Containment is not automatic, but a conscious admin choice.

- There are mechanisms (RLDP, rogue on wire) to help you decide if the rogue is on your network or not.

- There is no mechanism to resist a deauth (it is part of the protocol). However, there is a protocol called 802.11w (also known as PMF, for which Cisco has a more elaborate and older solution called MFP) that allows the AP and the clients to agree on a hash, and therefore ignore any external deauth message. This would effectively achieve the protection you describe.

 

hth

 

Jerome 

Saravanan Lakshmanan Sun, 09/06/2015 - 01:12

#802.11w/mfp doesn't work with open/tkip/wep enabled wlan. It works only with WPA2-PSK or WPA2-802.1x. 802.11w supported from WLC code 7.4.
#Some clients doesn't honor Broadcast deauth and can be contained only using Unicast deauths :)
#Alternatively, attacker can spoof wireless client MAC and send de-auth attack to its connected AP :)

FCC fine on Rogue containment:-
http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/

It requires the WLAN environment ie., WLC code and wireless clients that supports 802.11w.
#client mfp support require ccxv5 certified clients.
#802.11w is supported by win 8 or higher only.
#Device Classification Guide - Look for 802.11w support
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/d...

#Restrictions for 802.11w:-
http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configurati...

Actions

This Discussion

 

 

Trending Topics - Security & Network