Em falamos sobre a importância da autenticação de dois fatores em portais corporativos. Na última vez, demonstramos como configurar uma autenticação segura no servidor web IIS.
Nos comentários, pediram-nos para escrever um guia para os servidores web mais comuns no Linux — nginx e Apache.
Vocês pediram — nós escrevemos.
O que é necessário para começar?
- Qualquer distribuição Linux moderna. Eu fiz a configuração de teste no MX Linux 18.2_x64. Claro que não é uma distribuição de servidor, mas para Debian dificilmente haverá diferenças. Para outras distribuições, os caminhos até as bibliotecas de configuração podem variar um pouco.
- Token. Continuamos usando o modelo , que é ideal em termos de desempenho para uso corporativo.
- Para trabalhar com o token no Linux, é necessário instalar os seguintes pacotes:
libccid libpcsclite1 pcscd pcsc-tools opensc
Emissão de certificados
Nos artigos anteriores, baseamo-nos no fato de que os certificados de servidor e clientes seriam emitidos por meio do Microsoft CA. Mas já que estamos configurando tudo no Linux, também iremos falar sobre uma alternativa para emitir esses certificados — sem sair do Linux.
Usaremos o XCA como CA (), que está disponível em qualquer distribuição moderna do Linux. Todas as ações que realizaremos no XCA podem ser feitas também na linha de comando usando as ferramentas OpenSSL e pkcs11-tool, mas para maior simplicidade e clareza, não as apresentaremos neste artigo.
Início
- Instalando:
$ apt-get install xca - E executamos:
$ xca - Criando nosso banco de dados para o CA — /root/CA.xdb
Recomendamos armazenar o banco de dados do Certificate Authority em uma pasta que seja acessível apenas ao administrador. Isso é importante para proteger as chaves privadas dos certificados raiz, que são usadas para assinar todos os outros certificados.
Criando chaves e certificado root CA
A infraestrutura de chaves públicas (PKI) baseia-se em um sistema hierárquico. O principal nesse sistema é o centro de certificação raiz ou root CA. Seu certificado deve ser criado em primeiro lugar.
- Criamos uma chave privada RSA-2048 para o CA. Para isso, na aba Chaves Privadas clicamos Nova Chave e selecionamos o tipo correspondente.
- Damos um nome para o novo par de chaves. Eu o chamei de — CA Key.
- Emitimos o próprio certificado CA, utilizando o par de chaves criado. Para isso, vamos para a aba Certificados e clicamos em Novo Certificado.
- Escolha obrigatória SHA-256, pois o uso de SHA-1 já não pode ser considerado seguro.
- Como modelo, escolha obrigatoriamente [default] CA. Não se esqueça de clicar em Aplicar tudo, caso contrário, o modelo não será aplicado.
- Na aba Assunto selecionamos nosso par de chaves. Lá você pode preencher todos os campos principais do certificado.
Criamos chaves e certificado para o servidor https
- Da mesma forma, criamos uma chave privada RSA-2048 para o servidor, a qual nomeei de — Chave do Servidor.
- Ao criar o certificado, escolhemos que o certificado do servidor deve ser assinado pelo certificado CA.
- Não esqueça de escolher SHA-256.
- Como modelo, escolhemos [default] HTTPS_server. Clicamos em Aplicar tudo.
- Depois, na aba Assunto selecionamos nossa chave e preenchemos os campos necessários.
Criamos chaves e certificado para o usuário
- A chave privada do usuário será armazenada no nosso token. Para trabalhar com ela, é necessário instalar a biblioteca PKCS#11 do nosso site. Para distribuições populares, disponibilizamos pacotes prontos, que estão aqui — . Também temos compilações para arm64, armv7el, armv7hf, e2k, mipso32el, que podem ser encontrados em nosso SDK — . Além das compilações para linux, também temos versões para macOS, freebsd e android.
- Adicionamos um novo Provedor PKCS#11 no XCA. Para isso, vamos ao menu Opções na aba Provedor PKCS#11.
- Clicamos Adicionar e escolhemos o caminho para a biblioteca PKCS#11. No meu caso, é usrliblibrtpkcs11ecp.so.
- Precisamos de um token formatado Rutoken ECP PKI. Baixamos a ferramenta rtAdmin —
- Executamos
$ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u - Como tipo de chave, escolhemos — chave RSA-2048 no Rutoken ECP PKI. Eu nomeei essa chave Chave do Cliente.
- Inserimos o PIN-código. E aguardamos a conclusão da geração do par de chaves hardware
- Criamos o certificado para o usuário de forma semelhante ao do servidor. Desta vez escolhemos o modelo [default] HTTPS_client e não esquecemos de clicar Aplicar tudo.
- Na aba Assunto inserimos as informações do usuário. Quando perguntados sobre a salvaguarda do certificado no token, respondemos afirmativamente.
Assim, na aba Certificados no XCA deve aparecer uma imagem semelhante a esta.
Esse conjunto mínimo de chaves e certificados é suficiente para começar a configuração dos servidores propriamente ditos.
Para a configuração, precisamos exportar o certificado da CA, o certificado do servidor e a chave privada do servidor.
Para isso, devemos selecionar o registro necessário na aba correspondente no XCA e clicar Export.
Nginx
Como instalar e iniciar um servidor nginx, não me alongarei — sobre este tema há artigos suficientes na internet, sem mencionar a documentação oficial. Vamos direto para a configuração do HTTPS e a autenticação de dois fatores por token.
Adicione as seguintes linhas na seção server em nginx.conf:
server {
listen 443 ssl;
ssl_verify_depth 1;
ssl_certificate /etc/nginx/Server.crt;
ssl_certificate_key /etc/nginx/ServerKey.pem;
ssl_client_certificate /etc/nginx/CA.crt;
ssl_verify_client on;
}Uma descrição detalhada de todos os parâmetros relacionados à configuração ssl no nginx pode ser encontrada aqui —
Vou apenas descrever brevemente aqueles que configurei:
- ssl_verify_client — indica que a cadeia de confiança do certificado deve ser verificada.
- ssl_verify_depth — define a profundidade da busca pelo certificado root de confiança na cadeia. Como nosso certificado de cliente é assinado imediatamente pelo certificado root, a profundidade é definida como 1. Se o certificado do usuário for assinado por uma CA intermediária, esse parâmetro deve ser definido como 2, e assim por diante.
- ssl_client_certificate — indica o caminho para o certificado root de confiança que é usado na verificação da confiança do certificado do usuário.
- ssl_certificate/ssl_certificate_key — indicam o caminho para o certificado/chave privada do servidor.
Não se esqueça de executar nginx -t para verificar se não há erros de digitação na configuração e se todos os arquivos estão nos lugares corretos, e assim por diante.
E é isso! Como podem ver, a configuração é muito simples.
Verificamos o funcionamento no Firefox
Como estamos fazendo tudo em Linux, vamos considerar que nossos usuários também estão trabalhando em Linux (se estiverem em Windows, então .
- Iniciamos o Firefox.
- Vamos tentar primeiro acessar sem o token. Recebemos esta mensagem:
- Acesse about:preferences#privacy, e vamos para Security Devices…
- Clicamos Carga, para adicionar um novo driver de dispositivo PKCS#11 e indicar o caminho para nossa librtpkcs11ecp.so.
- Para verificar se o certificado é reconhecido, você pode acessar Certificate Manager. Uma solicitação para inserir o PIN será exibida. Após a inserção correta, você pode verificar se na aba Your Certificates apareceu nosso certificado do token.
- Agora acessamos com o token. O Firefox oferece a opção de escolher o certificado que será selecionado no servidor. Escolhemos nosso certificado.
- LUCRO!
A configuração é realizada uma vez, e como pode ser visto na janela de solicitação de certificado, podemos salvar nossa escolha. Após isso, ao acessar o portal, só precisaremos inserir o token e o PIN do usuário que foi definido durante a formatação. Após essa autenticação, o servidor já sabe qual usuário entrou e não há necessidade de criar mais janelas de verificação, permitindo que o usuário acesse imediatamente seu painel pessoal.
Apache
Assim como com o nginx, ninguém deve ter problemas para instalar o apache. Se você não sabe como instalar este servidor web, basta usar a documentação oficial.
Agora começamos a configurar nosso HTTPS e a autenticação de dois fatores:
- Para começar, é necessário ativar o mod_ssl:
$ a2enmod ssl - E então ativar as configurações padrão de HTTPS do site:
$ a2ensite default-ssl - Agora editamos o arquivo de configuração: /etc/apache2/sites-enabled/default-ssl.conf:
SSLEngine on SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/sites-enabled/Server.crt SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt SSLVerifyClient require SSLVerifyDepth 10Como você pode ver, os nomes dos parâmetros são praticamente os mesmos que os nomes dos parâmetros no nginx, então não vou explicar. Mais uma vez, quem estiver interessado em detalhes - sinta-se à vontade para consultar a documentação.
Agora reiniciamos nosso servidor:$ service apache2 reload $ service apache2 restart
Como você pode ver, configurar a autenticação de dois fatores em qualquer servidor web, tanto no Windows quanto no Linux, leva no máximo uma hora. E a configuração dos navegadores leva cerca de 5 minutos. Muitos acreditam que a configuração e o uso da autenticação de dois fatores são complicados e difíceis de entender. Espero que nosso artigo pelo menos um pouco desmistifique esse mito.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Você precisa de instruções para configurar o funcionamento do TLS com certificados no padrão GOST 34.10-2012:
Sim, o TLS-GOST é muito necessário
Não, a configuração com algoritmos GOST não é interessante
44 usuários votaram. 9 usuários se abstiveram.
Fonte: habr.com
