¿Qué es un Probe Request? Cómo descubren redes los dispositivos

¿Qué es un Probe Request? Entendiendo cómo los dispositivos descubren redes. Una sesión informativa técnica de Purple. Introducción y contexto. Bienvenido a esta sesión informativa técnica de Purple. Le guiaré a través de uno de los mecanismos más fundamentales —y que más frecuentemente se malinterpreta— en el WiFi empresarial: el probe request. 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 de la GDPR. Así que entremos en materia. Cada vez que un dispositivo —un smartphone, una laptop, una tablet— 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 un frame de gestión, definido bajo la norma IEEE 802.11, y es transmitido por el dispositivo cliente, no por el punto de acceso. Piense en ello como si el dispositivo gritara en la habitación: "¿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 lo sepa. Y para los arquitectos de red y operadores de recintos, esos probe requests son una mina de oro de datos operativos, siempre y cuando sepa cómo capturarlos e interpretarlos correctamente. Inmersión técnica profunda. Profundicemos en la mecánica. Un probe request es un frame de gestión de Capa 2 transmitido en las bandas de radio de 2.4 GHz o 5 GHz. Bajo el estándar IEEE 802.11, se clasifica como un frame de gestión de subtipo 4. El frame 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 capacidad, incluyendo las capacidades HT —es decir, de alto rendimiento— 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 probe comodín. Aquí el campo SSID está vacío: el dispositivo está pidiendo esencialmente a cualquier punto de acceso dentro de su 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 busca 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 —el frame de probe response— refleja gran parte del contenido del frame de 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 construir su lista de redes disponibles incluso antes de que el usuario abra su configuración de 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, por lo general 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 una gran importancia operativa. En un recinto de alta densidad (un estadio, un centro de convenciones, una gran tienda minorista), puede haber miles de dispositivos enviando solicitudes de sondeo simultáneamente 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 administración puede degradar notablemente el rendimiento de los clientes conectados. Es por esto que los puntos de acceso de nivel empresarial implementan el filtrado de solicitudes de sondeo y la limitación de velocidad como estándar. Ahora hablemos de las direcciones MAC y por qué esto es sumamente importante para la analítica. Históricamente, cada solicitud de sondeo llevaba la dirección MAC de hardware real del dispositivo: un identificador único global de 48 bits grabado en la tarjeta de interfaz de red. Esto hacía que la analítica basada en sondeos fuera extremadamente confiable. Se podía rastrear un dispositivo en todo el recinto, medir el tiempo de permanencia, identificar 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 ahora generan 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 constante al conectarse a una red específica, pero una diferente al realizar 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 ahora no es confiable para dispositivos no conectados. Los conteos de dispositivos únicos se inflan. La identificación de visitantes recurrentes únicamente a partir de los datos de sondeo ya no es viable. La solución (y aquí es donde el WiFi para invitados autenticado se vuelve fundamental) es trasladar su 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 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, lo que le brinda datos de afluencia precisos y que cumplen con el 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. Debido a que las solicitudes de sondeo son tramas de administración no cifradas, son visibles para cualquiera que tenga una herramienta de captura de paquetes en modo monitor. Una solicitud de sondeo dirigida revela los SSIDs de las redes a las que un dispositivo se ha conectado previamente, lo que se conoce como la lista de redes preferidas o PNL. Esto representa una exposición real de la privacidad. Un dispositivo que camina por su establecimiento está transmitiendo los nombres de cada red a la 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 ataques de tipo "evil twin". Un atacante que capture una solicitud de sondeo dirigida para un SSID específico puede levantar un punto de acceso malicioso con ese SSID y esperar a que el dispositivo se conecte automáticamente. Los protocolos de WPA3 "enhanced open" y la autenticación simultánea de iguales (SAE) mitigan significativamente este riesgo, pero solo si su infraestructura los admite y los aplica. Recomendaciones de implementación y errores comunes. Bien, pasemos a lo que realmente se hace con esto en una implementación real. Primero, si está implementando o actualizando una red WiFi para invitados en un lugar 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 los dispositivos distantes se asocien. 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 cierta intensidad de señal. Esto reduce significativamente el ruido de las tramas de administración. Segundo, si está ejecutando análisis de afluencia o tiempo de permanencia, acepte que los datos basados únicamente en sondeos ya no son suficientes. Su estrategia de análisis debe basarse en sesiones autenticadas. Esto significa que su Captive Portal o flujo de incorporación debe ser lo suficientemente fluido como para que los visitantes realmente se conecten. Los datos de Purple muestran que los establecimientos con una experiencia de incorporación bien diseñada (inicio de sesión con redes sociales, captura de correo electrónico o un flujo sin contraseña) registran tasas de conexión del 60 al 80 por ciento de los dispositivos en el lugar. Esa es su población de análisis. Tercero, para el cumplimiento de GDPR en el Reino Unido y la UE, la recopilación de datos de solicitudes de sondeo, incluso de forma anonimizada, requiere una evaluación cuidadosa de la base legal. Si está capturando y almacenando 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 puede identificar a un individuo a partir de los datos, incluso de forma indirecta, se trata de datos personales. Trabaje con su DPO antes de implementar cualquier sistema de análisis basado en sondeos. Cuarto, ten cuidado con las tormentas de sondeo (probe storms) en entornos densos. Si observas una degradación inexplicable del rendimiento en un lugar con gran afluencia de personas, extrae los registros de tus AP y analiza las tasas de tramas de gestión. Una tormenta de sondeo suele ser la culpable. La solución es una combinación de filtrado de RSSI mínimo, limitación de la tasa de respuesta de sondeo y garantizar que tu banda de 5 GHz se anuncie correctamente para que los dispositivos compatibles la prefieran sobre la de 2.4 GHz. Preguntas y respuestas rápidas. Permíteme repasar algunas preguntas que surgen con regularidad. ¿Puedo usar solicitudes de sondeo (probe requests) para contar la afluencia de personas sin un Captive Portal? Técnicamente sí, pero después de iOS 14 la precisión es deficiente. Verás recuentos únicos inflados y no tendrás datos de visitantes recurrentes. Para cualquier estimación que vaya más allá de un orden de magnitud aproximado, necesitas sesiones autenticadas. ¿Funcionan las solicitudes de sondeo en redes WiFi 6E de 6 GHz? Sí, pero con diferencias. La banda de 6 GHz utiliza un mecanismo de descubrimiento llamado FILS (Fast Initial Link Setup) y descubrimiento fuera de banda, lo que cambia la dinámica de sondeo. Si estás implementando WiFi 6E, consulta la documentación de tu proveedor sobre el comportamiento de escaneo en 6 GHz. ¿Cuál es la diferencia entre una solicitud de sondeo (probe request) y una solicitud de asociación? Una solicitud de sondeo es previa a la asociación: el dispositivo está descubriendo redes. Una solicitud de asociación se realiza después de la autenticación, cuando el dispositivo solicita formalmente unirse a una red específica. Son etapas diferentes de la máquina de estados de conexión 802.11. ¿La aleatorización de MAC es consistente 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. Es por eso que la identidad basada en sesiones, y no la identidad basada en MAC, es la arquitectura correcta. Resumen y próximos pasos. Para concluir: las solicitudes de sondeo son el latido del descubrimiento de WiFi. Cada dispositivo en tu establecimiento las genera constantemente. Comprender su estructura, sus limitaciones y sus implicaciones de seguridad es fundamental para diseñar implementaciones de WiFi para invitados que sean confiables, con capacidad de análisis y que cumplan con las normativas. Los puntos clave son estos. Uno: los análisis basados en sondeos sin autenticación no son confiables en un mundo posterior a la aleatorización de MAC. Dos: el WiFi para invitados autenticado es tu capa de identidad; es lo que hace que tus análisis sean precisos y que tus datos cumplan con el GDPR. Tres: la gestión de tormentas de sondeo es una preocupación operativa real en lugares de alta densidad y debe abordarse en la etapa de diseño de la infraestructura. Cuatro: las solicitudes de sondeo dirigidas exponen la lista de redes preferidas de tu dispositivo, un riesgo de seguridad real que WPA3 y las prácticas de higiene de red pueden mitigar. Si deseas profundizar más, la documentación técnica de Purple cubre cómo nuestra plataforma agnóstica de hardware captura y procesa los datos de sondeo junto con los datos de sesiones autenticadas para brindarte análisis precisos del lugar. También puedes explorar nuestras guías sobre orientación (wayfinding) por WiFi y trilateración, que se basan directamente en los fundamentos de las solicitudes de sondeo que hemos cubierto hoy. Gracias por escuchar. Esta ha sido una sesión informativa técnica de Purple.