cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1744
Views
4
Helpful
7
Replies

WLC v4.2.112.0 - IDS Signatures - Deauth/Auth and Assoc Floods

kfarrington
Level 3
Level 3

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

2 Accepted Solutions

Accepted Solutions

johnruffing
Level 4
Level 4

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:

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

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:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.1ddf672c/0#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Expert%20Archive&topic=Wireless%20-%20Mobility&topicID=.ee7f999&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cbf522e/16#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cbf520e/1#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cbeccbc/0#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.1ddfaecb/1#selected_message

Thanks,

John

(Please remember to rate helpful posts)

View solution in original post

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

View solution in original post

7 Replies 7

johnruffing
Level 4
Level 4

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:

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

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:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.1ddf672c/0#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Expert%20Archive&topic=Wireless%20-%20Mobility&topicID=.ee7f999&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cbf522e/16#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cbf520e/1#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cbeccbc/0#selected_message

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.1ddfaecb/1#selected_message

Thanks,

John

(Please remember to rate helpful posts)

John, This is fantastic. Many thx for the help. Starting to look at this now :))

Kind regards,

Ken

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

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

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

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)

Hallo,

thanks a lot for your reply.

I thing i am going to upgrade to release 5 as soon as possible.

Sincerely,

Matthias

Getting Started

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: