O que é um Probe Request? Entendendo como os dispositivos descobrem redes

O que é um Probe Request? Entendendo 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 frequentemente mais incompreendidos — no WiFi corporativo: o probe request. Se você é responsável por uma implantação de WiFi para visitantes, uma rede de varejo multilojas ou um programa de análise de presença em locais físicos, entender os probe requests não é opcional. É a base sobre a qual tudo o mais se apoia — desde análises de fluxo de visitantes e medição de tempo de permanência até os desafios de randomização de MAC e conformidade com a GDPR. Então, vamos direto ao assunto. Toda vez que um dispositivo — um smartphone, um laptop, um tablet — não está conectado a uma rede, ele está constantemente varrendo em busca de uma. Esse processo de varredura começa com um probe request. Trata-se de um frame de gerenciamento, definido sob a norma IEEE 802.11, e é transmitido pelo dispositivo cliente, não pelo ponto de acesso. Pense nisso como o dispositivo gritando na sala: "Tem alguém aqui que eu conheço?" O ponto de acesso escuta e, se reconhecer a solicitação, responde. Isso acontece centenas de vezes por dia, muitas vezes sem que o proprietário do dispositivo saiba. E para arquitetos de rede e operadores de locais físicos, esses probe requests são uma mina de ouro de dados operacionais — se você souber como capturá-los e interpretá-los corretamente. Aprofundamento Técnico. Vamos nos aprofundar na mecânica. Um probe request é um frame de gerenciamento de Camada 2 transmitido nas bandas de rádio de 2.4 GHz ou 5 GHz. Sob o padrão IEEE 802.11, ele é classificado como um frame de gerenciamento de subtipo 4. O frame contém vários elementos de informação importantes: o campo SSID, o elemento de taxas suportadas, o elemento de taxas suportadas estendidas e informações de capacidade, incluindo recursos HT — que é alta taxa de transferência — e VHT para dispositivos 802.11ac. Existem dois tipos de probe requests. O primeiro é um probe request de transmissão (broadcast), às vezes chamado de probe curinga. Aqui, o campo SSID fica vazio — o dispositivo está essencialmente pedindo a qualquer ponto de acesso ao alcance para se identificar. O segundo é um probe request direcionado, onde o campo SSID contém um nome de rede específico. Isso acontece quando o dispositivo está procurando ativamente por uma rede à qual já se conectou anteriormente e que armazenou em sua lista de redes preferenciais. A resposta do ponto de acesso — o frame de probe response — espelha grande parte do conteúdo do frame de beacon. Ele inclui o SSID, o BSSID, o intervalo de beacon, o carimbo de data/hora e o conjunto completo de recursos. Essa troca é o que permite que um dispositivo crie sua lista de redes disponíveis antes mesmo de o usuário abrir suas configurações de WiFi.Agora, há uma distinção importante entre a varredura ativa (active scanning) e a varredura passiva (passive scanning). A varredura ativa é o ciclo de solicitação e resposta de sonda (probe request/response) que acabei de descrever. A varredura passiva é diferente — o dispositivo simplesmente escuta os quadros de beacon (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 usa uma combinação de ambas, dependendo do seu estado de energia e do domínio regulatório em que estão operando. É aqui que a situação se torna operacionalmente significativa. Em um local de alta densidade — um estádio, um centro de convenções, uma grande loja de varejo — você pode ter milhares de dispositivos enviando simultaneamente solicitações de sonda em vários canais. Isso cria o que é conhecido como condições de tempestade de sondas (probe storm). Cada solicitação de sonda consome tempo de transmissão (airtime). Em uma rede mal projetada, essa sobrecarga de quadros de gerenciamento pode degradar significativamente a taxa de transferência (throughput) dos clientes conectados. É por isso que os pontos de acesso de nível empresarial implementam filtragem de solicitação de sonda e limitação de taxa como padrão. Agora vamos falar sobre endereços MAC e por que isso importa enormemente para a análise de dados (analytics). Historicamente, cada solicitação de sonda carregava o endereço MAC de hardware real do dispositivo — um identificador de 48 bits globalmente exclusivo gravado na placa de interface de rede. Isso tornava as análises baseadas em sondas extremamente confiáveis. Você podia rastrear um dispositivo pelo seu local, medir o tempo de permanência, identificar visitantes recorrentes e criar mapas de calor de fluxo de pessoas com alta confiança. Isso mudou significativamente com o iOS 14 em 2020 e o Android 10 antes dele. A Apple e o Google introduziram a randomização de endereços MAC para solicitações de sonda. Em vez de transmitir o MAC de hardware real, os dispositivos agora geram um endereço MAC randomizado para a varredura. No iOS, essa randomização é por SSID — o que significa que o dispositivo usa um MAC randomizado consistente ao se conectar a uma rede específica, mas um diferente ao realizar a varredura. No Android, a implementação varia de acordo com o fabricante. O impacto prático para os operadores de locais é significativo. As análises de fluxo de pessoas baseadas em sondas que dependiam de endereços MAC persistentes agora não são confiáveis para dispositivos não conectados. As contagens de dispositivos exclusivos são infladas. A identificação de visitantes recorrentes apenas a partir de dados de sonda não é mais viável. A solução — e é aqui que o WiFi de visitantes autenticado se torna crítico — é mover sua camada de identidade do endereço MAC para o usuário autenticado. Quando um visitante se conecta por meio de um Captive Portal ou de um login social, você captura uma identidade persistente e consentida que sobrevive à randomização de MAC. A plataforma de guest WiFi da Purple faz exatamente isso — ela vincula as análises à sessão autenticada, não ao endereço de hardware, fornecendo dados de fluxo de pessoas precisos e em conformidade com a GDPR, independentemente do comportamento do MAC do dispositivo. Há também uma dimensão de segurança nas probe requests que os analistas de segurança de rede precisam entender. Como as probe requests são frames de gerenciamento não criptografados, elas ficam visíveis para qualquer pessoa com uma ferramenta de captura de pacotes em modo monitor. Uma probe request direcionada revela os SSIDs das redes às quais um dispositivo se conectou anteriormente — o que é conhecido como lista de redes preferenciais, ou PNL. Isso representa uma exposição real de privacidade. Um dispositivo que transita pelo seu estabelecimento está transmitindo os nomes de todas as redes às quais já se conectou. Esse é um dos motivos pelos quais a randomização de MAC foi introduzida em primeiro lugar. Do ponto de vista da superfície de ataque, as probe requests possibilitam ataques do tipo evil twin. Um invasor que captura uma probe request direcionada para um SSID específico pode configurar um ponto de acesso invasor com esse SSID e esperar que o dispositivo se conecte automaticamente. Os protocolos de open aprimorado e autenticação simultânea de iguais — SAE — do WPA3 mitigam significativamente esse risco, mas apenas se a sua infraestrutura os suportar e aplicar. Recomendações de Implementação e Armadilhas. Certo, vamos passar para o que você realmente faz com isso em uma implantação real. Primeiro, se você estiver implantando ou atualizando uma rede WiFi de visitantes em um local de alta densidade, o posicionamento dos seus pontos de acesso e o planejamento de canais devem levar em conta a sobrecarga de probe requests. Use 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 corporativos permite configurar a filtragem de probe response para que os APs respondam apenas a dispositivos acima de uma determinada intensidade de sinal. Isso reduz significativamente o ruído dos frames de gerenciamento. Segundo, se você estiver executando análises de fluxo de pessoas ou tempo de permanência, aceite que os dados baseados apenas em probe não são mais suficientes. Sua estratégia de analytics precisa ser construída em torno de sessões autenticadas. Isso significa que o seu Captive Portal ou fluxo de integração precisa ser fluido o suficiente para que os visitantes realmente se conectem. Os dados da Purple mostram que locais com uma experiência de integração bem projetada — login social, captura de e-mail ou um fluxo sem senha — apresentam taxas de conexão de 60 a 80 por cento dos dispositivos no local. Essa é a sua população de analytics. Terceiro, para conformidade com a GDPR no Reino Unido e na UE, a coleta de dados de probe requests — mesmo anonimizada — exige uma avaliação cuidadosa da base legal. Se você estiver capturando e armazenando frames de probe para analytics, precisará documentar sua base de legítimo interesse e garantir a minimização de dados. As diretrizes do ICO sobre rastreamento de WiFi são claras: se você puder identificar um indivíduo a partir dos dados, mesmo que indiretamente, trata-se de dados pessoais. Trabalhe com o seu DPO antes de implantar qualquer sistema de analytics baseado em probe. Quarto, cuidado com as tempestades de sondagem (probe storms) em ambientes densos. Se você estiver observando uma degradação inexplicável do throughput em um local com alto fluxo de pessoas, puxe os logs do seu AP e analise as taxas de quadros de gerenciamento. Uma tempestade de sondagem costuma ser a culpada. A correção é uma combinação de filtragem de RSSI mínimo, limitação da taxa de resposta de sondagem e garantia de que sua banda de 5 GHz seja anunciada corretamente para que os dispositivos compatíveis a prefiram em relação à de 2.4 GHz. Perguntas e Respostas Rápidas. Deixe-me passar por algumas perguntas que surgem regularmente. Posso usar probe requests para contar o fluxo de pessoas sem um Captive Portal? Tecnicamente sim, mas após o iOS 14 a precisão é baixa. Você verá contagens exclusivas infladas e nenhum dado de visitantes recorrentes. Para qualquer coisa além de estimativas brutas de ordem de grandeza, você 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 usa um mecanismo de descoberta chamado FILS — Fast Initial Link Setup — e descoberta fora de banda, o que altera a dinâmica de sondagem. Se você estiver implantando WiFi 6E, verifique a documentação do seu fornecedor 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á descobrindo redes. Um association request ocorre após a autenticação, quando o dispositivo está solicitando formalmente para se conectar a um SSID específico. São etapas diferentes da máquina de estados de conexão 802.11. A randomização de MAC é consistente após a conexão? No iOS, sim — o dispositivo usa um MAC randomizado estável para um determinado SSID. No Android, isso varia. Algumas implementações re-randomizam a cada conexão. É por isso que a identidade baseada em sessão, e não a identidade baseada em MAC, é a arquitetura correta. Resumo e Próximos Passos. Para resumir: os probe requests são o batimento cardíaco da descoberta de WiFi. Cada dispositivo em seu estabelecimento os gera constantemente. Compreender sua estrutura, suas limitações e suas implicações de segurança é fundamental para projetar implantações de guest WiFi confiáveis, compatíveis com analytics e em conformidade com as normas. Os principais pontos a reter são estes. Um: analytics baseados em sondagem sem autenticação não são confiáveis em um mundo pós-randomização de MAC. Dois: o guest WiFi autenticado é a sua camada de identidade — é o que torna seus analytics precisos e seus dados em conformidade com a GDPR. Três: o gerenciamento de tempestades de sondagem é uma preocupação operacional real em locais de alta densidade e precisa ser abordado na fase de design da infraestrutura. Quatro: probe requests direcionados expõem a lista de redes preferenciais do seu dispositivo — um risco real de segurança que o WPA3 e as práticas de higiene de rede podem mitigar. Se você quiser se aprofundar, a documentação técnica da Purple aborda como nossa plataforma agnóstica de hardware captura e processa dados de sondagem juntamente com dados de sessão autenticada para fornecer analytics precisos do local. Você também pode explorar nossos guias sobre wayfinding por WiFi e trilateração, que se baseiam diretamente nos fundamentos de probe requests que cobrimos hoje. Obrigado por ouvir. Este foi um briefing técnico da Purple.