RE: Cisco Wireless Rogue Containment

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
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
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
Received on Sat Aug 08 2009 - 23:05:06 ART