In ´management frame protection´ (http://wiki.mikrotik.com/wiki/Wireless#Proprietary_extensions) MT implemented some measures against DOS attacks on wireless networks. But it works basically only 100% for MT AP-Client combinations.
I can set client to “required” and AP to “allowed” but what about non MT clients that don’t have such functionality?
A hacker can still spoof their mac’s and initiated de-auth data for these clients. If hacker can manage to do it for all non MT clients, and if there are enough, he can still bring the network down by simply occupy most of the air time of the AP.
Even protected MT-clients hardly get the change to communicate any more.
In http://users.csc.calpoly.edu/~bellardo/pubs/usenix-sec03-80211dos-html/node11.html
and http://www.sysnet.ucsd.edu/~bellardo/pubs/jsoe04-80211dos-poster.pdf
another approach is mentioned that could stop non MT-clients MAC spoofing to initiate attacks.
How is MT doing on this? Can they arrange something like this? Or can we already? May be I don’t know, can anybody fill me in?
Or has anybody another approach of stopping DOS attacks on the wireless?
R.
Hi Rudy
“The Management Frame required” was enabled on the AP and also on the MT clients the same.
It did nothing to stop the attack.
However, the old SmartBridge units were capable of no more than wep 128, there was 4 connected at the time of the attack. But because the SB is inadequate in security, I lumped these all together of a Virtual AP interface on the same AP, but pointed the security to WEP only.
Maybe if was the absense of ALL units to use ManFrame that caused the problem.
As you know the rest of the network was on the same subnet, (nothing routed), yet clients were not affected on the other AP’s… Only ALL clients disconnected on the one AP.
I read the article that you linked to and confirm that the deauths started at a few disconnects per second, recorded in the log, until after say 30 seconds the rate of disconnects rapidly increased. The router log eventually showing deauth entries of over 100 in a second.
( spending afternoon absorbed in PCQ which you have me addicted to and suffering bad cold, (hope I didnt pass that on)) it only started today.
I think your problem indeed was the fact you have non man.frame.protected clients.
Setting up a virtual AP for them was a good idea.
It would probably only stop a unicast attack. (like coming from one client)
But I think your guy was smart enough to send a broadcast attack and thus forcing all your non protected clients to dissassociate. At the same time he must have issued many RTS requests to the broadcast mac which then ´eats´ al radio time of both the AP and other non protected units.
This way even your protected units are denied their airtime?
That is only happens on one AP and not on the rest of the network makes sense to me.
The de-auth and RTS/CTS only works in the wireless network of that AP-client network I would presume.
But maybe Monday we will see more intake in this post from other readers or even MT!
I think the issue is something really needed to take a look at since attacks on wireless network will become more and more and issue.
R.
Some bug?
quote from manual (see link on top of topic):
required - establish association only with remote devices that support management protection (for AP - accept only clients that support management protection, for client - connect only to APs that support management protection).
I have client set (tried sec. profile setting “required” in both main wireless interface window as in the connect-to list) to required.
Now, it doesn’t matter if the AP is on “required”, “allowed” or “disabled”. It associates anyway!
When I set AP to “required” only MFP (management frame protection) enabled clients associate, not the none MFP clients.
So the “required” works as expected on the AP, but not on the client! Is this a bug?
Ap runs ROS4.5, client 3.30
R.