我正在運行 Ubuntu 20.04 LEMP（Linux、Nginx、MariaDb、PHP）電子郵件/Web 伺服器。我還在我的 MacOS 用戶端電腦上進行一些 nmap 漏洞測試。在 MacOS 上，我使用 Oh My Zsh！啟用 nmap 插件。為了從 MacOS 用戶端電腦上對 Ubuntu 伺服器進行一些漏洞測試，我發出了以下命令：
nmap_check_for_vulns my.server.ip.address
這是一個別名命令
nmap --script=vuln
使用我的伺服器的 IP 位址發出命令後，nmap 報告了以下漏洞：
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
在伺服器上，輸出為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))
提供的 nmap 鏈接https://www.ietf.org/rfc/rfc2246.txt，沒有提供我能找到的這個特定漏洞的參考。
我的問題是，這個漏洞意味著什麼，什麼進程正在使用它，以及如何在不禁用連接埠 456 的情況下在 Ubuntu 20.04 伺服器上緩解此漏洞？我是否需要修復 postfix/dovecot SMTP 伺服器中的 Diffie Hellman 問題？
答案1
匿名 TLS 是一種配置，也稱為「無憑證 TLS」。伺服器金鑰對沒有信任鏈，因此絕對無法防範中間人攻擊。證書的發明正是為了解決這個問題。
相關 Postfix 文件頁是TLS_自述文件。
Postfix smtp 伺服器（這是在 TCP 連接埠 465 上執行的服務）支援無憑證操作，但是僅適用於內部主機：
對於不是公用 Internet MX 主機的伺服器，Postfix 支援沒有憑證的設定。
首先，這是您設定時啟用的唯一模式smtpd_tls_cert_file = none，但您不能將其用於面向公眾的伺服器。相反，請使用適當的全球可信任證書和密鑰對。 Let's Encrypt 的那個就可以了。可以透過以下方式設定：
smtpd_tls_chain_files = /.../rsachain.pem
smtpd_tls_cert_file =
smtpd_tls_key_file =
其中該rsachain.pem文件應依序包含以下內容的串連：私鑰、伺服器憑證、憑證鏈。
請注意，TLS 1.3 不支援無憑證操作。因此，消除警告的一種方法（實際上是一種好的方法）是禁用任何較舊的內容：
smtpd_tls_protocols = >=TLSv1.3
這樣做的問題是，一些舊的或不合格的客戶端（舊到不支援 TLS v1.3）將無法建立 TLS 連線。
另一種方法是直接停用無憑證操作：
smtpd_tls_exclude_ciphers = aNULL
無論如何，如果僅僅因為 Postfix 沒有排除 aNULL 就引發 nmap 警報，那麼根據 Postfix 手冊，這是一個誤報：
人們無法強制遠端 SMTP 用戶端檢查伺服器證書，因此通常沒有必要排除匿名密碼。
其理由如下。
即使在伺服器上停用此功能，也很容易發生降級攻擊，即僅發布此 aNULL 套件和 TLS v1.2（或更低版本）的 MitM 代理程式。完全避免此問題的唯一方法是配置客戶不使用匿名密碼和/或易受攻擊的協定並檢查伺服器憑證。您必須在每個用戶端上單獨配置此功能，因此沒有必要在伺服器上停用它。
答案2
最高版本Ubuntu 20.04 伺服器中的 Postfix目前是Postfixv3.4.13。這postfix的最高穩定版本是Postfix v3.6，因此緩解這些漏洞取決於您的 postfix 版本。
對於任一版本的 postfix，為了緩解這些漏洞，您需要停用以下任何內容TLSv1.3在後綴中。
在 Postfix 3.6 以下版本中您可以透過編輯/etc/postfix/main.cf文件來做到這一點。
sudo nano /etc/postfix/main.cf
並加入!SSLv2, !SSLv3, !TLSv1, !TLSv1.1 !TLSv1.2以下行：
smtpd_tls_mandatory_protocols =
smtpd_tls_protocols =
smtp_tls_mandatory_protocols =
smtp_tls_protocols =
就我而言，我只需!TLSv1.2通過更改以下行來添加
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
到
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
在 Postfix 3.6 以下版本中，上述更改應該會有效地導致 postfix「僅」接受 TLSv1.3 及更高版本的連接，從而成功緩解此漏洞。
在 postfix 大於或等於 v3.6 中您可以透過編輯/etc/postfix/main.cf文件來做到這一點。
sudo nano /etc/postfix/main.cf
並加入>=TLSv1.3以下行：
smtpd_tls_mandatory_protocols =
smtpd_tls_protocols =
smtp_tls_mandatory_protocols =
smtp_tls_protocols =
所以你的配置/etc/postfix/main.cf應該是這樣的：
smtpd_tls_mandatory_protocols = >=TLSv1.3
smtpd_tls_protocols = >=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.3
smtp_tls_protocols = >=TLSv1.3
在 Postfix 大於或等於 3.6 版本中，上述更改應該會有效地導致 postfix「僅」接受 TLSv1.3 及更高版本的連接，從而成功緩解此漏洞。
答案3
smtps是使用 TLS 加密傳送電子郵件的連接埠。該連接埠由您的 SMTP 伺服器使用。
若要消除漏洞，您需要變更 SMTP 伺服器設定。有兩種選擇：
- 禁止使用 465 連接埠。您仍然可以使用其他 SMTP 連接埠傳送電子郵件。
- 修復 SMTP 伺服器中的 DH 問題。
另一種選擇是使用防火牆阻止連接埠 465。