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

[kfarrington]

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

[ericgarnel]

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]

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.

[sajid gul]

Can you please help me on the following case 

https://supportforums.cisco.com/users/engrsajidkhan

[kfarrington]

Thx guys, that is much help :))

[johnruffing]

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]

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]

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]

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]

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]

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]

Jerome,

Many thx indeed. That is most helpful :)

Kindest regards,

Ken

[kfarrington]

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]

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]

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