Autenticación RADIUS con MFA: proteja cada punto de acceso a la red

RADIUS —el protocolo que gestiona silenciosamente la autenticación de la mayoría de las VPN corporativas, redes Wi-Fi e infraestructuras de red— se diseñó en otra época. Cumple su función con fiabilidad: un dispositivo de red envía credenciales a un servidor RADIUS, el servidor las verifica contra un directorio, y se concede o deniega el acceso. Lo que no hace es comprobar que la persona que introduce esas credenciales sea realmente quien dice ser. Una contraseña robada vale exactamente igual que una legítima.

Añadir MFA a RADIUS cierra esa brecha. En lugar de sustituir su infraestructura existente, un proxy RADIUS se sitúa entre sus dispositivos de red y su directorio, exigiendo un segundo factor en cada solicitud de autenticación antes de emitir un Access-Accept.

Respuesta rápida

RADIUS (Remote Authentication Dial-In User Service) es la columna vertebral del control de acceso a la red en la mayoría de los entornos empresariales, gestionando la autenticación de VPN, Wi-Fi corporativo, dispositivos de acceso a la red, NPS y puertas de enlace VDI. El propio protocolo, definido en la RFC 2865, se diseñó décadas antes de que los ataques basados en credenciales se convirtieran en la norma. Añadir MFA sobre RADIUS hoy significa insertar un segundo paso de verificación entre el dispositivo de red y su directorio, sin sustituir su infraestructura existente. Protectimus funciona como un proxy RADIUS: su firewall Cisco, su puerta de enlace Fortinet o su firewall Palo Alto siguen hablando RADIUS exactamente igual que antes, mientras se aplica un segundo factor en la capa de proxy antes de emitir un RADIUS Access-Accept.

Datos clave

Las credenciales son el vector de ataque nº 1

FACT

Los ataques basados en credenciales —incluidos el phishing, el credential stuffing y el password spraying— figuran de forma constante entre los principales vectores de acceso inicial en las brechas de red, siendo los endpoints VPN un objetivo primario.

AAL2 exige MFA

NIST

El Nivel de Garantía de Autenticador 2 (AAL2) de NIST SP 800-63B exige explícitamente autenticación multifactor para cualquier acceso de red a sistemas sensibles.

(NIST Special Publication 800-63B)

La infraestructura VPN está bajo ataque

CISA

El aviso de CISA sobre seguridad VPN señala que los atacantes se dirigen habitualmente a la infraestructura de acceso remoto precisamente porque a menudo carece de un segundo factor de autenticación.

(CISA’s advisories)

Ventajas clave

RADIUS MFA icon

No requiere cambios de infraestructura

Protectimus funciona como un proxy RADIUS; sus puertas de enlace VPN, controladores inalámbricos y conmutadores de red existentes conservan su configuración.

On-Premise MFA Platform – Security feature: A Cluster-Based, Fault-Tolerant System

Implementación rápida

Muchas organizaciones pueden implementar RADIUS MFA en un solo día laborable, según la complejidad de la infraestructura y los requisitos de integración.

MFA for RADIUS icon

Independiente del proveedor

Integraciones documentadas y probadas con Cisco ASA/FTD, Juniper, Fortinet FortiGate, Palo Alto GlobalProtect, SonicWall, Check Point, F5 y muchas otras plataformas.

MFA for Windows and RDP icon

Sincronización completa con AD/LDAP

El aprovisionamiento de usuarios, las políticas de grupo y las búsquedas en el directorio se obtienen de su Active Directory o LDAP existente.

On-premise MFA platform icon

On-premises o en la nube

Existen opciones de implementación que permiten a las organizaciones elegir la arquitectura que mejor se adapte a sus requisitos de seguridad y operativos.

VPN MFA icon

Diseñado para VPN

y otros escenarios de acceso remoto basados en RADIUS.

Qué es la autenticación RADIUS y por qué necesita MFA

RADIUS es un protocolo cliente/servidor que centraliza la autenticación, autorización y registro (AAA) para el acceso a la red. Cuando un usuario se conecta a una VPN, se autentica en el Wi-Fi corporativo o inicia sesión en un conmutador a través de una interfaz de gestión, el dispositivo de red (llamado NAS, Network Access Server) envía un paquete Access-Request al servidor RADIUS. Ese servidor valida las credenciales y responde con uno de tres mensajes: Access-Accept (permitir el acceso), Access-Reject (denegar) o Access-Challenge (solicitar información adicional, como un OTP).

Es un protocolo ordenado y probado a lo largo del tiempo. Pero su diseño original asumía que una combinación válida de usuario y contraseña era prueba suficiente de identidad. En 2026, esa suposición es insostenible.

Por qué las contraseñas por sí solas no protegen los servicios autenticados por RADIUS

El credential stuffing es el ataque que quita el sueño a los equipos de seguridad de red. Los atacantes compran o recopilan listas de pares usuario/contraseña filtrados —miles de millones de ellos se comercian libremente en foros criminales— y automatizan los intentos de inicio de sesión contra los endpoints VPN. La mayoría de las puertas de enlace VPN no tienen políticas de bloqueo lo bastante estrictas como para detener los ataques lentos y sostenidos. Incluso una tasa de éxito del 0,5% frente a una lista de 50.000 credenciales entrega a los atacantes 250 sesiones VPN válidas.

El password spraying es la variante más silenciosa: en lugar de atacar una sola cuenta, los atacantes prueban una contraseña común (como Autumn2024!) contra miles de cuentas. Elude la mayoría de los umbrales de bloqueo de cuentas y resulta casi invisible en los registros.

Más allá de los ataques indiscriminados, los atacantes dirigidos usan el phishing para recolectar credenciales de dominio y luego pivotan directamente hacia el acceso VPN o Wi-Fi, eludiendo por completo las defensas perimetrales.

RADIUS en sí no tiene ningún mecanismo para exigir un segundo factor. Transmite las credenciales a un directorio backend, recibe un Accept/Reject y ahí termina la conversación. Una forma habitual de añadir MFA a RADIUS es desplegar un proxy RADIUS que intercepta el Access-Request, valida la contraseña con el sistema ascendente y luego exige un desafío de OTP antes de emitir un Access-Accept.

Cómo añade Protectimus la MFA a la autenticación RADIUS

La arquitectura es deliberadamente sencilla. El servidor RADIUS de Protectimus se sitúa entre su dispositivo de red y su backend RADIUS/AD existente como RADIUS proxy. El dispositivo de red no sabe que algo ha cambiado; simplemente envía su Access-Request a una dirección IP distinta. Desde el lado de AD, el servidor de Protectimus se autentica contra el directorio usando la contraseña del usuario exactamente igual que siempre.

Flujo de autenticación

Usuario
Cliente VPN / Wi-Fi
Access-Request (usuario + contraseña)
Dispositivo de red
Cisco ASA / FortiGate / UniFi, etc.
RADIUS Access-Request
Servidor RADIUS de Protectimus
Valida la contraseña vía AD / LDAP

Devuelve Access-Challenge (OTP)
El usuario introduce el OTP
Servidor RADIUS de Protectimus
Valida el OTP

Devuelve Access-Accept
Dispositivo de red Sesión de usuario establecida

Paso 1: comprobación de credenciales. Protectimus reenvía la contraseña del usuario a Active Directory o LDAP para la autenticación principal. Si la contraseña falla, la solicitud se rechaza de inmediato. No se emite ningún aviso de MFA para las contraseñas fallidas, lo que evita los ataques de enumeración.

Paso 2: desafío de MFA. Tras una comprobación de contraseña exitosa, Protectimus envía un Access-Challenge de vuelta al dispositivo de red con un aviso para el segundo factor. El usuario introduce su código TOTP desde la app de MFA, un token OTP hardware, o un OTP por chatbot/SMS/email.

Paso 3: aceptar o rechazar. Si el segundo factor se valida, se emite un Access-Accept. Si no, un Access-Reject. El dispositivo de red aplica el resultado.

Una nota técnica importante: el flujo de Access-Challenge requiere que el dispositivo NAS admita el challenge/response de RADIUS. La mayoría de los clientes VPN modernos (Cisco AnyConnect, Fortinet SSL VPN, Palo Alto GlobalProtect) lo gestionan de forma nativa. Para los dispositivos que no admiten el Access-Challenge de RADIUS, Protectimus ofrece el modo Inline. En este modo, los usuarios introducen su contraseña y el OTP en un único campo usando un separador configurable (por ejemplo, contraseña,otp). Este enfoque permite aplicar la MFA incluso en sistemas antiguos que solo admiten un único intercambio de autenticación.

Métodos de MFA compatibles con RADIUS

Los distintos escenarios de acceso a la red requieren distintos métodos de segundo factor. Un cliente de túnel VPN no tiene interfaz de navegador. Un suplicante Wi-Fi 802.1X corporativo tiene aún menos. La siguiente tabla asocia los métodos con los escenarios.

MétodoCómo funcionaIdeal paraNotas
App autenticadora (TOTP)Código rotativo de 30 segundos desde una app autenticadoraVPN y otros servicios compatibles protegidos por RADIUSFunciona con prácticamente cualquier cliente RADIUS; no requiere internet tras el registro
Tokens hardware (TOTP)Código rotativo de 30 segundos desde un dispositivo TOTP físicoEntornos air-gapped, usuarios sin smartphoneCompatible con Protectimus Two, Slim NFC, Flex, Shark y tokens de terceros compatibles con OATH
SMS OTPCódigo de 6 dígitos enviado por SMSVPN y otros servicios compatibles protegidos por RADIUSRequiere señal móvil; funciona con el modo Inline
Email OTPCódigo de 6 dígitos enviado por emailVPN y otros servicios compatibles protegidos por RADIUSAdecuado donde el SMS no está disponible
Chatbot OTPOTP entregado mediante Telegram, Viber o Facebook MessengerVPN y otros servicios compatibles protegidos por RADIUSSin coste de SMS ni dependencia del operador móvil

Específicamente para VPN: el TOTP (mediante app o token hardware) y el OTP por chatbot/SMS/email funcionan tanto en modo challenge/response como en modo Inline.

Clientes RADIUS y equipos de red compatibles

Protectimus dispone de integraciones documentadas y probadas con el siguiente equipo de red. La guía completa de integración RADIUS MFA incluye la configuración paso a paso para cada uno.

Proveedor

Producto / función

Tipo de acceso

Cisco

ASA, FTD, AnyConnect VPN

VPN

Cisco

Switches Catalyst (inicio de sesión AAA)

Acceso administrativo

Juniper

SRX, Pulse Connect Secure

VPN

Fortinet

FortiGate SSL VPN

VPN

Palo Alto

GlobalProtect VPN

VPN

SonicWall

NetExtender, Mobile Connect

VPN

Check Point

Mobile Access blade

VPN

F5

APM (Access Policy Manager)

VPN / proxy de aplicaciones

Citrix

ADC (NetScaler)

VPN / proxy de aplicaciones

Ubiquiti

UniFi Controller (Guest Portal)

Wi-Fi de invitados

Array Networks

AG Series SSL VPN

VPN

Esta lista cubre las implementaciones más comunes. Cualquier dispositivo que envíe solicitudes RADIUS estándar según la RFC 2865 funcionará, aunque no figure aquí.

Nota: algunas implementaciones basadas en RADIUS aún no están incluidas en nuestras integraciones documentadas. Como Protectimus funciona como un proxy RADIUS basado en estándares, otras arquitecturas RADIUS —incluidas las implementaciones basadas en FreeRADIUS o Microsoft NPS— también pueden ser compatibles. Si está planificando una de estas implementaciones, contacte con nuestro equipo para hablar de su entorno concreto.

RADIUS MFA para VPN

La VPN es, con diferencia, la implementación de RADIUS MFA más habitual, y también la más crítica desde el punto de vista de la seguridad. Una sesión VPN comprometida otorga a un atacante la misma posición en la red que un empleado remoto legítimo, con acceso a recursos compartidos de archivos, aplicaciones web internas, bases de datos y rutas de movimiento lateral.

Cómo funciona la MFA en VPN (sin navegador)

Cuando un usuario se conecta mediante Cisco AnyConnect o el cliente SSL VPN de Fortinet, la conexión se inicia a nivel del sistema operativo o de la app cliente. No hay navegador, ni JavaScript, ni URI de redirección. El cliente VPN envía las credenciales directamente al NAS, que las reenvía como un Access-Request de RADIUS.

Con el soporte de challenge/response habilitado en el cliente VPN, el flujo funciona exactamente como se describe en la sección de arquitectura: el usuario ve un segundo aviso (“Introduzca su OTP”) en la interfaz del cliente VPN tras introducir su contraseña. La mayoría de los clientes VPN modernos representan correctamente este campo, y los usuarios lo encuentran intuitivo.

Para los clientes VPN antiguos que no admiten el Access-Challenge de RADIUS, Protectimus ofrece el modo Inline. Los usuarios introducen su contraseña y el OTP en un único campo de autenticación usando un separador configurado. Esto permite a las organizaciones implementar la MFA sin sustituir su infraestructura VPN existente.

Asegúrese de que la puerta de enlace VPN pueda alcanzar siempre el servidor RADIUS de Protectimus (UDP 1812/1813 si se usa el registro contable), independientemente de la configuración de enrutamiento de la VPN.

Consulte la guía completa de integración RADIUS MFA y MFA for Cisco AnyConnect VPN para conocer los pasos de configuración específicos de cada proveedor.

Para obtener una descripción general completa de la implementación de MFA en Cisco, Fortinet, Palo Alto, SonicWall, OpenVPN y otras puertas de enlace VPN, consulte la solución Protectimus MFA para VPN.

RADIUS MFA para el acceso a redes inalámbricas

Aunque la VPN es la implementación de RADIUS MFA más habitual, las organizaciones también usan RADIUS para proteger el acceso a redes inalámbricas. El flujo exacto de autenticación depende de la infraestructura inalámbrica y del método de autenticación en uso.

Protectimus admite escenarios de acceso inalámbrico que se integran con la RADIUS-based authentication, incluidas implementaciones de Wi-Fi de invitados como el Ubiquiti UniFi Guest Portal. En estos entornos, los usuarios se autentican mediante una contraseña de un solo uso entregada por SMS, chatbot, email, o un TOTP generado por una app autenticadora o un token hardware, según la implementación.

Para entornos de Wi-Fi de invitados, Protectimus puede desplegarse con el servicio en la nube de Protectimus o con la Protectimus On-Premise Platform. Las solicitudes de autenticación se validan a través de la plataforma de Protectimus antes de conceder el acceso a la red, mientras los administradores conservan capacidades centralizadas de registro y gestión de usuarios.

Al planificar la MFA para redes inalámbricas empresariales, verifique que su infraestructura inalámbrica y su flujo de autenticación admiten el método de autenticación RADIUS requerido. Las capacidades de autenticación pueden variar según el controlador inalámbrico, la puerta de enlace de acceso o la implementación del portal cautivo.

Opciones de implementación

RADIUS MFA en la nube (SaaS)

El servidor RADIUS de Protectimus se instala dentro de su red y se configura para comunicarse con el servicio en la nube de Protectimus. Sus dispositivos de red envían las solicitudes de autenticación RADIUS al servidor RADIUS local de Protectimus, que valida las credenciales principales del usuario contra su Active Directory o LDAP y verifica el segundo factor a través del servicio en la nube de Protectimus. No se requiere ninguna plataforma de MFA on-premises, lo que hace que esta implementación sea adecuada para las organizaciones que desean una implementación rápida y una infraestructura mínima.

Servidor RADIUS MFA on-premises

El servidor RADIUS de Protectimus y la Protectimus On-Premise Platform se instalan en servidores estándar Windows Server o Linux dentro de su red. El servidor RADIUS valida las credenciales principales contra Active Directory o LDAP y verifica el segundo factor usando la plataforma local de Protectimus. Todas las solicitudes de autenticación permanecen dentro de su infraestructura, lo que hace que esta implementación sea adecuada para organizaciones con requisitos de residencia de datos, entornos air-gapped o políticas de seguridad internas que prohíben los servicios de autenticación en la nube.

Configuración de alta disponibilidad

En ambos modos de implementación, Protectimus admite configuraciones de alta disponibilidad. Las organizaciones pueden desplegar instancias primarias y secundarias del servidor RADIUS de Protectimus. Los dispositivos de red pueden configurarse con ambas IP de servidor usando el failover RADIUS estándar (el servidor secundario se usa si el primario no responde dentro del período de tiempo de espera configurado). La mayoría de los firewalls empresariales, puertas de enlace VPN y clientes RADIUS admiten esto de forma nativa.

En las implementaciones en la nube, las instancias redundantes del servidor RADIUS de Protectimus se conectan al servicio en la nube de Protectimus. En las implementaciones on-premises, la alta disponibilidad también puede extenderse a la propia Plataforma Protectimus desplegándola como un clúster tras un balanceador de carga gestionado por el cliente. Las organizaciones también pueden desplegar componentes en ubicaciones separadas para reducir aún más el riesgo de interrupción del servicio.

Requisitos del sistema e integración

Componente

Requisito

Opciones de implementación

Windows, Linux, Docker

Puertos RADIUS

UDP 1812 (autenticación), UDP 1813 (registro contable)

Protocolo IP

Compatible con IPv4 e IPv6

Integración con directorios

Directorios Active Directory y LDAP

Dispositivos de red

Cualquier cliente RADIUS compatible con RFC 2865

Java

Java es necesario para las instalaciones en Windows. Si Java no está instalado, el instalador puede instalarlo automáticamente. Consulte la documentación actual de Protectimus para conocer las versiones compatibles.

Reglas de firewall

UDP 1812 abierto entre los clientes RADIUS y el servidor RADIUS de Protectimus; acceso LDAP/LDAPS (389/636) desde el servidor RADIUS de Protectimus hasta Active Directory o LDAP, si se usa para la autenticación principal.

Paso a paso: cómo configurar RADIUS MFA en 5 pasos

Paso 1 — implemente el servidor RADIUS de Protectimus.Elija la implementación en la nube o on-premises. Para la nube, cree una cuenta en service.protectimus.com, active el acceso a la API e instale el servidor RADIUS de Protectimus dentro de su red. Para on-premises, descargue el paquete instalador, ejecútelo en su servidor Windows o Linux de destino, e instale tanto el servidor RADIUS de Protectimus como la Protectimus On-Premise Platform.

Paso 2 — configure su conexión AD/LDAP.In the Protectimus RADIUS Server configuration file, add your domain controller address, bind account, search base, and authentication provider settings. Test the connection to confirm that the Protectimus RADIUS Server can communicate with your directory service.

Paso 3 — añada su dispositivo de red como cliente RADIUS. En la configuración del servidor RADIUS de Protectimus, registre la dirección IP y el secreto compartido de cada dispositivo NAS, como su puerta de enlace VPN, firewall u otro dispositivo de red compatible. Este es el mismo secreto compartido que configurará en el lado del dispositivo.

Paso 4 — dirija el dispositivo de red hacia Protectimus. En su Cisco ASA, Fortinet, Palo Alto u otro dispositivo compatible, cambie la IP del servidor RADIUS al servidor RADIUS de Protectimus. Configure el secreto compartido para que coincida con el que configuró en el Paso 3 y configure el puerto UDP 1812 para la autenticación RADIUS.

Paso 5 — registre a los usuarios y pruebe. Registre un grupo piloto de usuarios, ya sea enviándoles un enlace de autorregistro o mediante importación masiva a través de un grupo de AD. Pídales que escaneen un código QR en su app autenticadora o asígneles tokens hardware. Pruebe el flujo completo de autenticación usando su servicio protegido por RADIUS: introduzca las credenciales, complete el desafío de OTP y confirme que se concede el acceso tras un código válido.

Para el recorrido técnico completo con capturas de pantalla específicas de cada proveedor, consulte la guía completa de integración RADIUS MFA.

Cumplimiento: cómo RADIUS MFA satisface los requisitos normativos

NIST SP 800-63B (AAL2)

Las directrices de identidad digital de NIST definen tres Niveles de Garantía de Autenticador. AAL2 exige dos factores de autenticación distintos para el acceso a sistemas sensibles. La MFA de RADIUS con TOTP o tokens hardware satisface directamente los requisitos de AAL2: la contraseña es el secreto memorizado (algo que usted sabe), y el código TOTP lo genera un autenticador vinculado (algo que usted tiene).

PCI DSS v4.0 — Requisito 8.4

El Requisito 8.4.2 de PCI DSS v4.0 exige MFA para todo acceso al entorno de datos de titulares de tarjetas, para cualquier usuario, ya se conecte de forma remota o desde dentro de la red. El Requisito 8.4.3 se centra específicamente en el acceso remoto: se exige MFA para todo acceso remoto a la red hacia el CDE que se origine fuera de la red de la organización, cubriendo por igual a empleados, contratistas y proveedores externos. RADIUS MFA ayuda a las organizaciones a satisfacer ambos requisitos aplicando la MFA para VPN y otros accesos protegidos por RADIUS a sistemas dentro del entorno de datos de titulares de tarjetas.

HIPAA — controles de acceso (45 CFR § 164.312)

La salvaguarda técnica de HIPAA sobre el control de acceso exige a las entidades cubiertas implementar procedimientos que concedan acceso a la ePHI únicamente a personas autorizadas. RADIUS MFA aborda esto directamente añadiendo un segundo paso de verificación al acceso VPN y Wi-Fi, las dos vías más habitualmente usadas para el acceso remoto a sistemas clínicos.

Directiva NIS2 (UE) — artículo 21

NIS2 exige a las entidades esenciales e importantes implementar soluciones de autenticación multifactor o continua para el acceso a los sistemas de red e información. RADIUS MFA satisface este requisito para los escenarios de acceso remoto, explícitamente señalados en la guía de implementación de ENISA.

ISO/IEC 27001:2022 — Anexo A 8.5

El control de ISO 27001 sobre autenticación segura recomienda explícitamente la MFA para escenarios de acceso de alto riesgo, incluidos el acceso remoto y las cuentas privilegiadas. RADIUS MFA ayuda a las organizaciones a implementar este control para VPN y otros servicios protegidos por RADIUS.

Preguntas frecuentes

Sí. Protectimus usa el Access-Challenge de RADIUS de forma nativa para los avisos interactivos de OTP. Cuando el dispositivo NAS admite challenge/response (como hacen la mayoría de los clientes VPN modernos), los usuarios ven un segundo campo de entrada para su OTP tras introducir su contraseña. Para los dispositivos que no admiten challenge/response, el modo Inline está disponible como alternativa.

Sí, y este es el modelo de implementación más habitual. Protectimus funciona como un proxy RADIUS situado por delante de su servidor de autenticación existente. Sus dispositivos NAS apuntan a Protectimus; Protectimus gestiona la aplicación de la MFA y luego reenvía la solicitud validada. Sus políticas de autenticación, enrutamiento y configuración de registro contable existentes permanecen sin cambios.

Protectimus usa el puerto de autenticación RADIUS estándar: UDP 1812. El registro contable (si se necesita) usa UDP 1813. Ambos son configurables.

Se admiten dos modos. En el modo challenge/response, el cliente VPN muestra un segundo aviso tras aceptar la contraseña; el usuario introduce su OTP en ese campo. En el modo Inline, el usuario introduce su contraseña y el OTP juntos en un único campo usando un separador configurado. No se requiere navegador en ningún caso; todo el flujo ocurre dentro de la interfaz de autenticación nativa del cliente.

Sí. Puede desplegar varias instancias del servidor RADIUS de Protectimus y configurar sus dispositivos NAS con objetivos RADIUS primario y secundario. Si el servidor primario no responde dentro del tiempo de espera de RADIUS, el NAS reintenta automáticamente con el secundario. En las implementaciones on-premises, la alta disponibilidad también puede extenderse a la plataforma de Protectimus desplegándola como un clúster. Los dispositivos de red cambian automáticamente al servidor secundario cuando el primario deja de estar disponible, ayudando a mantener la disponibilidad de la autenticación.

Sí, y esta es la configuración predeterminada para la mayoría de las implementaciones empresariales. Protectimus se conecta a su AD mediante LDAP o LDAPS (puerto 389/636) y reenvía la validación de contraseña al controlador de dominio. Se admiten políticas basadas en grupos: puede exigir MFA para algunos grupos de AD y eximir a otros, o asignar métodos de MFA distintos según el grupo.

Empiece a proteger el acceso a su red hoy mismo

Cada endpoint VPN, cada red Wi-Fi corporativa y cada servicio protegido por RADIUS es un punto de entrada potencial. RADIUS MFA cierra la brecha de la autenticación basada únicamente en credenciales sin requerir cambios en su infraestructura de red existente.

Send Us A Message icon

Envíenos un mensaje

    Este sitio está registrado en wpml.org como sitio de desarrollo. Cambia a una clave de sitio de producción en remove this banner.