05-13-2008 04:32 AM - edited 07-03-2021 03:51 PM
Hello all,
Apologies if this has been asked already. There seems to be many posts with people getting critical alarms and they are due to Cisco bugs ?
Couple of points.
I am running the above version and I am getting lots of IDS Deauth Auth and Assoc alarms on the WLCs/WCS.
How do I know if these are bug releated or not?
Also, does anyone know of how these three and the other signature attacks work? IE, a deauth is a number of deauth messages sent to an AP, but how many gets sent before the WLC reports on them? ie, what is the criteria to generate IDS alarms. Also for the other signature attacks?
There does not seem to be too much docs on this on the web?
Many thx and kind regards,
Ken
Solved! Go to Solution.
05-13-2008 07:06 AM
Ken:
This is an area that has been a bit murky in terms of documentation. There have been a number of requests for better documentation, but we are still waiting to see it.
Surprisingly, one of the best forms of
"documentation" is by reviewing the Wireless IDS signature file which has some comments and explains how the parameters work. You may find that a bit enlightening.
Also, when it comes to false alarms, we have seen quite a number of them in various flavors. Here are a couple of thoughts:
If you are performing "containment" or rogue APs, the Wireless IDS system currently interprets its own containment messages as a false-positive/attack. This is a known bug ( CSCsj06015 )that says it is fixed, but to my knowledge continues to be a problem.
Here is a link to the bug:
Also, when certain brands of clients go out of range, a string of dissassociation messages is sent over the RF to ensure that the RF connection is broken. However, the number of these legitimate sign-offs sometimes exceeds the permitted value in Cisco's Wireless IDS signature file and the WLC erroneously interprets these as a false-positive / attack, when in fact, it is a normal signoff. The value of the number of detections per second can be adjusted (in fact, TAC suggested making some changes there - but this really needs to be tuned better at the factory to prevent these from ocurring). One of the links below discusses the methodology for changing the Wireless IDS. Newer versions of the WCS/WLC are supposed to allow a parameter/GUI based edit of these parameters vs. exporting/editing/uploading the Wireless IDS signature file out of/into each WLC.
For your reading pleasure, here are some links that you might find helpful which discuss various wrinkles in the wireless IDS:
Thanks,
John
(Please remember to rate helpful posts)
05-14-2008 06:47 AM
I believe that MacFreq has to do with how many packets per time interval have come from the SAME mac address vs. Freq which would be ANY mac address within the specified timeframe.
That's my take at least.
- John
05-13-2008 07:06 AM
Ken:
This is an area that has been a bit murky in terms of documentation. There have been a number of requests for better documentation, but we are still waiting to see it.
Surprisingly, one of the best forms of
"documentation" is by reviewing the Wireless IDS signature file which has some comments and explains how the parameters work. You may find that a bit enlightening.
Also, when it comes to false alarms, we have seen quite a number of them in various flavors. Here are a couple of thoughts:
If you are performing "containment" or rogue APs, the Wireless IDS system currently interprets its own containment messages as a false-positive/attack. This is a known bug ( CSCsj06015 )that says it is fixed, but to my knowledge continues to be a problem.
Here is a link to the bug:
Also, when certain brands of clients go out of range, a string of dissassociation messages is sent over the RF to ensure that the RF connection is broken. However, the number of these legitimate sign-offs sometimes exceeds the permitted value in Cisco's Wireless IDS signature file and the WLC erroneously interprets these as a false-positive / attack, when in fact, it is a normal signoff. The value of the number of detections per second can be adjusted (in fact, TAC suggested making some changes there - but this really needs to be tuned better at the factory to prevent these from ocurring). One of the links below discusses the methodology for changing the Wireless IDS. Newer versions of the WCS/WLC are supposed to allow a parameter/GUI based edit of these parameters vs. exporting/editing/uploading the Wireless IDS signature file out of/into each WLC.
For your reading pleasure, here are some links that you might find helpful which discuss various wrinkles in the wireless IDS:
Thanks,
John
(Please remember to rate helpful posts)
05-13-2008 07:15 AM
John, This is fantastic. Many thx for the help. Starting to look at this now :))
Kind regards,
Ken
05-13-2008 07:26 AM
Hi John
So..
# Broadcast deauth flood
Name = "Bcast deauth", Ver = 0, Preced= 1, FrmType = mgmt, Pattern = 0:0:0x00C0:0x00FF, Pattern = 0:4:0x01:0x01, Freq=50, Quiet = 300, Action = report, Desc="Broadcast Deauthentication Frame", Track=signature_n_mac, MacFreq=30
Im sorry, I dont get this bit - Freq and MacFreq?
My Head hurts :(
# MacFreq = Packet match frequency in packets/interval. The value of this token indicates how many packets
# per measurement interval must match this signature before the signature 'Action' is executed. A value of
# 0 indicates that the signature 'Action' is to be taken ever time a packet matches the signature.
# The maximum value for this token is 65535.
# This token is optional if 'Track' is missing, or the 'Track' is 'signature'.
# Otherwise, there must be one 'MacFreq' token per signature if the 'Track' is 'mac' or 'signature_n_mac'.
#
# Freq = Packet match frequency in packets/interval. The value of this token indicates how many packets
# per measurement interval must match this signature before the signature 'Action' is executed. A value of
# 0 indicates that the signature 'Action' is to be taken ever time a packet matches the signature.
# The maximum value for this token is 65535.
# This token is optional if 'Track' is present and the 'Track' is 'mac'.
# Otherwise, there must be one 'Freq' token per signature.
#
Could you help clarify this point mate?
Many thx indeed,
Ken
05-14-2008 06:47 AM
I believe that MacFreq has to do with how many packets per time interval have come from the SAME mac address vs. Freq which would be ANY mac address within the specified timeframe.
That's my take at least.
- John
09-15-2008 09:04 AM
Hi John,
do you know if bug CSCsj06015 is already fixed with any release ( 5.0 ?), because we have 4.2.130.0 running and still getting auth / deauth flood messages at our management station?
Thanks a lot for your help.
Best regards.
Matthias
09-16-2008 03:59 AM
Matthias:
I believe that this is finally fixed in the newest release of 5.1.151.0
(See the email from the 3rd-level Cisco TAC engineer)
"I've upgraded to 5.1.151.0 in my lab and I am no longer seeing the false rogue messages."
Hope his helps,
John
(Please remember to rate helpful posts)
09-17-2008 12:57 AM
Hallo,
thanks a lot for your reply.
I thing i am going to upgrade to release 5 as soon as possible.
Sincerely,
Matthias
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: