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.