Captive Portal Architecture: Security, Redirection, and Best Practices

Hable en inglés británico con un tono seguro, con autoridad y conversacional, como un consultor de redes senior que explica un tema a un cliente mientras toman un café. Con un ritmo pausado, una dicción clara y sin prisas. Pausas naturales ocasionales para dar énfasis. Profesional pero no rígido: Bienvenido al Technical Briefing de Purple. Soy su anfitrión, y hoy profundizaremos en la arquitectura de Captive Portal; específicamente, en el modelo de seguridad, las mecánicas de redirección y las decisiones de diseño que diferencian una implementación que cumple con las normativas y está bien diseñada de una que le causará problemas a las tres de la mañana. [medium pause] Pongámonos en situación. Supongamos que opera una red WiFi para invitados en una cadena de hoteles, un complejo comercial o un estadio. Miles de dispositivos se conectan todos los días. Algunos de esos dispositivos contienen malware. Algunos de esos usuarios intentarán acceder a contenido que no deberían. Y su equipo legal quiere saber, por escrito, que ha obtenido un consentimiento válido antes de almacenar un solo byte de datos personales. [medium pause] Ese es el problema que la arquitectura de Captive Portal está diseñada para resolver. Analicemos cómo funciona realmente. [medium pause] Sección uno. La cadena de redirección. Cuando un dispositivo de invitado se conecta a su SSID de WiFi, obtiene una dirección IP de un pool de DHCP en una VLAN dedicada para invitados; llamémosla VLAN 20. Sus dispositivos corporativos están en la VLAN 10. Estas dos VLAN nunca deben enrutarse entre sí. Eso no es negociable desde el punto de vista de PCI DSS y, francamente, tampoco desde una perspectiva de seguridad básica. Ahora bien, el dispositivo está conectado, pero aún no se ha autenticado. El controlador lo coloca en lo que llamamos un estado de preautenticación. El dispositivo solo puede acceder a una pequeña lista de dominios permitidos: el walled garden. Todo lo demás se intercepta. Aquí está la parte ingeniosa. Cuando el dispositivo intenta cargar una página web, o cuando el sistema operativo realiza su comprobación de detección de Captive Portal (lo cual iOS hace de forma automática al consultar captive.apple.com), el resolutor de DNS en la puerta de enlace devuelve la dirección IP del servidor de Captive Portal en lugar del destino real. El navegador sigue esa redirección y llega a su splash page. [medium pause] Esto es la Capa 3 y la Capa 7 trabajando en conjunto. La VLAN se encarga del aislamiento de la red. La intercepción de DNS maneja la redirección. Y el Captive Portal gestiona la capa de identidad y consentimiento. Tres mecanismos distintos que funcionan de forma secuencial. [medium pause] Sección dos. Autenticación y RADIUS. Una vez que el invitado interactúa con la splash page (ya sea aceptando los términos y condiciones, ingresando una dirección de correo electrónico, autenticándose mediante inicio de sesión social o verificando un código SMS), la plataforma debe indicarle al controlador de red que abra el firewall para ese dispositivo específico. Aquí es donde entra en juego RADIUS. RADIUS significa Remote Authentication Dial-In User Service. Es un protocolo definido en RFC 2865 y es el estándar de la industria para comunicar decisiones de autenticación entre un servidor de políticas y un dispositivo de acceso a la red. Purple funciona como un servidor RADIUS alojado en la nube. Cuando un invitado completa el flujo del Captive Portal, Purple envía un mensaje RADIUS Access-Accept al controlador WiFi local, ya sea un Cisco Meraki, un controlador HPE Aruba, un Ruckus SmartZone o un punto de acceso Juniper Mist. El controlador recibe ese mensaje y cambia el dispositivo del invitado del estado de preautenticación al estado autorizado, abriendo las reglas del firewall y otorgando acceso a internet. [medium pause] Hay una extensión importante de RADIUS que debe conocer: Cambio de Autorización o CoA (Change of Authorisation). CoA permite que el servidor RADIUS envíe un mensaje a mitad de sesión al controlador para revocar o modificar una sesión que ya está activa. Purple utiliza CoA para hacer cumplir los tiempos de espera de la sesión, desconectar dispositivos que hayan sido marcados por violaciones de políticas y admitir flujos de trabajo de derecho al olvido según el GDPR, donde un usuario solicita la eliminación de sus datos y Purple puede revocar inmediatamente su sesión activa. [medium pause] Sección tres. El walled garden. El walled garden es una lista de permitidos (whitelist) de direcciones IP y nombres de dominio a los que los dispositivos no autenticados pueden acceder antes de completar el flujo del Captive Portal. Si hace esto mal, su página de bienvenida no se cargará. Si lo hace muy mal, habrá creado una brecha de seguridad. Como mínimo, su walled garden debe incluir la URL del Captive Portal, cualquier endpoint de CDN que sirva los recursos del portal y los endpoints de autenticación de cualquier proveedor de inicio de sesión social que utilice: Google, Facebook, Microsoft. Si utiliza la verificación por SMS, deberá incluir en la lista de permitidos el endpoint de la API de la pasarela de SMS. La trampa que afecta a la mayoría de las implementaciones son las direcciones IP dinámicas. Los servicios en la nube no siempre tienen IP estáticas. Si incluye una IP en la lista de permitidos en lugar de un dominio, y esa IP cambia, su portal dejará de funcionar. Utilice la lista de permitidos basada en dominios si su controlador lo admite, y realice pruebas después de cada cambio. [medium pause] Sección cuatro. Diseño de seguridad. Hablemos de la arquitectura de seguridad con más detalle, porque aquí es donde la mayoría de las implementaciones tienen brechas. Primero: aislamiento de clientes (client isolation). Actívelo. Esta es una configuración en el punto de acceso que evita que los dispositivos de los invitados se comuniquen directamente entre sí a través del medio inalámbrico. Sin esto, un dispositivo comprometido en su red de invitados puede sondear y atacar a otros dispositivos de invitados. Es una solución de una sola casilla que elimina toda una clase de ataques de igual a igual (peer-to-peer). Segundo: tiempos de concesión de DHCP (DHCP lease times). En un lugar de alta rotación (un centro de transporte, un estadio, una tienda minorista concurrida), necesita tiempos de concesión cortos. De treinta a sesenta minutos. Si deja el valor predeterminado en veinticuatro horas y tiene diez mil dispositivos conectándose en el día del partido, agotará su grupo de direcciones IP antes del medio tiempo. Los nuevos dispositivos no se conectarán. Su equipo de operaciones recibirá quejas. Mantenga las concesiones cortas. Tercero: el cifrado. Tu Captive Portal debe servirse a través de HTTPS con un certificado TLS válido. Si se sirve a través de HTTP, los navegadores modernos lo marcarán como no seguro, los usuarios desconfiarán de él y estarás transmitiendo credenciales en texto plano. Utiliza TLS 1.2 como mínimo; se prefiere TLS 1.3. La capa de transporte de WiFi debe utilizar WPA2-AES o WPA3; nunca WEP, nunca TKIP. Cuarto: la segmentación de VLAN. Tu VLAN de invitados debe estar completamente aislada de cualquier segmento de red que toque datos de tarjetas de pago. La versión 4.0 de PCI DSS es explícita al respecto. Si tu red de invitados puede enrutarse a una subred que contenga un sistema de punto de venta, toda tu red de POS entrará en el alcance de una auditoría de PCI. Esa es una carga de cumplimiento reglamentario significativa. Segmenta correctamente desde el primer día. [medium pause] Sección cinco. GDPR y cumplimiento de datos. Cada Captive Portal que recopila datos personales (y la dirección de correo electrónico, el número de teléfono y el inicio de sesión social cuentan como datos personales según el GDPR) debe cumplir con requisitos específicos. Necesitas una base legal para el procesamiento. Para el WiFi de invitados, eso suele ser el consentimiento. El consentimiento debe ser libre, específico, informado e inequívoco. Las casillas previamente marcadas no cuentan. Vincular el consentimiento de WiFi con el consentimiento de marketing no cuenta. El modelo de aceptación de elección consciente de Purple separa el consentimiento de acceso a la red del consentimiento de marketing, de modo que los invitados pueden conectarse sin verse obligados a aceptar correos electrónicos de marketing. Necesitas documentar qué datos recopilas, por qué los recopilas, dónde se almacenan y cuánto tiempo los conservas. Purple cuenta con la certificación ISO 27001, cumple con GDPR, cumple con CCPA y cuenta con la certificación Cyber Essentials. La plataforma almacena datos en centros de datos que cumplen con las normas y con políticas de retención documentadas. Y necesitas un flujo de trabajo de derecho al borrado. Si un invitado solicita la eliminación de sus datos, debes poder procesar eso en un plazo de treinta días. La plataforma de Purple admite esto de forma nativa, y el mecanismo RADIUS CoA que mencioné anteriormente significa que puedes revocar sesiones activas al mismo tiempo. [medium pause] Ahora pasemos a las recomendaciones de implementación y a los errores que vemos con más frecuencia. [medium pause] Error uno: Walled Gardens mal configurados. La página de bienvenida se carga, pero el botón de inicio de sesión social no funciona. O la página se carga pero el logotipo no aparece porque el dominio de la CDN no está en la lista blanca. Prueba tu Walled Garden en un dispositivo nuevo sin DNS en caché antes de ponerlo en marcha. Error dos: PSK compartidas. Algunos establecimientos todavía utilizan una sola contraseña de WiFi escrita en un pizarrón. Eso no es un Captive Portal; es un secreto compartido que cualquiera puede fotografiar y compartir. No te brinda datos de identidad, ni registro de consentimiento, ni la capacidad de revocar el acceso individual. Reemplázalo con un Captive Portal gestionado. Error tres: tamaño insuficiente del pool de DHCP. Ya he hablado de esto, pero vale la pena repetirlo. Diseña el tamaño de tu pool de DHCP para conexiones concurrentes pico, no para conexiones promedio. En un estadio con cuarenta mil aficionados, es posible que tengas veinte mil dispositivos intentando conectarse simultáneamente. Planifica en consecuencia. Cuarto error: sin tiempo de espera de sesión. Sin un tiempo de espera de sesión, un dispositivo que se conectó hace seis meses y nunca regresó aún mantiene un estado de sesión autorizado en su controlador. Ese es un registro obsoleto que desperdicia recursos y genera ruido de auditoría. Establezca tiempos de espera de sesión. Treinta minutos de inactividad es un valor predeterminado razonable. [pausa media] Preguntas y respuestas rápidas. Pregunta: ¿Funciona el Captive Portal en todos los dispositivos? Respuesta: Los sistemas operativos modernos (iOS, Android, Windows, macOS) tienen detección de Captive Portal integrada. Detectan el redireccionamiento y muestran el portal automáticamente. Los dispositivos más antiguos pueden requerir que el usuario abra un navegador manualmente. La plataforma de Purple gestiona ambos flujos. Pregunta: ¿Podemos usar Captive Portal junto con 802.1X? Respuesta: Sí. Muchas implementaciones empresariales utilizan 802.1X para los dispositivos del personal, donde los certificados o credenciales se autentican automáticamente, y un Captive Portal para los dispositivos de invitados en un SSID independiente. Purple se integra con la infraestructura RADIUS que admite ambos flujos simultáneamente. Pregunta: ¿Qué pasa con OpenRoaming? Respuesta: OpenRoaming es un estándar que permite a los dispositivos conectarse a WiFi automáticamente mediante autenticación basada en certificados, omitiendo por completo el Captive Portal. Purple actúa como un proveedor de identidad gratuito para OpenRoaming bajo la licencia Connect. Es la dirección futura para una conectividad de invitados fluida, pero los Captive Portals siguen siendo el estándar para la captura de datos y la gestión del consentimiento hoy en día. [pausa media] Para resumir. Una implementación de Captive Portal bien diseñada se basa en cinco pilares. Aislamiento de VLAN para proteger su red corporativa. Intercepción de DNS y redirección HTTPS para mostrar la página de inicio. Autenticación RADIUS para abrir el firewall después del consentimiento. Un walled garden configurado correctamente para garantizar que el portal se cargue de manera confiable. Y un manejo de datos que cumpla con el GDPR para proteger tanto a sus invitados como a su organización. La plataforma de Purple gestiona las cinco capas en 80,000 establecimientos activos, con 440 millones de inicios de sesión procesados en 2024 y un tiempo de actividad del 99.999%. Se integra de forma nativa con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, por lo que, sin importar el hardware que utilice, puede implementarlo sin tener que reemplazar su infraestructura actual. Si desea profundizar en cualquiera de estos temas (diseño de SSID, configuración de RADIUS o flujos de trabajo de cumplimiento de GDPR), visite purple.ai para acceder a la biblioteca completa de guías técnicas. Gracias por escuchar.