Rogue AP Containment

I tested the capability of containing rogue AP over the air in a lab environment. It works great, but I have the following questions/concerns:
1. How could I detect if others/hackers do this to our wireless network?
2. Will the WLCs be able to detect this kind of stuff?
3. Any links or documents on this topic would be greatly appreciated.
Thanks
Binh

Be very careful when you are using AP Containment.  In some countries, if you contain the wrong AP/WLAN, you and/or your organization can be liable.
The WLC/WCS can conduct AP Containment very well.  I know because I've used this on Rogues AP found WITHIN the premises.

Similar Messages

  • Rogue AP Alarm in Prime

    Hi, I'm working on Prime alarm and I'm wondering how to do this :
    1) I would like that all rogue AP not containing a substring to be friendly
    2) I would like that all rogue AP containing that substring malicious.
    Is it possible ? I can't seem to figure out how the Rogue AP rules works...
    Thanks,
    Simon Laurendeau

    Hi Simon,
    Yes, you are correct. You require 7.5.x onwards to have wildcard rogue SSID classification. Here is what 7.5.102.0 Release notes says about it.
     "In the earlier releases, you could create rogue policy rules based on SSID, but the SSID had to be an exact match. In this release, you can create rogue policy rules based on wildcard SSID, where the rule is enforced by any SSID that contains the wildcard SSID string. You can configure up to 25 wildcard rule per rogue rule."
    HTH
    Rasika
    **** Pls rate all useful responses ****

  • WLC 7.0.98.0 CPU high utilization

    I could not find anything wrong with the show tech on WLC. Client complaints CPU high utilization. Please help!

    Hi Andrew,
    There are a couple of interesting things in the debug output you included, firstly there are some unsupported rates by the clients, in other words do you have some 802.11b clients trying to connect? Because I think you may have unsupported the 'b' rates on the controller. So either - ensure you have no 'b' clients or start supporting 'b' rates again (1, 2, 5.5, 11)
    Secondly there some rogue AP containment going on, this can cause either your AP to have a high CPU, f there are multiple rogue APs being contained, or it may be that your own clients are being de-authenticated by another wireless network in the area - in other words, your network is under attack.
    HTH
    Best wishes
    Mike

  • Run application from applet

    is it possible to run an application from an applet? is so how can i go about doing this?

    hey may be the use of Runtime can help u solve ur
    prblm....
    Runtime.exec("Application name");luck,
    jayNope. You should know some basic things before trying to give answers.
    If (unsigned/untrusted) applets could just run any other app, imagine the chaos when someone hits a rogue website containing an applet that executes something like "format c:"
    You want to run an external program on the client's machine from an applet? You can't, thank heavens. You need to rethink your design.

  • IPad email has been hacked

    My iPad email seems to have been hacked. I have searched for other cases where this has happened, but I only see items where the respondent has said that the iPad cannot be hacked... So I will explain why I think mine really has been hacked.
    - 2 days ago at 6.15 am when I was asleep and my iPad was safely locked up at home an email was sent via my yahoo email account.
    - the email was address to myself and 3 contacts I know.
    - I saw the email later in the day because, of course, it landed in my inbox (I actually saw it first on another device)
    - over the years I have seen plenty of spam and spoofed email, but this looked different
        - firstly, one of the addressee emails was actually wrong and I also had a bounce email to say that yahoo had failed to deliver the message
    - so my first thought was that someone had hacked my yahoo account and sent the email from there. I therefore changed the password, hoping this would put a stop to the problem
    - in retrospect I checked the sent items box online in my yahoo mail account. The offending message was indeed there, so no doubt that it had been sent via the account. At that point I thought it likely that the hack had been via the online email service and not from any of my devices.
    - however, still curious I started checking all my devices (all Apple: 2 macs, 2 iPhones and finally the iPad)
    - all the devices showed no suspicious sent item except my iPad which showed the rogue email in the sent items folder under my email account details
    So, the questions now are:
    - how did this happen?
    - how do I stop this happening again?
    Ps. The rogue email contained a link to the following URL
    //ceramiccoatingsfl.com/www.cnbcnews.com.reportage24h.today.viewprofit37.php

    Unless the iPad was out of your sight long enough for someone to send the email it was not hacked. Its just not physcally possible to hack an iPad and then remotely send the email.
    What happened is that since your iPad is synced to your Yahoo mail, any activity on your account is mirrored on the iPad. so when the email was sent thorugh your Yahoo account, the sent mail is put in your Sent folder which is mirrored to your iPad.

  • APs being contained as rogues by an external system

    A rogue containment policy is being initiated against my organization's APs and I do not have the tools/knowledge necessary to track down its point of origin. What tools or steps are required to identify who is containing an AP?
    Thanks

    I currently have this weird issue too
    I have no idea why. It started yesterday and continued today. I know that some people are in that area playing around with some Zigbee RFID tags, but I don't think that should make a problem?
    Here from the controller logfile:
    wism-1250-2: *Apr 09 14:40:03.582: %LWAPP-1-AP_CONTAINED: spam_lrad.c:25558 AP 1200b-6106-1 is being contained on slot 0
    Containment is after around 1 minute over (WCS sends two mails, one with containment and one with CLEAR). I don't know if the users have some issues because of this, so far only one complained, but that could also be because he's using an Apple and not a stadard client.
    The controller logfile doesn't show a "resolve" of the containment.
    Auto containment of rogues is disabled on the controller.
    Any ideas? Or did you ever receive an answer from your tac case?
    Thanks,
    Patrick

  • Issue containing a rogue AP

    My WLC has detected (via 15 detecting radios) a rogue AP with a client connected to it. The infrastructure has not determined that the AP is plugged into the local network. I'm trying to contain the AP - I classify it as "Malicious", update its status to "Contain" & assign 2 APs (though the number of APs don't matter here) to contain the rogue.
    Everything looks right, as the WLC shows that the rogue AP is in a "Contained" status. However, after about a minute the WLC shows the rogue having been reverted to an "Alert" status. I've contain other rogues before but have yet to see one not have the "Contained" status stick.
    Anyone seen this? Or know why it's happening? Thanks!

    Check and verify that the "rogue" is not one of your APs associated to a controller with a different mobility group name but on the same network as your primary mobility group. This is the only way I could think that this is happeneing. Also, try a 4 AP containment. At 2 APs a client could still associate to the rogue thus generating a new alert.

  • WiSMs appear to be auto-containing rogues

    (This appears to be the converse situation of another relatively recent post. I thought it might be better to have a separate thread rather than muddy up that conversation).
    I have a relatively new deployment of 8 WiSMs controllers (4 of which are currently production and 4 are available for failover). The WiSMs are running code v5.2.157.0 and I have about 50 AP1252's split between the 4 production controllers.
    We also have WCS v5.2.130.0 in the environment to manage the controllers. I am a little concerned by some messages I am seeing on the WCS which seem to indicate the WiSMs are auto-containing rogues even though I have verified there are no Auto-Contain features enabled on any of the WiSM controllers.
    Here is a sample of a WCS log entry which concerns me:
    Rogue AP '00:23:75:07:68:b0' with SSID 'qwest5184' and channel number '4' is detected by AP 'xxxx-2-a4' Radio type '802.11b' with RSSI '-92' and SNR '5'. RogueAP contained.
    I can dig up more of these but all seem to indicate an action is being taken on Rogue APs even though we specifically have these options unselected (under Security | Wireless Protection Policies | Rogue Policies | General) and their are no Rogue Rules defined either.
    Is there anywhere else I should be checking where something like this could be enabled?
    I need to make sure I am not being a problem before I can go to my neighbors and expect the same.
    Thanks for any ideas.

    Did you get a resolution to this?
    I have the same issue, but am unsure if my WLC's are auto containing rogues, or whether WCS is just falsely reporting the containment.
    I see no auto containment setting anywhere on my WLC (4.2.170.0), so I doubt very much it is auto containing.
    Anyone know where I can check/look?
    My WCS version is 5.2.130.

  • Drawbacks of using 4 APs to contain a rogue AP

    What are the benefits/drawbacks of using 4 controller-based APs to contain a rogue AP vs using just one. If I understand it correctly a single AP can never be set to contain more than 3 rogues, and will never use more than 30% of its resources to do so. Also, you can set a maximum of 4 APs on "containment duty" against one rogue. I also believe that containment involves sending spoofed messages to the wireless clients which requires your APs to be within range of all the rogue clients.
    So.. what do you guys think? Let me know if my conclusions regarding the process are incorrect!
    Thanks!

    If you actually try this in the lab with a client set to do a continuous ping, you will see that containing with only one AP will still allow clients to connect. The plan here, as it was designed by Airespace, was to only contain radios that you KNOW are a threat. APs on your own wired network were detected by RF and then verified to be on the wired network with a protocol called RLDP. Once an AP was discovered via RLDP, the rogue was automatically contained by a 4 AP containment if 4 APs heard the rogue. An alert was then sent to the administrator and the rogue was mapped for location so that it could be collected. Containing APs that were neighboring was disuaded because of the FCC "Good Neighbor" policy. You needed to make sure the AP was an actual threat to the security of your network before taking action. This became Cisco's policy on all rogue devices and they disabled RLDP from the system. Now if you do a contain you see the Legal Disclaimer that Cisco has put into place. A 4 AP containment will use some resources of your APs but it should not be a long term fix. You should go and deal with the rogue device personally once it is contained and mapped. After dealing with it, set the appropriate rogue state and remove containment.

  • ROGUES containing or friendly ap

    Hello, I've got a huge wireless network enviroment and I need to filter a lot of warnings in Cisco PRIME Infrastructure (PI) / WLC related to "Rogue Alarms"
    My network is in an urban enviroment and there's lot of residential buldings surround my network infrastruture.
    First of all, I need to create a list of friendly AP's to prevent them to create an alert in my PI or WLC.
    in WLC I can do it, but one by one. As you can see in the attached picture below I've got more than 200 friendly AP's to add tho this Whitelist
    [url=http://postimg.org/image/qt4f4j0ep/][img]http://s8.postimg.org/qt4f4j0ep/containing_rogues.jpg[/img][/url]
    1 - what's the best practice to prevent these Access Points to be detected as a alarm in PI or WLC?
    2- Can I add them all at once to this Friendly AP list, or I need to do it one by one?
    Thank you

    I've already seen those documents, but I want to add to a Friendly AP list, lots of networks, but I don't wanna do it, one by one..
    There is any option to do it at once?
    as you can see in the attached file I've got more than 200 networks called ZON-XXXX
    As the SSID is variable in some characters, i'm trying to find a way to create a rule who match my needs and put all these networks in Friendly AP List
    zon-x-rule.jpg
    I've tried to create a rule with a User configured SSID of "ZON-*" but I got no lucky.
    Anyone got some advice to help me?
    thank you

  • Threads listed using kill -3 does not contain all threads via ps -auxww

    Hello
    We are currently experiencing a problem running ServletExec (java Servlet container) where a process starts hogging the CPU. We end up having to restart the program.
    As a Java developer, in these situations you tend to issue "kill -3 <pid>" commands to try to determine the rogue thread. The java VM traps this signal and outputs it's currently executing threads to system error.
    In Linux, each java thread is implemented as a process. The rogue process I mentioned above does NOT appear in the "kill -3" stack trace which is very strange.
    So I ran a very simple java program that starts a thread and continuously sleeps for 2 seconds and then prints out "Sleeping..". If I issue kill -3 commands against this program and compare against a listing of the threads using ps -auxww the latter contains more 2 threads.
    So the "problem" is not a ServletExec issue.
    Am I correct in my assumption that all the processes seen using ps -auxww should be visible in the Java stack trace? If not, how can I find out what the rogue java process is doing?
    Many thanks for any info.
    Environment:
    Red Hat release          ES 2.1
    kernel version          2.4.9-e.62smp
    hardware               hp ProLiant DL360 G3
    java               j2sdk1.4.2_09
    ServletExec               4.1.1 patch 27

    In Linux, each java thread is implemented as a process.It was not exactly true even with the elder versions of Linux, let alone the newer ones. With some versions however threads showed up as processes in the output of "ps" or some other diagnostic tool.
    In good old days, the traditional fork() Unix system call, which copies the running process along with its memory state and runs both copies as separate processes (with the return value of the said system call differentiating between the parent and the child process) had some flags, Linux-extension ones, to fine-tune what is exactly copied and shared among the processes. (File handles are shared for example by default). One possibity was to tell the new process to share the memory with the old one - threading was solved (hacked) this way but, as said, it was withj the elder Linux versions.

  • Rogue AP: Question

    I need a bit of info with the below topics.
    Q1. What is a Rogue AP?
    Q2. WLC 4400 is detecting a number of rogue access points from neighboring buildings. How should the WLC 4400 deal with these rogue access points?
    Q3. Can the WLC 4400 block these accees points from broadcasting their SSID's into our air space?
    Regards,
    Colm

    For the Clases, you have the ability to define what criteria must be met for a roge to be called friendly or malicious.  Under the Security tab > Wireless Protection Policy, Rogue Policies, Rogue Rules.
    Class Type:
    unclassified  <---  AP detected but not matching any policy
    friendly  <---  AP matches the criteria of a friendly AP
    malicious <--- AP matches the criteria of a malicious AP
    Update Status:
    Contain <--Contain the AP, uses our own AP to spoof the AP to get the clients to join "us" instead of "them" , once again, you need to be real careful with this, as if you are containing your neighbors, there can be reprocussions
    Alert  <-- Just a message saying there is a rogue

  • Rogue AP Countermeasure in WLC

    WLC detects rogue AP in their environtment, WLC also have some action to do with those rogue AP, by changing Update Status in Rogue AP Detail to Contain. It will make the AP that detect rogue AP launch the management frame (deauthentication frame) to that rogue AP. So whatever and whoever client trying to connect to the rogue AP, they will kicked out or deauthenticated.
    So that's in theory.
    In a real, i set up an AP using Nokia tethering features. Obviously the WLC will detect it as rogue AP, and i initiate deauth attack to AP that i just been setup using WLC. In theory all device that trying to associate to this AP will deauthenticated or it will not be connected. But in my lab, i am trying to connect my other device to my nokia AP. And voila my other device is connected.
    So my question ,
    What makes my other device is not deauthenticated ?
    Thanks

    Did you use Monitor mode AP?
    Also If client and AP are using 802.11w then containment will not work as in that case the management frames are protected.
    To dig further you can try the setup where you have one monitor mode Ap to launch deauth attach. One sniffer  mode Ap to see whats going on in Air. and a hotspot which you already have  for containing.

  • RD (Rogue Detector) or RLDP (Rogue Location Discovery Protocol)

    Hi all,
    Cisco documentaion states that there are two ways for detecting Rogues.
    Rogue Detector Access Point
    You can make an AP operate as a rogue detector, which allows it to be placed on a trunk port so that it can hear all wired-side connected VLANs. It proceeds to find the client on the wired subnet on all the VLANs. The rogue detector AP listens for Address Resolution Protocol (ARP) packets in order to determine the Layer 2 addresses of identified rogue clients or rogue APs sent by the controller. If a Layer 2 address that matches is found, the controller generates an alarm that identifies the rogue AP or client as a threat. This alarm indicates that the rogue was seen on the wired network.
    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 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.
    The AP then tries to obtain an IP address from the rogue AP and forwards 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.
    So how do you turn on the latter (RLDP)?
    Many thx indeed
    Ken
    The following modes of operations exist:
    http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00806a4da3.shtml
    Q. What are the different modes in which a lightweight access point (LAP) can operate?
    A. An LAP can operate in any of these modes:
    •Local mode—This is the default mode of operation. When an LAP is placed into local mode, the AP will transmit on the normally assigned channel. However, the AP also monitors all other channels in the band over a period of 180 seconds to scan each of the other channels for 60ms during the non-transmit time. During this time, the AP performs noise floor measurements, measures interference, and scans for IDS events.
    •REAP mode—Remote Edge Access Point (REAP) mode enables an LAP to reside across a WAN link and still be able to communicate with the WLC and provide the functionality of a regular LAP. REAP mode is supported only on the 1030 LAPs.
    •H-REAP Mode— H-REAP is a wireless solution for branch office and remote office deployments. H-REAP enables customers to configure and control access points (APs) in a branch or remote office from the corporate office through a WAN link without the need to deploy a controller in each office. H-REAPs can switch client data traffic locally and perform client authentication locally when the connection to the controller is lost. When connected to the controller, H-REAPs can also tunnel traffic back to the controller.
    •Monitor mode—Monitor mode is a feature designed to allow specified LWAPP-enabled APs to exclude themselves from handling data traffic between clients and the infrastructure. They instead act as dedicated sensors for location based services (LBS), rogue access point detection, and intrusion detection (IDS). When APs are in Monitor mode they cannot serve clients and continuously cycle through all configured channels listening to each channel for approximately 60 ms.
    Note: From the controller release 5.0, LWAPPs can also be configured in Location Optimized Monitor Mode (LOMM), which optimizes the monitoring and location calculation of RFID tags. For more information on this mode, refer to Cisco Unified Wireless Network Software Release 5.0.
    Note: With controller release 5.2, the Location Optimized Monitor Mode (LOMM) section has been renamed Tracking Optimization, and the LOMM Enabled drop-down box has been renamed Enable Tracking Optimization.
    Note: For more information on how to configure Tracking Optimization, read the Optimizing RFID Tracking on Access Points section.
    •Rogue detector mode—LAPs that operate in Rogue Detector mode monitor the rogue APs. They do not transmit or contain rogue APs. The idea is that the rogue detector should be able to see all the VLANs in the network since rogue APs can be connected to any of the VLANs in the network (thus we connect it to a trunk port). The switch sends all the rogue AP/Client MAC address lists to the Rogue Detector (RD). The RD then forwards those up to the WLC in order to compare with the MACs of clients that the WLC APs have heard over the air. If MACs match, then the WLC knows the rogue AP to which those clients are connected is on the wired network.
    •Sniffer mode—An LWAPP that operates in Sniffer mode functions as a sniffer and captures and forwards all the packets on a particular channel to a remote machine that runs Airopeek. These packets contain information on timestamp, signal strength, packet size and so on. The Sniffer feature can be enabled only if you run Airopeek, which is a third-party network analyzer software that supports decoding of data packets.
    •Bridge Mode— Bridge mode is used when the access points are setup in a mesh environment and used to bridge between each other.

    Found this in another post here on the forum :
    There are 3 ways to detect rogue Aps:
    1. Ap in monitor mode (sits and scans all channels. Can detect rogue Aps under 30 seconds
    2. RLDP (done passively from normal Aps. Can take up to 15 minutes to detect rogue AP)
    3. Rogue Detector (looks for broadcast packets from wireless clients on wired network)
    For case number 2, a normal AP would be one in local or h-reap connected mode that normally have clients attached, but that are going off channel occasionally to scan for rogues / noise.  The process of trying to validate that there is a network attached rogue (RDLP enabled) could likely be service interrupting depending on your AP layout.
    -John

  • How to avoid interferences caused by rogues APs

    Hi Everybody,
    I have a WLC running well with 10 LAPs.
    The problem that I have approximatively 60 Rogues APs and I have a lot of perturbations in signals (noise, interference, ...) caused by theses APs.
    How to avoid these interferences ?? is it the classification Malicieous APs ??

    wow! belay that...DO NOT CONTAIN THE ROGUES!
    Unless you can prove they are in your network and shouldn't be, there can be legal ramifications for doing so.
    What you need to do first, is adjust the sensiitivity for rogues.  by default it's -128, change that to -75.  Once you've done this, then you can evalutate which rogues are in your network, or belong to neighboring businesses.  For neighboring, go talk to their IT staff and see if you can get them to lower power so you aren't interferring with each other, cause if you see them, they probably see you as well.
    HTH,
    Steve
    Please remember to rate useful posts, and mark questions as answered

Maybe you are looking for