Estou executando um servidor de e-mail/web Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP). Também estou fazendo alguns testes de vulnerabilidade do nmap em minha máquina cliente MacOS. No MacOS, estou usando Oh My Zsh! com o plugin nmap habilitado. Para fazer alguns testes de vulnerabilidade no meu servidor Ubuntu da minha máquina cliente MacOS, emiti o comando:
nmap_check_for_vulns my.server.ip.address
que é um comando de alias para
nmap --script=vuln
Após emitir o comando com o endereço IP do meu servidor, o nmap relatou as seguintes vulnerabilidades:
465/tcp open smtps
| ssl-dh-params:
| VULNERABLE:
| Anonymous Diffie-Hellman Key Exchange MitM Vulnerability
| State: VULNERABLE
| Transport Layer Security (TLS) services that use anonymous
| Diffie-Hellman key exchange only provide protection against passive
| eavesdropping, and are vulnerable to active man-in-the-middle attacks
| which could completely compromise the confidentiality and integrity
| of any data exchanged over the resulting session.
| Check results:
| ANONYMOUS DH GROUP 1
| Cipher Suite: TLS_DH_anon_WITH_AES_128_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: Unknown/Custom-generated
| Modulus Length: 2048
| Generator Length: 8
| Public Key Length: 2048
| References:
|_ https://www.ietf.org/rfc/rfc2246.txt
No servidor, a saída de sudo -ss lnpté:
LISTEN 0 100 0.0.0.0:465 0.0.0.0:* users:(("smtpd",pid=586529,fd=6),("master",pid=2078,fd=29))
O link nmap fornecidohttps://www.ietf.org/rfc/rfc2246.txt, não fornece referência a esta vulnerabilidade ESPECÍFICA que posso encontrar.
Minha pergunta é: o que significa essa vulnerabilidade, qual processo a utiliza e como posso mitigar essa vulnerabilidade em meu servidor Ubuntu 20.04, sem desabilitar a porta 456? Preciso corrigir o problema de Diffie Hellman nos servidores SMTP postfix/dovecot e, em caso afirmativo, como faço para fazer isso?
Responder1
TLS anônimo é o tipo de configuração também conhecido como "TLS sem certificados". Não existe uma cadeia de confiança para o par de chaves do servidor, portanto, absolutamente nenhuma proteção contra ataques MitM. Os certificados foram inventados exatamente para combater esse problema.
A página de documentação relacionada do Postfix éTLS_README.
O servidor Postfix smtp (que é um serviço executado na porta TCP 465) suporta operação sem certificado, massomente para hosts internos:
Para servidores que não são hosts MX da Internet públicos, o Postfix suporta configurações sem certificados.
Primeiro de tudo, este é o único modo ativado quando você define smtpd_tls_cert_file = none, mas você não deve usá-lo para servidores voltados ao público. Em vez disso, use um certificado e um par de chaves confiáveis globalmente adequados. Aquele do Let's Encrypt servirá. Poderia ser configurado da seguinte maneira:
smtpd_tls_chain_files = /.../rsachain.pem
smtpd_tls_cert_file =
smtpd_tls_key_file =
onde este rsachain.pemarquivo deve conter concatenação do seguinte, nesta ordem: chave privada, certificado do servidor, cadeia de certificados.
Observe que o TLS 1.3 não oferece suporte à operação sem certificado. Portanto, uma maneira de se livrar do aviso (bom, na verdade) é desabilitar qualquer coisa mais antiga:
smtpd_tls_protocols = >=TLSv1.3
O problema com isso é que alguns clientes antigos ou não conformes (antigos o suficiente para não suportar o TLS v1.3) não conseguirão estabelecer a conexão TLS.
Outra maneira é desabilitar diretamente a operação sem certificado:
smtpd_tls_exclude_ciphers = aNULL
De qualquer forma, se o alerta nmap foi gerado simplesmente porque o Postfix não excluiu essa coisa aNULL, isso é um alarme falso, de acordo com o manual do Postfix:
Não se pode forçar um cliente SMTP remoto a verificar o certificado do servidor, portanto, excluir cifras anônimas geralmente é desnecessário.
A razão para isso é a seguinte consideração.
Mesmo quando isso está desabilitado no servidor, há um ataque de downgrade facilmente possível, que é um proxy MitM que publica apenas este conjunto aNULL e TLS v1.2 (ou menos). A única maneira de estar completamente protegido contra o problema é configurarclientesnão utilizar cifras anônimas e/ou protocolos vulneráveis e verificar o certificado do servidor. Você deve configurar isso em cada cliente individualmente, portanto não faz sentido desativá-lo no servidor.
Responder2
A versão mais alta doPostfix no servidor Ubuntu 20.04atualmente é Postfixv3.4.13. Oa versão mais estável do postfix é o Postfix v3.6, portanto, a mitigação dessas vulnerabilidades depende da sua versão do postfix.
Para qualquer versão do postfix, para mitigar essas vulnerabilidades, você precisa desabilitar qualquer coisa abaixoTLSv1.3no Postfix.
No Postfix inferior à versão 3.6você pode fazer isso editando seu /etc/postfix/main.cfarquivo.
sudo nano /etc/postfix/main.cf
e adicionando !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 !TLSv1.2às seguintes linhas:
smtpd_tls_mandatory_protocols =
smtpd_tls_protocols =
smtp_tls_mandatory_protocols =
smtp_tls_protocols =
no meu caso eu só tive que adicionar !TLSv1.2alterando as seguintes linhas
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
para
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, !TLSv1.2
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, !TLSv1.2
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, !TLSv1.2
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, !TLSv1.2
No Postfix inferior à versão 3.6, as alterações acima devem efetivamente fazer com que o postfix aceite "apenas" conexões TLSv1.3 e superiores, mitigando com êxito esta vulnerabilidade.
No postfix maior ou igual a v3.6você pode fazer isso editando seu /etc/postfix/main.cfarquivo.
sudo nano /etc/postfix/main.cf
e adicionando >=TLSv1.3às seguintes linhas:
smtpd_tls_mandatory_protocols =
smtpd_tls_protocols =
smtp_tls_mandatory_protocols =
smtp_tls_protocols =
então sua configuração /etc/postfix/main.cfdeve ficar assim:
smtpd_tls_mandatory_protocols = >=TLSv1.3
smtpd_tls_protocols = >=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.3
smtp_tls_protocols = >=TLSv1.3
No Postfix maior ou igual à versão 3.6, as alterações acima devem efetivamente fazer com que o postfix aceite "apenas" conexões TLSv1.3 e superiores, mitigando com êxito esta vulnerabilidade.
Responder3
smtpsé a porta para envio de e-mail usando criptografia TLS. A porta é usada pelo seu servidor SMTP.
Para fechar a vulnerabilidade, você precisa alterar a configuração do servidor SMTP. Existem duas opções:
- Desative o uso da porta 465. Você ainda pode usar outras portas SMTP para enviar e-mail.
- Corrija o problema de DH no servidor SMTP.
Outra alternativa é bloquear a porta 465 com o firewall.