O que é um Probe Request? Compreender Como os Dispositivos Descobrem Redes

O que é um Probe Request? Compreender Como os Dispositivos Descobrem Redes. Uma Sessão Técnica da Purple. Introdução e Contexto. Bem-vindo a esta sessão técnica da Purple. Vou orientá-lo através de um dos mecanismos mais fundamentais — e frequentemente mais incompreendidos — no WiFi empresarial: o probe request. Se é responsável por uma implementação de guest WiFi, uma rede de retalho multi-site ou um programa de análise de recintos, compreender os probe requests não é opcional. É a base sobre a qual tudo o resto assenta — desde a análise de afluência e medição do tempo de permanência até aos desafios de aleatorização de MAC e conformidade com o GDPR. Então, vamos a isso. Sempre que um dispositivo — um smartphone, um portátil, um tablet — não está ligado a uma rede, está constantemente a procurar uma. Esse processo de varredura começa com um probe request. É uma trama de gestão, definida sob a norma IEEE 802.11, e é transmitida pelo dispositivo cliente, não pelo access point. Pense nisso como o dispositivo a gritar na sala: "Está aí alguém que eu conheça?" O access point escuta e, se reconhecer o pedido, responde. Isto acontece centenas de vezes por dia, muitas vezes sem que o proprietário do dispositivo o saiba. E para os arquitetos de rede e operadores de recintos, esses probe requests são uma mina de ouro de dados operacionais — se souber como capturá-los e interpretá-los corretamente. Análise Técnica Aprofundada. Vamos aprofundar a mecânica. Um probe request é uma trama de gestão de Camada 2 transmitida nas bandas de rádio de 2,4 GHz ou 5 GHz. Sob a norma IEEE 802.11, é classificado como uma trama de gestão de subtipo 4. A trama contém vários elementos de informação importantes: o campo SSID, o elemento de taxas suportadas, o elemento de taxas suportadas alargadas e informações de capacidade, incluindo capacidades HT — ou seja, de alto débito — e VHT para dispositivos 802.11ac. Existem dois tipos de probe requests. O primeiro é um broadcast probe request, por vezes chamado de probe wildcard. Aqui, o campo SSID está vazio — o dispositivo está essencialmente a pedir a qualquer access point ao alcance para se identificar. O segundo é um directed probe request, onde o campo SSID contém um nome de rede específico. Isto acontece quando o dispositivo está ativamente à procura de uma rede à qual se ligou anteriormente e que tem guardada na sua preferred network list. A resposta do access point — a trama probe response — reflete grande parte do conteúdo da trama beacon. Inclui o SSID, o BSSID, o intervalo do beacon, o carimbo de data/hora e o conjunto completo de capacidades. Esta troca é o que permite a um dispositivo construir a sua lista de redes disponíveis antes mesmo de o utilizador abrir as suas definições de WiFi. Agora, existe uma distinção importante entre varredura ativa e varredura passiva. A varredura ativa é o ciclo de probe request e response que acabei de descrever. A varredura passiva é diferente — o dispositivo simplesmente escuta as tramas beacon que os access points transmitem periodicamente, normalmente a cada 100 milissegundos. A varredura passiva é mais lenta, mas consome menos energia. A maioria dos dispositivos modernos utiliza uma combinação de ambas, dependendo do seu estado de energia e do domínio regulamentar em que estão a operar. É aqui que isto se torna operacionalmente significativo. Num recinto de alta densidade — um estádio, um centro de conferências, uma grande superfície comercial — pode ter milhares de dispositivos a enviar simultaneamente probe requests através de múltiplos canais. Isto cria o que é conhecido como condições de probe storm. Cada probe request consome tempo de antena. Numa rede mal desenhada, esta sobrecarga de tramas de gestão pode degradar visivelmente o débito para os clientes ligados. É por isso que os access points de classe empresarial implementam filtragem de probe requests e limitação de taxa como padrão. Agora vamos falar sobre endereços MAC e por que razão isto é extremamente importante para a análise de dados. Historicamente, cada probe request transportava o endereço MAC real de hardware do dispositivo — um identificador de 48 bits globalmente único gravado na placa de interface de rede. Isto tornava as análises baseadas em probes extremamente fiáveis. Podia monitorizar um dispositivo ao longo do seu recinto, medir o tempo de permanência, identificar visitantes recorrentes e construir mapas de calor de afluência com elevada confiança. Isso mudou significativamente com o iOS 14 em 2020 e o Android 10 antes dele. A Apple e a Google introduziram a aleatorização de endereços MAC para probe requests. Em vez de transmitirem o MAC real de hardware, os dispositivos geram agora um endereço MAC aleatório para a varredura. No iOS, esta aleatorização é por SSID — o que significa que o dispositivo utiliza um MAC aleatório consistente ao ligar-se a uma rede específica, mas um diferente ao efetuar probes. No Android, a implementação varia consoante o fabricante. O impacto prático para os operadores de recintos é significativo. As análises de afluência baseadas em probes que dependiam de endereços MAC persistentes são agora pouco fiáveis para dispositivos não ligados. As contagens de dispositivos únicos são inflacionadas. A identificação de visitantes recorrentes apenas a partir de dados de probes já não é viável. A solução — e é aqui que o guest WiFi autenticado se torna crítico — é mover a sua camada de identidade do endereço MAC para o utilizador autenticado. Quando um visitante se liga através de um captive portal ou de um login social, captura uma identidade persistente e consentida que sobrevive à aleatorização de MAC. A plataforma de guest WiFi da Purple faz exatamente isto — associa as análises à sessão autenticada, não ao endereço de hardware, fornecendo-lhe dados de afluência precisos e em conformidade com o GDPR, independentemente do comportamento do MAC do dispositivo. Existe também uma dimensão de segurança nos probe requests que os analistas de segurança de rede precisam de compreender. Como os probe requests são tramas de gestão não encriptadas, são visíveis para qualquer pessoa com uma ferramenta de captura de pacotes em modo de monitorização. Um directed probe request revela os SSIDs das redes às quais um dispositivo se ligou anteriormente — o que é conhecido como preferred network list, ou PNL. Esta é uma exposição real de privacidade. Um dispositivo que caminha pelo seu recinto está a transmitir os nomes de todas as redes a que alguma vez se ligou. Esta é uma das razões pelas quais a aleatorização de MAC foi introduzida em primeiro lugar. Do ponto de vista da superfície de ataque, os probe requests permitem ataques evil twin. Um atacante que capture um directed probe request para um SSID específico pode criar um access point falso com esse SSID e esperar que o dispositivo se ligue automaticamente. Os protocolos Enhanced Open e Simultaneous Authentication of Equals — SAE — do WPA3 mitigam significativamente este risco, mas apenas se a sua infraestrutura os suportar e impuser. Recomendações de Implementação e Erros Comuns. Muito bem, passemos para o que realmente deve fazer com isto numa implementação real. Primeiro, se estiver a implementar ou a atualizar uma rede de guest WiFi num recinto de alta densidade, o posicionamento dos seus access points e o planeamento de canais devem ter em conta a sobrecarga de probe requests. Utilize uma estratégia de largura de canal mínima — 20 MHz em 2,4 GHz — e implemente limiares mínimos de RSSI para evitar que dispositivos distantes se associem. A maioria dos controladores empresariais permite-lhe configurar a filtragem de respostas a probes para que os APs apenas respondam a dispositivos acima de uma determinada força de sinal. Isto reduz significativamente o ruído das tramas de gestão. Segundo, se estiver a realizar análises de afluência ou de tempo de permanência, aceite que os dados apenas de probes já não são suficientes. A sua estratégia de análise precisa de ser construída em torno de sessões autenticadas. Isto significa que o seu captive portal ou fluxo de adesão precisa de ser suficientemente fluido para que os visitantes se liguem realmente. Os dados da Purple mostram que os recintos com uma experiência de adesão bem desenhada — login social, captura de e-mail ou um fluxo sem palavra-passe — registam taxas de ligação de 60 a 80 por cento dos dispositivos no recinto. Essa é a sua população de análise. Terceiro, para a conformidade com o GDPR no Reino Unido e na UE, a recolha de dados de probe requests — mesmo anonimizados — requer uma avaliação cuidadosa da base jurídica. Se estiver a capturar e a armazenar tramas de probe para análise, precisa de documentar a sua base de interesse legítimo e garantir a minimização dos dados. As orientações do ICO sobre a monitorização de WiFi são claras: se conseguir identificar um indivíduo a partir dos dados, mesmo que indiretamente, trata-se de dados pessoais. Trabalhe com o seu DPO antes de implementar qualquer sistema de análise baseado em probes. Quarto, tenha atenção às probe storms em ambientes densos. Se estiver a registar uma degradação inexplicável do débito num recinto com elevada afluência, extraia os registos dos seus APs e analise as taxas de tramas de gestão. Uma probe storm é frequentemente a culpada. A solução é uma combinação de filtragem de RSSI mínimo, limitação da taxa de resposta a probes e garantia de que a sua banda de 5 GHz é devidamente anunciada para que os dispositivos compatíveis a prefiram em detrimento da de 2,4 GHz. Perguntas e Respostas Rápidas. Deixe-me passar por algumas perguntas que surgem regularmente. Posso utilizar probe requests para contar a afluência sem um captive portal? Tecnicamente sim, mas após o iOS 14 a precisão é fraca. Verá contagens únicas inflacionadas e nenhum dado de visitantes recorrentes. Para tudo o que vá além de estimativas aproximadas de ordem de grandeza, precisa de sessões autenticadas. Os probe requests funcionam em redes WiFi 6E de 6 GHz? Sim, mas com diferenças. A banda de 6 GHz utiliza um mecanismo de descoberta chamado FILS — Fast Initial Link Setup — e descoberta fora de banda, o que altera a dinâmica dos probes. Se estiver a implementar WiFi 6E, verifique a documentação do seu fabricante sobre o comportamento de varredura em 6 GHz. Qual é a diferença entre um probe request e um association request? Um probe request é pré-associação — o dispositivo está a descobrir redes. Um association request surge após a autenticação, quando o dispositivo está formalmente a solicitar a adesão a uma rede específica. São fases diferentes da máquina de estados de ligação 802.11. A aleatorização de MAC é consistente após a ligação? No iOS, sim — o dispositivo utiliza um MAC aleatório estável para um determinado SSID. No Android, varia. Algumas implementações voltam a aleatorizar em cada ligação. É por isso que a identidade baseada em sessões, e não a identidade baseada em MAC, é a arquitetura correta. Resumo e Próximos Passos. Para concluir: os probe requests são o batimento cardíaco da descoberta de WiFi. Todos os dispositivos no seu recinto estão a gerá-los constantemente. Compreender a sua estrutura, as suas limitações e as suas implicações de segurança é fundamental para desenhar implementações de guest WiFi fiáveis, capazes de efetuar análises e em conformidade com as normas. As principais conclusões são estas. Um: as análises baseadas em probes sem autenticação não são fiáveis num mundo pós-aleatorização de MAC. Dois: o guest WiFi autenticado é a sua camada de identidade — é o que torna as suas análises precisas e os seus dados em conformidade com o GDPR. Três: a gestão de probe storms é uma preocupação operacional real em recintos de alta densidade e precisa de ser abordada na fase de desenho da infraestrutura. Quatro: os directed probe requests expõem a preferred network list do seu dispositivo — um risco de segurança real que o WPA3 e as práticas de higiene de rede podem mitigar. Se quiser aprofundar este tema, a documentação técnica da Purple aborda a forma como a nossa plataforma agnóstica de hardware captura e processa dados de probes juntamente com dados de sessões autenticadas para lhe fornecer análises precisas de recintos. Também pode explorar os nossos guias sobre orientação de percursos (wayfinding) por WiFi e trilateração, que se baseiam diretamente nos fundamentos de probe requests que abordámos hoje. Obrigado por ouvir. Esta foi uma sessão técnica da Purple.