Re: Cisco Wireless Rogue Containment

Thanks Alot for Clearing that up with RLDP Roman.

I don't see my client listed as a rogue client. How does it get this info?
If my client was connected to the network once through an ap and then
connected to a rogue should it remember that connection and now show me as a
rogue client? In order to show me as a rogue client does the rogue ap need
to be connected to my lan?

During containment if I send deauth to the clients I get it forces them to
reauthenticate correct? Is the deauth meant to be enough to denial of
service clients or is it just meant to be a passive deauth so they will
eventually hope to connect to the proper ap? What is the purpose of sending
deauth frames to the rogue ap?

Dane

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

> 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
doesnt
> 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 its not
> connected to your network, then you dont 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, thats 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 APs performance.
>
>
>
> Rogue AP detector serves exactly the same purpose as RLDP, but it works
> with WPA/WEP rogue APs and it doesnt 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
>
> 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
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Aug 09 2009 - 01:21:26 ART