Che cos'è una Probe Request? Capire come i dispositivi scoprono le reti

Che cos'è una Probe Request? Capire come i dispositivi rilevano le reti. Un briefing tecnico Purple. Introduzione e contesto. Benvenuti a questo briefing tecnico di Purple. Vi illustrerò uno dei meccanismi più fondamentali, e spesso più fraintesi, del WiFi aziendale: la probe request. Se vi occupate di un'installazione WiFi per ospiti, di una rete di vendita al dettaglio multisede o di un programma di analisi delle presenze in una sede, la comprensione delle probe request non è facoltativa. È la base su cui poggia tutto il resto: dall'analisi dell'affluenza e dalla misurazione dei tempi di permanenza alle sfide della randomizzazione dei MAC e alla conformità al GDPR. Entriamo quindi nel vivo dell'argomento. Ogni volta che un dispositivo (uno smartphone, un laptop, un tablet) non è connesso a una rete, esegue costantemente una scansione per trovarne una. Questo processo di scansione inizia con una probe request. Si tratta di un frame di gestione, definito dallo standard IEEE 802.11, che viene trasmesso dal dispositivo client e non dall'access point. Immaginatelo come se il dispositivo gridasse nella stanza: "C'è qualcuno che conosco?". L'access point ascolta e, se riconosce la richiesta, risponde. Questo accade centinaia di volte al giorno, spesso senza che il proprietario del dispositivo lo sappia. Per i progettisti di reti e i gestori di sedi, queste probe request sono una miniera d'oro di dati operativi, a patto che si sappia come acquisirle e interpretarle correttamente. Approfondimento tecnico. Analizziamo più a fondo gli aspetti tecnici. Una probe request è un frame di gestione di livello 2 (Layer 2) trasmesso sulle bande radio a 2,4 GHz o 5 GHz. Secondo lo standard IEEE 802.11, è classificata come frame di gestione di sottotipo 4. Il frame contiene diversi elementi informativi chiave: il campo SSID, l'elemento delle velocità supportate, l'elemento delle velocità supportate estese e le informazioni sulle funzionalità, tra cui le funzionalità HT (high-throughput) e VHT per i dispositivi 802.11ac. Esistono due tipi di probe request. Il primo è una probe request broadcast, a volte chiamata probe wildcard. In questo caso, il campo SSID è vuoto: il dispositivo sta essenzialmente chiedendo a qualsiasi access point nel raggio d'azione di identificarsi. Il secondo è una probe request diretta, in cui il campo SSID contiene un nome di rete specifico. Ciò accade quando il dispositivo sta cercando attivamente una rete a cui si è connesso in precedenza e che ha memorizzato nel suo elenco di reti preferite. La risposta dell'access point (il frame probe response) rispecchia gran parte del contenuto del frame beacon. Include l'SSID, il BSSID, l'intervallo di beacon, il timestamp e l'insieme completo delle funzionalità. Questo scambio è ciò che consente a un dispositivo di creare il proprio elenco di reti disponibili prima ancora che l'utente apra le impostazioni Wi-Fi. Ora, c'è un'importante distinzione da fare tra scansione attiva e scansione passiva. La scansione attiva è il ciclo di richiesta e risposta di probe che ho appena descritto. La scansione passiva è diversa: il dispositivo si limita ad ascoltare i frame beacon che gli access point trasmettono periodicamente, in genere ogni 100 millisecondi. La scansione passiva è più lenta ma consuma meno energia. La maggior parte dei dispositivi moderni utilizza una combinazione di entrambe, a seconda del loro stato di alimentazione e del dominio normativo in cui operano. È qui che la questione diventa rilevante dal punto di vista operativo. In una sede ad alta densità (uno stadio, un centro congressi, una grande area di vendita al dettaglio) si possono avere migliaia di dispositivi che inviano simultaneamente richieste di probe su più canali. Questo crea la cosiddetta condizione di "probe storm". Ogni richiesta di probe consuma tempo di trasmissione (airtime). In una rete mal progettata, questo sovraccarico di frame di gestione può degradare sensibilmente il throughput per i client connessi. Ecco perché gli access point di livello enterprise implementano di serie il filtraggio delle richieste di probe e la limitazione della frequenza (rate limiting). Parliamo ora degli indirizzi MAC e del perché questo è estremamente importante per gli analytics. In passato, ogni richiesta di probe conteneva il reale indirizzo MAC hardware del dispositivo, un identificatore a 48 bit univoco a livello globale masterizzato nella scheda di interfaccia di rete. Ciò rendeva gli analytics basati su probe estremamente affidabili. Era possibile tracciare un dispositivo all'interno della struttura, misurare il tempo di sosta (dwell time), identificare i visitatori ricorrenti e creare mappe di calore delle presenze con un elevato livello di affidabilità. La situazione è cambiata in modo significativo con iOS 14 nel 2020 e, in precedenza, con Android 10. Apple e Google hanno introdotto la randomizzazione degli indirizzi MAC per le richieste di probe. Invece di trasmettere il MAC hardware reale, i dispositivi ora generano un indirizzo MAC casuale per la scansione. Su iOS, questa randomizzazione avviene per ciascun SSID: ciò significa che il dispositivo utilizza un MAC casuale coerente quando si connette a una rete specifica, ma uno diverso durante il probing. Su Android, l'implementazione varia a seconda del produttore. L'impatto pratico per i gestori delle strutture è notevole. Gli analytics sulle presenze basati su probe che si affidavano a indirizzi MAC persistenti sono ora inaffidabili per i dispositivi non connessi. Il conteggio dei dispositivi unici risulta gonfiato. L'identificazione dei visitatori ricorrenti basata esclusivamente sui dati di probe non è più praticabile. La soluzione (ed è qui che il WiFi per ospiti autenticato diventa fondamentale) consiste nello spostare il livello di identità dall'indirizzo MAC all'utente autenticato. Quando un visitatore si connette tramite un Captive Portal o un login social, si acquisisce un'identità persistente e autorizzata che sopravvive alla randomizzazione dei MAC. La piattaforma guest WiFi di Purple fa esattamente questo: collega gli analytics alla sessione autenticata, non all'indirizzo hardware, fornendo dati sulle presenze precisi e conformi al GDPR, indipendentemente dal comportamento del MAC del dispositivo. C'è anche una dimensione di sicurezza legata alle probe request che gli analisti di sicurezza di rete devono comprendere. Poiché le probe request sono frame di gestione non crittografati, sono visibili a chiunque disponga di uno strumento di acquisizione pacchetti in modalità monitor. Una probe request mirata rivela gli SSID delle reti a cui un dispositivo si è connesso in precedenza, ovvero la cosiddetta preferred network list, o PNL. Si tratta di una reale vulnerabilità per la privacy. Un dispositivo che transita all'interno del tuo locale trasmette i nomi di tutte le reti a cui si è mai collegato. Questo è uno dei motivi per cui è stata introdotta originariamente la MAC randomisation. Dal punto di vista della superficie di attacco, le probe request consentono attacchi di tipo evil twin. Un utente malintenzionato che intercetta una probe request mirata per uno specifico SSID può attivare un access point non autorizzato con quell'SSID e attendere che il dispositivo si connetta automaticamente. I protocolli WPA3 enhanced open e simultaneous authentication of equals — SAE — mitigano significativamente questo rischio, ma solo se la tua infrastruttura li supporta e li applica. Raccomandazioni di implementazione e insidie. Bene, passiamo a come gestire concretamente questo aspetto in un deployment reale. In primo luogo, se stai implementando o aggiornando una rete WiFi per gli ospiti in una sede ad alta densità, il posizionamento degli access point e la pianificazione dei canali devono tenere conto del sovraccarico delle probe request. Utilizza una strategia di larghezza di banda minima del canale — 20 MHz su 2.4 GHz — e implementa soglie minime di RSSI per impedire l'associazione di dispositivi distanti. La maggior parte dei controller aziendali consente di impostare il filtraggio delle probe response in modo che gli AP rispondano solo ai dispositivi con una potenza di segnale superiore a una determinata soglia. Ciò riduce significativamente il rumore dei frame di gestione. In secondo luogo, se utilizzi analisi sui flussi di visitatori o sul tempo di permanenza (dwell time), tieni presente che i soli dati delle probe non sono più sufficienti. La tua strategia di analytics deve essere basata su sessioni autenticate. Ciò significa che il tuo Captive Portal o il flusso di onboarding devono essere così fluidi da spingere i visitatori a connettersi effettivamente. I dati di Purple mostrano che le strutture con un'esperienza di onboarding ben progettata — social login, acquisizione di email o flusso senza password — registrano tassi di connessione compresi tra il 60% e l'80% dei dispositivi presenti nella sede. Questa rappresenta la tua popolazione di riferimento per le analytics. In terzo luogo, per la conformità al GDPR nel Regno Unito e nell'UE, la raccolta dei dati delle probe request — anche se anonimizzati — richiede un'attenta valutazione della base giuridica. Se acquisisci e memorizzi i frame delle probe per scopi di analytics, devi documentare la tua base di legittimo interesse e garantire la minimizzazione dei dati. Le linee guida dell'ICO sul tracciamento WiFi sono chiare: se è possibile identificare un individuo dai dati, anche indirettamente, si tratta di dati personali. Collabora con il tuo DPO prima di implementare qualsiasi sistema di analytics basato su probe. In quarto luogo, attenzione alle "tempeste di probe" (probe storm) negli ambienti ad alta densità. Se riscontri un degrado inspiegabile del throughput in un luogo ad alta affluenza, estrai i log dei tuoi AP e analizza i frame rate di gestione. Una tempesta di probe è spesso la colpevole. La soluzione è una combinazione di filtraggio RSSI minimo, limitazione della frequenza di risposta ai probe (probe response rate limiting) e garanzia che la banda a 5 GHz sia pubblicizzata correttamente, in modo che i dispositivi compatibili la preferiscano a quella a 2.4 GHz. Domande e risposte rapide. Esaminiamo alcune domande che sorgono regolarmente. Posso usare le probe request per contare le presenze senza un Captive Portal? Tecnicamente sì, ma dopo iOS 14 la precisione è scarsa. Noterai conteggi univoci gonfiati e nessun dato sui visitatori ricorrenti. Per qualsiasi stima che vada oltre un ordine di grandezza approssimativo, sono necessarie sessioni autenticate. Le probe request funzionano sulle reti WiFi 6E a 6 GHz? Sì, ma con alcune differenze. La banda a 6 GHz utilizza un meccanismo di rilevamento chiamato FILS — Fast Initial Link Setup — e il rilevamento out-of-band, che modifica la dinamica dei probe. Se stai distribuendo il WiFi 6E, verifica la documentazione del tuo fornitore sul comportamento di scansione a 6 GHz. Qual è la differenza tra una probe request e una richiesta di associazione? Una probe request è precedente all'associazione: il dispositivo sta rilevando le reti. Una richiesta di associazione avviene dopo l'autenticazione, quando il dispositivo richiede formalmente di accedere a un SSID specifico. Si tratta di fasi diverse della macchina a stati delle connessioni 802.11. La randomizzazione del MAC è coerente una volta stabilita la connessione? Su iOS sì: il dispositivo utilizza un MAC randomizzato stabile per un determinato SSID. Su Android varia. Alcune implementazioni eseguono una nuova randomizzazione a ogni connessione. Ecco perché l'identità basata sulla sessione, e non quella basata sul MAC, rappresenta l'architettura corretta. Riepilogo e prossimi passi. Per riassumere: le probe request sono il battito cardiaco del rilevamento WiFi. Ogni dispositivo presente nella tua struttura le genera costantemente. Comprenderne la struttura, i limiti e le implicazioni di sicurezza è fondamentale per progettare installazioni di guest WiFi affidabili, conformi al GDPR e predisposte per l'analisi dei dati. I punti chiave sono questi. Uno: le analisi basate sui probe senza autenticazione non sono affidabili in un mondo post-randomizzazione del MAC. Due: il guest WiFi autenticato è il tuo livello di identità, ed è ciò che rende accurate le tue analisi e rende i tuoi dati conformi al GDPR. Tre: la gestione delle tempeste di probe è un problema operativo reale nei luoghi ad alta densità e deve essere affrontata in fase di progettazione dell'infrastruttura. Quattro: le probe request dirette espongono l'elenco delle reti preferite del dispositivo, un rischio reale per la sicurezza che il WPA3 e le pratiche di igiene di rete possono mitigare. Se desideri approfondire, la documentazione tecnica di Purple illustra come la nostra piattaforma indipendente dall'hardware acquisisca ed elabori i dati dei probe insieme ai dati delle sessioni autenticate per offrirti analisi accurate sulla tua struttura. Puoi anche esplorare le nostre guide sul wayfinding WiFi e sulla trilaterazione, che si basano direttamente sui concetti fondamentali delle probe request trattati oggi. Grazie per l'attenzione. Questo è stato un briefing tecnico Purple.