RadSec: Protección del tráfico de autenticación RADIUS con TLS

RadSec: Protección del tráfico de autenticación RADIUS con TLS. Una sesión técnica de Purple. Introducción y contexto. Bienvenido a esta sesión técnica de Purple. Le guiaré a través de RadSec — RADIUS sobre TLS —, qué es, por qué es importante en este momento y cómo se despliega realmente. Esta sesión está dirigida directamente a arquitectos de red e ingenieros de seguridad que ya utilizan RADIUS en la nube o planean migrar allí. Si todavía utiliza servidores RADIUS locales con UDP y un secreto compartido, esta sesión es para usted. Pongámonos en situación. RADIUS ha sido la columna vertebral de la autenticación de red durante más de treinta años. Sustenta 802.1X, WPA2-Enterprise, WPA3-Enterprise y prácticamente todos los sistemas de Captive Portal en producción hoy en día. El protocolo en sí, definido en el RFC 2865, fue diseñado en una época en la que internet era un lugar muy diferente. El tráfico de autenticación entre sus dispositivos NAS (sus puntos de acceso, conmutadores y controladores) y su servidor RADIUS viajaba a través de UDP, puerto 1812 para autenticación y puerto 1813 para contabilidad. ¿Y ese tráfico? En su mayor parte, sin cifrar. La única protección era un secreto compartido utilizado para ofuscar el atributo de contraseña del usuario, e incluso eso presenta debilidades bien documentadas. Durante años, esto fue aceptable porque el tráfico RADIUS permanecía en redes privadas y controladas. Sus dispositivos NAS y su servidor RADIUS estaban en la misma LAN, o conectados a través de un circuito MPLS dedicado. La superficie de ataque era manejable. Pero el mundo ha cambiado. La infraestructura nativa de la nube, los despliegues en recintos distribuidos, las redes superpuestas SD-WAN y la transición a servicios RADIUS en la nube han alterado fundamentalmente el modelo de amenazas. Su tráfico de autenticación ahora atraviesa el internet público o, en el mejor de los casos, una infraestructura compartida que no controla por completo. Ahí es donde entra RadSec. Análisis técnico detallado. RadSec, definido formalmente en el RFC 6614, es RADIUS sobre TLS. El concepto es sencillo: en lugar de enviar paquetes RADIUS sobre UDP, los encapsula dentro de una conexión TLS sobre TCP. El resultado es que todo el tráfico de autenticación y contabilidad entre su NAS y su servidor RADIUS está completamente cifrado, autenticado mutuamente y protegido en su integridad. El RFC 7360 amplía esto a DTLS (Datagram TLS sobre UDP), que conserva algunas de las características de latencia del transporte UDP original al tiempo que añade cifrado. Para la mayoría de los despliegues empresariales, TLS sobre TCP es la opción correcta. Vale la pena considerar DTLS en entornos de alto rendimiento y sensibles a la latencia, como los despliegues en grandes estadios. Hablemos de la mecánica. RadSec funciona en el puerto TCP 2083, que es el puerto asignado por la IANA para este protocolo. Cuando un dispositivo NAS inicia una conexión RadSec, abre una conexión TCP con el servidor RADIUS en el puerto 2083 y realiza un saludo TLS. Este saludo es mutuo: tanto el cliente (su NAS) como el servidor presentan certificados X.509. El certificado del servidor se valida frente a una CA de confianza. El certificado de cliente identifica al NAS ante el servidor RADIUS. Una vez establecida la sesión TLS, los paquetes RADIUS fluyen dentro de ese túnel cifrado exactamente igual que lo harían sobre UDP, pero ahora con total confidencialidad, integridad y protección contra ataques de denegación por reenvío (replay). Esto supone una desviación significativa del RADIUS tradicional en tres aspectos importantes. En primer lugar, el transporte es TCP, no UDP. Esto significa que obtiene una entrega fiable y ordenada. Los paquetes perdidos se retransmiten automáticamente. En segundo lugar, la autenticación de ambos extremos se basa en certificados, no en secretos compartidos. Esto elimina toda una clase de ataques basados en secretos compartidos débiles o comprometidos. En tercer lugar, se cifra todo el paquete RADIUS, no solo el atributo de contraseña. Esto significa que los nombres de usuario, los identificadores de sesión y todos los atributos de RADIUS están protegidos en tránsito. Desde la perspectiva de la gestión de certificados, necesita una PKI (infraestructura de clave pública) para emitir y gestionar certificados tanto para su servidor RADIUS como para sus dispositivos NAS. En la práctica, la mayoría de los proveedores de RADIUS en la nube, incluida la infraestructura de autenticación nativa de la nube de Purple, se encargan de la gestión de certificados del lado del servidor por usted. Su responsabilidad es aprovisionar certificados de cliente en sus dispositivos NAS. Para despliegues a gran escala, esto se gestiona normalmente a través de su plataforma de gestión de red o un sistema de gestión de certificados dedicado. Los certificados deben utilizar como mínimo RSA de 2048 bits o ECDSA P-256, con un período de validez que equilibre la sobrecarga operativa con la higiene de seguridad; doce meses es un valor predeterminado razonable. Ahora, abordemos la comparación con el enfoque alternativo que utilizan muchas organizaciones hoy en día: túneles IPsec o redes superpuestas VPN para proteger el tráfico RADIUS. IPsec es un enfoque perfectamente válido, pero funciona en una capa diferente. Está cifrando todo el tráfico entre dos extremos, lo que añade complejidad: debe gestionar IKE, claves precompartidas o certificados para el propio túnel, y la sobrecarga operativa de mantener el estado del túnel en potencialmente cientos de sitios. RadSec es más quirúrgico. Cifra específicamente el tráfico del protocolo RADIUS, funciona en la capa de aplicación y se integra directamente con su infraestructura RADIUS. Para despliegues de RADIUS en la nube donde se conectan muchos dispositivos NAS en recintos distribuidos a un servidor en la nube centralizado, RadSec es arquitectónicamente más limpio y operativamente más sencillo. Permítame guiarle a través de cómo se ve un despliegue multisitio en la práctica. Tiene un servidor RADIUS en la nube (digamos que es la plataforma de Purple) con un certificado TLS válido de una CA de confianza. Tiene tres tipos de recintos: un hotel, una tienda minorista y un centro de conferencias. Cada uno tiene dispositivos NAS: puntos de acceso, conmutadores o controladores de LAN inalámbrica. Cada dispositivo NAS debe configurarse con la dirección del servidor RadSec, el puerto 2083 y un certificado de cliente. El NAS inicia la conexión TLS, se completa el saludo mutuo y, a partir de ese momento, todo el tráfico de autenticación 802.1X para invitados y personal en ese recinto fluye cifrado hacia el servidor RADIUS en la nube. Si la conexión TLS se cae (por ejemplo, debido a una interrupción de la red), el NAS la restablece automáticamente. Este modelo de conexión persistente es en realidad más eficiente que UDP para despliegues de gran volumen porque evita la sobrecarga del procesamiento por paquete. En el lado del firewall, debe permitir TCP saliente en el puerto 2083 desde su red de gestión de NAS hacia la dirección IP o FQDN de su servidor RADIUS. Si aplica una política de salida estricta, también querrá permitir el tráfico de retorno. Esto es más sencillo que gestionar las reglas de firewall de IPsec, que a menudo requieren excepciones del protocolo ESP e IKE en UDP 500 y 4500. Recomendaciones de implementación y errores comunes. Hablemos de lo que realmente falla en los despliegues de RadSec, porque hay algunos modos de fallo constantes que veo en las organizaciones. El primer problema y el más común son los fallos de validación de la cadena de certificados. Su dispositivo NAS debe confiar en la CA que firmó el certificado del servidor RADIUS. Si utiliza un proveedor de RADIUS en la nube con un certificado de una CA pública conocida (DigiCert, Let's Encrypt, Sectigo), la mayoría de los dispositivos NAS modernos confiarán en él de forma nativa. Pero si utiliza una CA interna, debe enviar el certificado de la CA a cada dispositivo NAS. Esto a menudo se pasa por alto durante el despliegue inicial y se manifiesta como fallos en el saludo TLS que parecen problemas de conectividad. El segundo error común es la caducidad de los certificados. A diferencia de los secretos compartidos, que no caducan, los certificados tienen un período de validez definido. Si el certificado de su servidor RADIUS caduca, todos los dispositivos NAS de su infraestructura fallarán en la autenticación simultáneamente. Necesita una gestión del ciclo de vida de los certificados: renovación automatizada siempre que sea posible, y supervisión con alertas mucho antes de la caducidad. Un aviso de noventa días es el mínimo; treinta días es mejor. El tercer problema es la compatibilidad de los dispositivos NAS. No todos los dispositivos NAS admiten RadSec de forma nativa. Las versiones más antiguas de Cisco IOS, algunos controladores Aruba heredados y ciertos puntos de acceso de consumo no son compatibles con RadSec. Antes de comprometerse con un despliegue de RadSec, audite su parque de NAS para comprobar la compatibilidad. Cisco IOS-XE 16.x y posteriores, Aruba AOS-CX, Ruckus SmartZone y la serie Juniper EX tienen un soporte sólido para RadSec. Para los dispositivos que no admiten RadSec de forma nativa, un proxy RadSec (una opción de código abierto como radsecproxy) puede salvar la brecha, aceptando RADIUS UDP de los dispositivos heredados y reenviándolo a través de TLS al servidor RADIUS en la nube. La cuarta consideración es la persistencia de la conexión y los keepalives. RadSec utiliza conexiones TCP persistentes, pero los firewalls y dispositivos NAT con políticas de tiempo de espera agresivas pueden interrumpir silenciosamente las conexiones inactivas. Configure keepalives TCP en sus conexiones RadSec; normalmente, un intervalo de keepalive de sesenta segundos es suficiente para evitar la interrupción prematura de la conexión. La mayoría de las implementaciones de servidores RADIUS y dispositivos NAS admiten esta configuración. Para Cisco IOS-XE, la configuración de RadSec se ve así. Define un servidor RADIUS con la dirección de su extremo de RADIUS en la nube, especifica TLS como transporte, hace referencia a su trustpoint (que es el almacén de certificados en el dispositivo) y establece el puerto de destino en 2083. A continuación, hace referencia a este servidor en la configuración de su grupo de servidores AAA. Los detalles varían según la versión de la plataforma, pero la estructura lógica es coherente entre los distintos proveedores. Para los controladores Aruba que ejecutan AOS, configura el servidor RADIUS con la opción RadSec habilitada, especifica el certificado de la CA para la validación del servidor y, opcionalmente, configura un certificado de cliente para TLS mutuo. La implementación de Aruba es madura y está bien documentada. Preguntas y respuestas rápidas. Permítame repasar las preguntas que me hacen con más frecuencia sobre RadSec. ¿Añade latencia RadSec? El saludo TLS añade una pequeña sobrecarga en el establecimiento inicial de la conexión, normalmente de menos de 100 milisegundos. Una vez establecida la conexión, la sobrecarga por paquete es insignificante. Para la autenticación 802.1X, donde el saludo ocurre una vez por sesión, esto no es una preocupación significativa. ¿Puedo ejecutar RadSec junto con el RADIUS UDP tradicional? Sí. La mayoría de los servidores RADIUS admiten ambos simultáneamente. Durante una migración, puede ejecutar RadSec para los sitios que lo admitan y recurrir a UDP para los sitios heredados. Este es el enfoque de migración recomendado. ¿Es necesario RadSec para el cumplimiento de PCI DSS? La versión 4.0 de PCI DSS exige que el tráfico de autenticación esté protegido en tránsito. RadSec es una de las formas más directas de cumplir con este requisito para la autenticación basada en RADIUS. Si procesa pagos con tarjeta a través de una red que utiliza autenticación RADIUS, RadSec debería estar en su hoja de ruta de cumplimiento. ¿Funciona RadSec con EAP? Sí. EAP (protocolo de autenticación extensible) se encapsula dentro de RADIUS, por lo que EAP-TLS, PEAP y EAP-TTLS funcionan de forma transparente sobre RadSec. El intercambio EAP en sí no se ve afectado. ¿Qué pasa con la contabilidad (accounting) de RADIUS? El RFC 6614 cubre tanto el tráfico de autenticación como el de contabilidad. Sus datos de contabilidad (registros de inicio, parada y actualización provisional de la sesión) también se cifran a través de la misma conexión TLS en el puerto 2083. Resumen y próximos pasos. En resumen: RadSec es la capa de transporte adecuada para RADIUS en cualquier despliegue donde el tráfico de autenticación cruce una infraestructura que no controla por completo. Esto incluye RADIUS en la nube, despliegues multisitio, entornos SD-WAN y cualquier escenario donde el tráfico RADIUS atraviese el internet público o la infraestructura de un operador compartido. Las acciones clave para su equipo son: primero, auditar su parque de NAS para comprobar la compatibilidad con RadSec e identificar cualquier dispositivo que necesite un proxy. Segundo, ponerse en contacto con su proveedor de RADIUS en la nube (o evaluar proveedores que admitan RadSec de forma nativa) y comprender su enfoque de gestión de certificados. Tercero, establecer un proceso de gestión del ciclo de vida de los certificados antes de la puesta en marcha. Cuarto, actualizar las reglas de su firewall para permitir TCP 2083 saliente desde su red de gestión de NAS. Quinto, probar su configuración de RadSec en un entorno de pruebas antes de implementarla en producción, prestando especial atención a la validación de la cadena de certificados y a la persistencia de la conexión bajo carga. Para las organizaciones que ejecutan la plataforma de Purple para WiFi de invitados y autenticación en recintos distribuidos, RadSec es el transporte recomendado para la conectividad de RADIUS en la nube. Se alinea con la arquitectura nativa de la nube de Purple y garantiza que los datos de autenticación que fluyen entre sus recintos y la plataforma estén completamente protegidos, lo que es importante tanto para su postura de seguridad como para sus obligaciones de cumplimiento bajo GDPR y PCI DSS. Si está planeando un despliegue o desea analizar su arquitectura específica, el equipo de Purple es el punto de partida adecuado. Esta ha sido una sesión técnica de Purple sobre RadSec. Gracias por su atención.