Mitigación de vulnerabilidades de RADIUS: Una guía de fortalecimiento de seguridad
Esta guía proporciona una referencia completa y práctica para gerentes de TI, arquitectos de red y CTO responsables de la infraestructura de WiFi empresarial en los sectores de hospitalidad, retail, eventos y entornos del sector público. Cubre toda la superficie de ataque de las implementaciones de servidores RADIUS, desde vulnerabilidades de colisión MD5 y secretos compartidos débiles hasta transporte UDP sin cifrar y métodos EAP mal configurados, y ofrece una hoja de ruta de fortalecimiento priorizada y alineada con los requisitos de IEEE 802.1X, PCI DSS y GDPR. Las organizaciones que implementen estas recomendaciones reducirán de manera significativa su exposición a ataques de red basados en credenciales, cumplirán con sus obligaciones de conformidad y construirán una postura de seguridad sólida para su infraestructura de WiFi corporativa y de invitados.
Escucha esta guía
Ver transcripción del podcast
Resumen Ejecutivo
RADIUS (Remote Authentication Dial-In User Service) sigue siendo el protocolo dominante para el control de acceso a la red en implementaciones de WiFi empresariales, respaldando la autenticación IEEE 802.1X en hoteles, tiendas minoristas, estadios, centros de conferencias y edificios del sector público. Sin embargo, RADIUS fue diseñado en la década de 1990 y varias de sus decisiones de diseño fundamentales (la dependencia del hashing MD5, el transporte UDP sin cifrado nativo y los secretos compartidos estáticos) se han convertido en vulnerabilidades críticas en el entorno de amenazas actual.
En julio de 2024, la vulnerabilidad BlastRADIUS (CVE-2024-3596) demostró que un atacante intermediario (man-in-the-middle) puede falsificar respuestas Access-Accept de RADIUS explotando la debilidad de integridad de MD5 en los paquetes Access-Request. Esto afecta a las principales implementaciones de RADIUS, incluyendo FreeRADIUS, Cisco ISE y Microsoft NPS. Las implementaciones sin parches siguen expuestas.
Esta guía proporciona una hoja de ruta de robustecimiento priorizada que cubre la gestión de parches, la higiene de secretos compartidos, la selección del método EAP, la implementación 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 el profesional de TI que necesita tomar una decisión defendible este trimestre, no el próximo año.
Análisis Técnico Detallado
Cómo Funciona RADIUS y Dónde se Quiebra
RADIUS opera como un protocolo cliente-servidor entre un Servidor de Acceso a la Red (NAS) — típicamente un punto de acceso WiFi, switch o concentrador VPN — y un servidor RADIUS que valida las credenciales contra un almacén de identidad backend como Active Directory o LDAP. El intercambio de autenticación sigue un modelo de solicitud-desafío-respuesta definido en RFC 2865, con la contabilidad (accounting) gestionada por separado bajo RFC 2866.
El protocolo transmite paquetes de autenticación sobre UDP, puerto 1812 para autenticación y puerto 1813 para contabilidad. El secreto compartido — una clave precompartida configurada tanto en el NAS como en el servidor RADIUS — se utiliza para generar el campo Response Authenticator y para ofuscar el atributo User-Password a través de un cifrado XOR basado en MD5. Esto no es cifrado en ningún sentido moderno; es ofuscación, y depende completamente del secreto y la fortaleza del secreto compartido.
Las cinco clases principales de vulnerabilidad en una implementación típica de RADIUS son las siguientes.
Vulnerabilidades de integridad y colisión MD5. El ataque BlastRADIUS (CVE-2024-3596) explota la ausencia de protección de integridad en los paquetes Access-Request. Debido a que el NAS no incluye un atributo Message-Authenticator de forma predeterminada en muchas configuraciones, un atacante con una posición de intermediario (man-in-the-middle) puede inyectar un atributo manipulado en el paquete antes de que llegue al servidor RADIUS. Al explotar técnicas de colisión de prefijo elegido de MD5, el atacante puede manipular el paquete de tal manera 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 mitigación consiste en exigir el atributo Message-Authenticator en todos los paquetes Access-Request, lo que proporciona protección de integridad HMAC-MD5 sobre todo el paquete. Este es un cambio 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 ancla criptográfica del intercambio RADIUS. Si es corto, predecible o no se ha rotado, un atacante que capture el tráfico RADIUS (lo cual es viable mediante suplantación de ARP o un dispositivo de red comprometido) puede realizar un ataque de fuerza bruta sin conexión contra el atributo User-Password. La guía de NIST SP 800-63B sobre secretos memorizados se aplica aquí: los secretos deben tener un mínimo de 20 caracteres, generarse de forma aleatoria y almacenarse en un sistema de gestión de secretos. Para entornos grandes con decenas o cientos de dispositivos NAS, la rotación manual es inviable desde el punto de vista operativo; la automatización a través de HashiCorp Vault o un gestor de secretos comparable 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 el nombre de usuario, la IP del NAS y los metadatos de la sesión, se transmiten en texto plano. RadSec (RADIUS sobre TLS), definido en RFC 6614 y actualizado en RFC 7360, resuelve esto al envolver el protocolo RADIUS en una sesión TLS 1.2 o TLS 1.3 sobre el puerto TCP 2083. RadSec proporciona autenticación mutua de certificados entre el NAS y el servidor RADIUS, cifrado completo de la carga útil y protección contra reproducción. Es el transporte correcto para cualquier tráfico RADIUS que cruce un límite de red no confiable.
EAP Method Selection. El Protocolo de Autenticación Extensible (EAP) define el método de autenticación interno utilizado dentro del marco 802.1X. EAP-MD5 está obsoleto y debe eliminarse de todas las implementaciones de inmediato; no proporciona autenticación mutua ni protección contra la recopilación de credenciales. PEAP (Protected EAP) y EAP-TTLS establecen un túnel TLS utilizando un certificado de servidor antes de transmitir las credenciales, lo que proporciona autenticación mutua y protege el método interno contra la interceptación. EAP-TLS elimina las contraseñas por completo, requiriendo que tanto el servidor como el cliente presenten certificados X.509. Es inmune al phishing y a los ataques de fuerza bruta, y es el método recomendado para entornos de alta seguridad.
Insufficient Logging and Monitoring. El registro de RADIUS registra cada evento de autenticación: éxito, falla, inicio de sesión, finalización de sesión. Estos datos son operativamente valiosos para la planificación de capacidad y comercialmente valiosos para WiFi Analytics , pero también son una fuente crítica de telemetría de seguridad. Las tormentas de autenticación fallidas, las autenticaciones desde direcciones MAC inesperadas y los patrones de acceso fuera de horario son detectables a partir de los registros de RADIUS. La mayoría de las organizaciones no están ingresando estos datos en un SIEM, y aquellas que lo hacen a menudo no tienen configurados umbrales de alerta.
The BlastRADIUS Attack in Detail
BlastRADIUS fue revelado en julio de 2024 por investigadores de la Universidad de Boston y la Universidad de California en 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 infiltrado malicioso con acceso a la red.
El ataque procede de la siguiente manera: el atacante intercepta un paquete Access-Request del NAS. Debido a que el paquete carece de un atributo Message-Authenticator (el valor predeterminado en muchas configuraciones), el atacante tiene la libertad de modificar la lista de atributos del paquete. Utilizando una colisión de prefijo elegido de MD5, el atacante diseña un paquete modificado que, al ser procesado por el servidor RADIUS, produce el mismo Response Authenticator que habría producido el paquete 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 otorga acceso total a la red.
El ataque es viable contra implementaciones de PEAP y EAP-TTLS donde el método interno utiliza MSCHAPv2. No afecta a las implementaciones de EAP-TLS, porque la autenticación mutua basada en certificados proporciona una protección de integridad que MD5 no puede debilitar.
Para las organizaciones que ejecutan Guest WiFi junto con 802.1X corporativo, la instancia RADIUS de la red de invitados también debe parcharse, incluso si utiliza MAC Authentication Bypass en lugar de EAP. Los requisitos de higiene de secretos compartidos y Message-Authenticator se aplican por igual.
Guía de Implementación
Fase 1: Remediación Inmediata (Semanas 1–2)
La primera prioridad es el parcheo. FreeRADIUS 3.2.5 y 3.0.27 incluyen la corrección de BlastRADIUS y aplican Message-Authenticator de forma predeterminada. Cisco ISE 3.1 Parche 8, 3.2 Parche 4 y 3.3 Parche 1 solucionan la vulnerabilidad. Microsoft lanzó KB5040434 para Windows Server 2022 NPS en julio de 2024. Verifique sus versiones actuales y aplique los parches dentro de su próxima ventana de cambios programada.
Simultáneamente, audite el firmware de sus dispositivos NAS. La aplicación de Message-Authenticator solo es efectiva si el NAS también envía el atributo. Consulte los avisos de seguridad de los proveedores de sus puntos de acceso y switches: Aruba, Ruckus, Cisco y Juniper lanzaron actualizaciones de firmware que abordan BlastRADIUS. Si utiliza hardware Ruckus, la guía de puntos de acceso inalámbricos Ruckus proporciona un contexto relevante para la gestión de firmware.
Para la Resolución de problemas de autenticación 802.1X en Windows 11 que puedan surgir después del parche, la causa más común es que el servidor NPS rechace las conexiones de clientes que no incluyen Message-Authenticator, un comportamiento de seguridad correcto que puede requerir la reconfiguración del suplicante en clientes Windows más antiguos.
Fase 2: Higiene de Secretos Compartidos (Semanas 2–4)
Exporte la lista completa de clientes NAS registrados en su servidor RADIUS. Para cada entrada, registre la longitud del secreto compartido y la fecha en que se cambió por última vez. Cualquier secreto de menos de 20 caracteres o que no se haya cambiado en más de 24 meses debe rotarse de inmediato.
Para nuevos secretos, utilice un generador aleatorio criptográfico: openssl rand -base64 32 produce una cadena base64 de 44 caracteres adecuada para su uso como secreto compartido de RADIUS. Almacene todos los secretos en un sistema de gestión de secretos. Implemente un programa de rotación: anualmente para dispositivos NAS de bajo riesgo, cada seis meses para dispositivos NAS dentro del alcance de PCI DSS.
Fase 3: Racionalización del Método EAP (Meses 1–2)
Audite los métodos EAP permitidos en su servidor RADIUS. Desactive EAP-MD5. Si utiliza PEAP-MSCHAPv2, verifique que la validación del certificado del servidor se aplique en todos los suplicantes; un suplicante mal configurado que acepte cualquier certificado de servidor es vulnerable a ataques de servidores RADIUS no autorizados. Para entornos dentro del alcance de PCI DSS, EAP-TLS es el camino recomendado. Comience la planificación de PKI si no cuenta con una infraestructura de certificados existente.
Para la Seguridad en redes Guest WiFi , tenga en cuenta que las redes de invitados suelen utilizar la autenticación de Captive Portal en lugar de 802.1X, por lo que el endurecimiento del método EAP se aplica principalmente a los SSIDs corporativos y del personal.
Fase 4: Despliegue de RadSec (Meses 2–3)
Identifique todas las rutas de tráfico RADIUS que crucen límites de red no confiables. Los escenarios comunes incluyen: un servidor RADIUS central que brinda servicio a propiedades hoteleras remotas a través de internet; un servicio RADIUS alojado en la nube al que acceden dispositivos NAS locales; y cadenas de proxy RADIUS donde el tráfico pasa por múltiples dominios de red.
Para cada ruta identificada, configure RadSec. En FreeRADIUS, esto requiere habilitar el listener tls en el puerto 2083 y configurar TLS mutuo con certificados de su PKI. En Cisco ISE, RadSec se configura en Administration > Network Devices. Asegúrese de que TLS 1.2 sea la versión mínima; deshabilite TLS 1.0 y 1.1 de forma explícita.
Fase 5: MFA para Acceso Administrativo (Mes 2–3)
La interfaz de administración del servidor RADIUS es un objetivo de alto valor. Un atacante que comprometa el servidor RADIUS puede modificar las políticas de autenticación, extraer secretos compartidos y redirigir el tráfico de autenticación. Implemente MFA para todos los inicios de sesión administrativos en el servidor RADIUS y su sistema operativo subyacente. Restrinja el acceso de administración a una VLAN de administración fuera de banda dedicada. 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 (Mes 3–4)
Configure su servidor RADIUS para reenviar los registros de contabilidad (accounting logs) a su SIEM en tiempo real. Defina los siguientes umbrales de alerta como línea base:
| Alerta | Umbral | Severidad |
|---|---|---|
| Autenticaciones fallidas desde una sola MAC | >5 en 60 segundos | Alta |
| Pico en la tasa de Access-Reject | >200% de la línea base de 7 días | Media |
| Autenticación desde una nueva MAC en el SSID corporativo | Primera ocurrencia | Media |
| Vencimiento del certificado del servidor RADIUS | 90 / 30 / 7 días | Alta / Crítica / Crítica |
| Errores por discrepancia de secreto compartido | Cualquier ocurrencia | Alta |
Mejores Prácticas
Las siguientes recomendaciones representan el consenso de IEEE 802.1X, NIST SP 800-63B, PCI DSS v4.0 y los avisos de seguridad de los proveedores.
Gestión de Certificados. Cualquier implementación que utilice EAP-TLS o RadSec tiene certificados X.509 en la ruta de autenticación. El vencimiento de los certificados es la causa más común de fallas de autenticación repentinas y totales en las implementaciones de WiFi empresariales. Implemente la gestión automatizada del ciclo de vida de los certificados. Configure alertas de monitoreo a los 90, 30 y 7 días antes del vencimiento. Para los certificados del servidor RADIUS, utilice un tamaño de clave mínimo de RSA de 2048 bits o ECDSA de 256 bits, con algoritmos de firma SHA-256 o superiores. No utilice SHA-1.
Segmentación de Red. El servidor RADIUS debe residir en un segmento de red de administración dedicado, aislado tanto de la red de invitados como de la red corporativa general. El acceso a los puertos RADIUS (UDP 1812, 1813, TCP 2083 para RadSec) debe restringirse mediante ACL de firewall a las direcciones IP específicas de los dispositivos NAS registrados. No se permite el acceso directo de internet a los puertos RADIUS. Redundancy and High Availability. A single RADIUS server is a single point of failure for your entire network access control infrastructure. Deploy a minimum of two RADIUS servers in an active-passive or active-active configuration. For Hospitality deployments with 24/7 guest connectivity requirements, RADIUS server downtime is directly equivalent to guest WiFi downtime — a reputational and commercial risk.
WPA3 and 802.1X. WPA3-Enterprise mandates the use of 192-bit security mode for government and high-security deployments, requiring AES-256-GCMP for data encryption and HMAC-SHA-384 for authentication. For most enterprise deployments, WPA3-Enterprise with standard 128-bit security is a significant improvement over WPA2-Enterprise, particularly in combination with EAP-TLS. Retail environments processing card payments should treat WPA3-Enterprise adoption as a PCI DSS risk reduction measure.
Vendor Patch Cadence. Subscribe to security advisories from your RADIUS server vendor and your NAS device vendors. FreeRADIUS, Cisco, Microsoft, Aruba, and Ruckus all publish CVE notifications. Integrate these into your vulnerability management programme with a defined SLA: critical vulnerabilities (CVSS ≥ 9.0) patched within 72 hours; high vulnerabilities (CVSS 7.0–8.9) within 14 days.
Troubleshooting and Risk Mitigation
Common Failure Modes
Post-Patch Authentication Failures. After applying BlastRADIUS patches, some NAS devices may fail to authenticate if their firmware does not support Message-Authenticator. Symptoms: sudden increase in Access-Reject responses with no change in user credentials. Diagnosis: enable RADIUS debug logging and check for "Message-Authenticator required but not present" errors. Resolution: update NAS firmware or, as a temporary measure, configure the RADIUS server to accept requests without Message-Authenticator from specific NAS IPs while firmware updates are scheduled.
Certificate Validation Failures in EAP-TLS. Symptoms: clients receive "Authentication Failed" with no corresponding Access-Reject in RADIUS logs. Diagnosis: check the RADIUS server's certificate chain — is the issuing CA trusted by the client's supplicant? Is the server certificate within its validity period? Resolution: ensure the full certificate chain (leaf + intermediate + root) is configured on the RADIUS server. Push the root CA certificate to client devices via MDM or Group Policy.
RadSec TLS Handshake Failures. Symptoms: NAS devices fail to establish RadSec connections after configuration change. Diagnosis: check TLS version compatibility — older NAS firmware may not support TLS 1.2. Check mutual certificate authentication — both ends must trust each other's CA. Resolution: verify TLS version support in NAS firmware release notes; ensure NAS device certificates are issued by the same CA trusted by the RADIUS server.
Shared Secret Mismatch. Síntomas: todas las autenticaciones de un NAS específico fallan con errores de "Invalid authenticator". Diagnóstico: discrepancia de secreto compartido (shared secret) entre la configuración del NAS y la entrada del cliente del servidor RADIUS. Resolución: vuelva a ingresar el secreto compartido en ambos lados, asegurándose de que no haya espacios al final ni problemas de codificación de caracteres. Utilice copiar y pegar desde un gestor de secretos para evitar errores de transcripción.
Registro de Riesgos
| Riesgo | Probabilidad | Impacto | Control de Mitigación |
|---|---|---|---|
| Explotación de BlastRADIUS | Alta (sin parches) | Crítico | Parche + aplicación de Message-Authenticator |
| Fuerza bruta de secreto compartido | Media | Alto | Secretos aleatorios de 32 caracteres, rotación anual |
| Servidor RADIUS no autorizado | Media | Alto | Autenticación mutua EAP-TLS, fijación de certificados (certificate pinning) |
| Vencimiento del certificado del servidor RADIUS | Alta | Crítico | Monitoreo automatizado, alertas de 90 días |
| Relleno de credenciales (credential stuffing) a través de 802.1X | Media | Alto | Políticas de bloqueo de cuentas, alertas SIEM |
| Compromiso del servidor RADIUS | Baja | Crítico | MFA para acceso de administrador, segmentación de red |
ROI e Impacto de Negocio
Cuantificación del Riesgo
El caso financiero para el endurecimiento (hardening) de RADIUS es evidente cuando se compara con los costos de una brecha de seguridad. El costo promedio de una brecha de datos en el Reino Unido en 2024 fue de £3.58 millones de libras, incluyendo multas regulatorias, remediación, costos legales y daño reputacional. Para las organizaciones dentro del alcance de PCI DSS —que incluye prácticamente a todos los operadores de Retail y Hospitality que procesan pagos con tarjeta a través de WiFi— una brecha en el control de acceso a la red que exponga datos de tarjetahabientes desencadena una investigación forense obligatoria, posibles multas de las marcas de tarjetas y la posible suspensión de los privilegios de procesamiento de tarjetas.
Para las organizaciones de Healthcare , una brecha de GDPR que involucre datos de pacientes a los que se accedió a través de un servidor RADIUS comprometido conlleva multas de hasta el 4% de la facturación anual global según el Artículo 83(5). El historial de cumplimiento de la ICO demuestra que las fallas de seguridad de la red se tratan como negligencia, no como accidentes técnicos.
Puntos de Referencia de Costos de Implementación
Las siguientes estimaciones de costos son indicativas para una infraestructura empresarial de 500 dispositivos:
| Actividad de Endurecimiento | Costo Estimado | Cronograma |
|---|---|---|
| Parcheo (FreeRADIUS / NPS / ISE) | Solo mano de obra interna | 1–2 semanas |
| Auditoría y rotación de secretos compartidos | Mano de obra interna + licencia de gestor de secretos (~£2,000/año) | 2–4 semanas |
| Despliegue de PKI EAP-TLS | £15,000–£30,000 (herramientas + servicios profesionales) | 2–3 meses |
| Implementación de RadSec | Mano de obra interna + costos de certificados (~£1,500) | 4–6 semanas |
| Integración con SIEM y alertas | Depende del SIEM existente; £0–£10,000 | 4–8 semanas |
Inversión total de endurecimiento para una infraestructura mediana: aproximadamente £20,000–£45,000. Frente a un costo base de brecha de £3.58 millones de libras, el ROI ajustado al riesgo es convincente incluso con estimaciones bajas de probabilidad de brecha.
Beneficios Operativos Más Allá de la Seguridad
Una infraestructura RADIUS robustecida también ofrece beneficios operativos. Una autenticación confiable y bien monitoreada reduce los tickets de soporte técnico relacionados con la conectividad WiFi. Los datos de contabilidad de RADIUS, al integrarse 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 que tienen un valor comercial directo para los operadores de recintos en los entornos de Hospitality y Transport .
Para las organizaciones del sector público y de Healthcare , un programa documentado de robustecimiento de RADIUS proporciona evidencia de controles técnicos para las evaluaciones de Cyber Essentials Plus, ISO 27001 y NHS DSPT, lo que reduce la carga de trabajo de las auditorías y demuestra la debida diligencia ante los reguladores.
Definiciones clave
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo cliente-servidor definido en RFC 2865 que proporciona autenticación, autorización y contabilidad (AAA) centralizadas para el acceso a la red. Los servidores RADIUS validan las credenciales enviadas por los dispositivos de red (NAS) contra un almacén de identidad backend como Active Directory o LDAP.
Los equipos de TI se encuentran con RADIUS como el backend de autenticación para WiFi 802.1X, autenticación de puertos cableados, acceso VPN y gestión de dispositivos de red. Es el protocolo que decide quién accede a la red.
IEEE 802.1X
Un estándar IEEE para el control de acceso a la red basado en puertos que define la encapsulación de EAP sobre LAN (EAPOL). Proporciona un marco de autenticación tanto para redes cableadas como inalámbricas, requiriendo que los dispositivos se autentiquen antes de que se les conceda acceso a la red.
802.1X es el estándar que hace que la autenticación WiFi empresarial funcione. Cuando un miembro del personal se conecta a un SSID corporativo y se le solicitan credenciales, 802.1X es el marco que orquesta ese intercambio, con RADIUS como backend.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Un método EAP que utiliza certificados X.509 para la autenticación mutua entre el cliente y el servidor RADIUS. Ambas partes deben presentar certificados válidos, eliminando por completo las contraseñas del intercambio de autenticación.
EAP-TLS es el estándar de oro para la autenticación WiFi empresarial. Es inmune al phishing de credenciales y a los ataques de fuerza bruta. El requisito operativo es una infraestructura PKI para emitir y gestionar certificados de cliente.
RadSec (RADIUS over TLS)
Un protocolo definido en RFC 6614 que encapsula paquetes RADIUS dentro de una sesión TLS sobre el puerto TCP 2083. Proporciona cifrado a nivel de capa de transporte, autenticación mutua de certificados y protección contra ataques de reproducción para el tráfico RADIUS.
RadSec es necesario para cualquier tráfico RADIUS que cruce un límite de red no confiable: enlaces WAN, conexiones a internet o infraestructura de red compartida. Es el reemplazo correcto para el RADIUS estándar sobre UDP en implementaciones multisitio.
BlastRADIUS (CVE-2024-3596)
Un ataque de intermediario (man-in-the-middle) revelado en julio de 2024 que explota la ausencia de protección de integridad en los paquetes Access-Request de RADIUS. Utilizando técnicas de colisión de prefijo elegido de MD5, un atacante puede falsificar una respuesta Access-Accept, otorgando acceso a la red a un usuario no autenticado.
BlastRADIUS afecta a todas las principales implementaciones de RADIUS, incluyendo FreeRADIUS, Cisco ISE y Microsoft NPS. Las organizaciones que no hayan aplicado los parches lanzados en julio de 2024 siguen expuestas a este ataque.
Message-Authenticator
Un atributo RADIUS (Atributo 80) que proporciona protección de integridad HMAC-MD5 sobre todo el paquete RADIUS. Cuando está presente en un Access-Request, evita el ataque de modificación de paquetes utilizado en BlastRADIUS.
Forzar Message-Authenticator en todos los paquetes Access-Request es la principal mitigación para BlastRADIUS. Debe configurarse tanto en el servidor RADIUS (para requerir el atributo) como en el dispositivo NAS (para incluir el atributo en las solicitudes).
NAS (Network Access Server)
En la terminología de RADIUS, el NAS es el dispositivo de red (normalmente un punto de acceso WiFi, switch o concentrador VPN) que actúa como el cliente RADIUS. Intercepta las solicitudes de conexión de los dispositivos finales y reenvía las solicitudes de autenticación al servidor RADIUS.
Los dispositivos NAS son los clientes RADIUS en una implementación. Los secretos compartidos se configuran por NAS. La mitigación de BlastRADIUS requiere actualizaciones de firmware en los dispositivos NAS, así como parches en el servidor RADIUS.
PEAP (Protected Extensible Authentication Protocol)
Un método EAP que establece un túnel TLS utilizando un certificado del lado del servidor antes de transmitir el método de autenticación interno (normalmente MSCHAPv2). Proporciona autenticación mutua y protege las credenciales contra la interceptación.
PEAP-MSCHAPv2 es el método de autenticación WiFi empresarial más implementado. Cumple con PCI DSS y es operativamente más simple que EAP-TLS porque no requiere certificados de cliente. Sin embargo, es vulnerable a ataques de servidores RADIUS falsos si no se fuerza la validación de certificados del lado del cliente.
Shared Secret
Una clave precompartida configurada tanto en el servidor RADIUS como en cada dispositivo NAS. Se utiliza para generar el campo Response Authenticator y para ofuscar el atributo User-Password. No es una contraseña para los usuarios finales; es una credencial de autenticación de servidor a servidor.
Los secretos compartidos débiles o estáticos son una de las vulnerabilidades más comunes de RADIUS. Un atacante que capture tráfico RADIUS puede realizar un ataque de fuerza bruta sin conexión contra un secreto compartido débil. La longitud mínima recomendada es de 32 caracteres, generados aleatoriamente.
PCI DSS (Payment Card Industry Data Security Standard)
Un conjunto de estándares de seguridad exigidos por las principales marcas de tarjetas (Visa, Mastercard, Amex) para las organizaciones que procesan, almacenan o transmiten datos de titulares de tarjetas. La versión 4.0, vigente a partir de marzo de 2024, incluye requisitos específicos para el control de acceso a la red y la autenticación sólida.
Las organizaciones de comercio minorista y hotelería con terminales de punto de venta conectadas a WiFi están dentro del alcance de PCI DSS. Las vulnerabilidades del servidor RADIUS que podrían permitir el acceso no autorizado a la red a entornos de datos de titulares de tarjetas representan un riesgo directo de cumplimiento.
Ejemplos resueltos
Un grupo hotelero de 12 propiedades y 350 habitaciones utiliza un servidor RADIUS centralizado alojado en el centro de datos de su oficina central. Cada propiedad se conecta a través de una WAN MPLS compartida. Una auditoría de seguridad ha señalado que el tráfico RADIUS no está cifrado a través de la WAN, los secretos compartidos son cadenas de 8 caracteres configuradas durante el despliegue inicial hace cinco años, y el servidor RADIUS ejecuta FreeRADIUS 3.0.21. El grupo procesa pagos con tarjeta a través de terminales POS conectados a WiFi en sus instalaciones de restaurante y spa. ¿Cuál es la prioridad de remediación y la secuencia de implementación?
La secuencia de remediación debe ordenarse por la gravedad del riesgo y la velocidad de implementación. Paso 1 (inmediato, dentro de las 72 horas): Parchear FreeRADIUS a 3.2.5 o 3.0.27. Esto aborda BlastRADIUS y aplica Message-Authenticator de forma predeterminada. Simultáneamente, verificar las versiones de firmware de los puntos de acceso en las 12 propiedades y programar actualizaciones de firmware para cualquier dispositivo NAS que no sea compatible con Message-Authenticator. Paso 2 (semana 1–2): Rotar todos los secretos compartidos. Generar secretos aleatorios de 32 caracteres usando openssl rand -base64 32 para cada uno de los registros NAS de las 12 propiedades. Almacenar en HashiCorp Vault o equivalente. Documentar la fecha de rotación. Paso 3 (mes 1–2): Implementar RadSec en la ruta WAN. Configurar el servidor FreeRADIUS para aceptar conexiones RadSec en el puerto TCP 2083. Emitir certificados TLS desde una CA interna para los dispositivos NAS de cada propiedad. Actualizar las reglas del firewall para permitir TCP 2083 desde los rangos de IP de los NAS de las propiedades hacia el servidor RADIUS. Deshabilitar UDP 1812/1813 de las interfaces orientadas a la WAN una vez que se confirme que RadSec está operativo. Paso 4 (mes 2–3): Para el SSID de WiFi de los POS dentro del alcance de PCI DSS, migrar de PEAP-MSCHAPv2 a EAP-TLS. Desplegar una PKI interna (Microsoft ADCS o el motor PKI de HashiCorp Vault). Emitir certificados de cliente a las terminales POS a través de MDM. Actualizar la política de RADIUS para requerir EAP-TLS para el SSID de los POS. Paso 5 (mes 3): Integrar los registros de contabilidad de RADIUS en el SIEM. Configurar alertas para picos de autenticación fallidos y vencimiento de certificados.
Una cadena minorista regional con 45 tiendas utiliza WPA2-Personal (clave precompartida) para el WiFi del personal y una red abierta para el WiFi de los clientes. El director de TI desea migrar el WiFi del personal a la autenticación 802.1X utilizando Microsoft NPS como servidor RADIUS, integrado con Active Directory. Las tiendas tienen una mezcla de puntos de acceso Aruba y Cisco. La cadena está dentro del alcance de PCI DSS. ¿Qué arquitectura deberían desplegar y cuáles son las decisiones clave de configuración?
La arquitectura recomendada es 802.1X con PEAP-MSCHAPv2 como método EAP inicial, con una hoja de ruta documentada hacia EAP-TLS. El servidor NPS debe desplegarse en un par redundante (primario + secundario) en el centro de datos central, con configuración de proxy RADIUS en los puntos de acceso para realizar la conmutación por error de forma automática. Decisiones de configuración: (1) Política de red de NPS: crear una política que coincida con el SSID del personal con PEAP-MSCHAPv2, requiriendo la membresía de grupo en un grupo de seguridad de AD (por ejemplo, 'WiFi-Staff-Access'). Establecer el tiempo de espera de la sesión en 8 horas para forzar la reautenticación. (2) Certificado: desplegar un certificado de servidor NPS desde una CA interna de Microsoft ADCS. Distribuir el certificado de la CA raíz a todos los dispositivos del personal a través de Directiva de grupo (Windows) y MDM (iOS/Android). (3) Configuración del suplicante: configurar los dispositivos Windows a través de Directiva de grupo (Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas de red inalámbrica). Para dispositivos iOS y Android, utilizar un perfil de MDM. Aplicar la validación del certificado del servidor; no permitir que los usuarios acepten certificados arbitrarios. (4) Configuración del punto de acceso: en Aruba, configurar el servidor RADIUS en Autenticación > Servidores. Establecer el secreto compartido en una cadena aleatoria de 32 caracteres. Habilitar RadSec si el firmware de Aruba lo admite (AOS 8.9+). En Cisco, configurar en Seguridad > AAA > RADIUS. (5) Registro de NPS: habilitar el registro de contabilidad de NPS en una base de datos de SQL Server. Configurar un período de retención de registros de un mínimo de 90 días para el cumplimiento de PCI DSS. (6) Post-migración: deshabilitar WPA2-Personal en el SSID del personal. Conservarlo únicamente como un SSID de emergencia con una PSK compleja almacenada en el administrador de secretos, para su uso exclusivo cuando NPS no esté disponible.
Preguntas de práctica
Q1. Tu organización opera un servidor FreeRADIUS 3.0.21 que soporta autenticación 802.1X para 800 dispositivos del personal en un campus de un solo sitio. El servidor RADIUS está en la misma VLAN de administración que todos los puntos de acceso. Una prueba de penetración ha identificado que los puntos de acceso están enviando paquetes Access-Request sin el atributo Message-Authenticator. El equipo de seguridad quiere aplicar Message-Authenticator de inmediato, pero el equipo de operaciones de red está preocupado por interrumpir la autenticación para 800 usuarios. ¿Cómo secuenciarías la remediación para minimizar la interrupción del servicio?
Sugerencia: Considera la diferencia entre que el servidor RADIUS requiera Message-Authenticator y que los dispositivos NAS lo envíen. Estos son dos cambios de configuración independientes con diferentes perfiles de riesgo.
Ver respuesta modelo
La secuencia correcta es: (1) Primero, actualiza FreeRADIUS a la versión 3.2.5. Esta versión exige Message-Authenticator de forma predeterminada, pero incluye un modo de compatibilidad que registra una advertencia en lugar de rechazar los paquetes que carecen del atributo. Esto te permite aplicar el parche sin interrumpir la autenticación de inmediato. (2) Audita las versiones de firmware de los puntos de acceso. Identifica qué modelos y versiones de firmware admiten Message-Authenticator en los paquetes Access-Request. (3) Actualiza el firmware de los puntos de acceso en lotes, comenzando con un grupo piloto de 50 dispositivos. Verifica que la autenticación siga funcionando después de cada lote. (4) Una vez que se confirme que todos los puntos de acceso están enviando Message-Authenticator, habilita la aplicación estricta en el servidor FreeRADIUS (require_message_authenticator = yes en clients.conf). (5) Monitorea los registros de RADIUS para detectar cualquier advertencia restante de "Message-Authenticator missing", lo que indicaría dispositivos NAS que no recibieron la actualización de firmware. El principio clave es que puedes actualizar el servidor primero sin romper nada, porque el modo de compatibilidad permite un período de transición. Exigir el rechazo estricto en el servidor debe ser el último paso, después de que todos los dispositivos NAS hayan sido actualizados.
Q2. El operador de un centro de conferencias utiliza un único servidor RADIUS que admite tanto el SSID del personal corporativo (802.1X con PEAP-MSCHAPv2) como el WiFi para invitados de eventos (Captive Portal con MAC Authentication Bypass). El gerente de TI pregunta si la instancia de RADIUS de WiFi para invitados debe protegerse con el mismo estándar que la instancia de RADIUS corporativa, dado que los invitados no se autentican con credenciales corporativas. ¿Cuál es tu recomendación?
Sugerencia: Considera los vectores de ataque que se aplican a MAC Authentication Bypass frente a la autenticación basada en EAP, y el riesgo de movimiento lateral entre las instancias de RADIUS de invitados y corporativas.
Ver respuesta modelo
La instancia de RADIUS de WiFi para invitados requiere protección, pero los controles específicos difieren de la instancia corporativa. El parche BlastRADIUS se aplica por igual: la vulnerabilidad afecta al servidor RADIUS independientemente del método de autenticación utilizado por los clientes. La higiene de la clave secreta compartida se aplica por igual: una clave secreta compartida débil entre el controlador del Captive Portal de invitados y el servidor RADIUS es explotable independientemente de si se utiliza EAP. El riesgo adicional clave es el servidor RADIUS compartido: si las solicitudes de autenticación de SSID de invitados y corporativas son manejadas por el mismo proceso de servidor RADIUS, una vulnerabilidad en la ruta de RADIUS de invitados podría usarse para pivotar hacia la política de autenticación corporativa. La arquitectura recomendada es ejecutar instancias de RADIUS separadas (o como mínimo servidores virtuales separados dentro de FreeRADIUS) para la autenticación de invitados y corporativa, con claves secretas compartidas separadas y conjuntos de políticas independientes. Esto proporciona un aislamiento tal que un compromiso de la ruta de RADIUS de invitados no expone las credenciales corporativas. Específicamente para la instancia de invitados: aplica el parche para BlastRADIUS, rota las claves secretas compartidas y asegúrate de que la instancia de RADIUS de invitados no tenga acceso al Active Directory corporativo. Los requisitos de EAP-TLS y RadSec son menos relevantes para una implementación de Captive Portal, pero RadSec aún debe considerarse si el controlador del Captive Portal está en un segmento de red diferente al del servidor RADIUS.
Q3. Un fideicomiso de atención médica planea migrar su WiFi clínico de WPA2-Personal a autenticación 802.1X. El fideicomiso cuenta con 1,200 dispositivos clínicos que incluyen laptops Windows, tabletas iOS y dispositivos de mano Android. El CISO quiere EAP-TLS como estado objetivo. El director de TI está preocupado por la complejidad de la implementación de PKI y propone PEAP-MSCHAPv2 como una solución permanente. ¿Cómo asesoras al CISO y al director de TI, y cuál es la ruta de implementación recomendada?
Sugerencia: Considera el modelo de amenazas específico para un entorno de atención médica: ¿cuáles son las consecuencias de un compromiso de credenciales y cómo aborda EAP-TLS los riesgos que PEAP-MSCHAPv2 no cubre?
Ver respuesta modelo
El instinto del CISO es correcto, pero la preocupación del director de TI es válida. El consejo recomendado es: implementar PEAP-MSCHAPv2 ahora como una solución provisional, con una hoja de ruta comprometida a 12 meses hacia EAP-TLS. La razón para no aceptar PEAP-MSCHAPv2 como una solución permanente en el sector salud es: (1) PEAP-MSCHAPv2 es vulnerable a ataques de servidores RADIUS falsos si no se aplica la validación de certificados del lado del cliente. En un entorno de atención médica donde el personal clínico puede conectar dispositivos personales, aplicar la configuración del suplicante de manera consistente en 1,200 dispositivos es un desafío operativo. (2) Las credenciales de MSCHAPv2, si se capturan a través de un ataque de RADIUS falso, se pueden descifrar fuera de línea utilizando herramientas como hashcat. En un contexto de atención médica, esas credenciales probablemente también brinden acceso a los sistemas clínicos. (3) Las evaluaciones de NHS DSPT y CQC esperan cada vez más controles de autenticación sólidos para el acceso a la red clínica. EAP-TLS proporciona una posición de evidencia de auditoría más sólida. La ruta de implementación: Mes 1-2: Implementar PEAP-MSCHAPv2 con validación forzada de certificados de servidor a través de perfiles MDM en los 1,200 dispositivos. Mes 3-6: Implementar Microsoft ADCS como la infraestructura PKI. Inscribir dispositivos Windows a través de la autoinscripción de directivas de grupo. Mes 6-9: Inscribir dispositivos iOS y Android a través de perfiles de certificado MDM. Mes 9-12: Migrar la política de SSID clínico de PEAP a EAP-TLS. Retener PEAP como alternativa para cualquier dispositivo que falle en la inscripción de certificados, con un monitoreo mejorado. Para obtener más información sobre la arquitectura de seguridad de redes clínicas, la guía de WiFi en Hospitales proporciona un contexto de implementación relevante.
Continúe leyendo esta serie
Tres SSIDs para gobernarlos a todos: guía de configuración de WiFi para invitados, personal e IoT
Esta guía de referencia técnica autorizada proporciona un plan paso a paso para implementar una arquitectura WiFi de tres SSIDs. Explica cómo segmentar el tráfico de invitados, personal e IoT utilizando captive portals, 802.1X RADIUS y PSK por dispositivo (xPSK) para optimizar el rendimiento y garantizar el cumplimiento de PCI DSS.
Integración de CommScope Ruckus con Purple WiFi: Guía de instalación y configuración
Esta guía de referencia técnica proporciona un manual de configuración definitivo para integrar arquitecturas de CommScope Ruckus con Purple WiFi. Detalla implementaciones paso a paso para Captive Portals de Guest WiFi, WiFi seguro para el personal a través de 802.1X y aislamiento de red multi-inquilino mediante Dynamic PSK de Ruckus.
Integración de Access Points Allied Telesis con Purple WiFi
Esta guía proporciona un manual de configuración completo para integrar los access points de la serie TQ de Allied Telesis con Purple WiFi. Cubre la redirección de Captive Portal externo, la autenticación RADIUS 802.1X y el direccionamiento dinámico de VLAN mediante claves privadas precompartidas (PPSK) para despliegues multi-inquilino seguros.