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

O que é um Probe Request? Compreender como os dispositivos descobrem redes. Um briefing técnico da Purple. Introdução e contexto. Bem-vindo a este briefing técnico da Purple. Vou orientá-lo através de um dos mecanismos mais fundamentais - e mais frequentemente mal compreendidos - no WiFi empresarial: o probe request. Se é responsável por uma implementação de guest WiFi, por uma rede de retalho multi-site ou por um programa de análise de locais públicos, compreender os probe requests não é opcional. É a base sobre a qual tudo o resto se apoia - desde a análise de tráfego de visitantes e medição do tempo de permanência até aos desafios de randomizaçã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 pesquisa começa com um probe request. É uma trama de gestão, definida ao abrigo do IEEE 802.11, e é transmitida pelo dispositivo cliente, não pelo ponto de acesso. Pense nisto como o dispositivo a gritar para a sala: "Está aí alguém que eu conheça?" O ponto de acesso ouve e, se reconhecer o pedido, responde. Isto acontece centenas de vezes por dia, muitas vezes sem que o proprietário do dispositivo chegue a saber. E para os arquitetos de rede e operadores de locais públicos, esses probe requests são uma mina de ouro de dados operacionais - se souber como os capturar e interpretar corretamente. Mergulho técnico profundo. 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 fundamentais: o campo SSID, o elemento de taxas suportadas, o elemento de taxas suportadas alargadas e informações de capacidade, incluindo capacidades HT - de alto rendimento - e VHT para dispositivos 802.11ac. Existem dois tipos de probe requests. O primeiro é um probe request de difusão (broadcast), por vezes chamado de wildcard probe. Aqui o campo SSID está vazio - o dispositivo está essencialmente a pedir a qualquer ponto de acesso ao alcance que se identifique. O segundo é um probe request direcionado, 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 guardou na sua lista de redes preferidas. A resposta do ponto de acesso - a trama de probe response - reflete grande parte do conteúdo da trama beacon. Inclui o SSID, o BSSID, o intervalo de 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 a varredura ativa e a varredura passiva. A varredura ativa é o ciclo de pedido e resposta de sonda que acabo de descrever. A varredura passiva é diferente - o dispositivo simplesmente escuta as tramas de sinalização (beacon frames) que os pontos de acesso 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 espaço de elevada densidade - um estádio, um centro de conferências, uma grande superfície comercial - pode ter milhares de dispositivos a enviar simultaneamente pedidos de sonda através de múltiplos canais. Isto cria o que é conhecido como condições de tempestade de sondas. Cada pedido de sonda consome tempo de transmissão (airtime). Numa rede mal concebida, esta sobrecarga de tramas de gestão pode degradar visivelmente o débito (throughput) dos clientes ligados. É por isso que os pontos de acesso de classe empresarial implementam filtragem de pedidos de sonda 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 analítica. Historicamente, cada pedido de sonda continha o endereço MAC real de hardware do dispositivo - um identificador exclusivo de 48 bits gravado na placa de rede. Isto tornava a analítica baseada em sondas extremamente fiável. Podia monitorizar um dispositivo ao longo do seu espaço, medir o tempo de permanência, identificar visitantes recorrentes e criar mapas de calor de tráfego pedonal 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 pedidos de sonda. Em vez de transmitir 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 realizar sondas. No Android, a implementação varia consoante o fabricante. O impacto prático para os operadores de espaços é significativo. A analítica de tráfego pedonal baseada em sondas que dependia de endereços MAC persistentes é agora pouco fiável 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 sondas já não é viável. A solução - e é aqui que o WiFi de convidados autenticado se torna crítico - consiste em 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 início de sessão social, o utilizador captura uma identidade persistente e consentida que resiste à aleatorização de MAC. A plataforma de WiFi de convidados da Purple faz exatamente isto - associa a analítica à sessão autenticada, e não ao endereço de hardware, fornecendo-lhe dados precisos de tráfego pedonal em conformidade com o GDPR, independentemente do comportamento do MAC do dispositivo. Existe também uma dimensão de segurança nos pedidos de sonda (probe requests) que os analistas de segurança de rede precisam de compreender. Como os pedidos de sonda são tramas de gestão não encriptadas, estão visíveis para qualquer pessoa com uma ferramenta de captura de pacotes em modo de monitorização. Um pedido de sonda direcionado revela os SSIDs das redes a que um dispositivo se ligou anteriormente - o que é conhecido como a lista de redes preferidas, ou PNL. Esta é uma exposição real de privacidade. Um dispositivo que passe pelo seu espaço está a transmitir os nomes de todas as redes a que já se ligou. Esta é uma das razões pelas quais a randomização de MAC foi introduzida em primeiro lugar. Do ponto de vista da superfície de ataque, os pedidos de sonda permitem ataques do tipo "evil twin". Um atacante que capture um pedido de sonda direcionado para um SSID específico pode configurar um ponto de acesso malicioso com esse SSID e esperar que o dispositivo se ligue automaticamente. Os protocolos de open aprimorado e autenticação simultânea de iguais - SAE - do WPA3 mitigam significativamente este risco, mas apenas se a sua infraestrutura os suportar e aplicar. Recomendações de Implementação e Armadilhas a Evitar. Muito bem, passemos ao que realmente deve fazer com isto numa implementação real. Primeiro, se estiver a implementar ou a atualizar uma rede WiFi de convidados num espaço de alta densidade, a colocação dos seus pontos de acesso e o planeamento de canais devem ter em conta a sobrecarga dos pedidos de sonda. Utilize uma estratégia de largura de canal mínima - 20 MHz em 2.4 GHz - e implemente limites mínimos de RSSI para evitar que dispositivos distantes se associem. A maioria dos controladores empresariais permite definir a filtragem de respostas de sonda para que os APs apenas respondam a dispositivos acima de uma determinada intensidade de sinal. Isto reduz significativamente o ruído das tramas de gestão. Segundo, se estiver a analisar dados de tráfego pedonal ou tempo de permanência, aceite que os dados baseados apenas em sondas já não são suficientes. A sua estratégia de analítica precisa de ser construída em torno de sessões autenticadas. Isto significa que o seu Captive Portal ou fluxo de integração de utilizadores precisa de ser suficientemente fluido para que os visitantes se liguem realmente. Os dados da Purple mostram que os espaços com uma experiência de integração bem concebida - login social, recolha de e-mail ou um fluxo sem palavra-passe - registam taxas de ligação de 60 a 80 por cento dos dispositivos no espaço. Essa é a sua população para efeitos de analítica. Terceiro, para a conformidade com o GDPR no Reino Unido e na UE, a recolha de dados de pedidos de sonda - mesmo que anonimizados - requer uma avaliação cuidadosa da base jurídica. Se estiver a capturar e a armazenar tramas de sonda para efeitos de analítica, precisa de documentar a sua base de legítimo interesse e garantir a minimização dos dados. As diretrizes do ICO sobre rastreio 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 analítica baseado em sondas. Quarto, tenha atenção às tempestades de sondas (probe storms) em ambientes densos. Se estiver a registar uma degradação inexplicável do rendimento (throughput) num local com grande fluxo de pessoas, analise os registos dos seus AP e verifique as taxas de tráfego de gestão. Uma tempestade de sondas é frequentemente a culpada. A solução é uma combinação de filtragem de RSSI mínimo, limitação da taxa de resposta de sondas 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. Permita-me abordar algumas questões que surgem regularmente. Posso utilizar pedidos de sonda (probe requests) para contar o fluxo de pessoas sem um Captive Portal? Tecnicamente sim, mas após o iOS 14 a precisão é fraca. Verá contagens únicas inflacionadas e nenhum dado sobre visitantes recorrentes. Para tudo o que vá além de estimativas brutas de ordem de grandeza, precisa de sessões autenticadas. Os pedidos de sonda funcionam em redes WiFi 6E de 6 GHz? Sim, mas com diferenças. A banda de 6 GHz utiliza um mecanismo de deteção chamado FILS - Fast Initial Link Setup - e deteção fora de banda, o que altera a dinâmica das sondas. Se estiver a implementar WiFi 6E, consulte a documentação do seu fabricante sobre o comportamento de varrimento em 6 GHz. Qual é a diferença entre um pedido de sonda (probe request) e um pedido de associação? Um pedido de sonda ocorre antes da associação - o dispositivo está a detetar redes. Um pedido de associação surge após a autenticação, quando o dispositivo solicita formalmente a adesão a um SSID específico. São fases diferentes da máquina de estados de ligação 802.1X. A aleatorização de MAC é consistente uma vez estabelecida 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 a cada ligação. É por isso que a identidade baseada na sessão, e não na identidade baseada em MAC, é a arquitetura correta. Resumo e Próximos Passos. Para concluir: os pedidos de sonda são o pulsar da deteção de WiFi. Todos os dispositivos no seu espaço estão a gerá-los constantemente. Compreender a sua estrutura, as suas limitações e as suas implicações de segurança é fundamental para conceber implementações de WiFi de convidados fiáveis, compatíveis com análises e em conformidade. As principais conclusões são estas. Um: as análises baseadas em sondas sem autenticação não são fiáveis num mundo pós-aleatorização de MAC. Dois: o WiFi de convidados 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 tempestades de sondas é uma preocupação operacional real em locais de alta densidade e precisa de ser abordada na fase de design da infraestrutura. Quatro: os pedidos de sonda direcionados expõem a lista de redes preferenciais 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 o assunto, a documentação técnica da Purple abrange a forma como a nossa plataforma independente de hardware recolhe e processa dados de sondas juntamente com dados de sessões autenticadas para lhe fornecer análises precisas do local. Também pode explorar os nossos guias sobre orientação e trilateração por WiFi, que se baseiam diretamente nos fundamentos de pedidos de sonda que abordámos hoje. Obrigado por ouvir. Esta foi uma apresentação técnica da Purple.