Authentication and Association flood attack.

[bakaholic39]

Hi all!

I just want to know is there a way to configure rate limit for authentication and association request to prevent the flood attack, either on AireOS and IOS-XE WLC.

As in my understanding, this type of attack aims to AP's association table if this table reached to the limit this may cause the AP resource outage.

Since the Cisco aWIPS solution only for "detecting" the anomalies. (I'm not get it why does it called wireless intrusion prevention)

[Saikat Nandy]

It's not about attacking APs association table, it's more like a disruption to the existing wireless network by sending something which is not legitimate. Important to note that you need DNAC for aWIPS to work correctly. Please refer - 
1. https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-12/config-guide/b_wl_17_12_cg/m_awips.html
2. https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/catalyst-center-rogue-management-application/2-3-7/quick-start-guide/b_rogue_management_qsg_2_3_7/rogue_management_chapter_01.html

[bakaholic39]

Hi Saikat,

Thanks for reply. Yes, I have DNAC integrated with 9800 WLC, and refer to the 2nd doc you provided, it's mentioned about Authentication flood is attacking to AP's association table.

[Saikat Nandy]

True..the interpretation is important here (how easily it can be understandable) and that's why said 'disruption to the existing wireless network by sending something which is not legitimate.'

[bakaholic39]

Sure, the impact is disruptive to the wireless network, but I'm looking for a way to prevent it. If this flood is being sent by a single source device, and excluded clients feature may help mitigate it. However, if the attack comes from multiple source devices, how can I prevent it? Is there a way to configure rate limiting to ignore requests that exceed a threshold within a short period of time?

[Leo Laohoo]

I'd use Client Exclusion Timeout to offset this. 

[bakaholic39]

Yep, I agree with that. However, Client Exclusion may has its limitations if a device experiences five consecutive 802.11 association failures, it will be marked as Excluded. Does this mean the WLC utilizes CPU resources to classify these failures

In a scenario where an attacker generates a large number of fake client and send auth or assoc req to the WLC, even the Client Exclusion mechanism could lead to excessive resource consumption. Therefore, it may be more effective if there is something on the control plane-level that automatically ignores certain types of requests when flooding occurs within a short period

[Leo Laohoo]

---

@bakaholic39 wrote:
Does this mean the WLC utilizes CPU resources to classify these failures

---

Compared to a wireless client hammering the WLC with incorrect password?  

Depending on the network, if Client Exclusion is set to a good number, it is a good tool.  

For example, in a hospital.  We all know that medical wireless client like static credentials entered manually.  We set our Client Exclusion to 300 seconds.  If we set exclusion to <60 seconds, the failed client authentication can hammer our 9800-80 to it's knees.

[bakaholic39]

Yeah, I understand how Client Exclusion works, it's an effective tool for preventing the same client from repeatedly failing authentication or association attempts. I'm also exploring additional ideas to mitigate a DDoS attack scenario based on the C9800 aWIPS signature, particularly authentication and association floods. If anyone has implemented a wireless network with a strong focus on security or DDoS attack prevention, I would appreciate their insights and experiences.

From what I've found online, both the showcase and official Cisco documents on Cisco wireless security offer minimal breakdown of aWIPS technical details.

[Leo Laohoo]

---

@bakaholic39 wrote:
If anyone has implemented a wireless network with a strong focus on security or DDoS attack prevention, I would appreciate their insights and experiences.

---

That will depend on how the SSID is configured, how heavily "loaded" the WLC, etc.

For instance, it is highly recommended to use PSK and not use any outside authentication servers.  The reason behind this is because the communication channels between the controller and the authentication server can get overwhelmed if the Client Exclusion is nonexistence or is set at a lower rate. 

Next, the 9800-40/-80 cannot cope if the authentication is not open or PSK.  I can attest to this claim because the OS is buggy and almost anything can trigger a catastrophic memory leak.  

Combine that with a 9800-40/-80/M/H1/H2 with AP scale of >51% and a daily wireless client count of >10k and it will not take long before the controller's memory utilization will hit catastrophic level in weeks.  

[JPavonM]

Authentication and Association floods happen by sending to the AP lots of auth and association packets, during initial negotiation of the wireless connection, way before dot1X happen, so Client Exclussion or any other feature in the AAA service won't be able to stop these attacks.

[bakaholic39]

Thanks for sharing, I see the Client Exclusion condition in the doc: Cisco Catalyst 9800 Series Configuration Best Practices - Cisco
Would it be correct to say that Client Exclusion may not be effective against an authentication flood, but could help mitigate an association flood by triggering the condition of 'Five consecutive 802.11 association failures'?