Dos comprobaciones de acceso no son dos factores: VPN y RADIUS

Añadir un segundo backend de autenticación a una puerta de enlace VPN parece añadir un segundo factor. Normalmente añade una segunda comprobación, que es un objeto distinto con modos de fallo distintos. Si ambas deben tener éxito, qué demuestra cada una y qué ocurre cuando una no está disponible son tres decisiones separadas. Equivóquese y la puerta acaba más estricta en la demostración y más débil durante una caída.

Qué demuestra realmente un segundo backend

Una consulta de cuenta local demuestra que un nombre existe en una base de datos y que una contraseña coincidía con él. Un intercambio RADIUS demuestra que un servidor RADIUS devolvió Access-Accept para los atributos que recibió. Ninguna de las dos afirmaciones menciona un tipo de factor, porque ambas verifican conocimiento. Y la guía de identidad digital del NIST cuenta tipos de factor distintos y sus autenticadores, no servidores ni avisos.

Existe un diseño legítimo en el que participan ambos sistemas. Un servicio central puede autenticar a la persona mientras la puerta comprueba de forma independiente si esa cuenta tiene derecho a este túnel. Eso es autorización junto a la autenticación, y llamarlo dos factores confunde una comprobación de política con una prueba de posesión.

RADIUS puede portar un segundo factor real cuando se antepone a algo que verifica uno, como una aprobación push o un token de hardware. El sobre no dice qué autenticadores ha demostrado el usuario, así que lea la política del backend y no la etiqueta de la puerta.

AND, OR y la reserva son productos distintos

Antes de comparar implementaciones, decida qué significa ambos en su requisito. Una política AND exige que pase cada comprobación nombrada, una política OR acepta la que tenga éxito, y una reserva prueba la segunda solo bajo condiciones de fallo declaradas. Esas tres se comportan de forma opuesta durante una caída, y normalmente solo una es lo que pretendía la revisión.

Añadir dos entradas de backend a una pantalla de configuración no revela qué política implementa el producto. Algunas puertas encadenan complementos en orden y se detienen en el primer rechazo, lo que es AND solo cuando cada complemento es obligatorio. Otras tratan la cuenta local como una anulación, lo que convierte una caída central en un bypass. La respuesta fiable es una prueba negativa documentada para cada ruta, ejecutada contra la compilación que despliega.

La reserva merece la mayor sospecha, porque existe para seguir funcionando cuando algo está roto. Una reserva que acepta una contraseña local siempre que RADIUS no es accesible ha convertido una política central en una segunda puerta más débil.

La doble comprobación de OpenVPN es un caso concreto

OpenVPN comunitario 2.6 exige tanto un certificado de cliente como el script auth-user-pass-verify configurado cuando ambos están habilitados. Eso es un AND documentado entre la verificación del certificado y un script de credenciales, y son realmente dos comprobaciones. Sigue sin ser automáticamente dos tipos de factor, ya que el script puede validar solo una contraseña.

La combinación también deja abierta la cuestión de la asociación. Un certificado suele identificar un dispositivo mientras las credenciales identifican a una persona, y nada en el flujo predeterminado exige que ambos se refieran al mismo principal. Decida qué pares están permitidos y luego imponga ese mapa dentro del script de verificación o en un paso de autorización posterior.

El modo solo certificado es una única comprobación, respaldada por una clave que puede o no estar protegida por un PIN. Un PIN convierte la misma credencial en conocimiento más posesión solo si la clave no puede usarse sin él. Dejar esa clave sin cifrar en el disco reduce la segunda parte a un permiso de archivo.

Los fabricantes de dispositivos construyen su propia fontanería, a menudo un módulo PAM o un complemento RADIUS detrás de una consola web. El comportamiento de la comunidad es una referencia de cómo son las dobles comprobaciones, no una descripción de cómo las combina un dispositivo.

Compruebe la combinación en su puerta

Lea la configuración antes de confiar en el resumen de la consola. Las líneas que deciden la política son el modo de certificado, el script de credenciales y el orden de los complementos.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

El grep muestra si se exige un certificado y qué script se ejecuta después, y el orden importa más de lo que sugieren los nombres. El volcado del certificado da la identidad que verá la puerta, incluidos el CN y el número de serie que necesita para el mapa de asociación. La prueba RADIUS es el caso negativo: una contraseña incorrecta debe producir Access-Reject, y una correcta Access-Accept. Si una credencial rechazada aún produce una sesión, el script no está en la ruta de autenticación en absoluto.

Después ejecute el caso de caída en una instancia de laboratorio: detenga el backend obligatorio y conéctese con credenciales válidas. El resultado esperado es un rechazo, y cualquier otra cosa es la política de reserva que nadie documentó.

Escriba el requisito como casos negativos

Un requisito utilizable nombra las pruebas, las cuentas autorizadas a presentarlas y el resultado cuando falta un verificador. También indica el emparejamiento permitido entre la identidad del dispositivo y la de la persona. Eso es más preciso que los nombres de producto del pedido, y se puede probar.

La aceptación debería incluir cuatro rechazos: una cuenta local no apta, una prueba obligatoria ausente, un segundo factor inválido y un backend obligatorio inaccesible. Cada rechazo necesita una línea de registro que lo distinga de los demás, o el siguiente incidente empieza con conjeturas. Registre qué componente tomó cada decisión, ya que la puerta, el servidor RADIUS y el directorio se culparán mutuamente.

Vuelva a ejecutar los cuatro rechazos tras cualquier cambio de complemento o de firmware. Son baratos, y la política que protegen es la parte que un atacante sondea primero.