Saltar al contenido principal

Autenticación multifactor RADIUS para VPN y Wi-Fi: 2FA TOTP con el servidor RADIUS de Casdoor

· 11 min de lectura
Yang Luo
Yang Luo
Casdoor Maintainer

Para poner autenticación multifactor delante de una VPN con RADIUS, la pasarela VPN envía el nombre de usuario y la contraseña al servidor RADIUS con PAP, el servidor verifica la contraseña y responde con un Access-Challenge, el cliente muestra un aviso y el usuario escribe el código 2FA de una aplicación de autenticador en una segunda solicitud. Casdoor incluye un servidor RADIUS que hace exactamente esto para usuarios que tienen configurado TOTP, por lo que una pasarela que pueda mostrar un aviso de Access-Challenge (FortiGate SSL VPN es una cuyo fabricante lo documenta) obtiene una contraseña más un código 2FA sin software adicional. Wi-Fi con WPA2/WPA3-Enterprise es diferente: 802.1X se ejecuta sobre EAP, que no tiene lugar para un código escrito, por lo que Casdoor tiene un interruptor para omitir el código para esos clientes.

Si quieres antecedentes sobre RADIUS en sí y cómo se compara con LDAP para dispositivos de red, lee primero RADIUS vs LDAP. Esta publicación trata sobre la parte MFA: qué va por el cable, qué clientes pueden llevar un segundo factor y cómo activarlo en Casdoor.

Qué clientes pueden hacer MFA RADIUS con Casdoor​

La tabla lista lo que cada fabricante documenta. "Soporte de challenge" significa que el cliente muestra el aviso de Access-Challenge al usuario y envía la respuesta de vuelta. Donde la página del fabricante que comprobamos no lo dice, la tabla lo indica en lugar de adivinar.

ClienteMétodo de autenticación RADIUS a usar con CasdoorSoporte de Access-ChallengeNotas
FortiGate SSL VPNPAP (establece el método en PAP, o deja Default, que intenta PAP primero)Sí, según FortinetFortinet dice que SSL VPN reenvía el challenge al cliente y espera la respuesta
FortiGate IPsec VPN (incluyendo FortiClient)PAPNo reenviado por defectoLa solución de Fortinet requiere MS-CHAP en el servidor RADIUS, que Casdoor no habla; usa SSL VPN u omite MFA
Cisco ASA (AnyConnect / Secure Client)PAP, el valor predeterminado de ASA para todos los tipos de conexiónNo indicado en la guía de configuración RADIUS de ASANo actives password-management en el grupo de túneles: cambia el ASA a MS-CHAPv2
OpenVPN Access ServerPAP (también ofrece CHAP y MS-CHAPv2)No indicado en la página de ajustes de RADIUSAccounting es un toggle separado, puerto predeterminado 1813
pfSense (servidor de autenticación RADIUS, usado por su OpenVPN)PAP (también MD5-CHAP, MS-CHAPv1, MS-CHAPv2)No indicado en la documentación de NetgateLos ejemplos OTP de Netgate ponen el código dentro del campo de contraseña, que Casdoor no acepta
WireGuardNingunoNo aplicableLos pares se autentican solo con claves públicas, por lo que no hay inicio de sesión para que RADIUS verifique
Wi-Fi, WPA2/WPA3-Enterprise (802.1X)EAP (PEAP, EAP-TTLS etc.)Sin aviso de código escritoCasdoor no implementa EAP; consulta la sección de Wi-Fi

Donde una celda diga "no indicado", prueba con el cliente VPN real antes de desplegarlo, y verifica que el aviso aparece y el código pasa.

Por qué solo PAP puede llevar la contraseña que Casdoor verifica​

RADIUS tiene varias formas de enviar una contraseña, y estas deciden qué puede verificar el servidor.

Con PAP, el cliente coloca la contraseña en el atributo User-Password, oculta mediante un hash MD5 del secreto compartido y el autenticador de la solicitud (RFC 2865, sección 5.2). El servidor invierte ese proceso con el mismo secreto, obtiene la contraseña en texto claro y puede verificarla contra un hash almacenado o un bind LDAP. Casdoor lee User-Password y ejecuta la misma comprobación de contraseña que su página de inicio de sesión.

Con CHAP, el cliente nunca envía la contraseña. Envía un hash de la contraseña y un desafío aleatorio. La RFC 2865 establece claramente que CHAP necesita la contraseña del usuario en texto claro en el servidor para recalcular ese hash. MS-CHAPv2 tiene la misma estructura con un hash NT. Un proveedor de identidad que almacena contraseñas como hashes unidireccionales (la organización integrada de Casdoor usa bcrypt) no puede verificar ninguno de los dos métodos. El servidor RADIUS de Casdoor solo lee User-Password, por lo que una solicitud CHAP o MS-CHAPv2 llega sin contraseña y es rechazada.

Dado que el ocultamiento de PAP utiliza solo MD5 con el secreto compartido, use un secreto largo y aleatorio, mantenga RADIUS en una red privada o una VPN entre la puerta de enlace y Casdoor, y active el atributo Message-Authenticator en el cliente. Casdoor verifica Message-Authenticator cuando una solicitud lo incluye y firma su respuesta en ese caso, lo cual es la mitigación para Blast-RADIUS (CVE-2024-3596). Los detalles están en la documentación del servidor RADIUS.

Access-Challenge frente a agregar el código a la contraseña​

Hay dos formas comunes de pasar un código 2FA a través de RADIUS.

  1. Access-Challenge. El servidor verifica la contraseña, luego responde con Access-Challenge, un atributo State y un Reply-Message. El cliente muestra el mensaje, el usuario escribe el código y el cliente envía una nueva Access-Request con el código en User-Password y el mismo State. La sección 4.4 de la RFC 2865 también especifica qué sucede en un cliente sin soporte de desafíos: DEBE tratar Access-Challenge como un Access-Reject.
  2. Código agregado a la contraseña. El usuario escribe password123456 en el único campo de contraseña, y el servidor separa los últimos seis dígitos. Esto funciona con cualquier cliente, razón por la cual los productos diseñados para puertas de enlace más antiguas ofrecen esta opción.

Casdoor implementa solo el primero. Aquí está el flujo en su servidor RADIUS (radius/server.go):

  • La primera Access-Request debe llevar la contraseña correcta. Un usuario con MFA activada recibe Access-Challenge, un State aleatorio y el Reply-Message please enter OTP.
  • El State es válido durante 120 segundos y se puede usar una sola vez. Está vinculado a la organización y al nombre de usuario de la primera solicitud.
  • La segunda Access-Request debe llevar ese State y el código TOTP de seis dígitos de la aplicación de autenticación del usuario en User-Password. Casdoor verifica el código contra el secreto TOTP del usuario y responde con Access-Accept o Access-Reject.
  • Los códigos incorrectos cuentan hacia el límite de inicios de sesión fallidos de la aplicación del usuario (5 intentos y un bloqueo de 15 minutos por defecto), separadamente de las contraseñas incorrectas.

De esto se derivan dos consecuencias. Un cliente que solo puede hacer "contraseña más código en un campo" fallará, porque Casdoor verifica toda la cadena como la contraseña. Y solo TOTP funciona sobre RADIUS: los códigos por SMS y correo electrónico requieren que Casdoor envíe un mensaje después del paso de contraseña, cosa que el servidor RADIUS no hace. Un usuario cuyo único método MFA es SMS o correo electrónico recibirá el desafío y luego un rechazo, así que pida a los usuarios de RADIUS que configuren una aplicación de autenticación.

Wi-Fi: 802.1X y WPA-Enterprise​

En Wi-Fi con WPA2-Enterprise o WPA3-Enterprise, el punto de acceso no recolecta una contraseña por sí mismo. Reenvía una conversación EAP entre el dispositivo (el suplicante) y el servidor RADIUS, y RADIUS transporta los paquetes EAP en atributos EAP-Message. En esa configuración, Access-Challenge ya está en uso: cada ida y vuelta del intercambio EAP es un par Access-Request y Access-Challenge (RFC 3579). La RFC 3579 también dice que un mensaje que lleva EAP-Message no debe incluir Reply-Message, por lo que no hay un campo para "please enter OTP" ni un diálogo en el teléfono o portátil donde escribir un código.

Dos puntos prácticos para Casdoor:

  • El servidor RADIUS de Casdoor no implementa EAP. Un punto de acceso no puede hablar directamente con él para WPA-Enterprise. Necesita un servidor EAP delante que termine el túnel TLS y reenvíe una solicitud PAP simple. FreeRADIUS puede hacer esto con EAP-TTLS y PAP como método interno, proxyando la solicitud interna a otro servidor RADIUS, y los dispositivos deben configurarse con TTLS y PAP dentro. PEAP con MS-CHAPv2, el predeterminado en muchos dispositivos, no funcionará contra Casdoor por la razón expuesta en la sección de PAP.
  • Para esos usuarios, active Skip MFA for RADIUS en la organización. Casdoor entonces acepta usuarios que tienen MFA tras la sola verificación de contraseña. El MFA en la página de inicio de sesión web no se ve afectado.

Puertos, secreto compartido y contabilidad​

La RFC 2865 asigna el puerto UDP 1812 a la autenticación RADIUS, y la RFC 2866 asigna el 1813 a la contabilidad. Casdoor escucha en un puerto UDP, radiusServerPort, y maneja tanto Access-Request como Accounting-Request allí. Así que dirija la contabilidad de la puerta de enlace al mismo puerto que la autenticación (1812 por defecto), no al 1813, o los paquetes de contabilidad irán a ningún lado. Si Casdoor se ejecuta en un contenedor, publique el puerto como UDP, por ejemplo -p 1812:1812/udp.

El secreto compartido es un valor único para todos los clientes, radiusSecret. Cada puerta de enlace que habla con Casdoor lo usa.

Para la contabilidad, Casdoor registra mensajes Start, Interim-Update y Stop en su base de datos (tabla radius_accounting), con el ID de sesión, tiempo de sesión, dirección NAS, IP enmarcada y contadores de bytes y paquetes. Solo hace eso para organizaciones con RADIUS activado.

Configurar Casdoor​

1. Configure las opciones de RADIUS. En conf/app.conf, o como variables de entorno con los mismos nombres:

radiusServerPort = 1812
radiusDefaultOrganization = "my-company"
radiusSecret = "a-long-random-string-shared-with-the-gateway"

radiusDefaultOrganization es la organización que Casdoor usa cuando una solicitud no tiene un atributo Class. Si su puerta de enlace no puede añadir un atributo Class a sus solicitudes, esta configuración decide qué usuarios de qué organización inician sesión vía RADIUS. Todas las claves están listadas en la referencia de configuración.

2. Active RADIUS para la organización. En la página de edición de la organización, active Enable RADIUS. Está desactivado por defecto y solo los administradores globales pueden cambiarlo. Mientras esté desactivado, Casdoor rechaza todas las solicitudes Access-Request para esa organización e ignora su contabilidad.

3. Decida sobre MFA para RADIUS. Deje Skip MFA for RADIUS desactivado para pasarelas VPN que soporten Access-Challenge. Actívelo para una organización cuyos clientes RADIUS no puedan responder a un desafío, como Wi-Fi WPA-Enterprise.

4. Configure TOTP para usuarios. Los usuarios configuran una aplicación autenticadora desde su página de perfil, como se describe en autenticación de múltiples factores. Para hacerla obligatoria, agregue el elemento TOTP con la regla Required bajo los elementos MFA de la organización. Tenga en cuenta el orden: un usuario que aún deba configurar MFA obligatorio o deba cambiar la contraseña primero, es rechazado mediante RADIUS hasta que complete eso en la página de inicio de sesión de Casdoor.

5. Pruebe desde la línea de comandos. radclient de FreeRADIUS envía solicitudes PAP e imprime la respuesta:

echo 'User-Name = "alice", User-Password = "her-password"' \
  | radclient -x casdoor.example.com:1812 auth a-long-random-string-shared-with-the-gateway

Para un usuario con TOTP, debería ver Access-Challenge con un State y el Reply-Message. Envíe el código de vuelta con ese State dentro de 120 segundos:

echo 'User-Name = "alice", User-Password = "123456", State = 0x...' \
  | radclient -x casdoor.example.com:1812 auth a-long-random-string-shared-with-the-gateway

Pegue el valor de State de la primera respuesta en lugar de 0x.... Un Access-Accept significa que la configuración es correcta, y lo siguiente es la pasarela.

Si también desea que Casdoor use un servidor RADIUS externo como segundo factor para su propio inicio de sesión web, esa es la dirección opuesta y está cubierta por el proveedor MFA RADIUS.

Referencias​