Preventing deauthentication attacks

Realistically, you cannot stop a bad guy from sending deauthentication packets.

Instead, you should focus on ensuring you are resilient to a deauth attack. Make sure your network is configured in a way that the deauth attack doesn't enable an attacker to compromise your network.

To do that, you need to make sure you are using WPA2. If you are using a pre-shared key (a passphrase), make sure the passphrase is very long and strong. If it is not already, change it immediately! If you are not using WPA2, fix that immediately!

The primary reason why bad guys send deauth packets is that this helps them execute a dictionary attack against your passphrase. If a bad guy captures a copy of the initial handshake, they can try out various guesses at your passphrase and test whether they are correct. Sending a deauth packet forces the targeted device to disconnect and reconnect, allowing an eavesdropper to capture a copy of the initial handshake. Therefore, standard practice of many attackers who might try to attack your wireless network is to send deauth packets. If you are seeing many deauth packets, that is a sign that someone may be trying to attack your wireless network and guess your passphrase.

Once the attacker has sent a deauth packet and intercepted the initial handshake, there are tools and online services that automate the task of trying to recover the passphrase, by guessing many possibilities. (See, e.g., CloudCracker for a representative example.)

The defense against this kind of attack is to ensure your passphrase is so long and strong that it cannot possibly be guessed. If it's not already long and strong, you need to change it right away, because someone is probably trying to guess it as we speak.

(The other reason a bad guy might send deauth packets is as an annoyance. However, as most users probably won't even notice, it's not a very effective annoyance.)

To learn more, see these resources:

  • How does deauthing work in aireplay-ng?

  • Can someone get my WPA2 password with honeypots?


Cisco spearheaded a method of detecting these attacks and even protecting this type of attack if it is enabled and the client device supports it (minimum support of CCXv5). The Cisco feature is called "Management Frame Protection" and full details can be found on the Cisco website.

In essence, the process adds a hash value to all management frames that are sent.

This process was standardized with the IEEE 802.11w amendment released in 2009, and is supported by most modern Linux/BSD distributions in the kernel. Windows 8 was introduced with 802.11w support by default (which did cause some initial problems in some environments). AFAIK, OS X still lacks 802.11w support.

For reference, 802.11w was rolled up in the 802.11-2012 maintenance release of the 802.11 standard.


Someone gave me an upvote which refreshed this answer in my mind and figured this was due an update.

The Wi-Fi Alliance (WFA) has made support of Protected Management Frames (PMF) mandatory to pass 802.11ac or Passpoint (aka HotSpot2.0) certifications. This has pushed support for 802.11w significantly and you can even find it in most consumer devices today.

Unfortunately, Apple still appears to be the holdout. Let me lead off by saying that I was surprised to find that Apple has not certified a single device with the WFA since early 2014. I know this is a voluntary process for vendors, but not taking part in the certification process seems like a bad idea to me for such a large manufacturer of wireless devices.

While Apple has added 802.11w support, there are still issues. Namely I came across this post earlier this year detailing issues with Apple connecting to a network with 802.11X authentication and 802.11w required. Networks that use a PSK (with 802.11w either optional or required) seem to work as do 802.1X networks with 802.11w optional.

So we are getting there, but still have some way to go.


The only way to prevent such an attack is to block the attacker's ability to send wireless transmissions that will reach your legitimate users. That's not a practical solution for several reasons (but extra points if you can convince your workers to sit in a Faraday Cage).

This blog page here quotes some of the relevant WiFi standard, most pointedly:

Deauthentication is not a request; it is a notification. Deauthentication shall not be refused by either party.

So, no, there's no real way to prevent such an attack.