Damaso,
When we have asked for documentation of this part of the system, it has been acknowledged by Cisco that this is still very poorly documented. It is my understanding that this is being worked on.
However, in the mean time, you may want to "upload" the Signature file from your WLC. This is a text file that is fairly well-documented and you will find some helpful information regarding the values in the Wireless IDS signature file and what they do.
To download the file from your WLC:
Commands -> Upload File -> Select 'Signature file' from the dropdown and store the file where you like.
For your convenience, I have included the factory version of the IDS signature file.
In case you are thinking about making any changes to your Wireless IDS file, you may be interested in our experience:
* We found that the WLC appeared to need a reboot after updating and "downloading" the IDS signature file to the WLC.
* File nameing appears to be VERY important (as in: DON'T CHANGE THE WIDS FILE NAME or the WLC will not parse the new signature file.
* In terms of understanding exactly what a particular alarm is, why it is critical, etc. Cisco is notably silent on this at this time. If you are using AirMagnet, you may find their descriptions much more meaningful since they explain what behavior causes these kinds of alarms, as well as why they may be a threat.
If you are looking into this because you are suffering from what appear to be false alarms from your system, you may also benefit from what we are going through with Cisco over the past eleven months with the WIDS:
After suffering from a number of false alarms in the system: Bcast Deauth, Disassoc Flood, Deauth Flood, we asked TAC for some help (back in October 2006).
After numerous promises that the problem would be "fixed in the next release" we finally got into June 2007 with some of the false alarms going away, and others appearing that were not before.
After our customer expressed their dissatisfaction, TAC, in a desperate attempt to try something, suggested adjusting some of the WIDS signature file values as follows: "Bcast Deauth", "Broadcast Probe flood", "Disassoc flood" Cisco TAC had us adjust our "Freq" values from 50 to 80 because it is not uncommon for certain drivers to sign off with a string of 64 disassociation messages once the client has drifted out of range. However, due to the low value for "Freq" (which is factory-set to 50). The value of 50 can often result in false alarms as clients send their normal signoff 64 times when going out of range. (Why 64 is not the default for these alarms is still unclear). So, we were directed to change the Freq=50 statements to Freq=80.
Result: While this will theoretically helps reduce false positives and may have minimally reduced their frequency, our customer's system still alarms on its own containment messages (even in 4.1.185) due to a bug in WLC IDS system. Bug ID: CSCsj06015 - Prevent 'Bcast deauth' alerts for rogue containment by other WLC in MG.
The level that WNBU (the Wireless Business Unit) has assigned for this bug is 6 (the lowest priority / a "cosmetic" bug) and it has been relegated to a "feature request" (apparently, for the WLC to NOT alarm on its own containment signals is a feature). To get this bug fixed, request has had to go through sales team, back to TAC, and ultimately to the product manager for the WLC!
WNBU's motto seems to have become "it's not a bug, it's a Feature Request".
We are still working with Cisco to get this self-alarming "feature request" escalated so that we do not continue to get CRITICAL false alarms from the WLC when we are performing containment.
Also, we are awaiting better documentation from Cisco on what these alarms are and how they are a threat.
I hope your experience with the Wireless IDS goes smoother than ours has so far.
- John
