Português: endurecimento de VPN no Windows — corrija a autenticação antes do túnel

O seu servidor VPN Windows pede um nome de utilizador e uma palavra-passe, e esse único diálogo esconde três tarefas não relacionadas. Uma prova quem é a pessoa, uma impede que alguém que observa o cabo reutilize essa prova, e uma decide a que endereços pode chegar depois. A maioria das implementações pequenas endurece primeiro o túnel e deixa as duas primeiras tarefas nos valores predefinidos, o que é a ordem errada.

Trabalhe na ordem em que o atacante trabalha. Primeiro o que se pode capturar do cabo. Depois o que se pode reproduzir mais tarde com essa captura. Por fim, aquilo a que um atacante autenticado consegue chegar depois de entrar.

Três tarefas, um só diálogo

A identidade é a parte em que as pessoas pensam, e é apenas um terço do problema. A prova de identidade tem de sobreviver a um observador que grava a troca e tenta de novo mais tarde. A autorização é uma decisão separada que o servidor toma depois de a identidade estar resolvida, e o Windows guarda-a num serviço diferente daquele que valida as credenciais.

Quando as três vivem no mesmo balde mental, o resultado habitual é um servidor que autentica com força e depois permite ao utilizador chegar a tudo. Corrigir isso mais tarde é mais difícil do que decidir a política agora, porque nessa altura o perfil de firewall, o conjunto de endereços e as rotas já codificam o pressuposto antigo.

Separe as três nas suas notas antes de tocar em qualquer definição e depois corrija-as do elo mais fraco para cima.

Porque é que o MS-CHAPv2 não passa um teste de reprodução

Se o servidor ainda aceita PPTP com MS-CHAPv2, o túnel não protege a palavra-passe em nenhum sentido relevante. O desafio e a resposta podem ser capturados e atacados offline, e em 2012 um serviço público de quebra demonstrou a recuperação a partir desse aperto de mão em cerca de um dia para uma palavra-passe típica. Uma palavra-passe mais longa e complexa aumenta o custo; não remove o material de que o atacante precisa da rede.

A propriedade que quer é uma credencial que não possa ser reproduzida. O EAP-TLS com certificados de cliente dá a cada dispositivo a sua própria identidade e permite revogar exatamente um dispositivo.

Implementar certificados é trabalho a sério: uma AC privada, um caminho de revogação que os clientes verificam e um plano de renovação que sobreviva à rotação de pessoal. Trate esse trabalho como o projeto e não como um obstáculo entre si e um túnel a funcionar. Orçamente-o como orçamentaria uma substituição de firewall. Uma palavra-passe partilhada só é mais barata até à primeira revogação.

Uma chave pré-partilhada autentica o par, não a pessoa

L2TP/IPsec com uma chave pré-partilhada prova que dois gateways conhecem o mesmo segredo. Não diz nada sobre que pessoa se está a ligar e não consegue distinguir um colaborador de outro nessa camada. Use um valor aleatório longo, muito acima dos dez caracteres que alguns guias sugerem, porque quem capturar o handshake pode atacar a chave offline.

Todos os clientes desse perfil partilham o segredo, por isso remover uma pessoa significa redistribuí-lo por todos os que ficam. Mantenha um passo separado de autenticação de utilizador por cima do segredo ao nível da máquina e passe para certificados à medida que a população de clientes cresce. Uma chave pré-partilhada combinada com MS-CHAPv2 são duas camadas fracas, e a segunda anula a primeira.

A autorização pertence ao Network Policy Server

O NPS no Windows decide quem se pode ligar, e fá-lo depois de a autenticação já ter sido bem-sucedida. Essa separação é o controlo de endurecimento mais útil do produto, e muitas implementações deixam-no intacto.

Use condições de política que reflitam restrições reais: pertença a grupos, a janela de tempo em que o suporte tem pessoal e o estado do dispositivo a partir de uma verificação de saúde. Acrescente um segundo fator onde os dados justificam o atrito, e lembre-se de que a política é avaliada por cada tentativa de ligação, o que a torna um controlo vivo e não um documento.

A contabilidade RADIUS também lhe dá um registo de quem se ligou e quando. Esse registo é a diferença entre uma revisão de incidente e um palpite, e existe quer alguém o leia quer não.

Limite aquilo a que um início de sessão bem-sucedido pode chegar

O adaptador VPN deve aterrar num perfil de firewall que permita os serviços de que a sua função precisa e não a sub-rede inteira. A questão do encaminhamento é separada da filtragem. Um túnel completo protege o dispositivo cliente e empurra cada byte pelo seu acesso ascendente, enquanto um túnel dividido mantém o tráfego local local e expõe o dispositivo a qualquer rede em que se encontre.

Nenhuma das duas opções é um valor predefinido de segurança. Ambas têm de ser registadas ao lado do perfil de firewall que pressupõem.

Verifique os caminhos de falha

Teste o que deve quebrar: uma palavra-passe errada, um certificado expirado, um dispositivo revogado, um utilizador fora do grupo. Cada caso deve falhar num ponto diferente, e o registo deve dizer qual foi. Execute o conjunto primeiro contra uma conta de teste e depois repita-o para um utilizador real. Uma rejeição que chega ao registo de eventos sem motivo merece ser corrigida muito antes de precisar desse registo.

Depois confirme que portas estão publicadas e porquê. O PPTP precisa de TCP 1723 e de GRE como protocolo IP em vez de porta, o IKEv2 precisa de UDP 500 e 4500, e o L2TP precisa de UDP 1701 mais IPsec. Expor uma interface de gestão para que um cliente se ligue não é uma reparação, é um segundo incidente à espera de ser descoberto.

Por fim, decida o que o servidor regista e durante quanto tempo. Um ponto final sem histórico de autenticação não consegue responder à primeira pergunta após um incidente, que é se a tentativa foi alguma vez autorizada.