☰

Der Nmap-Schwachstellenscan meldet die Schwachstelle „SMTPs auf Port 465 SSL-DH-Params“ auf dem Ubuntu 20.04-Webserver. Wie kann die Schwachstelle geschlossen werden?

tag-icon • tag-icon ubuntu nmap vulnerabilities smtps
Der Nmap-Schwachstellenscan meldet die Schwachstelle „SMTPs auf Port 465 SSL-DH-Params“ auf dem Ubuntu 20.04-Webserver. Wie kann die Schwachstelle geschlossen werden?

Ich verwende einen Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP) E-Mail-/Webserver. Ich führe auch einige Nmap-Schwachstellentests von meinem MacOS-Client-Rechner aus durch. Unter MacOS verwende ich Oh My Zsh! mit aktiviertem Nmap-Plugin. Um einige Schwachstellentests auf meinem Ubuntu-Server von meinem MacOS-Client-Rechner aus durchzuführen, habe ich den folgenden Befehl eingegeben:

nmap_check_for_vulns my.server.ip.address

Das ist ein Alias-Befehl für

nmap --script=vuln

Nachdem ich den Befehl mit der IP-Adresse meines Servers eingegeben hatte, meldete nmap die folgenden Schwachstellen:

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

Auf dem Server lautet die Ausgabe 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))

Der bereitgestellte Nmap-Linkhttps://www.ietf.org/rfc/rfc2246.txt, enthält keinen Hinweis auf diese SPEZIFISCHE Sicherheitslücke, den ich finden kann.

Meine Frage ist, was diese Sicherheitslücke bedeutet, welcher Prozess sie nutzt und wie ich diese Sicherheitslücke auf meinem Ubuntu 20.04-Server beheben kann, ohne Port 456 zu deaktivieren. Muss ich das Diffie-Hellman-Problem in den Postfix/Dovecot-SMTP-Servern beheben und wenn ja, wie gehe ich dabei vor?

Antwort1

Anonymes TLS ist eine Konfiguration, die auch als „TLS ohne Zertifikate“ bekannt ist. Es gibt keine Vertrauenskette für das Schlüsselpaar des Servers und daher absolut keinen Schutz vor MitM-Angriffen. Zertifikate wurden genau zu diesem Zweck entwickelt.

Die zugehörige Postfix-Dokumentationsseite istTLS_README.

Der Postfix SMTP-Server (ein Dienst, der auf TCP-Port 465 läuft) unterstützt den zertifikatlosen Betrieb, abernur für interne Hosts:

Für Server, die keine öffentlichen Internet-MX-Hosts sind, unterstützt Postfix Konfigurationen ohne Zertifikate.

Zunächst einmal ist dies der einzige Modus, der aktiviert wird, wenn Sie festlegen smtpd_tls_cert_file = none, aber Sie dürfen ihn nicht für öffentlich zugängliche Server verwenden. Verwenden Sie stattdessen ein geeignetes, global vertrauenswürdiges Zertifikat und Schlüsselpaar. Das von Let's Encrypt reicht aus. Es könnte folgendermaßen eingerichtet werden:

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

wobei diese rsachain.pemDatei eine Verkettung der folgenden Elemente in dieser Reihenfolge enthalten sollte: privater Schlüssel, Serverzertifikat, Zertifikatskette.

Beachten Sie, dass TLS 1.3 den zertifikatlosen Betrieb nicht unterstützt. Eine Möglichkeit, die Warnung loszuwerden (und das ist eigentlich eine gute), besteht darin, alles Ältere zu deaktivieren:

smtpd_tls_protocols = >=TLSv1.3

Das Problem dabei ist, dass einige alte oder nicht konforme Clients (alt genug, um TLS v1.3 nicht zu unterstützen) keine TLS-Verbindung herstellen können.

Eine andere Möglichkeit besteht darin, den zertifikatslosen Betrieb direkt zu deaktivieren:

smtpd_tls_exclude_ciphers = aNULL

Wenn der Nmap-Alarm nur deshalb ausgelöst wurde, weil Postfix dieses aNULL-Ding nicht ausgeschlossen hat, handelt es sich gemäß dem Postfix-Handbuch um einen Fehlalarm:

Da ein Remote-SMTP-Client nicht gezwungen werden kann, das Serverzertifikat zu überprüfen, ist der Ausschluss anonymer Chiffren im Allgemeinen nicht erforderlich.

Grund hierfür ist folgende Überlegung.

Selbst wenn diese Funktion auf dem Server deaktiviert ist, ist ein Downgrade-Angriff leicht möglich. Dabei handelt es sich um einen MitM-Proxy, der nur diese aNULL-Suite und TLS v1.2 (oder niedriger) veröffentlicht. Die einzige Möglichkeit, vollständig vor diesem Problem geschützt zu sein, besteht in der KonfigurationKundenkeine anonymen Chiffren und/oder anfällige Protokolle zu verwenden und das Serverzertifikat zu überprüfen. Sie müssen dies auf jedem Client einzeln konfigurieren, es macht also keinen Sinn, es auf dem Server zu deaktivieren.

Antwort2

Die höchste Version vonPostfix in Ubuntu 20.04 Serverderzeit ist PostfixVersion 3.4.13. DerDie höchste stabile Version von Postfix ist Postfix v3.6, daher hängt die Minderung dieser Schwachstellen von Ihrer Postfix-Version ab.

Für beide Versionen von PostfixUm diese Schwachstellen zu beheben, müssen Sie Folgendes deaktivieren:TLSv1.3in Postfix.

In Postfix niedriger als Version 3.6Sie können dies tun, indem Sie Ihre /etc/postfix/main.cfDatei bearbeiten.

sudo nano /etc/postfix/main.cf

und fügen Sie !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 !TLSv1.2die folgenden Zeilen hinzu:

smtpd_tls_mandatory_protocols = 
smtpd_tls_protocols = 
smtp_tls_mandatory_protocols = 
smtp_tls_protocols =

in meinem Fall musste ich nur !TLSv1.2die folgenden Zeilen ändern

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

Zu

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 niedriger als Version 3.6, die oben genannten Änderungen sollten dazu führen, dass Postfix „nur“ Verbindungen mit TLSv1.3 und höher akzeptiert, wodurch diese Sicherheitslücke erfolgreich geschlossen wird.

In Postfix größer oder gleich v3.6Sie können dies tun, indem Sie Ihre /etc/postfix/main.cfDatei bearbeiten.

sudo nano /etc/postfix/main.cf

und fügen Sie >=TLSv1.3die folgenden Zeilen hinzu:

smtpd_tls_mandatory_protocols = 
smtpd_tls_protocols = 
smtp_tls_mandatory_protocols = 
smtp_tls_protocols =

Ihre Konfiguration sollte also /etc/postfix/main.cffolgendermaßen aussehen:

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

In Postfix größer oder gleich Version 3.6, die oben genannten Änderungen sollten dazu führen, dass Postfix „nur“ Verbindungen mit TLSv1.3 und höher akzeptiert, wodurch diese Sicherheitslücke erfolgreich geschlossen wird.

Antwort3

smtpsist der Port zum Senden von E-Mails mit TLS-Verschlüsselung. Der Port wird von Ihrem SMTP-Server verwendet.

Um die Sicherheitslücke zu schließen, müssen Sie die Konfiguration Ihres SMTP-Servers ändern. Dazu gibt es zwei Möglichkeiten:

  1. Deaktivieren Sie die Verwendung von Port 465. Sie können weiterhin andere SMTP-Ports zum Senden von E-Mails verwenden.
  2. Beheben Sie das DH-Problem im SMTP-Server.

Eine andere Alternative besteht darin, Port 465 mit der Firewall zu blockieren.

verwandte Informationen