C’è un attacco che da anni si esegue con un Raspberry Pi da 40 euro e pochi comandi aireplay-ng: deauth flood. Espelle ogni client wireless da una rete in pochi secondi. E nel 2026, in molte aziende, funziona ancora.
Il problema non è il Wi-Fi in sé: è che i management frame dell’802.11 — beacon, deauth, disassociate, action — viaggiano in chiaro per design, indipendentemente dal cifrario WPA2/WPA3 sui data frame. PMF (Protected Management Frames, definito in 802.11w-2009) li firma e li cifra. Se non lo abiliti, il tuo WPA3 è zoppo.
Cosa proteggono i management frame
Pensa a tutto ciò che non è “dato utente”:
| Tipo frame | Funzione | Senza PMF |
|---|---|---|
| Beacon | Annuncio SSID, capability | Spoofabile (rogue AP) |
| Probe Request/Response | Discovery | Tracciabile (privacy) |
| Authentication | Inizio handshake | Manipolabile (downgrade) |
| Deauthentication | Disconnessione | Falsificabile (DoS istantaneo) |
| Disassociation | Rilascio risorse | Falsificabile (DoS istantaneo) |
| Action frame | QoS, BA, Radio Measurement | Inseribile |
Il vettore più sfruttato è il deauth: un attaccante invia un frame “fingendoti” il client o l’AP, e l’altro endpoint chiude la sessione. Con un loop, la rete è inutilizzabile finché il radio dell’attaccante è acceso.
PMF, in due righe
802.11w introduce due nuovi cifrari per i management frame protetti:
- BIP (Broadcast/Multicast Integrity Protocol) — firma i frame multicast (deauth diretto a tutti i client).
- CCMP/GCMP per management frame unicast — cifra e firma i deauth/disassociate diretti a un singolo client.
La chiave deriva dal 4-way handshake (IGTK per multicast, PTK per unicast): chi non ha la chiave non può forgiare un frame valido. Il risultato è che il deauth flood smette di funzionare contro client PMF-attivi.
I tre stati di PMF
Sull’AP imposti la modalità per SSID. Le opzioni reali nei prodotti enterprise:
- Disabled — niente PMF, vulnerabile. Da evitare salvo legacy hardware obbligatorio.
- Optional / Capable — l’AP supporta PMF e lo negozia per i client che lo dichiarano. Client vecchi continuano a connettersi senza protezione. Default in molti vendor — ed è il problema.
- Required / Mandatory — solo client PMF-capable possono associarsi. Sicuro, ma rifiuta dispositivi pre-2012.
WPA3 richiede sempre PMF mandatory. WPA2 lo supporta ma quasi mai lo impone, a meno che lo si configuri manualmente.
Cosa supporta PMF nella tua flotta
La compatibilità è migliore di quanto pensi:
- Windows 10/11 — supporto nativo da release iniziali, attivo se SSID lo richiede.
- macOS 10.10+, iOS 11+ — PMF mandatory funziona senza intervento utente.
- Android 6+ — supporto PMF; Android 10+ in modalità mandatory senza problemi.
- Linux con wpa_supplicant 2.4+ — PMF gestito via
ieee80211w=2. - IoT / barcode scanner / VoIP wireless — qui il rischio è reale. Molti dispositivi industriali pre-2018 non supportano PMF e si scollegano se forzato.
Prima di abilitare PMF Required, fai un inventario: una notte con un controller che logga le associazioni rifiutate ti dice esattamente chi ha problemi.
Strategia di migrazione enterprise
Quello che applichiamo nei progetti reali:
- Discovery: dump degli OUI dei MAC associati e classificazione client (laptop / smartphone / IoT / scanner / VoIP). Filtri tipici: client con OUI di Zebra, Honeywell, Aruba VoIP — vanno verificati uno per uno.
- SSID separati: due SSID anche sullo stesso VLAN — uno con WPA3-Personal/Enterprise + PMF Required (per client moderni), uno temporaneo WPA2 + PMF Optional (per IoT legacy). Si pianifica la dismissione del secondo entro 12 mesi.
- Test pilota in un’unica sede o piano: 2 settimane, monitor di errori associazione su SIEM (Wazuh / Graylog).
- Roll-out a ondate: per evitare che un cluster di dispositivi legacy generi un mass-disconnect.
- Verifica con pentest mirato: deauth flood + Pixie Dust + KRACK replay — se reggono, hai chiuso il capitolo.
Indicativamente in un’azienda con flotta moderna (laptop + smartphone aziendali + AP Wi-Fi 6) la migrazione completa richiede 3-6 settimane di lavoro.
Errori che vediamo spesso
- PMF Optional considerato sufficiente: non lo è. Un client che non lo richiede resta vulnerabile. Optional è un’estensione di compatibilità, non una postura di sicurezza.
- Abilitarlo solo sul SSID guest: il guest è di solito il meno critico. Servono soprattutto sul corporate.
- Non aggiornare il controller / firmware AP: implementazioni PMF in firmware vecchi (pre-2018) hanno bug di interoperabilità noti, soprattutto Cisco IOS-XE e alcuni Aruba CX. Serve patch level recente.
Come verificare se PMF è davvero attivo
Dal tuo laptop, una volta connesso:
# macOS
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I | grep -i "802.11w"
# Linux
iw dev wlan0 link | grep -i "rsna"
# Windows (PowerShell come admin)
netsh wlan show interfaces | findstr /i "PMF"Se non trovi conferma di “PMF: enabled” o “RSN ieee80211w: required”, la sessione non è protetta — anche se il SSID dichiara WPA3.
E nei pentest?
Quando facciamo un penetration test Wi-Fi la prima cosa che proviamo è il deauth flood mirato sul management VLAN. Se funziona, l’audit si chiude lì: il resto delle protezioni perde valore quando un attaccante può forzare la riassociazione di un client e poi fare evil-twin con captive portal.
PMF Required è la base. Sopra si costruiscono 802.1X, WPA3-Enterprise 192-bit, segmentazione, NAC. Senza la base, tutto il resto è teatro.
In sintesi
Se l’audit di un cliente ci consegna una rete WPA3 con PMF “Optional”, lo classifichiamo come finding High. Non Medium, High. Perché ignora la lezione più ripetuta degli ultimi quindici anni: il management plane di una rete è bersaglio almeno quanto il data plane.
Vuoi un audit veloce della tua configurazione PMF su tutti gli SSID? Scrivici: in mezza giornata leggiamo i tuoi controller, classifichiamo i client e ti diamo un piano di hardening.