Dúas comprobacións de acceso non son dous factores: VPN e RADIUS

Engadir un segundo backend de autenticación a unha pasarela VPN parece engadir un segundo factor. Normalmente engade unha segunda comprobación, que é un obxecto distinto con modos de fallo distintos. Se ambas deben ter éxito, que demostra cada unha e que ocorre cando unha non está dispoñible son tres decisións separadas. Equivóquese e a pasarela acaba máis estrita na demostración e máis feble durante unha caída.

Que demostra realmente un segundo backend

Unha consulta de conta local demostra que un nome existe nunha base de datos e que un contrasinal lle correspondía. Un intercambio RADIUS demostra que un servidor RADIUS devolveu Access-Accept para os atributos que recibiu. Ningunha das dúas afirmacións menciona un tipo de factor, porque ambas verifican coñecemento. E a guía de identidade dixital do NIST conta tipos de factor distintos e os seus autenticadores, non servidores nin avisos.

Existe un deseño lexítimo no que participan ambos os dous sistemas. Un servizo central pode autenticar a persoa mentres a pasarela comproba de forma independente se esa conta ten dereito a este túnel. Iso é autorización xunto á autenticación, e chamalo dous factores confunde unha comprobación de política cunha proba de posesión.

RADIUS pode portar un segundo factor real cando se antepón a algo que verifica un, como unha aprobación push ou un token de hardware. O sobre non di que autenticadores demostrou o usuario, así que lea a política do backend e non a etiqueta da pasarela.

AND, OR e a reserva son produtos distintos

Antes de comparar implementacións, decida que significa ambos no seu requisito. Unha política AND esixe que pase cada comprobación nomeada, unha política OR acepta a que teña éxito, e unha reserva proba a segunda só baixo condicións de fallo declaradas. Esas tres compórtanse de forma oposta durante unha caída, e normalmente só unha é o que pretendía a revisión.

Engadir dúas entradas de backend a unha pantalla de configuración non revela que política implementa o produto. Algunhas pasarelas encadean complementos en orde e detéñense no primeiro rexeitamento, o que é AND só cando cada complemento é obrigatorio. Outras tratan a conta local como unha anulación, o que converte unha caída central nunha evasión. A resposta fiable é unha proba negativa documentada para cada ruta, executada contra a compilación que despregue.

A reserva merece a maior sospeita, porque existe para seguir funcionando cando algo está roto. Unha reserva que acepta un contrasinal local sempre que RADIUS non é accesible converteu unha política central nunha segunda porta máis feble.

A dobre comprobación de OpenVPN é un caso concreto

OpenVPN comunitario 2.6 esixe tanto un certificado de cliente como o script auth-user-pass-verify configurado cando ambos están habilitados. Iso é un AND documentado entre a verificación do certificado e un script de credenciais, e son realmente dúas comprobacións. Segue sen ser automaticamente dous tipos de factor, xa que o script pode validar só un contrasinal.

A combinación tamén deixa aberta a cuestión da asociación. Un certificado adoita identificar un dispositivo mentres as credenciais identifican unha persoa, e nada no fluxo predeterminado esixe que ambos se refiran ao mesmo principal. Decida que pares están permitidos e despois impoña ese mapa dentro do script de verificación ou nun paso de autorización posterior.

O modo só certificado é unha única comprobación, apoiada por unha chave que pode ou non estar protexida por un PIN. Un PIN converte a mesma credencial en coñecemento máis posesión só se a chave non se pode usar sen ela. Deixar esa chave sen cifrar no disco reduce a segunda parte a un permiso de ficheiro.

Os fabricantes de aparellos constrúen a súa propia fontanería, a miúdo un módulo PAM ou un complemento RADIUS detrás dunha consola web. O comportamento da comunidade é unha referencia de como son as dobles comprobacións, non unha descrición de como un aparello as combina.

Comprobe a combinación na súa pasarela

Lea a configuración antes de confiar no resumo da consola. As liñas que deciden a política son o modo de certificado, o script de credenciais e a orde dos 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

O grep mostra se se esixe un certificado e que script se executa despois, e a orde importa máis do que suxiren os nomes. O volcado do certificado dá a identidade que verá a pasarela, incluídos o CN e o número de serie que necesita para o mapa de asociación. A proba RADIUS é o caso negativo: un contrasinal incorrecto debe producir Access-Reject, e un correcto Access-Accept. Se unha credencial rexeitada aínda produce unha sesión, o script non está na ruta de autenticación en absoluto.

Despois execute o caso de caída nunha instancia de laboratorio: deteña o backend obrigatorio e conecte con credenciais válidas. O resultado esperado é un rexeitamento, e calquera outra cousa é a política de reserva que ninguén documentou.

Escriba o requisito como casos negativos

Un requisito utilizable nomea as probas, as contas autorizadas a presentalas e o resultado cando falta un verificador. Tamén indica o emparellamento permitido entre a identidade do dispositivo e a da persoa. Iso é máis preciso que os nomes de produto no pedido, e pódese probar.

A aceptación debería incluír catro rexeitamentos: unha conta local non apta, unha proba obrigatoria ausente, un segundo factor inválido e un backend obrigatorio inaccesible. Cada rexeitamento necesita unha liña de rexistro que o distinga dos demais, ou o seguinte incidente comeza con conxecturas. Rexistre que compoñente tomou cada decisión, xa que a pasarela, o servidor RADIUS e o directorio culparán os outros dous.

Volve executar os catro rexeitamentos tras calquera cambio de complemento ou de firmware. Son baratos, e a política que protexen é a parte que un atacante sonda primeiro.