Duas verificações de login não são dois fatores: VPN e RADIUS

Adicionar um segundo backend de autenticação a um gateway VPN parece adicionar um segundo fator. Normalmente acrescenta uma segunda verificação, que é um objeto diferente com modos de falha diferentes. Se ambas devem ter sucesso, o que cada uma prova e o que acontece quando uma não está disponível são três decisões separadas. Erre e o gateway fica mais rígido na demonstração e mais fraco durante uma falha.

O que um segundo backend realmente prova

Uma consulta de conta local prova que um nome existe numa base de dados e que uma palavra-passe lhe correspondia. Uma troca RADIUS prova que um servidor RADIUS devolveu Access-Accept para os atributos que recebeu. Nenhuma das afirmações menciona um tipo de fator, porque ambas verificam conhecimento. E a orientação do NIST sobre identidade digital conta tipos de fator distintos e os seus autenticadores, não servidores ou pedidos.

Existe um desenho legítimo em que ambos os sistemas participam. Um serviço central pode autenticar a pessoa enquanto o gateway verifica de forma independente se essa conta tem direito a este túnel. Isso é autorização ao lado da autenticação, e chamar-lhe dois fatores confunde uma verificação de política com uma prova de posse.

O RADIUS pode transportar um segundo fator real quando está à frente de algo que verifica um, como uma aprovação push ou um token de hardware. O envelope não diz que autenticadores o utilizador apresentou, por isso leia a política do backend e não o rótulo do gateway.

AND, OR e fallback são produtos diferentes

Antes de comparar implementações, decida o que ambos significa no seu requisito. Uma política AND exige que cada verificação nomeada passe, uma política OR aceita a que tiver sucesso, e um fallback só tenta a segunda em condições de falha declaradas. Essas três comportam-se de forma oposta durante uma falha, e normalmente só uma delas é o que a revisão pretendia.

Adicionar duas entradas de backend a um ecrã de configuração não revela que política o produto implementa. Alguns gateways encadeiam plugins por ordem e param no primeiro recusar, o que só é AND quando cada plugin é obrigatório. Outros tratam a conta local como uma substituição, o que transforma uma falha central num desvio. A resposta fiável é um teste negativo documentado para cada caminho, executado contra a compilação que implementa.

O fallback merece a maior suspeita, porque existe para continuar a funcionar quando algo está avariado. Um fallback que aceita uma palavra-passe local sempre que o RADIUS está inacessível converteu uma política central numa segunda porta mais fraca.

A dupla verificação do OpenVPN é um caso concreto

O OpenVPN comunitário 2.6 exige tanto um certificado de cliente como o script auth-user-pass-verify configurado quando ambos estão ativos. É um AND documentado entre a verificação do certificado e um script de credenciais, e são realmente duas verificações. Ainda não são automaticamente dois tipos de fator, já que o script pode validar apenas uma palavra-passe.

A combinação também deixa aberta a questão da associação. Um certificado identifica normalmente um dispositivo enquanto as credenciais identificam uma pessoa, e nada no fluxo predefinido exige que ambos se refiram ao mesmo principal. Decida que pares são permitidos e depois imponha esse mapa dentro do script de verificação ou num passo de autorização posterior.

O modo apenas certificado é uma única verificação, apoiada por uma chave que pode ou não estar protegida por um PIN. Um PIN converte a mesma credencial em conhecimento mais posse apenas se a chave não puder ser usada sem ele. Deixar essa chave sem cifra no disco reduz a segunda parte a uma permissão de ficheiro.

Os fabricantes de equipamentos constroem a sua própria canalização, muitas vezes um módulo PAM ou um plugin RADIUS atrás de uma consola web. O comportamento da comunidade é uma referência de como são as duplas verificações, não uma descrição de como um equipamento as combina.

Verifique a combinação no seu gateway

Leia a configuração antes de confiar no resumo da consola. As linhas que decidem a política são o modo de certificado, o script de credenciais e a ordem dos plugins.

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 é exigido um certificado e que script corre depois, e a ordem importa mais do que os nomes sugerem. O dump do certificado dá a identidade que o gateway verá, incluindo o CN e o número de série necessários para o mapa de associação. O teste RADIUS é o caso negativo: uma palavra-passe errada deve produzir Access-Reject, e uma correta Access-Accept. Se uma credencial recusada ainda produz uma sessão, o script não está de todo no caminho de autenticação.

Depois execute o caso de falha numa instância de laboratório: pare o backend obrigatório e ligue-se com credenciais válidas. O resultado esperado é uma recusa, e qualquer outra coisa é a política de fallback que ninguém documentou.

Escreva o requisito como casos negativos

Um requisito utilizável nomeia as provas, as contas autorizadas a apresentá-las e o resultado quando falta um verificador. Também indica o emparelhamento permitido entre a identidade do dispositivo e a da pessoa. Isso é mais preciso do que os nomes de produto na encomenda, e pode ser testado.

A aceitação deve incluir quatro recusas: uma conta local inelegível, uma prova obrigatória em falta, um segundo fator inválido e um backend obrigatório inacessível. Cada recusa precisa de uma linha de registo que a distinga das outras, ou o próximo incidente começa com suposições. Registe que componente tomou cada decisão, já que o gateway, o servidor RADIUS e o diretório se vão culpar mutuamente.

Execute novamente as quatro recusas após qualquer alteração de plugin ou firmware. São baratas, e a política que protegem é a parte que um atacante sonda primeiro.