LWAPP Rogue AP report

Hi
In my WCS, I see hundreds of rogue AP. Most of them are my AP also controled by my WiSMs. Wy does I get rogue report for them? The radio mac of the rogue report is usualy one digit higher then the base mac of the AP

I don't know if this is related or not:
I have been working with Cisco TAC and they indicate that the following false alarm: "Disassociation Flood" alarm is due to a software bug that is to be fixed in the November timeframe (aka Concannon release):
"IDS Signature attack detected. Signature Type: Standard, Name: Disassoc flood, Description: Disassociation flood, Track: per-signature, Detecting AP Name"
What caught my attention to relate this to what you are describing is that the error/trap indicates that the supposed disassociation flood is coming from the radio MAC addresses of our own trusted APs being controlled by the WLC.
Bug is identified as CSCse70641
Externally found severe defect: Assigned (A) Problems with signatures in 4.0.155.0 Symptom:High number of 'Disassoc flood' and 'Broadcast Probe floo' alarms. In3.2 this is not showing up, for controllers on the same area The shorter mask of 4.0 seems to match additional frames resulting infalse positives Conditions: Between 3.2 and 4.0 versions, there are several changes on the standardsignature database. For 3.2, for example, signature 7 (Disassoc flood)was 0:0x00A0:0x03FF, on 4.0 now is 0:0:0x00A0:0x00FF Additionally thisdoes not matches the information present on the header of the signaturefile. If the byte stream is compared, for a disasociation flood, theframe starts with 0xA000, after applying either of the twomasks, results in 0, failing the verification. For the signature to becorrect, it a double byte swapping is needed, which is not documented orpresent.
The current workaround is as follows:
Workaround:
Disable signatures
To disable the signature file -
In the controller, go to 'Security' --> 'Wireless Protection Policies'
--> 'Standard Signatures' and click 'detail' on the far right of the
signature you wish to disable. You will see a 'State' check box, simply
uncheck and
hit apply. The signature will now show in a disabled state.
Hope this helps

Similar Messages

Cisco Prime Rogue AP Report - No Rogues from 3702 Series AP's

I am running Cisco Prime Infrastructure (2.1) that manages a Cisco 5508 WLC (7.6). We have multiple version of AP's managed by this WLC to include 1142, 2602, 3702, etc...In Cisco prime when we run a Rogue AP Report. None of the Rogue AP's discovered by 3702's are displayed in the report. The Rogues show on the WLC though from all AP's. Cannot find a reason for this. Any ideas?

The Rogue alarm state always stays on "removed" once deleted
CSCuo91446
Description
Symptom:
Once one of the alarm of rogue AP is deleted the newer rogue AP alarm changed to removed state even for different mac address.
Because of the removed state the detecting AP which detected the rogue is not displayed
Conditions:
1) Auto SPT is turned on
2) Prime 2.0 or 2.1
Workaround:
Click on refresh from network for each alarm in removed state or disable auto spt
Last Modified:
Jun 30,2014
Status:
Fixed
Severity:
3 Moderate
Product:
Cisco Prime Network Control System Series Appliances
Known Affected Releases:
(1)
2.1(0.0.1)

Rogue Account Report

Hello Guys.
I have some doubts, in respect of Rogue Accounts Report, What the best way to solve users that can be showed at this report?
Thanks in Advance for any help.
Daniel.

uhnnn interesting, I know these ways, but One thing that I do not know yet, by example...
I ran the Rogue Account Report, and this report showed me X, Y users, to solve that user, I made a attestation, but the user had been showed again when I ran the Report, Is there other way to solve this problem?
Thanks.
Edited by: user10365508 on Aug 15, 2012 10:06 AM

Rogue reporting in WCS

Can anybody tell me what the difference is between the following 2 default Security reports:
Rogue APs
Rouge APs Event
WE run both of these nightly, but the Rogue APs Event report usually is about 20 pages or so, and the information there has way more than what I see when I compare to my controller. The Rogue APs report usually matches what I see on my controller regarding current rogues. Does the Rogue APs Event report just detail everything that the access points have seen in the reporting time period? Some clarification on this would be greatly appreciated.
Thank you.

Rogues Detected by APs Report displays information about specific rogue access points detected on the network, rather than having to look into each rogue alarm and manually assemble a list. The data that is returned includes but is not limited to the following: the name of the detecting access point, the MAC address of the rogue, and the location of the rogue.
and Security Summary Report shows the number of association failures, rogues access points, ad hocs, and access point connections or disconnections over one month.

Reporting problems with Cisco WCS

hi all,
I was wondering whether anyone has experienced the following symptoms on Reporting.
WCS Rogue AP reports do not run and show up as 'Expired'
this does not occur to all the Rouge AP reports though (they are being created based on floor areas; one report per campus)
customer is using the following
WCS Version: 7.0.230.0
any idea on this, could this be a software bug?
thanks a lot
with kind regards,
Lancellot

Hi,
The report expires when it is scheduled report and configured for some specific time. After the time passed the report expires. re-schedule the report time and change the start-date time of the schedule and that should resolve your issue.
HTH
Amjad
Rating useful replies is more useful than saying "Thank you"

Anyone captured an RLDP trace

I have not been able to get WiSM controllers on 4.x code to detect a wire-side rogue with open auth (Cisco AP and Apple Airport Express). It did find the open Airport AP once when running 3.x code, but has not since the upgrade.
Has anyone succcessfully captured the Rogue Location Discovery Protocol in action (and has a trace they can share)? Anyone seen an LWAPP AP associate through a Rogue and report it back to the controller?
Thanks,

In order for an AP to be detected as a rogue, the following conditions must be present :
-the AP must be 'seen' at least 2 times (through beacons or probes)
-the AP's mac must also be seen on the wired segment
-the AP must be sending beacons or probes
-the AP must be on channel & band that is being monitored.
you may refer to the configuration guide for more information, hope this helps :
http://www.cisco.com/en/US/products/ps6366/products_configuration_guide_chapter09186a00806b0757.html#wp1107407

OIM 9.1.0.2 - User group permission conflict issue

Hi Gurus,
IHAC who have faced a strange behavior about permission conflict.
User has been assigned to a user group (ANALISTA DRSI) who have permission to disable resource of the users he administrates. The user group has been assigned to resource's administrator.
The same use has been assigned to other user group (ANALISTA ADM DRSI) who have other permission. The user group has been not assigned to resource's administrator.
If the user has been only assigned to ANALISTA DRSI user group the user is able to see records on Rogue Account report. If the customer has been assigned to both ANALISTA DRSI and ANALISTA ADM the user is not able to see the record on Rogue Account report. He got a display error message (You do not have permission). Both user groups have the Report menu item assigned.
My question: if the customer is assigned to a user group who have permission to see the reports, should not the user is able to see the report even though he is also into the other group who do not have permission?
Is there conflit in the OIM???
Any tip will be very appreciated.

Orgnaization > Manage > Select Org in which users are getting created > Administrative Group (Drop Down) > Select Group for which users are not coming.

Two separate enterprise WiFi networks in the same building

I work in a building that currently has Cisco controller based access points. The access points aren't managed by us and are actually part of another campus. We are given access to them but they don't work quite like we want them to. So we are wanting to bring in our own Cisco WLC 2504 with 3702 APs. But when we brought this up with the main campus they said we can't have two separate enterprise wireless networks in the same building. That their APs will mark our APs as rogues and try to shut them down. There was also mention that they can't share the same channel and that the radios will negotiate with each other to determine how much power they need for coverage. But from what I've read none of that is true. So maybe I misunderstanding something and hoping someone here with more experience can shed some light on this. The only reason we would want to keep their wireless in the building is so when their staff come to our office they can use it.
So can two separate WLC/AP systems on different subnets and broadcasting different SSIDs exist in the same building with out causing any issues?

By default, the WLC code does not try to contain rogue AP's. Just lots of alarm's and unclassified rogue's.
In this case you hosts may have actually enabled containment but would have also received a screen full of warning about the public nature of the unlicensed wifi band.
Here the Superior Court system is side by side with the County system even to the extent that the AP's are next to each other. Gets fun. Since each SSID constitutes a rogue, each unit represents a LOT of rogues to report.
Good Luck

Do two wifi networks in the same home have to conflict with each other?

I have an Xfinity1 system that requires its own combo modem/router supplied by Xfinity in order to run its system. The premise here is that you can play live tv from any of your devices like computers, iPads and iPhones using their wifi system, and it works well.
I was advised by Apple that my two Airport Expresses, which provided my network before I brought in the Xfinity system, should be reconfigured to "join" my Xfinity network instead of maintaining their own separate network. So I reconfigured everything at their direction, and now my Airports won't stream music or anything else. I called Apple, we checked out my configuration and found out my Airports were set up and working correctly.
Now I have been advised by a senior Apple tech to go back to my original setup with the Xfinity network and a separate Airport Express network. This was late last night, and I was just too tired to do it at that point. So, today I have a phone appointment with that senior Apple tech to change everything back to my original setup.
I would like some input from the community about this situation. Maybe there is more to this than meets the eye. Like why are these Airports currently not streaming music from any of my devices? The Airport icon shows up when I try to stream music, but when I choose one of the two Expresses nothing happens.
The Xfinity system does not stream Apple stuff. Could the problem be that, by joining the Xfinity network, the Airports cannot stream music from iTunes or iPads or iPhones because the Xfinity system cannot accommodate Apple content under any circumstances. In other words, do you just have to have an Apple network to stream Apple content?
HELP.

By default, the WLC code does not try to contain rogue AP's. Just lots of alarm's and unclassified rogue's.
In this case you hosts may have actually enabled containment but would have also received a screen full of warning about the public nature of the unlicensed wifi band.
Here the Superior Court system is side by side with the County system even to the extent that the AP's are next to each other. Gets fun. Since each SSID constitutes a rogue, each unit represents a LOT of rogues to report.
Good Luck

Impersonation of AP issue

Hi,
i have a WISM with release 6.0 and 150 AP connected all in the same RRM. In the TrapLog I see a lot of |"Impersonation of AP......" messages. This issue is between AP connected to the same WISM and in he same RRM.
Any idea?
Regards
Giovanni
An

Hi Roman,
sorry for the late but I'm in vacation. I read now the answer at the case that I opened to the TAC about this issue.
From the case notes which you have added, I can see that you are affected by the bug:
CSCsi18369
AP Auth: Known rogues are reported as impersonation alerts
Symptom:
If AP authentication is enabled, the controller will report the entries in the known AP MAC address
list, as impersonation alerts.
Workaround:
Use MFP or disable AP Authentication
Regards
Giovanni

"Fake AP or other attack may be in progress." WCS 4.1.83

Hello.
I am receiving this critical alarm usually 1-3 times a day and it doesn't make any sense. I was hoping someone here could let me know if this is a legit problem or just another convenient "cosmetic bug" (There seem to be alot of those with 4.1).
The full message is:
"Fake AP or other attack may be in progress. Rogue AP count on system 'xxx.xxx.xxx.xxx' has exceeded the security warning threshold of '625'."
(IP address above was purposely hidden)
There are, as of typing this, 200 rogue APs reported by both controllers (combined, one has 110 the other 90). This alarm is still 'active' in WCS. Even if there were "fake ap"s, wouldn't the controllers report them as rogues into their count?
Thanks for any input,
Jeff

Jeff:
I can relate to what you are saying about the so-called "cosmetic" or "feature request" status of these bugs.
TAC keeps bouncing us back to sales - who bounces us back to TAC... but I digress.
Back to your issue:
That sure is a lot of rogue APs!
One key is to determine if there really are 200 physical access points out there or if someone is out there "spoofing" multiple APs.
Do you think that these are real APs? Have you tried locating them (using the "High Resolution Map" drop down in the rogue AP detail screen) to see if a large number of these aps are in the same location or found by the same AP? If so, that may indicate that this is a spoofed attack going on.
Are you sure that your controllers are in the same mobility group? If not, I believe that one controller will see the other controller's APs as rogue (even though they are not).
Another observation, if the rogue APs you are seeing utilize the "virtual mac" (like Cisco), one physical AP can have multiple virtual mac addresses (one for each SSID with separate sets for 802.11b/g and 802.11a). That means that one physical AP could appear to be as many as 16 or even 32 APs (in the case of AireSpace LWAPS) if both bands are lit up and all SSIDs are lit up as well. One way to help identify this is to note that if you sort the radio mac addresses, you will note that the there will be blocks of APs with identical mac addreses except for the last character which might be nearly sequential.
For example, what appears to five APs is really the same AP with different SSIDs assigned to it:
01:02:03:04:05:00
01:02:03:04:05:01
01:02:03:04:05:03
01:02:03:04:05:02
01:02:03:04:05:04
Have you categorized at least some of these as "Known External" (assuming, of course, that they are)? I am wonding if that would help the system ignore some or not...
Please refer to the following link:
http://www.cisco.com/en/US/docs/wireless/wcs/4.0/configuration/guide/wcsevent.html
The following condition is referenced:
AP_MAX_ROGUE_COUNT_EXCEEDED
Field Description
MIB Name
bsnApMaxRogueCountExceeded.
WCS Message
Fake AP or other attack may be in progress. Rogue AP count on AP with MAC address ''{0}'' associated with Switch ''{2}'' has exceeded the security warning threshold of ''{1}''.
Symptoms
The number of rogues detected by a switch (controller) exceeds the internal threshold.
WCS Severity
Critical.
Probable Causes
?There may be too many rogue access points in the network.
?A fake access point attack may be in progress.
Recommended Actions
Identify the source of the rogue access points.
========================
As an aside,
We have asked Cisco for documentation of these various "attacks" as well as for some valid values for the IDS signature file in order to be able to "tune" some of these better as well.
- John

Help with Switchport Trace on WCS v 5.2.130

I am having trouble getting the "switchport trace" for rogue devices working. I have imported a seed list of switches and made sure that snmp RW community is correct. However, I am still not able to run the trace and have it return any results - always get "switchport trace failed". Anybody got this working that could offer some additional insight. Thanks in advance.

Currently, WCS provides rogue access point detection by retrieving information from the controller. The rogue access point table is populated with any detected BSSID addresses from any frames that are not present in the neighbor list. At the end of a specified interval, the contents of the rogue table are sent to the controller in a Lightweight Rogue AP Report message. With this method, WCS would simply gather the information received from the controllers; but with software release 5.1, you can now incorporate switch port tracing of wired rogue access point switch port. This enhancement allows you to react to found wired rogue access points and prevent future attacks. The trace information is available only in the WCS log and only for rogue access points, not rogue clients.
http://www.cisco.com/en/US/docs/wireless/wcs/5.2/configuration/guide/5_2ctrlcfg.html#wp1089752

Limiting reported rogues

I'm running WCS ver 7.0.164 and the controllers are running 7.0.98 code. I have a daily rogue report configured to email me the rogue access points reported by the controllers and access points. How do I limit the reporting so that any rogue with a RSSI of less than -85 is not reported? I created a "rogue ap rule" and set the match conditition to a minimum RSSI of -85. Then I applied that to a "rogue ap rule group" and applied that to the controllers, but I still get the same number of rogues in my report.
Thanks,
Al

Post the rogue message you are getting for starters.
Also how is your rogue policies configured? Here is the users guide for configuring rogue policies using the templates.
http://www.cisco.com/en/US/docs/wireless/wcs/7.0/configuration/guide/7_0temp.html#wp1100222
You modify the rogue ap rules to prevent those rogues from appearing:
Viewing or Editing Rogue Access Point Rules
You can view or edit current rogue access point rules on a single WLC. Follow these steps to access the rogue access point rules. See the "Configuring a Rogue AP Rules Template" section on page 12-77 for more information.
Step 1 Choose Configure > Controllers.
Step 2 Click an IP address under the IP Address column.
Step 3 From the left sidebar menu, choose Security > Rogue AP Rules. The Rogue AP Rules displays the rogue access point rules, the rule types (malicious or friendly), and the rule sequence.
Step 4 Choose a Rogue AP Rule to view or edit its details.

WLSE not reporting rogue AP

Does anyone know of circumstances why WLSE (2.7) would not detect a non registered AP. We connected a non Cisco AP (Microsoft MN700 router/wireless base station) to our LAN yet WLSE is not sending out Faultnotifiers.It seems to be selectively ignoring at least this one particular type of AP because it has detected other rogue AP's.

This can happen when Rogue AP was detected by APs whose locations were not specified or specified later than the detection.
In Unknown Radio List Window, find out which access points were reporting the detection. Make sure you have placed them in a particular floor using Location Manager. If you have placed them later than the initial detection, turn on the Radio Monitoring for those reporting APs and wait for a while. When reporting APs detect the same Rogue AP again, it will correctly determine the possible location of the Rogue.

WCS Report - Rogues on Wired LAN

Each WLC on our network shows "Rogues on Wired Network" from the Summary screen, however, checking these can be time consuming due to the number of WLC's in the network.
All of the WLC's are connected to a WCS so I was wondering whether a report for "Rogues on Wired Network" is available on the WCS??
I've spent a while looking around the WCS but can't find this information.
Any help that would make checking this easier greatfully recevied...

Unfortunately no. The feature works quite well only since WCS 6.0.
If you have a WCS 4.1 you may be able to update to 5.2 or 6.0 as licensing should be the same. Check with your sales team.

LWAPP Rogue AP report

Similar Messages

Maybe you are looking for