¿Qué es una Probe Request? Entendiendo cómo los dispositivos descubren redes

¿Qué es un probe request? Entendiendo cómo los dispositivos descubren redes. Un informe técnico de Purple. Introducción y contexto. Le damos la bienvenida a este informe técnico de Purple. Voy a guiarle a través de uno de los mecanismos más fundamentales (y que más frecuentemente se malinterpreta) en el sector de WiFi empresarial: el probe request o solicitud de sondeo. Si usted es responsable de un despliegue de WiFi para invitados, de una red de retail multisitio o de un programa de analítica de espacios, entender los probe requests no es opcional. Es la base sobre la que se asienta todo lo demás, desde la analítica de afluencia y la medición del tiempo de permanencia hasta los desafíos de la aleatorización de direcciones MAC y el cumplimiento del GDPR. Así que entremos en materia. Cada vez que un dispositivo (un smartphone, un portátil, una tableta) no está conectado a una red, está escaneando constantemente en busca de una. Ese proceso de escaneo comienza con un probe request. Se trata de una trama de gestión, definida bajo la norma IEEE 802.11, y es transmitida por el dispositivo cliente, no por el punto de acceso. Piense en ello como si el dispositivo gritara en la sala: "¿Hay alguien aquí a quien conozca?". El punto de acceso escucha y, si reconoce la solicitud, responde. Esto ocurre cientos de veces al día, a menudo sin que el propietario del dispositivo llegue a saberlo. Y para los arquitectos de red y operadores de recintos, esos probe requests son una mina de oro de datos operativos, siempre que sepa cómo capturarlos e interpretarlos correctamente. Inmersión técnica detallada. Profundicemos en la mecánica. Un probe request es una trama de gestión de Capa 2 transmitida en las bandas de radio de 2.4 GHz o 5 GHz. Bajo el estándar IEEE 802.11, se clasifica como una trama de gestión de subtipo 4. La trama contiene varios elementos de información clave: el campo SSID, el elemento de tasas soportadas, el elemento de tasas soportadas extendidas y la información de capacidades, incluidas las capacidades HT (alta velocidad de transferencia) y VHT para dispositivos 802.11ac. Existen dos tipos de probe requests. El primero es un probe request de difusión (broadcast), a veces llamado sondeo comodín (wildcard). Aquí el campo SSID está vacío: el dispositivo está pidiendo esencialmente a cualquier punto de acceso dentro del alcance que se identifique. El segundo es un probe request dirigido, donde el campo SSID contiene un nombre de red específico. Esto ocurre cuando el dispositivo está buscando activamente una red a la que se ha conectado previamente y que tiene guardada en su lista de redes preferidas. La respuesta del punto de acceso (la trama de probe response) refleja gran parte del contenido de la trama de balizamiento (beacon). Incluye el SSID, el BSSID, el intervalo de beacon, la marca de tiempo y el conjunto completo de capacidades. Este intercambio es lo que permite a un dispositivo crear su lista de redes disponibles incluso antes de que el usuario abra la configuración de su WiFi. Ahora bien, existe una distinción importante entre el escaneo activo y el pasivo. El escaneo activo es el ciclo de solicitud y respuesta de sondeo que acabo de describir. El escaneo pasivo es diferente: el dispositivo simplemente escucha las tramas de baliza (beacon frames) que los puntos de acceso transmiten periódicamente, normalmente cada 100 milisegundos. El escaneo pasivo es más lento pero consume menos energía. La mayoría de los dispositivos modernos utilizan una combinación de ambos, según su estado de energía y el dominio regulatorio en el que estén operando. Aquí es donde adquiere importancia desde el punto de vista operativo. En un recinto de alta densidad (un estadio, un centro de conferencias, una gran superficie comercial) puede haber miles de dispositivos enviando simultáneamente solicitudes de sondeo a través de múltiples canales. Esto crea lo que se conoce como condiciones de tormenta de sondeo (probe storm). Cada solicitud de sondeo consume tiempo de transmisión en el aire. En una red mal diseñada, esta sobrecarga de tramas de gestión puede degradar de forma medible el rendimiento de los clientes conectados. Es por ello que los puntos de acceso de calidad empresarial implementan el filtrado de solicitudes de sondeo y la limitación de velocidad como estándar. Hablemos ahora de las direcciones MAC y de por qué esto es enormemente importante para la analítica. Históricamente, cada solicitud de sondeo llevaba la dirección MAC de hardware real del dispositivo: un identificador de 48 bits único a nivel mundial grabado en la tarjeta de interfaz de red. Esto hacía que la analítica basada en sondeos fuera extremadamente fiable. Se podía rastrear un dispositivo por todo el recinto, medir el tiempo de permanencia, identificar a los visitantes recurrentes y crear mapas de calor de afluencia con un alto nivel de confianza. Eso cambió significativamente con iOS 14 en 2020 y Android 10 antes de este. Apple y Google introdujeron la aleatorización de direcciones MAC para las solicitudes de sondeo. En lugar de transmitir la MAC de hardware real, los dispositivos generan ahora una dirección MAC aleatoria para el escaneo. En iOS, esta aleatorización es por SSID, lo que significa que el dispositivo utiliza una MAC aleatoria coherente cuando se conecta a una red específica, pero una diferente cuando realiza el sondeo. En Android, la implementación varía según el fabricante. El impacto práctico para los operadores de recintos es significativo. La analítica de afluencia basada en sondeos que dependía de direcciones MAC persistentes ya no es fiable para los dispositivos no conectados. El recuento de dispositivos únicos se infla. La identificación de visitantes recurrentes a partir de los datos de sondeo por sí sola ya no es viable. La solución (y aquí es donde el WiFi de invitados autenticado pasa a ser fundamental) es trasladar la capa de identidad de la dirección MAC al usuario autenticado. Cuando un visitante se conecta a través de un Captive Portal o un inicio de sesión social, usted captura una identidad persistente y consentida que sobrevive a la aleatorización de la MAC. La plataforma de WiFi para invitados de Purple hace exactamente esto: vincula la analítica a la sesión autenticada, no a la dirección de hardware, proporcionándole datos de afluencia precisos y que cumplen con la GDPR, independientemente del comportamiento de la MAC del dispositivo. También existe una dimensión de seguridad en las solicitudes de sondeo (probe requests) que los analistas de seguridad de red deben comprender. Dado que las solicitudes de sondeo son tramas de gestión no cifradas, son visibles para cualquiera que disponga de una herramienta de captura de paquetes en modo monitor. Una solicitud de sondeo dirigida revela los SSIDs de las redes a las que se ha conectado previamente un dispositivo - lo que se conoce como la lista de redes preferidas o PNL. Esto representa una exposición real de la privacidad. Un dispositivo que se desplaza por su recinto está transmitiendo los nombres de todas las redes a las que se ha unido. Esta es una de las razones por las que se introdujo la aleatorización de direcciones MAC en primer lugar. Desde la perspectiva de la superficie de ataque, las solicitudes de sondeo permiten los ataques de tipo "evil twin". Un atacante que capture una solicitud de sondeo dirigida a un SSID específico puede levantar un punto de acceso no autorizado con ese SSID y esperar a que el dispositivo se conecte automáticamente. Los protocolos de apertura mejorada y autenticación simultánea de iguales - SAE - de WPA3 mitigan significativamente este riesgo, pero solo si su infraestructura los soporta y los impone. Recomendaciones de implementación y errores comunes. Bien, pasemos a lo que realmente se hace con esto en un despliegue real. En primer lugar, si está desplegando o renovando una red WiFi de invitados en un recinto de alta densidad, la ubicación de sus puntos de acceso y la planificación de canales deben tener en cuenta la sobrecarga de las solicitudes de sondeo. Utilice una estrategia de ancho de canal mínimo - 20 MHz en 2.4 GHz - e implemente umbrales mínimos de RSSI para evitar que se asocien dispositivos lejanos. La mayoría de los controladores empresariales le permiten configurar el filtrado de respuestas de sondeo para que los AP solo respondan a dispositivos que superen una determinada intensidad de señal. Esto reduce significativamente el ruido de las tramas de gestión. En segundo lugar, si está analizando métricas de afluencia o tiempo de permanencia, acepte que los datos basados únicamente en sondeos ya no son suficientes. Su estrategia analítica debe estructurarse en torno a sesiones autenticadas. Esto significa que su Captive Portal o flujo de incorporación debe ser lo suficientemente fluido como para que los visitantes se conecten de verdad. Los datos de Purple demuestran que los recintos con una experiencia de incorporación bien diseñada - inicio de sesión social, captura de correo electrónico o un flujo sin contraseña - registran tasas de conexión de entre el 60 y el 80 por ciento de los dispositivos del recinto. Ese es su universo de análisis. En tercer lugar, para cumplir con el GDPR en el Reino Unido y la UE, la recopilación de datos de solicitudes de sondeo - incluso anonimizados - requiere una evaluación cuidadosa de la base legal. Si captura y almacena tramas de sondeo para análisis, debe documentar su base de interés legítimo y garantizar la minimización de datos. La guía de la ICO sobre el seguimiento de WiFi es clara: si se puede identificar a una persona a partir de los datos, incluso de forma indirecta, se trata de datos personales. Trabaje con su DPO antes de desplegar cualquier sistema analítico basado en sondeos. En cuarto lugar, cuidado con las tormentas de sondas (probe storms) en entornos densos. Si observa una degradación inexplicable del rendimiento en un recinto con mucha afluencia de público, extraiga los registros de sus AP y analice las tasas de tramas de gestión. Una tormenta de sondas suele ser la culpable. La solución es una combinación de filtrado RSSI mínimo, limitación de la tasa de respuesta de sondas y asegurarse de que su banda de 5 GHz esté correctamente anunciada para que los dispositivos compatibles la prefieran antes que la de 2.4 GHz. Preguntas y respuestas rápidas. Permítame repasar algunas preguntas que surgen con regularidad. ¿Puedo utilizar las solicitudes de sonda para contar la afluencia sin un Captive Portal? Técnicamente sí, pero después de iOS 14 la precisión es deficiente. Verá recuentos únicos inflados y no tendrá datos de visitantes recurrentes. Para cualquier cosa que vaya más allá de estimaciones aproximadas de orden de magnitud, necesita sesiones autenticadas. ¿Funcionan las solicitudes de sonda en redes de 6 GHz con WiFi 6E? Sí, pero con diferencias. La banda de 6 GHz utiliza un mecanismo de detección llamado FILS - Fast Initial Link Setup - y detección fuera de banda, lo que cambia la dinámica de las sondas. Si va a implantar WiFi 6E, consulte la documentación del fabricante sobre el comportamiento de escaneo en 6 GHz. ¿Cuál es la diferencia entre una solicitud de sonda (probe request) y una solicitud de asociación (association request)? Una solicitud de sonda es previa a la asociación: el dispositivo está descubriendo redes. Una solicitud de asociación se produce después de la autenticación, cuando el dispositivo solicita formalmente unirse a una red específica. Son fases diferentes de la máquina de estados de conexión de 802.1X. ¿Es coherente la aleatorización de direcciones MAC una vez conectado? En iOS, sí: el dispositivo utiliza una MAC aleatoria estable para un SSID determinado. En Android, varía. Algunas implementaciones vuelven a aleatorizar en cada conexión. Por eso, la identidad basada en sesiones, y no la basada en MAC, es la arquitectura adecuada. Resumen y próximos pasos. Para terminar: las solicitudes de sonda son el latido del descubrimiento de WiFi. Todos los dispositivos de su establecimiento las generan constantemente. Comprender su estructura, sus limitaciones y sus implicaciones de seguridad es fundamental para diseñar despliegues de WiFi de invitados que sean fiables, aptos para análisis y conformes con la normativa. Los puntos clave son estos. Uno: los análisis basados en sondas sin autenticación no son fiables en un mundo posterior a la aleatorización de direcciones MAC. Dos: el WiFi de invitados autenticado es su capa de identidad, lo que hace que sus análisis sean precisos y que sus datos cumplan con el GDPR. Tres: la gestión de las tormentas de sondas es una preocupación operativa real en espacios de alta densidad y debe abordarse en la fase de diseño de la infraestructura. Cuatro: las solicitudes de sonda dirigidas exponen la lista de redes preferidas de su dispositivo, un riesgo real de seguridad que WPA3 y las prácticas de higiene de red pueden mitigar. Si desea profundizar más, la documentación técnica de Purple explica cómo nuestra plataforma agnóstica de hardware captura y procesa los datos de las sondas junto con los datos de las sesiones autenticadas para ofrecerle análisis precisos del recinto. También puede explorar nuestras guías sobre orientación en interiores por WiFi y trilateración, que se basan directamente en los principios fundamentales de las solicitudes de sonda que hemos tratado hoy. Gracias por su atención. Esta ha sido una sesión técnica informativa de Purple.