Mitigación de vulnerabilidades de RADIUS: guía de securización de red

Resumen Ejecutivo

RADIUS (Remote Authentication Dial-In User Service) sigue siendo el protocolo principal para el control de acceso a la red en despliegues de WiFi corporativos, sustentando la autenticación IEEE 802.1X en hoteles, tiendas, estadios, centros de conferencias y edificios del sector público. Sin embargo, la arquitectura de RADIUS se remonta a la década de 1990, y varias de sus decisiones de diseño fundacionales (la dependencia del hash MD5, el transporte UDP sin cifrado nativo y los secretos compartidos estáticos) se han convertido en riesgos significativos en el entorno de amenazas actual.

En julio de 2024, la vulnerabilidad BlastRADIUS (CVE-2024-3596) demostró que un atacante man-in-the-middle puede falsificar respuestas Access-Accept de RADIUS explotando las debilidades de integridad de MD5 en los paquetes Access-Request. La vulnerabilidad afecta a las principales implementaciones de RADIUS, incluyendo FreeRADIUS, Cisco ISE y Microsoft NPS. Los despliegues sin parchear siguen estando expuestos a riesgos.

Esta guía proporciona una hoja de ruta de securización priorizada que abarca la gestión de parches, la higiene de secretos compartidos, la selección del método EAP, el despliegue de RadSec, la autenticación multifactor para el acceso administrativo y la integración con SIEM para la detección de anomalías. Está escrita para profesionales de TI que necesitan tomar decisiones defendibles este trimestre, no el próximo año.

Análisis Técnico Detallado

Cómo funciona RADIUS y cuáles son sus puntos débiles

RADIUS opera como un protocolo cliente - servidor entre un servidor de acceso a la red (NAS) (normalmente un punto de acceso WiFi, un switch o un concentrador VPN) y un servidor RADIUS, que valida las credenciales contra un almacén de identidades backend como Active Directory o LDAP. El intercambio de autenticación sigue el modelo de solicitud - desafío - respuesta definido en RFC 2865, con la contabilidad gestionada por separado bajo RFC 2866.

El protocolo transmite paquetes de autenticación sobre UDP, utilizando el puerto 1812 para la autenticación y el 1813 para la contabilidad. El secreto compartido (la clave precompartida configurada tanto en el NAS como en el servidor RADIUS) se utiliza para generar el campo Response Authenticator y para cifrar el atributo User-Password a través de un cifrado XOR basado en MD5. Esto no es cifrado en ningún sentido moderno; es una ofuscación que depende enteramente del secreto y la robustez del secreto compartido.

Las cinco categorías principales de vulnerabilidad en un despliegue típico de RADIUS son las siguientes.

Vulnerabilidades de integridad y colisión MD5. El ataque BlastRADIUS (CVE-2024-3596) explota la falta de protección de integridad en los paquetes Access-Request. Dado que muchas configuraciones no incluyen por defecto el atributo Message-Authenticator desde el NAS, un atacante en una posición intermedia (man-in-the-middle) puede inyectar atributos manipulados antes de que el paquete llegue al servidor RADIUS. Utilizando una técnica de colisión de prefijo elegido de MD5, el atacante puede manipular el paquete para que el servidor RADIUS calcule un Response Authenticator válido para el paquete modificado, devolviendo un Access-Accept para una solicitud que debería haber sido rechazada. La solución consiste en exigir el atributo Message-Authenticator en todos los paquetes Access-Request, lo que proporciona protección de integridad HMAC-MD5 en todo el paquete. Esto requiere cambios de configuración tanto en el NAS como en el servidor RADIUS, no solo un parche del servidor.

Secretos compartidos débiles o estáticos. El secreto compartido es el anclaje criptográfico del intercambio RADIUS. Si el secreto es corto, predecible o nunca se rota, un atacante que capture el tráfico RADIUS (posible mediante ARP spoofing o un dispositivo de red comprometido) puede descifrar por fuerza bruta el atributo User-Password de forma offline. Las directrices de la norma NIST SP 800-63B sobre secretos memorizados se aplican aquí: los secretos deben tener al menos 20 caracteres, generarse de forma aleatoria y almacenarse en un sistema de gestión de secretos. Para redes grandes con decenas o cientos de dispositivos NAS, la rotación manual es inviable a nivel operativo; la automatización mediante HashiCorp Vault o un gestor de secretos similar es el enfoque correcto.

Transporte UDP no cifrado. El estándar RADIUS sobre UDP no proporciona confidencialidad en la capa de transporte. El atributo User-Password se ofusca pero no se cifra. Todos los demás atributos - incluidos los nombres de usuario, las direcciones IP de NAS y los metadatos de sesión - viajan en texto plano. RadSec (RADIUS sobre TLS), definido en RFC 6614 y actualizado en RFC 7360, soluciona esto envolviendo el protocolo RADIUS en un túnel TLS sobre el puerto TCP 2083, estableciendo una sesión TLS 1.2 o TLS 1.3. RadSec proporciona autenticación mutua de certificados entre el NAS y el servidor RADIUS, cifrado completo de la carga útil y protección contra la repetición de paquetes. Es el transporte correcto para cualquier tráfico RADIUS que cruce un límite de red no seguro.

Selección del método EAP. El Protocolo de Autenticación Extensible (EAP) define los métodos de autenticación internos utilizados dentro del marco 802.1X. EAP-MD5 está obsoleto y debe eliminarse de todas las implementaciones de inmediato; no proporciona autenticación mutua ni resistencia a los ataques de recopilación de credenciales. PEAP (EAP protegido) y EAP-TTLS establecen un túnel TLS utilizando un certificado de servidor antes de transmitir las credenciales, proporcionando autenticación mutua y protegiendo el método interno de la interceptación. EAP-TLS elimina por completo las contraseñas, requiriendo certificados X.509 tanto en el servidor como en el cliente. Es inmune al phishing y a los ataques de fuerza bruta y es el método recomendado para entornos de alta seguridad. Registro y supervisión insuficientes. El registro de RADIUS registra cada evento de autenticación: éxito, fallo, inicio de sesión, parada de sesión. Estos datos son operativamente valiosos para la planificación de la capacidad y comercialmente valiosos para WiFi Analytics , pero también son una fuente crítica de telemetría de seguridad. Las tormentas de fallos de autenticación, las autenticaciones desde direcciones MAC desconocidas y los patrones de acceso fuera de las horas de trabajo son detectables a partir de los registros de RADIUS. La mayoría de las organizaciones no ingieren estos datos en un SIEM, y las que lo hacen rara vez configuran umbrales de alerta.

El ataque BlastRADIUS al detalle

BlastRADIUS se dio a conocer en julio de 2024 por investigadores de la Universidad de Boston y la UC San Diego. El ataque requiere una posición de intermediario (man-in-the-middle) entre el NAS y el servidor RADIUS, lo cual se puede lograr mediante envenenamiento ARP en un segmento de red compartido, un router comprometido o un usuario interno malicioso con acceso a la red.

El ataque se desarrolla de la siguiente manera: el atacante intercepta un paquete Access-Request del NAS. Dado que el paquete carece del atributo Message-Authenticator (el valor predeterminado en muchas configuraciones), el atacante es libre de modificar la lista de atributos del paquete. Utilizando una colisión de prefijo elegido de MD5, el atacante construye un paquete modificado para el cual el servidor RADIUS calculará el mismo Response Authenticator que el original. Por lo tanto, el servidor devuelve un Access-Accept para una solicitud que contiene atributos controlados por el atacante, incluido un Service-Type de Administrative que autoriza el acceso total a la red.

El ataque es eficaz contra implementaciones PEAP y EAP-TTLS que utilizan MSCHAPv2 como método interno. No afecta a las implementaciones EAP-TLS, donde la autenticación mutua basada en certificados proporciona una protección de integridad que MD5 no puede subvertir.

Para las organizaciones que ejecutan tanto Guest WiFi como 802.1X corporativo, la instancia RADIUS de la red de invitados también debe ser parcheada, incluso si utiliza la omisión de autenticación de MAC (MAC Authentication Bypass) en lugar de EAP. La higiene de secretos compartidos y el requisito de Message-Authenticator se aplican por igual.

Guía de implementación

Fase 1: Corrección inmediata (semanas 1-2)

El parcheo es lo primero. FreeRADIUS 3.2.5 y 3.0.27 contienen las correcciones de BlastRADIUS y aplican Message-Authenticator por defecto. Cisco ISE 3.1 Parche 8, 3.2 Parche 4 y 3.3 Parche 1 solucionan la vulnerabilidad. Microsoft publicó el KB5040434 para Windows Server 2022 NPS en julio de 2024. Verifique sus versiones actuales y aplique los parches en su próximo período de cambios programado.

At the same time, audit your NAS device firmware. Message-Authenticator enforcement is only effective if the NAS also sends the attribute. Check your access point and switch vendor advisories - Aruba, Ruckus, Cisco and Juniper have all released firmware updates for BlastRADIUS. If you are running Ruckus hardware, the wireless access point Ruckus guide provides relevant firmware management context.

For troubleshooting Windows 11 802.1X authentication issues that can appear after patching, the most common cause is the NPS server rejecting connections from clients that do not include Message-Authenticator - correct security behaviour that may require supplicant reconfiguration on older Windows clients.

Phase 2: Shared secret hygiene (weeks 2-4)

Export the full list of NAS clients registered on your RADIUS servers. For each entry, record the shared secret length and the date it was last changed. Any secret below 20 characters, or unchanged for more than 24 months, should be rotated immediately.

For new secrets, use a cryptographically random generator - openssl rand -base64 32 produces a 44-character base64 string well suited to use as a RADIUS shared secret. Store all secrets in a secrets management system. Implement a rotation schedule: annually for low-risk NAS devices, every six months for NAS devices in PCI-DSS scope.

Phase 3: EAP method rationalisation (months 1-2)

Audit the EAP methods your RADIUS servers permit. Disable EAP-MD5. If you are running PEAP-MSCHAPv2, verify that all supplicants enforce server certificate validation - a misconfigured supplicant that accepts any server certificate is vulnerable to rogue RADIUS server attacks. For environments in PCI-DSS scope, EAP-TLS is recommended. If you have no existing certificate infrastructure, begin PKI planning.

For securing guest WiFi networks , note that guest networks typically use Captive Portal authentication rather than 802.1X, so EAP method hardening applies primarily to corporate and staff SSIDs.

Phase 4: RadSec deployment (months 2-3)

Identify every RADIUS traffic path that crosses an untrusted network boundary. Common scenarios include a central RADIUS server serving remote hotels over the internet; on-premises NAS devices reaching a cloud RADIUS service; and RADIUS proxy chains where traffic traverses multiple network domains.

For each identified path, configure RadSec. On FreeRADIUS this means enabling the tls listener on port 2083 and configuring mutual TLS with certificates from your PKI. On Cisco ISE, RadSec is configured under Administration > Network Devices. Ensure TLS 1.2 as a minimum; explicitly disable TLS 1.0 and 1.1.

Phase 5: Multi-factor authentication for administrative access (months 2-3)

La interfaz de gestión de un servidor RADIUS es un objetivo de gran valor. Un atacante que comprometa el servidor RADIUS puede modificar las políticas de autenticación, extraer secretos compartidos y redirigir los flujos de autenticación. Obligue el uso de MFA en los inicios de sesión administrativos para todos los servidores RADIUS y sus sistemas operativos subyacentes. Restrinja el acceso de gestión a una VLAN de gestión dedicada fuera de banda. Implemente el control de acceso basado en roles: los ingenieros de red no deben tener los mismos privilegios que los administradores de seguridad.

Fase 6: Integración con SIEM y alertas (meses 3-4)

Configure sus servidores RADIUS para reenviar los registros de contabilidad a su SIEM en tiempo real. Defina los siguientes umbrales de alerta básicos:

Buenas prácticas

Las siguientes recomendaciones sintetizan el consenso entre IEEE 802.1X, NIST SP 800-63B, PCI-DSS v4.0 y las advertencias de seguridad de los proveedores.

Gestión de certificados. Cualquier despliegue que utilice EAP-TLS o RadSec cuenta con certificados X.509 en su ruta de autenticación. La expiración de los certificados es la causa más común de fallos de autenticación repentinos y totales en los despliegues de WiFi corporativos. Implemente la gestión automatizada del ciclo de vida de los certificados. Configure alertas de monitorización a los 90, 30 y 7 días antes de la expiración. Para los certificados de servidor RADIUS, utilice claves RSA de mínimo 2048 bits o ECDSA de 256 bits, y algoritmos de firma SHA-256 o superiores. No utilice SHA-1.

Segmentación de red. Los servidores RADIUS deben ubicarse en un segmento de gestión dedicado, aislado de las redes de invitados y corporativas generales. El acceso a los puertos RADIUS (UDP 1812, 1813 y TCP 2083 para RadSec) debe restringirse mediante ACL de cortafuegos a las direcciones IP específicas de los dispositivos NAS registrados. No permita el acceso directo a internet a los puertos RADIUS.

Redundancia y alta disponibilidad. Un único servidor RADIUS es un punto único de fallo para toda su infraestructura de control de acceso a la red. Despliegue al menos dos servidores RADIUS en una configuración activo - pasivo o activo - activo. Para despliegues en el sector de la hostelería con requisitos de conectividad para invitados las 24 horas del día, los 7 días de la semana, el tiempo de inactividad del servidor RADIUS se traduce directamente en un tiempo de inactividad de la red WiFi de invitados, lo que supone un riesgo comercial y reputacional.WPA3 and 802.1X. WPA3-Enterprise en modo de seguridad de 192 bits, necesario para implementaciones gubernamentales y de alta seguridad, exige AES-256-GCMP para el cifrado de datos y HMAC-SHA-384 para la autenticación. Para la mayoría de las implementaciones empresariales, WPA3-Enterprise con seguridad estándar de 128 bits ya es una mejora significativa con respecto a WPA2-Enterprise, en particular cuando se combina con EAP-TLS. Los entornos de comercio minorista que procesan pagos con tarjeta deben considerar la adopción de WPA3-Enterprise como una medida de reducción de riesgos PCI-DSS.

Cadencia de parches del proveedor. Suscríbase a los avisos de seguridad del proveedor de su servidor RADIUS y de los proveedores de sus dispositivos NAS. FreeRADIUS, Cisco, Microsoft, Aruba y Ruckus publican notificaciones de CVE. Incorpore estas notificaciones a su programa de gestión de vulnerabilidades con SLA definidos: vulnerabilidades críticas (CVSS ≥ 9.0) parcheadas en un plazo de 72 horas; vulnerabilidades de gravedad alta (CVSS 7.0 - 8.9) en un plazo de 14 días.

Solución de problemas y mitigación de riesgos

Modos de fallo comunes

Fallos de autenticación tras el parcheo. Tras aplicar los parches de BlastRADIUS, algunos dispositivos NAS pueden fallar al autenticarse si su firmware no es compatible con Message-Authenticator. Síntoma: un aumento repentino de respuestas Access-Reject sin cambios en las credenciales de los usuarios. Diagnóstico: habilite el registro de depuración de RADIUS y busque errores del tipo "Message-Authenticator required but not present". Resolución: actualice el firmware del NAS o, como medida temporal, configure el servidor RADIUS para que acepte solicitudes sin Message-Authenticator de IP de NAS específicas mientras se programan las actualizaciones de firmware.

Fallos de validación de certificados en EAP-TLS. Síntoma: los clientes reciben el mensaje "error de autenticación" sin el correspondiente Access-Reject en el registro de RADIUS. Diagnóstico: compruebe la cadena de certificados del servidor RADIUS - ¿confía el suplicante del cliente en la CA emisora? ¿Está el certificado del servidor dentro de su periodo de validez? Resolución: asegúrese de que la cadena de certificados completa (hoja + intermedio + raíz) esté configurada en el servidor RADIUS. Distribuya los certificados de la CA raíz a los dispositivos de los clientes a través de MDM o políticas de grupo.

Fallos en el protocolo de enlace TLS de RadSec. Síntoma: los dispositivos NAS no pueden establecer conexiones RadSec después de un cambio de configuración. Diagnóstico: compruebe la compatibilidad de la versión de TLS - es posible que el firmware de los NAS más antiguos no admita TLS 1.2. Compruebe la autenticación mutua de certificados - ambas partes deben confiar en la CA de la otra. Resolución: verifique la compatibilidad de la versión de TLS en las notas de la versión del firmware del NAS; asegúrese de que los certificados del dispositivo NAS estén emitidos por la misma CA en la que confía el servidor RADIUS.

Discrepancia en la clave secreta compartida. Síntoma: todas las autenticaciones de un NAS concreto fallan con errores de "autenticador no válido". Diagnóstico: una discrepancia de la clave secreta compartida entre la configuración del NAS y la entrada del cliente del servidor RADIUS. Resolución: vuelva a introducir la clave secreta compartida en ambos extremos, comprobando si hay espacios en blanco al final o problemas de codificación de caracteres. Copie y pegue desde su gestor de secretos para evitar errores de transcripción.

Registro de riesgos

ROI e impacto empresarial

Cuantificación del riesgo

El argumento financiero para el endurecimiento de RADIUS es más evidente cuando se compara con los costes de una brecha de seguridad. El coste medio de una brecha de datos en el Reino Unido en 2024 fue de 3,58 millones de libras, lo que incluye multas reglamentarias, remediación, costes legales y daños a la reputación. Para las organizaciones dentro del alcance de PCI-DSS (básicamente todos los operadores de Retail y Hospitality que aceptan pagos con tarjeta a través de WiFi), una brecha en el control de acceso a la red que exponga datos de titulares de tarjetas desencadena una investigación forense obligatoria, posibles multas de los esquemas de tarjetas y la posible suspensión de los derechos de procesamiento de tarjetas.

Para las organizaciones de Healthcare , una brecha de GDPR que afecte a datos de pacientes a los que se haya accedido a través de un servidor RADIUS comprometido conlleva multas de hasta el 4% de la facturación anual global en virtud del artículo 83, apartado 5. El historial de control de la ICO demuestra que los fallos de seguridad de la red se tratan como negligencia, no como una desgracia técnica.

Puntos de referencia de costes de implementación

Las siguientes estimaciones de costes asumen una red corporativa de 500 dispositivos:

La inversión total en endurecimiento para una mediana empresa es de aproximadamente 20.000-45.000 £. Frente a la base de referencia del coste de una brecha de seguridad de 3,58 millones de libras, el ROI ajustado al riesgo es convincente incluso bajo supuestos conservadores de probabilidad de brecha.

Beneficios operativos más allá de la seguridad

Una infraestructura RADIUS endurecida también ofrece dividendos operativos. Una autenticación fiable y bien monitorizada reduce los tickets de soporte técnico relacionados con la conectividad WiFi. Los datos de contabilidad de RADIUS, cuando se integran con WiFi Analytics , proporcionan visibilidad a nivel de sesión sobre los patrones de uso de la red, los tiempos de permanencia y los tipos de dispositivos; datos con un valor comercial directo para los operadores de recintos en entornos de Hospitality y Transport . Para las organizaciones del sector público y el sector sanitario , un programa documentado de securización de RADIUS proporciona pruebas de los controles técnicos para las evaluaciones de Cyber Essentials Plus, ISO 27001 y NHS DSPT - lo que reduce el esfuerzo de auditoría y demuestra la debida diligencia ante los organismos reguladores.