2

I am running an Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP) email/web server. I am also doing some nmap vulnerability tests form my MacOS Client machine. On MacOS, I am using Oh My Zsh! with the nmap plugin enabled. To do some vulnerability tests on my Ubuntu Server from my MacOS client machine, I issued the command:

nmap_check_for_vulns my.server.ip.address

which is an alias command for

nmap --script=vuln

After issuing the command with my server's IP address, nmap reported the following Vulnerabilities:

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

On the server, the output of sudo -ss lnpt is:

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

The provided nmap link https://www.ietf.org/rfc/rfc2246.txt, doesn't provide reference to this SPECIFIC vulnerability that I can find.

My question is, what does this vulnerability mean, what process is using it, and how can I mitigate this vulnerability on my Ubuntu 20.04 server, without disabling port 456? Do I need to fix the Diffie Hellman issue in the postfix/dovecot SMTP servers, and if so, how do I go about doing so?

DanRan
  • 133

3 Answers3

2

Anonymous TLS is the kind of configuration is also known as "TLS without certificates". There is no chain of trust for server's keypair, therefore absolutely no protection from MitM attacks. Certificates were invented exactly to fight this issue.

Related Postfix documentation page is TLS_README.

Postfix smtp server (which is a service running on TCP port 465) supports certificate-less operation, but only for internal hosts:

For servers that are not public Internet MX hosts, Postfix supports configurations with no certificates.

First of all, this is the only mode enabled when you set smtpd_tls_cert_file = none, but you must not use this for public-facing server. Instead, use proper globally trusted certificate and key pair. The one from Let's Encrypt will do. It could be setup in a following way:

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

where this rsachain.pem file should contain concatenation of the following, in that order: private key, server certificate, certificate chain.

Notice that TLS 1.3 does not support certificate-less operation. So one way get rid of the warning (good one, actually) is to disable anything older:

smtpd_tls_protocols = >=TLSv1.3

The problem with this is that some old or non-conforming clients (old enough to not support TLS v1.3) will be unable to establish TLS connection.

Other way is to directly disable certificate-less operation:

smtpd_tls_exclude_ciphers = aNULL

Anyway, if the nmap alert was raised simply because Postfix did not have this aNULL thing excluded, this is a false alarm, according to the Postfix manual:

One can't force a remote SMTP client to check the server certificate, so excluding anonymous ciphers is generally unnecessary.

The reason for this is the following consideration.

Even when this thing is disabled on the server there is an easily possible downgrade attack which is a MitM proxy that only publishes this aNULL suite and TLS v1.2 (or less). The only way to be completely protected from the issue is to configure clients to not use anonymous ciphers and/or vulnerable protocols and to check the server certificate. You must configure this on each client individually, so there is no point to disable it on the server.

Nikita Kipriyanov
  • 15,624
0

The highest version of Postfix in Ubuntu 20.04 Server currently is Postfix v3.4.13. The highest stable version of postfix is Postfix v3.6, so mitigating these vulnerabilities depends on your version of postfix.

For either version of postfix, to mitigate these vulnerabilities, you need to disable anything below TLSv1.3 in Postfix.

In Postfix less than version 3.6 you can do this by editing your /etc/postfix/main.cf file.

sudo nano /etc/postfix/main.cf

and adding !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 !TLSv1.2 to the following lines:

smtpd_tls_mandatory_protocols = 
smtpd_tls_protocols = 
smtp_tls_mandatory_protocols = 
smtp_tls_protocols =

in my case I just had to add !TLSv1.2 by changing the following lines

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

to

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

In Postfix less than version 3.6, the above changes should effectively cause postfix to "only" accept TLSv1.3 connections and higher, successfully mitigating this vulnerability.

In postfix greater than or equal to v3.6 you can do this by editing your /etc/postfix/main.cf file.

sudo nano /etc/postfix/main.cf

and adding >=TLSv1.3 to the following lines:

smtpd_tls_mandatory_protocols = 
smtpd_tls_protocols = 
smtp_tls_mandatory_protocols = 
smtp_tls_protocols =

so your configuration in /etc/postfix/main.cf should look like this:

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

In Postfix greater than or equal to version 3.6, the above changes should effectively cause postfix to "only" accept TLSv1.3 connections and higher, successfully mitigating this vulnerability.

DanRan
  • 133
-1

smtps is the port for sending email using TLS encryption. The port is used by your SMTP server.

To close the vulnerability, you need to change your SMTP server configuration. There are two options:

  1. Disable port 465 from being used. You can still use other SMTP ports for sending email.
  2. Fix the DH issue in the SMTP server.

Another alternative is to block port 465 with the firewall.

Tero Kilkanen
  • 38,887