Signature attack ???

The wireless network use 2100 controller run 4.2.205.0 and 1242G APs.
In 2100 controller's trap log :
103 Thu Sep 16 14:49:19 2010 IDS Signature attack cleared. Signature Type: Standard, Name: Auth flood, Description: Authentication Request flood, Track: per-Mac, Detecting AP Name: AP9caf.ca01.c890, Radio Type: 802.11b/g, Preced: 5, Channel: 11
104 Thu Sep 16 14:49:05 2010 IDS Signature attack cleared. Signature Type: Standard, Name: Deauth flood, Description: Deauthentication flood, Track: per-Mac, Detecting AP Name: AP9caf.ca01.c870, Radio Type: 802.11b/g, Preced: 9, Channel: 1
105 Thu Sep 16 14:48:15 2010 IDS Signature attack cleared. Signature Type: Standard, Name: Auth flood, Description: Authentication Request flood, Track: per-signature, Detecting AP Name: AP9caf.ca01.c890, Radio Type: 802.11b/g, Preced: 5, Channel: 11
109 Thu Sep 16 14:31:49 2010 IDS Signature attack detected. Signature Type: Standard, Name: Auth flood, Description: Authentication Request flood, Track: per-signature, Detecting AP Name: AP9caf.ca01.c890, Radio Type: 802.11b/g, Preced: 5, Hits: 50, Channel: 11, srcMac: 00:1C:BF:7D:49:3F
110 Thu Sep 16 14:31:23 2010 IDS Signature attack detected. Signature Type: Standard, Name: Auth flood, Description: Authentication Request flood, Track: per-Mac, Detecting AP Name: AP9caf.ca01.c890, Radio Type: 802.11b/g, Preced: 5, Hits: 30, Channel: 11, srcMac: 00:1C:BF:7D:49:3F
Does someone really want to attack my wireless network?
Thanks!

Could be. Your AP is detecting an Intel Wireless NIC flooding de-authenticate messages. Your best bet is to track this machine down or contain it.

Similar Messages

IDS Signature Attacks - OVERLOAD

Guys,
I know that this has been talked about many timres, but wanted to ask a couple of points.
Question 1. On the WCS, on some days we are receiving up to 70+ critical alarms for signature attacks. These are all Deauth, Auth Flood attacks. (There are a couple of Assoc floods).
Pls see similar post on open forum
http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Wireless%20-%20Mobility&topic=Security%20and%20Network%20Management&topicID=.ee6e8c0&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc0798a
Now, in the signature file we have the following profiles set. (Pls note Deauth flood and Assoc Flood, BUT NO AUTH FLOOD)
Name = "Deauth flood", Ver = 0, Preced= 8, FrmType = mgmt, Pattern = 0:0:0x00C0:0x00FF, Freq=50, Quiet = 600, Action = report, Desc="Deauthentication flood", Track=signature_n_mac, MacFreq=30
Name = "Assoc flood", Ver = 0, Preced= 4, FrmType = mgmt, Pattern = 0:0:0x0000:0x00FF, Freq=50, Quiet = 600, Action = report, Desc="Association Request flood", Track=signature_n_mac, MacFreq=30
Can you guys or Cisco TAC advise us on if we need to change these values and are there any rules? and where is the signature pattern for an "Auth flood"? Dont see it in the file?
Question 2. The WCS only appears to report these critical signature alarms (and other alarms) for the last 7 days. I have tried to read through the WCS documentation and cannot find what happens to the alarms after 7 days and if this 7 day period is configurable?
Once again, Many thx guys for all the help,
Ken ( all IDS'd out )

I hadn't noticed before that the AUTH FLOOD has no corresponding IDS signature file entry - bizarre!
Attempts to get TAC to come up with any recommended changes for the signature file (at least in my experience going all the way to 3rd level TAC) resulted in an akward silence the other end of the line. I hope that your experience is better.
Each version of WLC software appears to fix some false alarms, but sometimes generates new ones. It is unclear if this is due to differing values in the signature file or (more likely) due to new code anomalies.
If you do run across better documentation on the Wireless IDS signature file, please feed it back into the forum.
As regular forum readers can attest, the Wireless IDS system false alarms, lack of explanation of the threat posture of these alarms, as well as the lack of documentaiton for tuning the signature file values without completely disabling the alarms, have been a sore spot with me.
I would even submit that it would be more helpful if Cisco would add a mechanism that would automatically forward these WIDS alarms (on a voluntary basis) back to Cisco. This would help Cisco developers to get a better idea of the numerous false positives we are seeing out here in the field enable them to provide a better-tuned signature file in the first place!
You may find the following post of interest:
http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Wireless%20-%20Mobility&topic=Security%20and%20Network%20Management&topicID=.ee6e8c0&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc08c87
As far as question 2 goes, when I tested this on our WCS 5.0, I am showing critical level security "WPA MIC" errors that go back to 5/19/08 (almost a month old).
Please remember to rate helpful posts.
John

IDS Signature attack detected...

I think my WLAN is under two DOS attacks, Deauth flood and Reassociation flood... The following are the traps shown on the controller (WLC 4402):
IDS Signature attack detected. Signature Type: Standard, Name: Deauth flood, Description: Deauthentication flood, Track: per-Mac, Detecting AP Name: W-Seattle-StudioRm8-02Flr-B-Fa36, Radio Type: 802.11b/g, Preced: 9, Hits: 30, Channel: 1, srcMac: 00:15:AF:ED:96:36
IDS Signature attack detected. Signature Type: Standard, Name: Reassoc flood, Description: Reassociation Request flood, Track: per-signature, Detecting AP Name: W-Seattle-StudioRm2-02Flr-B-Fa43, Radio Type: 802.11b/g, Preced: 6, Hits: 50, Channel: 6, srcMac: 00:1D:E0:99:5E
The network is for hotel guests so there is no authentication/encryption... Any suggestions about how I can mitigate those attacks?
In the trap messages they also list the Src MAC addresses. However I was reading about those two attacks and seems the attacks are actually spoofing MAC addresses of clients. So are they the real mac addresses of the hacker? Should I block them?
If I should, how can I do it? I was thinking using MAC-filter however it seems only allow clients with configured MAC addresses and will deny the ones that are not listed... As you can guess, we are hotel enviroment and we can't keep allowing new MAC addresses for new guests... So any suggestions?
Any advice is welcome! Thank you!

When you see 'deauth flood' messages this means that an
AP is seeing a lot of deauths in the air. These messages
often happen when a NIC card leaves an area where there
there are dense APs.
If you want this to trigger less often:
5.0:
Management > Trap Controls > 802.11 Security Traps > IDS Signature Attack
Wireless Protection Policies > Standard Signatures > >
modify/save
for example if you wanted to see the alarm on '60' detections of
'Deauth flood' instead of '50'.
Below 5.0:
You can modify the IDS settings so that the messages occurs less often
or not at all:
http://www.cisco.com/warp/public/102/controller_ids_sig.html
If you want it to trigger not at all:
Management > Trap Controls > 802.11 Security Traps > IDS Signature Attack
Below 5.0:
http://www.cisco.com/warp/public/102/controller_ids_sig.html

The wireless system has detected a possible intrusion attack by signature..

We are getting the following "critical" alert with the following:
Description
NULL Probe Response - Zero length SSID element
Message
{controller} IDS 'NULL probe resp 1' Signature attack detected on AP 'AP Name' protocol '802.11b/g' on Controller 'x.x.x.x'. The Signature description is 'NULL Probe Response - Zero length SSID element', with precedence '2'. The attacker's mac address is 'xx:xx:xx:xx:xx:xx', channel number is '6', and the number of detections is '1'.
Help
The wireless system has detected a possible intrusion attack by signature detection for a specific attacker. Immediate attention is required.
I'm trying to find more information on this and am wondering if this is a false/positive.
Thanks for help in advance.

I would point more towards a false positive alert here.
NULL Probe Response - Zero length SSID element:
Some frames are permitted to carry a null (zero length) SSID, called a broadcast SSID. For example, a station can send a probe request that carries a broadcast SSID; the AP must return its actual SSID in the probe response. Some APs can be configured to send a zero-length broadcast SSID in beacon frames instead of sending their actual SSID. However, it is not possible to keep an SSID value secret, because the actual SSID (ESS name) is carried in several frames.
As far as how to modify the IDS sensor in the WLC:
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008063e5d0.shtml
HTH

WCS IDS False Alarms - NetStumbler Generic Attack

We have a particular installation where we are seeing four (4) types of IDS errors constantly reappearing:
"IDS Signature attack detected. Signature Type: Standard"
"Disassoc flood, Description: Disassociation flood
"AP impersonation"
"NetStumbler Generic Attack"
In the first three alarms, Cisco has acknowledged that there are known issues with false IDS alarms that are supposed to be fixed in an upcoming "BE-MR2" in mid-December, and a new IDS signature in January.
Is anyone else experiencing the NetStumbler Generic IDS alarm? We see them on a regular basis.
If so, please reply - as I would like to forward this on to TAC to make sure they get this fixed in the next release.
We are using WLC-4.x and WCS 4.x with LAP-1131AG access points.
- John

The Disassociation attack is a known bug acknowledged by Cisco TAC. (That is not a guarantee that it is a false alarm - that is what has been especially frustrating in troubleshooting these).
Specifically, though, I am trying to confirm that others are experiencing the NetStumbler attack as we suspect this is another false alarm since it came from the MAC address of a trusted laptop that was confirmed to not be running NetStumbler - and, yes, I realize that the MAC address can be spoofed, but with the high number of false positives on the other types of alarms mentioned earlier, it would seem more likely that the WLC's IDS subsystem needs tweaking.
I would really like to get this fixed within the next release, and am hoping that additional confirmation may help get Cisco to resolve it more quickly.
- John

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

Need help with modifying IDS Sensor in WLC; Null Probe Response problem.

I need help in figuring out how to handle a NULL Probe Response report we are getting from our WCS.
We are getting the following alert from our WCS:
1. Message: IDS 'NULL probe resp 2' Signature attack cleared on AP 'XXXAP_#2' protocol '802.11b/g' on Controller '161.201.97.8'. The Signature description is 'NULL Probe Response - No SSID element'. - Controller Name: XXX-XXXX-XX
And
1. Message: IDS 'NULL probe resp 2' Signature attack detected on AP 'XXXAP#2' protocol '802.11b/g' on Controller '161.201.97.8'. The Signature description is 'NULL Probe Response - No SSID element', with precedence '3'. The attacker's mac address is 'ac:86:74:1e:15:5f', channel number is '5', and the number of detections is '1'. - Controller Name: XXX-XXXX-XX.
Is this something to be concerned with in terms of a potential attack, or should I ignore these types of emails?
According to a previous post here: https://supportforums.cisco.com/discussion/10731846/wireless-system-has-detected-possible-intrusion-attack-signature I need to modify my IDS Signature folder in the WLC. I have no idea how to modify the file itself into the format needed to prevent these intrusions. Could somebody please help me correctly enter the right format needed for this file, or correct me in my thinking. I assume I'm in the right direction but if anyone has further information that could be helpful it would be greatly appreciated. Thanks in advance.

The IDS signatures are stored in a file called wlc-sig_std.sig. That file can be edited via GUI by navigating to Security > Wireless Protection Policy > Standard Signatures. The links that you shared contain links to Cisco documentation that leave out the important parts of the documentation. The only way to get that documentation is to pull the existing signatures from the WLC using Commands > Upload File. Read that file for details on the syntax, then adjust your values in the GUI. I've attached a text document with the standard signature file.

WCS Error

Hai,
We have deployed 5508 WLC along with 3502 AP's, from wcs plus i am receiving the following error. Can anyone help me out what to do in this situation.
IDS 'Deauth flood' Signature attack detected on AP <AP NAME >' protocol '802.11b/g' on Controller < IP ADDRESS>. The Signature description is 'Deauthentication flood', with precedence '9'. The attacker's mac address is <MAC ADDRESS >, channel number is '6', and the number of detections is '300'.
Regards,
Muhammad Noman

Have you thought about the following:
- Check with TAC that your version of Controller software does not have a bug know to cause this, some do.
- Once a bug is ruled out, treat this like a genuine attack, and use rssi to detect the rogue AP sending these deauth messages. This shouldn't be too hard if you can see this on multiple APs.

WLC 5508 - SNMP traps

OK, so I'm at wit's end with this one now.
I configured my SNMP items on the controller and let it roll.
I started to watch my SNMP monitor (SNMPc Management Console by CastleRock) and saw some life from my controller. Yay, woot and dance.
I then started narrowing down the SNMP trap controls because I was getting more than what I want/need currently. I really just want to know if an AP falls off the network or if the controller's link drops.
I continued to get alerts that were just not desireable at this point.
The traps were similar to this:
ciscoLwappDot11ClientAssocNacAlert [1] cldcClientMacAddress.0.36.214.60.32.32 (DisplayString): 00:24:d6:3c:20:20 [2] cldcClientWlanProfileName.0.36.214.60.32.32 (DisplayString): Wireless [3] cldcClientIPAddress.0.36.214.60.32.32 (IpAddress): 172.31.19.101 [4] cldcApMacAddress.0.36.214.60.32.32 (DisplayString): 00:08:30:39:6c:80 [5] cldcClientQuarantineVLAN.0.36.214.60.32.32 (Integer): 0 [6] cldcClientAccessVLAN.0.36.214.60.32.32 (Integer): 119
I couldn't find the culprit, so I turned off (unchecked) all trap controls in the web interface and then verified in the CLI with "show trapflags".
I continue to get these same messages.
Any ideas?
Model: AIR-CT5508-K9
Version: 7.2.103.0

I went through the entire log (about 2000 lines) and almost all are this same type:
(Cisco Controller) >show traplog
Number of Traps Since Last Reset ............ 323738
Number of Traps Since Log Last Displayed .... 0
Log System Time              Trap
0 Mon Mar 11 08:21:49 2013 Client with MAC address 00:24:d6:3c:20:20 has joi
                             ned profile SC Wireless
1 Mon Mar 11 08:20:16 2013 Client with MAC address 00:24:d6:3c:20:20 has joi
                             ned profile SC Wireless
2 Mon Mar 11 08:19:09 2013 Client with MAC address 00:24:d6:3c:20:20 has joi
                             ned profile SC Wireless
3 Mon Mar 11 08:10:21 2013 Client with MAC address cc:af:78:44:7d:2b has joi
                             ned profile SC Wireless
4 Mon Mar 11 08:10:18 2013 Client with MAC address cc:af:78:44:7d:2b has joi
                             ned profile SC Wireless
Keep in mind that I have all trap controls disabled.
(Cisco Controller) >show trapflags
Authentication Flag.............................. Disable
Link Up/Down Flag................................ Disable
Multiple Users Flag.............................. Disable
configsave....................................... Disabled
strong-pwd check................................. Disabled
Client Related Traps
        802.11 Disassociation........................... Disabled
        802.11 Association.............................. Disabled
        802.11 Deauthenticate........................... Disabled
        802.11 Authenticate Failure..................... Disabled
        802.11 Association Failure...................... Disabled
        Excluded........................................ Disabled
        Authentication.................................. Disabled
Cisco AP
        AuthFailure..................................... Disabled
        Register........................................ Disabled
        InterfaceUp..................................... Disabled
802.11 Security related traps
        WEP/WPA Decrypt Error........................... Disabled
        IDS Signature Attack............................ Disable
AAA
        auth............................................ Disabled
        servers......................................... Disabled
rogueap......................................... Disabled
Auto-RF Profiles
        Load............................................ Disabled
        Noise........................................... Disabled
        Interference.................................... Disabled
        Coverage........................................ Disabled
Auto-RF Thresholds
        tx-power........................................ Disabled
        channel......................................... Disabled
Mesh
        auth failure.................................... Disabled
        child excluded parent........................... Disabled
        parent change................................... Disabled
        child moved..................................... Disabled
        excessive parent change......................... Disabled
        onset SNR....................................... Disabled
        abate SNR....................................... Disabled
        console login................................... Disabled
        excessive association........................... Disabled
        default bridge group name....................... Disabled
        excessive hop count............................. Disabled
        excessive children.............................. Disabled
        sec backhaul change............................. Disabled
Hopefully I'm just missing something stupid, but it appears all flags are off.
Message was edited by: Casey Hearn
Added "Show TrapFlags" details.

WLC - block MAC Address

Wireless system with 3 x WLC-4402, version 6.0.199.4, about 100 AP, about 300 clients.
I need to block some clients that are bombarding me with frequent and repeated "Signature attack" (Auth flood).
I tried to put the MAC Address in the black-list (Disabled Client), but it seams non work.
Other suggestion ?
Claudio

If its an authentication issue, then you can enable client exclusion on the WLAN also. 3 failures will automatically put them in the exculsion list. Not that I like pgrading, but the latest versions of 7.0.x are pretty good, but you need to make sure your AP's support that code. 6.x is pretty old.
http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html
Thanks,
Scott
Help out other by using the rating system and marking answered questions as "Answered"

Wireless AP

I am getting following logs on one of my controllers.
IDS Signature attack cleared. Signature Type: Standard, Name: Auth flood, Description: Authentication Request flood, Track: per-Mac, Detecting AP Name: BE-KO-A-AP103, Radio Type: 802.11b/g, Preced: 5, Channel: 6
The logs are from various channels and AP. Because of this users are not able to connect to wireless. Please help

However it says the attack is cleared, the authentication request flood attack !

WCS Alarms

Hi ,
Iam getting continueous alarm message on my WCS Server..
The messeges are " IDS 'NetStumbler generic' Signature attack cleared on AP " and " AP Impersonation " both are says critical alarms.
Please help me on how to resolve this alarms to stop generating.
Thanks & Regds,
Lalit

Hello,
Do a search in this document for netstumbler for an explanation of the IDS signature causing this alarm:
http://www.cisco.com/en/US/docs/wireless/controller/5.0/configuration/guide/c5sol.html
The AP impersonation alarm is triggered by an snmp trap sent by the WLC. The trap sent is:
bsnAPImpersonationDetected.
This happens when a radio of an authenticated access point has heard from another
access point whose MAC address neither matches that of a rogue nor is it an authenticated
neighbor of the detecting access point.
On aggressive environments, a helpful feature is to enable access point authentication with
a threshold of 2. This enables you to detect possible AP impersonation and minimize false
positive detections.
This is how to configure it from the CLI of the Wireless Lan Controller (WLC):
config wps ap-authentication enable
config wps ap-authentication threshold 2
Finally, you can change the severity of the AP impersonation alarm in WCS from critical to
lower so you are not alerted. This can be done from Administration > Settings > Severity Configuration.

1522 AP's and 3350 MSE

Hi,
I need to upgrade my location appliance. I am currently running a 2710, WCS version 6.0.196.0 and 21 4402 controllers on 6.0.182.0. There are 11 sites spread accross Canada and the Northern US. There are going to be a minimum of 4 more this year. The majority of my sites are outdoors and use 1522's. I have some indoor sites on 1242's, the biggest being an office building with 32 radios.
The problem I have is I've hit the limit on clients that can be tracked on the 2710. For the record, I don't run rogue detection on all radios. I spread it out so that I don't get too many overlaps. I am looking at moving to the 3350 but see that the WIPS software does not include 1522's. Does that mean I lose my ability to detect disassociation floods etc if I go to the new platform? Or, does the context aware software still provide some notification?
Thanks,
Dan

Scott,
Thanks very much for the reply. So if I just install a new 3350 I will still have my standard suite of signature attacks? I will still have triangulation of client devices available to show me client locations on my WCS Maps etc?
If so then I will go with the base 3350 and if required install any additional software down the road. I'm a little panicky right now as time is short and I have hit the limits of the 2710. Trying to budget the new MSE.
Thanks again,
Dan

WLAN Controller Message

Hi FREINDS,
I am consistly receiving following message on one of my WLAN controller, please could you tell me the severity level and solution of the following message:
IDS Signature attack cleared. Signature Type: Standard, Name: NULL probe resp 1, Description: NULL Probe Response - Zero length SSID element, Track: per-Mac, Detecting AP Name: KU-GF-I2-W03, Radio Type: 802.11b/g, Preced: 2, Channel: 11
Thanks & Regards,
Faysal

The null signature alarm is really nothing. I disabled this alarm on my wlcs.
Device can send different types of probe request. For example they ca. Send a direct probe request from your laptop to an ap. they can send broadcasted probe request from your laptop to everyone. And some device are programmed to send null probe reuest. Often if you run net stumbler that program sends null probes.
Some manufactures, not Cisco gear though, when they see a null probe request will respond with their hidden (non broadcasted) ssids.
These alerts are informing you that a device(s) are sending nulls ..
I hope this helps..
Sent from Cisco Technical Support iPhone App
Sent from Cisco Technical Support iPhone App

Auth Flood Issue

Hi,
I have 5508 setup with 450 - 3502E APs in our environment. The issue is that we have an auditorium that serves anywhere from 10 to 50 users. The issue is that I have seen that whenever the auditorium has alot of users in it, Auth Flood msgs are being generated.
I will be very grateful if someone can help with Cisco IDS Auth Flood parameters, as in which parameter should be tweaked in order to resolve this issue, without having any effect on the whole network? Furthermore, if someone has Cisco recommendation document on this I will be very grateful.
Thanks
Usama

Hi Usama,
When you see 'deauth flood' messages this means that an AP is seeing a lot of deauths in the air. These messages
often happen when a NIC card leaves an area where there there are dense APs.
If you want it to trigger not at all:
Management > Trap Controls > 802.11 Security Traps > IDS Signature Attack
Check the TAC reply for same kind of problem:
https://supportforums.cisco.com/thread/338432
Regards
Dont forget to rate helpful posts.

Signature attack ???

Similar Messages

Maybe you are looking for