RadSec: Cómo RADIUS sobre TLS mejora la seguridad de la autenticación WiFi

RadSec: Cómo RADIUS sobre TLS mejora la seguridad de la autenticación WiFi Un informe de inteligencia de Purple Enterprise WiFi Tiempo de ejecución aproximado: 10 minutos --- [INTRODUCCIÓN Y CONTEXTO - aprox. 1 minuto] Bienvenido a la serie de inteligencia de Purple Enterprise WiFi. Soy su anfitrión, y hoy abordaremos un tema que se encuentra justo en la intersección de la seguridad de la red y el riesgo operativo: RadSec - formalmente definido en la norma RFC 6614 - y por qué debería estar en su hoja de ruta de infraestructura si aún no lo está. Si usted es un gerente de TI, arquitecto de redes o CTO responsable de la red WiFi empresarial en un grupo hotelero, un complejo comercial, un estadio o un campus del sector público, este informe es para usted. Vamos a cubrir qué es realmente RadSec, por qué el protocolo RADIUS tradicional lo deja expuesto, cómo implementar RadSec en un entorno del mundo real y los errores comunes que atrapan a los equipos. Nada de teoría por el simple hecho de teorizar - solo la información que necesita para tomar una decisión este trimestre. Comencemos. --- [INMERSIÓN TÉCNICA PROFUNDA - aprox. 5 minutos] Empecemos con el problema. RADIUS - Remote Authentication Dial-In User Service - ha sido el pilar de la autenticación WiFi empresarial desde la década de 1990. Cuando un usuario o dispositivo se conecta a su red WiFi corporativa o de invitados, el punto de acceso actúa como un cliente RADIUS, reenviando las solicitudes de autenticación a un servidor RADIUS, el cual valida las credenciales contra su directorio - Active Directory, LDAP o un proveedor de identidad en la nube - y concede o deniega el acceso. Este es el modelo de autenticación 802.1X que sustenta las redes WPA2 y WPA3. El problema es que el sistema RADIUS tradicional fue diseñado para una época diferente. Funciona sobre UDP - User Datagram Protocol - en los puertos 1812 y 1813. UDP no tiene conexión, lo que significa que no hay un saludo de tres vías (handshake), no hay estado de sesión y, fundamentalmente, no hay cifrado nativo. La única protección entre su punto de acceso y su servidor RADIUS es un secreto compartido - esencialmente una contraseña - que se utiliza para ofuscar la contraseña del usuario en tránsito mediante el hashing MD5. MD5, como la mayoría de ustedes sabrá, está criptográficamente roto. Ha estado roto durante años. ¿Qué significa eso en la práctica? Significa que en cualquier segmento de red donde un atacante pueda interceptar el tráfico RADIUS - lo que incluye switches comprometidos, dispositivos no autorizados en su VLAN de gestión, o cualquier punto entre un punto de acceso remoto y un servidor RADIUS alojado en la nube - existe el potencial de que capturen los intercambios de autenticación, intenten ataques de diccionario sin conexión contra el secreto compartido y, en algunas configuraciones, expongan por completo las credenciales de los usuarios. Para un grupo hotelero que ofrece WiFi para invitados en 200 propiedades, o una cadena de tiendas minoristas con puntos de acceso en cada sucursal que transmiten datos a un servidor RADIUS central a través de la internet pública, este no es un riesgo teórico. Es una superficie de ataque activa. Esto es exactamente lo que RadSec resuelve. RadSec - definido en RFC 6614 y actualizado por RFC 7360 - envuelve el tráfico RADIUS dentro de un túnel TLS. En lugar de UDP, utiliza TCP en el puerto 2083. En lugar de un secreto compartido y MD5, utiliza autenticación TLS mutua con certificados X.509. Tanto el cliente RADIUS como el servidor RADIUS presentan certificados, verifican la identidad del otro y establecen una sesión cifrada antes de que se intercambie cualquier dato de autenticación. TLS 1.3 es la versión recomendada actualmente, la cual proporciona secreto perfecto hacia adelante y elimina una serie de vulnerabilidades de cifrado heredadas. El efecto práctico es significativo. Los datos de credenciales, los atributos de usuario y los tokens de sesión se cifran de extremo a extremo entre el punto de acceso - o un proxy RadSec - y el servidor RADIUS. Un atacante que intercepte el tráfico en el cable solo verá registros TLS cifrados. El secreto compartido sigue estando presente para compatibilidad con versiones anteriores, pero ya no realiza ningún trabajo de seguridad significativo - TLS se encarga de la carga. Hay otra dimensión aquí que es cada vez más relevante: el roaming. La federación Eduroam, utilizada por universidades e instituciones de investigación en toda Europa y más allá, ha estado operando RadSec durante años como parte de su infraestructura de roaming interinstitucional. Más recientemente, el estándar OpenRoaming de la Wi-Fi Alliance - que permite un roaming de WiFi sin fricciones a través de las sedes participantes - exige RadSec para todo el tráfico de la federación. Si está implementando una infraestructura compatible con OpenRoaming, RadSec no es opcional; es un prerrequisito. Purple admite OpenRoaming bajo su licencia Connect, actuando como un proveedor de identidad dentro de la federación, y RadSec es fundamental para el funcionamiento de esa red de roaming segura. Desde el punto de vista del cumplimiento, RadSec es cada vez más relevante para PCI DSS 4.0, que endurece los requisitos en torno a la protección de los datos de autenticación en tránsito. Si su infraestructura de WiFi entra en contacto con entornos de tarjetas de pago - y en el sector minorista y de hospitalidad, esto ocurre con frecuencia - la brecha de cifrado en el RADIUS tradicional es un hallazgo que tarde o temprano se detectará en una auditoría. El GDPR exige de manera similar medidas técnicas adecuadas para proteger los datos personales; las credenciales de usuario y los metadatos de sesión que fluyen sin cifrar a través de su red son difíciles de defender en una auditoría de protección de datos. Ahora hablemos de arquitectura. Existen dos patrones de implementación principales para RadSec. El primero es el soporte nativo de RadSec en su servidor RADIUS y puntos de acceso. FreeRADIUS 3.0 y superior admite RadSec de forma nativa. Microsoft NPS no admite RadSec de forma nativa en sus versiones actuales, lo que representa una limitación significativa para las organizaciones que ejecutan una infraestructura centrada en Windows. Cisco ISE admite RadSec. Aruba ClearPass admite RadSec. Si tanto su servidor RADIUS como el fabricante de sus puntos de acceso admiten RadSec de forma nativa, este es el camino más limpio - configure los certificados TLS en ambos extremos, abra el puerto TCP 2083 en su firewall y estará cifrando el tráfico RADIUS de extremo a extremo. El segundo patrón es un proxy RadSec. Esta es la implementación más común en la práctica, particularmente para organizaciones con infraestructura RADIUS heredada o entornos de múltiples proveedores. Un proxy RadSec - radsecproxy es la implementación de código abierto más utilizada - se ubica entre sus puntos de acceso y su servidor RADIUS. Los puntos de acceso envían RADIUS estándar sobre UDP al proxy en la red local. El proxy finaliza esa conexión, vuelve a encapsular el tráfico RADIUS dentro de un túnel TLS y lo reenvía al servidor RADIUS ascendente sobre TCP 2083. Este enfoque le permite agregar RadSec a una infraestructura existente sin reemplazar su servidor RADIUS, y es de gran utilidad cuando su servidor RADIUS está alojado en la nube o se accede a él a través de la internet pública. La gestión de certificados es la complejidad operativa que debe planificar. Necesitará una PKI - Infraestructura de Clave Pública - para emitir y gestionar los certificados X.509 utilizados para TLS mutuo. Eso significa una Autoridad de Certificación, emisión de certificados para cada cliente y servidor RADIUS, y un proceso para la rotación de certificados antes de su vencimiento. Los certificados que vencen sin que nadie se dé cuenta interrumpirán la autenticación de todos los usuarios de su red de forma simultánea - y ese es un escenario que querrá evitar. Automatice la renovación de certificados utilizando ACME o la API de su CA, y configure alertas de monitoreo con suficiente anticipación a las fechas de vencimiento. --- [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aprox. 2 minutos] Permítame darle algunas recomendaciones prácticas. Primero: realice una auditoría antes de implementar. Mapee cada cliente RADIUS - puntos de acceso, concentradores VPN, switches que realizan 802.1X - y cada servidor RADIUS en su entorno. Identifique cuáles de ellos son compatibles con RadSec de forma nativa y cuáles necesitarán un proxy. Esta auditoría generalmente revela dispositivos heredados que no admiten TLS en absoluto, los cuales deben incluirse en su plan de reemplazo. Segundo: comience con el tráfico de mayor riesgo. Si tiene tráfico RADIUS que atraviesa la internet pública - sitios remotos, RADIUS alojado en la nube, grupos de hoteles con múltiples propiedades - esa es su primera prioridad. El tráfico RADIUS local en una VLAN de administración bien segmentada es de menor riesgo, pero aun así debería estar en el plan de trabajo. Tercero: pruebe el TLS mutuo minuciosamente antes del lanzamiento. El modo de falla más común en las implementaciones de RadSec son los errores de validación de certificados - nombres comunes que no coinciden, certificados intermedios vencidos o clientes que no confían en la CA que firmó el certificado del servidor. Utilice openssl s_client para probar los saludos de conexión TLS antes de cambiar el tráfico de producción. Cuarto: no descuide el monitoreo. RadSec agrega una capa de conexión TCP que el RADIUS tradicional no tiene. Las fallas de conexión TCP, los tiempos de espera del saludo de conexión TLS y los errores de certificado se manifestarán como fallas de autenticación para sus usuarios. Asegúrese de que los registros de su servidor RADIUS y los registros de su proxy se estén enviando a su SIEM o plataforma de monitoreo para que pueda distinguir un problema de conectividad RadSec de un problema de política de autenticación. El error que veo con más frecuencia es que las organizaciones implementan RadSec en el lado del servidor pero olvidan actualizar sus reglas de firewall. El puerto TCP 2083 debe estar abierto entre cada cliente RADIUS y el servidor o proxy RADIUS. Si estás acostumbrado a administrar reglas UDP 1812, el puerto TCP 2083 puede pasarse por alto en el proceso de cambio de firewall. - [Preguntas y respuestas rápidas - aprox. 1 minuto] Permíteme repasar rápidamente algunas preguntas que escucho con regularidad. "¿RadSec reemplaza a 802.1X?" No. RadSec asegura la capa de transporte entre el punto de acceso y el servidor RADIUS. 802.1X es el marco de autenticación entre el dispositivo cliente y el punto de acceso. Funcionan en capas diferentes y son complementarios. "¿Es compatible RadSec con todos los proveedores de puntos de acceso?" No de forma universal. Cisco, Aruba, Ruckus y Meraki tienen distintos niveles de soporte para RadSec - consulta tu versión específica de firmware. Cuando no hay soporte nativo, un proxy RadSec es tu solución. "¿Qué pasa con DTLS - RADIUS sobre DTLS?" El RFC 7360 define RADIUS sobre DTLS, que utiliza UDP en lugar de TCP, conservando algunas de las características sin conexión del RADIUS tradicional al tiempo que añade cifrado. Se implementa menos que RadSec sobre TLS, pero vale la pena evaluarlo si la latencia es una preocupación en entornos de alto rendimiento. "¿Cómo afecta esto al rendimiento del roaming?" La conexión TCP de RadSec es persistente, lo que de hecho puede mejorar el rendimiento del roaming en entornos federados al reducir la sobrecarga de configuración de la conexión para las solicitudes de autenticación posteriores. - [RESUMEN Y PRÓXIMOS PASOS - aprox. 1 minuto] Para resumir: RadSec es la respuesta madura y basada en estándares a una brecha de seguridad real en el RADIUS tradicional. Si gestionas WiFi empresarial a gran escala - a través de múltiples sitios, a través de internet o en entornos sujetos a PCI-DSS o GDPR - la pregunta no es si debes implementar RadSec, sino cuándo y cómo. Tus próximos pasos: audita tu infraestructura RADIUS esta semana. Identifica tus flujos de tráfico de mayor riesgo. Consulta la documentación del proveedor de tu servidor RADIUS y de tus puntos de acceso para verificar el soporte nativo de RadSec. Si utilizas FreeRADIUS, puedes tener una implementación de prueba de RadSec funcionando en un día. Si utilizas Microsoft NPS, comienza a evaluar un proxy o una ruta de migración a un servidor con capacidad para RadSec. La plataforma de Purple está diseñada para integrarse con la infraestructura RADIUS empresarial, admitiendo flujos de autenticación seguros tanto para entornos corporativos como de WiFi para invitados. Si quieres entender cómo encaja RadSec en tu implementación específica, el equipo de Purple puede guiarte en el proceso. Gracias por escuchar. Hasta la próxima. - FIN DEL GUION