RE: Cisco Wireless Rogue Containment

RLDP is not used to Deauth the clients. RLDP is used to figure out whether
or not Rogue AP is connected to your wired network. RLDP is not on by
default. If RLDP is on, RLDP process runs once per Rogue AP. RLDP doesn't
work with WPA/WEP rogue APs. RLDP works with Wireless Router rogue APs.

RLDP process. Turn a managed AP into a fake client that associates to a
Rogue AP, gets DHCP IP and sends RLDP packets to the WLC. If WLC sees those
packets, then the Rogue AP is attached to your network. Bad thing. RLDP
stops here. Now you want to contain them or shutdown the port. If it's not
connected to your network, then you don't want to contain because of legal
issues.

Containment (deauth) is a separate process that you can initiate manually or
use auto-containment in 5.x/6.x. You are basically telling controller to
pick any of your managed one or more APs that are close to Rogue AP and tell
those APs to send deauth frames to the rogue AP or to the rogue clients.
This has nothing to do with RLDP.

Yes, that's the problem with containment. If you want containment to be
effective, you need to leave it on permanently, otherwise rogue clients will
reassociate if you turn off containment. This wireless containment process
is not good for AP's performance.

Rogue AP detector serves exactly the same purpose as RLDP, but it works with
WPA/WEP rogue APs and it doesn't work with Wireless Router (NAT) rogue APs.
Same goal. You want to detect if Rogue AP is attached to the wired LAN.
Rogue AP detector has its radio disabled.

Containment should have worked in your case. You need to try to contain your
rogue client (under clients in WLC) instead of your rogue AP. See if that
works.

Roman Rodichev

6xCCIE #7927 (R&S, Security, Voice, Storage, Service Provider, Wireless)

Instructor, Content Developer

ieMentor Corporation <http://www.iementor.com/> http://www.iementor.com

Y!M: roman7927

From: Dane Newman [mailto:dane.newman_at_gmail.com]
Sent: Saturday, August 08, 2009 11:48 PM
To: Roman Rodichev
Cc: Cisco certification
Subject: Re: Cisco Wireless Rogue Containment

Wow Roman Thank you so much for that post that was so helpful.

So correct me if I am wrong but situationally the wlc can do the following:

If the rogue is open and connected to the wired network:

RLDP can be used to deauth the clients

If the rogue is open and not connected to the wired network:

Can RLDP be used here to deauth the clients but not send the udp packet back
to the WLC? Is the UDP packet sent only purpose to populate the Is the
rogue connected to the wired network field?...also you said it only does
this one per a rogue detection. So if it goes ahead and does this then the
clients rejoin a few mins after what is the purpose? It would have just
disconnected them once and they rejoin after?

If the rogue has security WPA or WEP and connected to the wired network:

Rogue AP Detector can be used but it only detects if the rogue AP is
connected to the wired network does not do anything to remediate the
problem. If a WCS is there it can be used with switchport trancing to
shutdown the port. The issue that clients are still connected though can be
solved with wireless contrainment sending deauth packets to the clients?

If the rogue has security and is not connected to the wired network:

Deauth packets can only be sent to clients through wireless containment this
is the only feature that works in this situation correct?. Does it
continously do this how often are deauth packets sent? Through my tests I
was able to still stay connected to the ap when I was using two 1130's to
contain the wireless network I was attached too. So my laptop must be
automatically connecting again? Is there any defense against this if
containment?

Once again thanks so much Roman for your time

Dane

On Sun, Aug 9, 2009 at 12:05 AM, Roman Rodichev <roman_at_iementor.com> wrote:

Dane, this is from my post on another forum, so excuse me if I'm not
answering your questions directly... also, just to clarify DEAUTH frame is a
management frame, so it's not encrypted. Therefore, containment works just
fine on WPA/WEP rogue AP's and rogue clients. It's the RLDP process that
will not work with rogue AP's that are using WPA/WEP.

There are three parts to this:

1. detect - automatic

2. classify - by default APs are untrusted/unknown, various methods can be
configured to classify them as trusted and threat (connected to wired
network).

3. over the air contain (aka mitigate) - in 4.x this is manual, in 5.x you
can configure auto-containment

First you need to detect. WLC does this automatically out of the box. It
listens the air for unknown APs, clients and ad-hocs. Are you seeing Rogue
APs under Monitor > Rogues > Rogue APs?

Next, you can manually classify rogue APs as "known" (internal or external).
Starting with 5.0 you can also build rogue rules based on RSSI, SSID,
Clients, etc. If an AP is classified as "known" (internal or external), WCS
stops alerting you.

Another key classification piece is to detect whether or not the rogue AP is
physically connected to your network which is a high security risk. There
are three ways WLC can detect it and neither of them is automatic. You must
configure these methods manually.

1. Rogue AP Detector, aka ARP sniffing. You have to dedicate one AP as
"Rogue Detector" (change AP mode from local to rogue detector). Configure
the port the AP is connected to as switchport mode trunk (normally it's
switchport mode access). Rogue Detector AP turns off and doesn't use its
radios. When WLC detects rogue APs it can also detect the MAC addresses of
any clients associated to that rogue APs, and the rogue detector AP simply
watches each hardwire trunked VLAN for ARP requests coming from those rogue
AP clients. If it sees one, WLC automatically classifies the rogue AP as
"threat" indicating that the rogue AP is physically connected to your
network. It doesn't actually do anything with the rogue AP, it simply
classifies it and alerts you. Also, keep in mind that this method doesn't
work if the rogue AP is a Wireless Router, because Wireless Routers NAT and
ARP requests don't propagate to the wire.

2. RLDP. Rogue Location Discovery Protocol. This feature is by default
turned off and can be enabled under Security > Wireless Protection Policies
> Rogue Polices. This feature works only when the rogue SSID is open,
meaning that it's not using WEP/WPA/802.1x. When you enable RLDP, your WLC
will pick some AP (you can't pick manually) which hears Rogue AP traffic, it
will temporarily shut off its radio, turn it into a client, and instruct it
to associate to the Rogue AP as client (this is where the requirement comes
in for the Rogue SSID to be open authentication). Once associated, AP gets a
DHCP IP through Rogue AP, it then sends a special small UDP port 6352 RLDP
packet to every possible WLC's IP address (mgmt ip, ap manager ip, dynamic
int IPs). If WLC gets one of those packets, it means that rogue AP is
physically connected to your network. This method will work when Rogue AP is
a Wireless Router. But this method is not recommended. It has an adverse
effect on your wireless clients because RLDP AP goes offline for a period of
time disconnecting your clients and forcing them to associate to another AP.
Also, keep in mind, that WLC runs this RLDP process *once* per detected
rogue AP. It doesn't periodically do this, it only does it once. In some
later WLC versions, you can configure RLDP to run only on "monitor mode"
APs, eliminating impact on your clients. Also, you can manually trigger RLDP
for a rogue AP from CLI "config rogue ap rldp initiate <rogue AP mac>". You
can "debug dot11 rldp" to see the process.

3. Switchport Tracing (need WCS, and WLC 5.1). This is a later feature that
requires WCS. You can add your Catalyst switches to WCS, and WCS will look
at CDP information and MAC tables on your switches to detect whether or not
Rogue AP is connected to your network. This works with secured and NAT
rogues. You can also *manually* instruct WCS to shut down the switchport
that Rogue AP is connected to.

You can also use WCS to show you approximately where the Rogue AP is located
on your floor map. You don't need Location or MSE appliance to do this.

There are also a couple of other features to be aware of:

1. WPS > Trusted AP policies. Once the Rogue AP is detected and manually
classified as "known" (trusted), you can configure a "Trusted AP policy"
forcing WLC to continuously monitor the state of that Rogue AP making sure
that it conforms with your policy. For example, you can configure a policy
that requires the "known" Rogue APs to have WPA security. If someone changes
Rogue AP's SSID security from WPA to open, WLC will detect this change and
alert you. You can also configure a policy to make sure that Rogue AP
doesn't use your valid WLC's SSIDs. Or you can have it alert you if your
trusted Rogue AP suddenly disappears from the network.

2. WPS > Rogue Policies > "Validate rogue clients against AAA". WLC will
authenticate rogue client's MAC address against AAA. Basically, you are
trying to detect if one of your internal wireless clients (known MAC
address) suddenly associates to a rogue AP. I believe that in WLC 4.x this
was only for alerting purposes, but in later WLC code you can also force WLC
to send Deauth packet (aka auto-containment) to your valid client forcing it
to disconnected from the Rogue AP.

The final piece to this puzzle is "containment". This is what you were
asking about "I do not see the way to Block Rogue APs from joining the wired
or wireless WLANs". None of the methods described above automatically shut
down the wired port that Rogue AP is connected to. If you use the
"switchport tracing" method, WCS will tell you which switch port the Rogue
AP is connected to, and you can manually shut it from WCS.

You can also use wireless containment, where up to 4 of your valid nearby
APs will send Deauth packets to clients connected to Rogue AP and/or to the
Rogue AP itself. In WLC 4.x this is not automatic and must be manually
initiated from WLC (Monitor > Rogues > Rogue APs / Clients) or from WCS. You
have to consider possible legal issues you could face if you start
auto-containing your neighbor's APs/clients. Also you should know that over
the air containment carries an adverse effect for client performance on
managed APs, because APs are busy sending Deauth packets during auto
containment.

In WLC 5.x versions, auto-containment is available. You can configure
specific rules on when to auto-contain:

1. You can auto-contain when Rogue AP is detected to be connected to the
wired network (through Rogue Detector AP, RLDP, switch port tracing)

2. You can auto-contain when Rogue AP is using your valid SSID. Make sure
you are using unique SSIDs that your neighbors wouldn't use

3. You can auto-contain your valid clients connected to Rogue APs. I
mentioned this earlier. You will need to have all your valid client's mac
addresses added to your RADIUS/ACS database.

Roman Rodichev
6xCCIE #7927 (R&S, Security, Voice, Storage, Service Provider, Wireless)
Instructor, Content Developer
ieMentor Corporation http://www.iementor.com <http://www.iementor.com/>
Y!M: roman7927

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Dane
Newman
Sent: Saturday, August 08, 2009 6:58 PM
To: Cisco certification
Subject: Cisco Wireless Rogue Containment

Hello Experts.

So I have gotten around to play with cisco wireless and I was curious if
someone could help me understand how exactly the rogue containment works.

I have found and read through this article
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a00
<http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0
080722d8c.shtml>
80722d8c.shtml

I have read these paragraph

*"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 active AP to move to the rogue channel and
connect to the rogue as a client. During this time, the active AP sends
deauthentication messages to all connected clients and then shuts down the
radio interface. Then, it will associate to the rogue AP as a client."*
I understand if the rogue is an open access point (no security) the system
can send deauth packets to clients. How does is exactly shut down the
radio? What does the last line mean then it will associate to the rogue ap
as a client? does this mean if it comes back up it will associate again>

AlsoI have read this below...

*"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."*
**
So when the rogue is secured I understand that it cannot connect
wirelessly. From what I am reading (please let me know if I am
understanding it correctly) access points can be put in rogue detectory mode
and trunked with all vlans. It then can only notify you that a rogue is
connected to the wired network? What if the rogue is not connected to your
wired network? Can anything be done to block the rogue then?

I have a 2106 controller and I am playing with it at the moment. I set it
up with 2 CAPWAP ap's and then set up a rogue ap in my home not connected to
the wired network. I ran a constant ping before containing it and it was
always below 1-2 MS response time. I then contained it using two AP's and
it started going over 500 MS + and dropping packets. Maybe its just my
imagionation but I would like to know how it's blocking or giving poor
preformance to the rogue? Is it doing anything or just my imagionation?

Dane

Blogs and organic groups at http://www.ccie.net <http://www.ccie.net/>
Received on Sun Aug 09 2009 - 00:05:46 ART