Como impedir que usuários compartilhem certificados no OpenVPN?

Question

Eu tenho um servidor OpenVPN que usa certificados e autenticação LDAP.

O problema é que um usuário pode compartilhar seu certificado e outros usuários LDAP válidos podem usar este certificado.

Pergunta

Como posso ter certeza de que o certificado de Bob só pode ser usado com o usuário LDAP "bob"?

    

Answer 1

De acordo com este post , common_name can não ser falsificado pelo usuário.

Adicione isto ao openvpn server.conf

script-security 2

# untrusted state
auth-user-pass-verify /etc/openvpn/scripts/check_cn_on_connect.sh via-env

/etc/openvpn/scripts/check_cn_on_connect.sh contém

#!/bin/bash

# username and common_name must be the same to allow access.
# users are not allowed to share their cert
if [ $username != $common_name ]; then
   echo "$(date +%Y%m%d-%H%M%S) DENIED  username=$username cert=$common_name" >> /var/log/openvpn-access.log
   exit 1
fi

echo "$(date +%Y%m%d-%H%M%S) GRANTED username=$username cert=$common_name" >> /var/log/openvpn-access.log

exit 0

Atualizar

Isto é para o OpenVPN 2.1.4. No 2.2.0 eles adicionaram muitas variáveis novas que você pode ver por env >> /tmp/env , onde uma dessas novas variáveis é a impressão digital / número de série dos certificados.

    

Answer 2

Existem muitas opções, desde que o OpenVPN é um projeto de código aberto, e tem a capacidade de escrever o seu próprio gancho de autenticação, existem muitas pessoas que fizeram muitas coisas diferentes para fornecer diferentes níveis de autenticação.

Eu não tentei a maioria deles apenas os vi mencionados nos docs / blogs / maillists. Alguns deles podem exigir correções ou a versão não-livre.

Um método principal será tornar a parte privada do seu par de chaves proibitivamente difícil de extrair / copiar.

• Use um token de hardware. A chave privada pode ser armazenada em um token físico e não pode ser copiada ou recuperada. (ref: O OpenVPN oferece suporte a cartões inteligentes através de tokens criptográficos baseados no PKCS # 11. )
• Tenho visto menções ao uso do TPM, isso é semelhante a um token de hardware, mas incorporado à placa-mãe. (ref: link )
• Eu vi algo em um mailist mencionando que era possível usar o armazenamento de certificados do Windows para a chave. As chaves aqui podem ser marcadas para que não sejam exportáveis. (Ref: link )

Se proteger a chave for proibitiva em termos de custo, não for compatível com as plataformas do cliente ou não for possível por algum outro motivo, você terá algumas opções.

• Exigem renovações freqüentes do certificado, portanto, um certificado copiado não pode ser usado por muito tempo.

• Defina muitos registros em seu servidor para observar anomalias. Se Bob normalmente só faz logon em sua casa e, em seguida, um dia, ele começa a fazer logon na Acme Inc., então você pode precisar investigar.

• Configure a autenticação multifator. Seu certificado conta como "algo que você tem". Então você deve estar procurando alternativas no 'algo que você é', ou 'algo que você sabe'. Isso inclui bio métricas, senhas / frases secretas.

• Como mencionei, o OpenVPN fornece autenticação muito flexível. Isso usa a opção auth-user-pass-verify . Esta opção passa o nome de usuário e a senha fornecidos para um script / programa externo que fará a decisão de autenticação com base no que você quiser.

Answer 3

Eu não sou um profissional de segurança. Sou rigoroso em relação à segurança. Sua pergunta atinge precisamente o núcleo da segurança de TI: confiança. Como eu vejo, nunca se deve assumir que Bob pode ser confiável. Claro, Bob pode ser um cara muito legal e confiável. Ele trabalha na sua empresa há mais de 20 anos. No entanto, a pessoa "Bob" é totalmente irrelevante em sua infraestrutura de TI.

Bob usa 'relays' arbitrários que permitem o acesso. Os relés podem ser qualquer coisa: uma senha, certificado, token de hardware, varredura de íris, DNA. São chaves que permitem o acesso ao seu sistema. Se a sua pergunta for sobre a verificação da identidade da pessoa que está usando uma chave, a única resposta honesta provavelmente é que você terá que estar na mesma sala. Em todos os outros casos, acho que você não deve assegurar-se de que Bob realmente é Bob e, atualmente, não está sendo mantido na ponta da arma enquanto obtém seu acesso. Portanto, no seu plano de design de infraestrutura de TI, o mais lógico é não se referir a "Bob": uma entidade obteve acesso ao seu site.

Como você só pode realmente saber que 'uma entidade' obteve acesso com uma chave que você transmitiu no passado, a perspectiva correta provavelmente é limitar o número de portas que a chave pode abrir. Quanto mais chaves você distribuir, menos portas elas abrem.

O OpenVPN também tem uma opção para permitir apenas uma conexão simultânea por chave. Então, se Alice fizer login com a chave de Bob enquanto Bob já estiver dentro, Alice terá seu acesso negado. Infelizmente isso também significa que Bob não pode logar quando Alice está conectada com a chave de Bob. Portanto, você deve configurar seu sistema para informá-lo sobre tentativas de login simultâneas de vários IPs de origem. E inicie ambos quando ocorrer alguma violação, para que Bob precise discar para obter ajuda.

O ponto é: não se assegure de coisas que você não pode ter certeza e tenha isso em mente ao projetar seu plano de segurança. Suponha que há sempre uma pessoa mais inteligente lá fora, bem à sua frente, que não pode esperar para provar que você está errado ... apenas "pelo lulz". : -)