Wireless Access

we are detecting lot of block ack attacks from clients inside our corporate network.

 

I wish to understand if this cause any harm to wifi network in terms of security ?

 

how can we detect source of this attack ?

 

thanks for help.

What version of ArubaOS?

6.1.3.6

This Block Ack is Causing Intermittent drops on client. my concern is how is this Block Ack attack generated ?

 

Would there be any cause on overall wireless network bcoz of that one client sending block ack attacks ?

Please open a support case.  It is entirely possible that the block ACK attacks are a false positive.

 

Just curious if you were able to find a resolution to this issue.. I have been experiencing the same problem with a Linux based mobile router (InMotion Router OMM).

 

I have tried turning on BC/MC Optimization, increasing the "Max Transmit Failures" to 20 under the SSID settings. Also tried turning off "Detect Block ACK DoS" under IDS settings.

 

The device is deleted from the controller causing the connection to drop on the router device. Although the device reports that the wireless connection is fine, no traffic (ping packets in this case) are able to go through. This happens every 1 minute or so which is very disturbing for any continous wireless communication.

 

Here are some other posts regarding the Block ACK packets but there are no resolutions posted:

 

http://community.arubanetworks.com/t5/802-11n-and-802-11ac-Basics-RF/Block-Ack-Request/td-p/51284

 

http://community.arubanetworks.com/t5/Wireless-IPS-and-Content/Block-Ack-Attack-the-cause-of-wifi-outage/td-p/48270

 

http://community.arubanetworks.com/t5/802-11n-and-802-11ac-Basics-RF/Block-ack-attack-causes/td-p/57184

 

 

Thanks!

A number of Block ACK attacks were logged as false positives and this was fixed in 6.1.3.6.  You should upgrade to 6.1.3.6 or later to see if the messages still exist.  If they still exist or if you still have client issues, please open a support case.

What good is the IDS detection if everything you see on has most likely been a false positive.???

Everytime I have inquired with support about a supposed attack.... it have been a false positive.

& I see that comment alot on all the BB....thanks

It honestly depends on what the alert is and why you have it enabled. Specific to Block ACK, it's very suceptible to clients with bad driver support, or when loads of clients have low SNR. From a WIDS perspective, the threat vector is VERY low (any high security concious customers should be using dot1x to which this attack is only a DoS anyway, akin to generating tons of noise targeted at one client).

 

So Block ACK, like many other signatures, requires a certain level of 'baselining' your environment first, then adjusting the triggers and thresholds in the controller so that the normal background noise of WIDS alerts is ignored and if there's an 'event' such that the triggers exceeds your modified thresholds, then you may or may not have something to investigate (though if you have an influx of new devices or clients are moving into low coverage areas, it might just be your new 'normal'). Some signatures, if seen, are actionable immediately, others may be trend or environmental without being a 'new threat'. As you may have found out, you can easily overload yourself with things that sound bad that turn out to be nascent, or are just 'normal noise'.

 

After Atmosphere, I will be writing up a WIDS VRD for AOS, Instant, and AirWave. I have all the moving parts, just not the time to sit and pound it all out, but I would expect the April time frame to expect it. It should have common vernacular descriptions of the signatures, a chart with best practices and recommendations based on your vertical, etc.  

I see lots of information here .... Little of it is actionable, or documented what to do with it, or what it might mean, or how to investigate it.

This makes it a waste the admins time.... More information on what to do, what it means, & how to stop it is needed but

Some attacks can only be detected, and there is nothing you can do about it.

Block ACKs is one of those attacks, but it is prone to false positives due to driver support.  You would probably need to be a security professional to know if the attacks are real, and what you can actually do about it.

 

I would disable it for now, since it is causing you issues with reporting.

This is just one example...
Omertà attacks gives the same false feedback.... False positives.

Omerta should NOT be a common alert (sic fasle positives) UNLESS you have loads of clients that have REALLY poor wifi chipsets/drivers. Omerta is a specific frame analysis signature looking for a specific string within the dossoc frame, and outside of the 'attack vector' no clients should send dissoc frames with that string. So if/when they do, it's most always a driver (bad driver) or bad wifi chipset. 

 

So if you ran something where you had loads of unknown clients with unquantified drivers/chipsets, you might see some/more false positive Omerta triggers, but then why would anyone run WIDS in an environment like that anyway. To that end, in a few months when the WIDS VRD comes out, we will provide guidance on the metrics/characterizations of each WIDS signature and when/where/why you may want to enable it ro not. As you've said, there's little guidance on each signature and we need to correct that, and we will be working on adding some new 'tunings' to our signatures baseline as part of a default config to account for new 'baseline thresholds' we see (ala we see more types of different kinds of frames due to 11n/11ac rates and new PHY technologies which in turns crosses some of those frame 'rate thresholds' and to mitigate requires raising those trigger thresholds, etc). 

 

TL;DR, more is coming and we will be using this and other feedback mechanisms to imrove. Thanks!

Per technician ...these are common false positive on 'Open' SSID's..... network

Gotcha, and at that point WIDS should be either disabled OR highly detuned (mostly just enable AP spoofing detection, ad-hoc on valid SSID, maybe hotspotter, etc) as there's really no such thing as 'WIDS' on an open SSID :)

Dear Everyone,

 

 it is very nice to see this conversation here :)

 I got same issues, IDS can cause a lot of false positive issue. Usually the only result in this situation if we turn off the problematic IDS feature but in this situation there is always a whole in our security because we won't be know when happen a real attack with the turned-off type.

 Is there any documentation or ppt or something what is the best IDS settings that give us security but limitate the false positives?

Thanks  a lot!

 

Gabor

It's in my wheelhouse to produce this starting mid-March and hope to have reviewed and published by late April, so it's coming. I have all the rough edges characterized, I just have to refine the language and build the platforms for capture. The document will have both detailed descriptions of the Signatures and what they identify, as well as a chart providing recommendations on what signatures should be enabled based on your vertical (K12, Retail, Government, etc). 

 

As far as tuning, we will add some guidance on what the knobs are, but the real 'effort' has to be done by the WLAN admins by baselining their environment, to figure out what the noise floor is based on their regular client compositions are. Some signatures are bad off the bat (AP spoofing, etc), others are more esoteric and ephemeral (things like framerate thresholds or malformed packets) because they can have a high degree of false positives NOT because it's a real threat, but because some vendors make crappy drivers. So that's part of the baselining. Also, some customers have enabled all WIDS signatures in environments that have no business enabling WIDS (think open SSIDs or guest environemtns like airports and retail with HIGH transient client compositions). 

 

So keep an eye out for the announcement about a WIDS VRD around the end of April.

Dear Jarrod,

 

 you are awesome!

 

 Thanks a lot, and we are waiting very excited the WIPS VRD.

 

Best Regards,

Gabor