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

Che cos'è una Probe Request? Capire come i dispositivi scoprono le reti. Un briefing tecnico Purple. Introduzione e contesto. Benvenuti a questo briefing tecnico Purple. Vi guiderò attraverso uno dei meccanismi più fondamentali — e più frequentemente fraintesi — del WiFi aziendale: la probe request. Se siete responsabili del deployment di un WiFi per ospiti, di una rete retail multi-sito o di un programma di analytics per un locale, comprendere le probe request non è un'opzione. È la base su cui poggia tutto il resto - dall'analisi del flusso di visitatori e la misurazione del tempo di permanenza fino alle sfide della randomizzazione dei MAC e alla conformità al GDPR. Quindi, entriamo nel vivo. Ogni volta che un dispositivo - uno smartphone, un laptop, un tablet - non è connesso a una rete, esegue costantemente una scansione alla ricerca di una connessione. 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 il dispositivo che grida 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. E per gli architetti di rete e i gestori dei locali, queste probe request sono una miniera d'oro di dati operativi - se si sa come catturarle e interpretarle correttamente. Approfondimento tecnico. Entriamo più nel dettaglio dei meccanismi. Una probe request è un frame di gestione di Livello 2 trasmesso sulle bande radio a 2.4 GHz o 5 GHz. Secondo lo standard IEEE 802.11, è classificato come un 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à, comprese le funzionalità HT - ovvero high-throughput - e VHT per i dispositivi 802.11ac. Esistono due tipi di probe request. Il primo è una probe request di broadcast, talvolta chiamata probe wildcard. In questo caso il campo SSID è vuoto - il dispositivo sta essenzialmente chiedendo a qualsiasi access point nel raggio di copertura 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 di probe response - rispecchia gran parte del contenuto del frame di 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 WiFi.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 beacon frame 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 dello stato di alimentazione e del dominio normativo in cui operano. Ecco dove la questione diventa rilevante dal punto di vista operativo. In un locale ad alta densità - uno stadio, un centro congressi, una grande area retail - si possono avere migliaia di dispositivi che inviano simultaneamente richieste di probe su più canali. Questo crea una condizione nota come tempesta di probe. Ogni richiesta di probe consuma tempo di trasmissione radio. In una rete progettata male, questo sovraccarico di frame di gestione può degradare sensibilmente la velocità di trasmissione per i client connessi. Questo è il motivo per cui gli access point di livello enterprise implementano di serie il filtraggio delle richieste di probe e la limitazione della velocità. Parliamo ora degli indirizzi MAC e del perché questo sia estremamente importante per l'analytics. Storicamente, ogni richiesta di probe conteneva il vero indirizzo MAC hardware del dispositivo - un identificatore univoco a 48 bit a livello globale registrato nella scheda di interfaccia di rete. Ciò rendeva l'analytics basata sui probe estremamente affidabile. Era possibile tracciare un dispositivo all'interno del locale, misurare il tempo di permanenza, identificare i visitatori ricorrenti e creare mappe di calore delle presenze con un'elevata accuratezza. La situazione è cambiata notevolmente 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 vero MAC hardware, i dispositivi ora generano un indirizzo MAC randomizzato per la scansione. Su iOS, questa randomizzazione avviene per SSID - il che significa che il dispositivo utilizza un MAC randomizzato coerente quando si connette a una rete specifica, ma uno diverso quando invia probe. Su Android, l'implementazione varia a seconda del produttore. L'impatto pratico per i gestori dei locali è notevole. L'analytics delle presenze basata sui probe, che si affidava a indirizzi MAC persistenti, non è più affidabile per i dispositivi non connessi. Il conteggio dei dispositivi univoci risulta gonfiato. L'identificazione dei visitatori ricorrenti basata esclusivamente sui dati dei 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 per WiFi per ospiti di Purple fa esattamente questo - associa l'analytics alla sessione autenticata e non all'indirizzo hardware, fornendo dati sulle presenze accurati 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 packet capture in modalità monitor. Una probe request diretta rivela gli SSID delle reti a cui un dispositivo si è connesso in precedenza - quella che è nota come preferred network list, o PNL. Si tratta di una vera e propria esposizione della privacy. Un dispositivo che attraversa la tua struttura sta trasmettendo i nomi di ogni singola rete a cui si è mai collegato. Questo è uno dei motivi per cui, in primo luogo, è stata introdotta la randomizzazione dei MAC. Dal punto di vista della superficie di attacco, le probe request consentono attacchi di tipo evil twin. Un utente malintenzionato che cattura una probe request diretta per uno specifico SSID può configurare un access point non autorizzato con quell'SSID e attendere che il dispositivo si connetta automaticamente. I protocolli enhanced open e simultaneous authentication of equals - SAE - di WPA3 mitigano significativamente questo rischio, ma solo se la tua infrastruttura li supporta e li impone. Raccomandazioni di implementazione e insidie. Bene, passiamo a ciò che si fa concretamente in una distribuzione reale. In primo luogo, se stai implementando o rinnovando una rete WiFi per gli ospiti in una struttura 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 del canale minima - 20 MHz su 2.4 GHz - e implementa soglie RSSI minime 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 che superano una determinata potenza del segnale. Questo riduce significativamente il rumore dei frame di gestione. In secondo luogo, se gestisci analisi delle presenze o del tempo di permanenza, accetta il fatto che i dati provenienti solo dalle 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 che i visitatori si connettano effettivamente. I dati di Purple mostrano che le strutture con un'esperienza di onboarding ben progettata - login social, acquisizione dell'e-mail o un flusso senza password - registrano tassi di connessione compresi tra il 60 e l'80 percento dei dispositivi presenti. Questa è la tua popolazione di analisi. In terzo luogo, ai fini della 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 analisi, 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 puoi identificare un individuo dai dati, anche indirettamente, si tratta di dati personali. Collabora con il tuo DPO prima di implementare qualsiasi sistema di analisi basato sulle probe. In quarto luogo, occorre prestare attenzione alle tempeste di probe negli ambienti ad alta densità. Se noti un degrado inspiegabile del throughput in un luogo ad alta affluenza, estrai i log dei tuoi AP e analizza i tassi dei frame di gestione. Spesso la causa è una tempesta di probe. La soluzione è una combinazione di filtraggio RSSI minimo, limitazione del tasso di risposta dei probe 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. Vediamo rapidamente alcune domande che sorgono regolarmente. Posso usare le richieste di probe per contare le presenze senza un Captive Portal? Tecnicamente sì, ma dopo iOS 14 la precisione è scarsa. Vedrai un numero di dispositivi unici gonfiato e nessun dato sui visitatori ricorrenti. Per qualsiasi dato che vada oltre una stima approssimativa, sono necessarie sessioni autenticate. Le richieste di probe 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 un rilevamento fuori banda, il che cambia 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 richiesta di probe e una richiesta di associazione? Una richiesta di probe precede l'associazione - il dispositivo sta rilevando le reti. Una richiesta di associazione arriva dopo l'autenticazione, quando il dispositivo richiede formalmente di accedere a una rete specifica. Si tratta di fasi diverse della macchina a stati di connessione 802.1X. 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'architettura corretta deve basarsi sull'identità della sessione e non sull'identità basata sul MAC. Riepilogo e prossimi passi. Per concludere: le richieste di probe sono il battito cardiaco del rilevamento WiFi. Ogni dispositivo all'interno del tuo spazio ne genera costantemente. Comprendere la loro struttura, i loro limiti e le loro implicazioni di sicurezza è fondamentale per progettare installazioni di guest WiFi affidabili, conformi alle normative 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à - è ciò che rende accurate le tue analisi e rende i tuoi dati conformi al GDPR. Tre: la gestione delle tempeste di probe è una reale preoccupazione operativa nei luoghi ad alta densità e deve essere affrontata in fase di progettazione dell'infrastruttura. Quattro: le richieste di probe dirette espongono l'elenco delle reti preferite del tuo dispositivo - un reale rischio di sicurezza che WPA3 e le pratiche di igiene di rete possono mitigare. Se desideri approfondire l'argomento, la documentazione tecnica di Purple spiega come la nostra piattaforma agnostica rispetto all'hardware acquisisca ed elabori i dati dei probe insieme ai dati delle sessioni autenticate per offrirti analisi accurate sulla tua sede. Puoi anche esplorare le nostre guide sulla navigazione e sulla trilaterazione WiFi, che si basano direttamente sui concetti fondamentali delle richieste di probe che abbiamo trattato oggi. Grazie per l'attenzione. Questo è stato un briefing tecnico di Purple.