AP Containment results in false Bcast Deauth alarms on the WLC / WCS

Unanswered Question

Here is something that I was surprised to learn:


If you turn on containment, the WLC will detect its own containment messages as "Bcast Deauth" wireless IDS errors.


See bug CSCsj06015 "Prevent 'Bcast deauth' alerts for rogue containment by other WLC in MG" for details.


http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&from=myNotification&bugId=CSCsj06015


Of course, it is technologically possible for the WLCs / RF Group of WLCs to keep a table of all the mac addresses that they are containing. If they detect a broadcast deauthentication (aka" Bcast deauth ), they should filter out these false positives so that you don't get flooded with these wireless IDS alarms (which are flagged as "Critical" in the system).


Apparently, the Cisco engineers point out that it is impossible to tell over the air where the attack is coming from and this is true (without MFP).


However, since I am actively launching containment against a rogue wireless device, do I really care if another hacker is helping me keep that device off the network?


Therefore, the wireless IDS system needs to be intelligent enough to filter out Bcast deauth alarms that it is creating.


Sadly, Cisco has labelled this bug as "cosmetic" at this time (4.1.171) .


- John


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Further efforts appear to indicate that the Wireless IDS will alarm on ANY dissassociation storm of traffic - whether it is intended for a trusted client or AP, or the dissassocation attack is launched against external ("rogue") clients/APs that are not even attached to your own system.


We have run this issue all the way to 3-tier TAC who gives us the response from the Wireless Business Development Unit (WNBU): "that's not a bug, it's a feature request" - which is quickly becoming the WNBU mantra when they encounter a bug they don't want to fix (we are hearing the same nonsense regarding sychronization issues between the WLC and WCS).


This has resulted in our having to make a formal request through the Cisco sales team for Cisco to add the "feature" that the wireless IDS not alarm on its own Wireless IDS containment messages.


Has anyone else experiencing these false alarms?


Why would I care if a hacker is attacking an adjacent system or system admin using an RF control system outside of my own RF system is containing a rogue AP or not?


Should the control system be expected to alarm on its own containment message by design?


Any thoughts?


- John

Actions

This Discussion

 

 

Trending Topics - Security & Network