IDS Signature attack

janet.maxwell · ‎01-25-2008

Good Day, We recently installed Cisco WISM's and 1240 AP's in our environment. Suddenly i am starting to see several of the messages below in the WISM logs,I turned off one of the AP's and noticed that the message cleared. Several hrs later it appeared referencing another AP. How do i verify that this is not a valid Breach? We have no other tools but the WISM to look at this. ====

IDS Signature attack detected. Signature Type: Standard, Name: Bcast deauth, Description: Broadcast Deauthentication Frame, Track: per-Mac, Detecting AP Name: AP12, Radio Type: 802.11b/g, Preced: 1, Hits: 30, Channel: 11, srcMac: 00:1B:77:5A:0E:D9

Rob Huffman · ‎01-25-2008

Hi Janet,

Have a look at this thread that details a number of Bugs relating to IDS False Alarms. John has done a great job;

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Wireless%20-%20Mobility&topic=Security%20and%20Network%20Management&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1ddf676d

Hope this helps!

Rob

johnruffing · ‎01-28-2008

Janet:

In my experience, the BCast Deuath can be the result of one of two different scenarios:

1) Your network is being attacked/contained by a different network. It might be an Aruba or another Cisco network. They may be seeing your equipment as rogue and are containing it.

2) (Most likely from my experience) You have decided to launch "containment" against rogue access points and your Cisco WIDS system is erroneously detecting its own containment messages and is alarming on them.

This is a known bug (BCast Deauth on Contained MAC - CSCsj06015) that we have been working with Cisco to get fixed for well over a year. It is supposed to be fixed in version "5.x" - whenever that is supposed to be.

Also, you may want to consider the following:

Depending upon the version of code that you are running, you will a range from many to a huge number of false alarms coming from the Wireless IDS.

While newer versions (such as 4.2) have improved SOME of this anomalous behavior, you will likely continue to see many alarms that are false positives.

Some normal behavior (such as a wireless device sending out a continuous string of deauthentication messages as a client goes out of range to ensure that the AP is no longer associated with the AP) is alarmed as anomalous behavior when, in fact, it is not. The string of 50 dissasociate messages is known, normal behavior. However, because the threashold is set to 30 in the WIDS file, the false alarms continue.

Cisco is aware of the fact that, in some cases, the threshold value of its WIDS file is set too sensitively (generating alarms on normal traffic). However, they have not been able to agree on what the improved WIDS files should be, and so we have seen little improvement in the WIDS - and the false alarms continue.

In some cases, the false alarms can be mitigated by making some adjustments to the parameters within the Wireless IDS signature file. If you choose to do this, you may want to work with TAC to ensure that you do not accidentally disable these alarms. However, my experience has been that TAC's ability to support the wireless IDS parameter file is sketchy at best. My advise is to continue to escalate to a higher level TAC engineer who can help advise you.

I have also found that the changes to the WIDS signature file are not recognized until after a reboot of the controller.

If I sound frustrated, it's only because I am (with Cisco's slow response to address their WIDS issues).

- John

(Please remember to rate helpful posts)