☰

El escaneo de vulnerabilidades de nmap informa la vulnerabilidad "smtps en el puerto 465 ssl-dh-params", en el servidor web Ubuntu 20.04. ¿Cómo cerrar la vulnerabilidad?

tag-icon • tag-icon ubuntu nmap vulnerabilities smtps
El escaneo de vulnerabilidades de nmap informa la vulnerabilidad "smtps en el puerto 465 ssl-dh-params", en el servidor web Ubuntu 20.04. ¿Cómo cerrar la vulnerabilidad?

Estoy ejecutando un servidor web/de correo electrónico Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP). También estoy haciendo algunas pruebas de vulnerabilidad de nmap desde mi máquina cliente MacOS. En MacOS, estoy usando Oh My Zsh! con el complemento nmap habilitado. Para realizar algunas pruebas de vulnerabilidad en mi servidor Ubuntu desde mi máquina cliente MacOS, emití el comando:

nmap_check_for_vulns my.server.ip.address

que es un comando de alias para

nmap --script=vuln

Después de emitir el comando con la dirección IP de mi servidor, nmap informó las siguientes 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

En el servidor, la salida de sudo -ss lnptes:

LISTEN                        0                             100                                                        0.0.0.0:465                                                      0.0.0.0:*                            users:(("smtpd",pid=586529,fd=6),("master",pid=2078,fd=29))

El enlace nmap proporcionadohttps://www.ietf.org/rfc/rfc2246.txt, no proporciona referencia a esta vulnerabilidad ESPECÍFICA que puedo encontrar.

Mi pregunta es, ¿qué significa esta vulnerabilidad, qué proceso la está utilizando y cómo puedo mitigar esta vulnerabilidad en mi servidor Ubuntu 20.04, sin deshabilitar el puerto 456? ¿Necesito solucionar el problema de Diffie Hellman en los servidores SMTP postfix/dovecot y, de ser así, cómo hago para hacerlo?

Respuesta1

TLS anónimo es el tipo de configuración que también se conoce como "TLS sin certificados". No existe una cadena de confianza para el par de claves del servidor, por lo tanto, no hay absolutamente ninguna protección contra los ataques MitM. Los certificados se inventaron precisamente para combatir este problema.

La página de documentación relacionada de Postfix esTLS_README.

El servidor smtp de Postfix (que es un servicio que se ejecuta en el puerto TCP 465) admite operaciones sin certificado, perosólo para hosts internos:

Para servidores que no son hosts públicos de Internet MX, Postfix admite configuraciones sin certificados.

En primer lugar, este es el único modo habilitado cuando configura smtpd_tls_cert_file = none, pero no debe usarlo para servidores públicos. En su lugar, utilice un par de claves y un certificado de confianza global adecuado. El de Let's Encrypt servirá. Se podría configurar de la siguiente manera:

smtpd_tls_chain_files = /.../rsachain.pem
smtpd_tls_cert_file =
smtpd_tls_key_file =

donde este rsachain.pemarchivo debe contener la concatenación de lo siguiente, en ese orden: clave privada, certificado de servidor, cadena de certificados.

Tenga en cuenta que TLS 1.3 no admite operaciones sin certificados. Entonces, una forma de deshacerse de la advertencia (buena, en realidad) es deshabilitar cualquier cosa anterior:

smtpd_tls_protocols = >=TLSv1.3

El problema con esto es que algunos clientes antiguos o no conformes (lo suficientemente antiguos como para no admitir TLS v1.3) no podrán establecer una conexión TLS.

Otra forma es deshabilitar directamente la operación sin certificado:

smtpd_tls_exclude_ciphers = aNULL

De todos modos, si la alerta de nmap se generó simplemente porque Postfix no tenía excluido este elemento NULL, esto es una falsa alarma, según el manual de Postfix:

No se puede obligar a un cliente SMTP remoto a verificar el certificado del servidor, por lo que generalmente no es necesario excluir cifrados anónimos.

La razón de esto es la siguiente consideración.

Incluso cuando esto está deshabilitado en el servidor, existe un ataque de degradación fácilmente posible, que es un proxy MitM que solo publica esta suite NULL y TLS v1.2 (o menos). La única forma de estar completamente protegido contra el problema es configurarclientelano utilizar cifrados anónimos y/o protocolos vulnerables y comprobar el certificado del servidor. Debe configurar esto en cada cliente individualmente, por lo que no tiene sentido deshabilitarlo en el servidor.

Respuesta2

La versión más alta dePostfix en el servidor Ubuntu 20.04actualmente es Postfixv3.4.13. ElLa versión estable más alta de Postfix es Postfix v3.6., por lo que mitigar estas vulnerabilidades depende de su versión de postfix.

Para cualquier versión de postfix, para mitigar estas vulnerabilidades, debe desactivar todo lo siguienteTLSv1.3en Postfix.

En Postfix inferior a la versión 3.6puedes hacer esto editando tu /etc/postfix/main.cfarchivo.

sudo nano /etc/postfix/main.cf

y añadiendo !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 !TLSv1.2a las siguientes líneas:

smtpd_tls_mandatory_protocols = 
smtpd_tls_protocols = 
smtp_tls_mandatory_protocols = 
smtp_tls_protocols =

en mi caso solo tuve que agregar !TLSv1.2cambiando las siguientes líneas

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

a

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

En Postfix inferior a la versión 3.6, los cambios anteriores deberían hacer que postfix "solo" acepte conexiones TLSv1.3 y superiores, mitigando exitosamente esta vulnerabilidad.

En postfix mayor o igual a v3.6puedes hacer esto editando tu /etc/postfix/main.cfarchivo.

sudo nano /etc/postfix/main.cf

y añadiendo >=TLSv1.3a las siguientes líneas:

smtpd_tls_mandatory_protocols = 
smtpd_tls_protocols = 
smtp_tls_mandatory_protocols = 
smtp_tls_protocols =

entonces su configuración /etc/postfix/main.cfdebería verse así:

smtpd_tls_mandatory_protocols = >=TLSv1.3
smtpd_tls_protocols = >=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.3
smtp_tls_protocols = >=TLSv1.3

En Postfix mayor o igual a la versión 3.6, los cambios anteriores deberían hacer que postfix "solo" acepte conexiones TLSv1.3 y superiores, mitigando exitosamente esta vulnerabilidad.

Respuesta3

smtpses el puerto para enviar correo electrónico mediante cifrado TLS. El puerto lo utiliza su servidor SMTP.

Para cerrar la vulnerabilidad, debe cambiar la configuración de su servidor SMTP. Hay dos opciones:

  1. Deshabilite el uso del puerto 465. Aún puedes usar otros puertos SMTP para enviar correo electrónico.
  2. Solucione el problema de DH en el servidor SMTP.

Otra alternativa es bloquear el puerto 465 con el firewall.

información relacionada