☰

nmap 脆弱性スキャンにより、Ubuntu 20.04 Web サーバー上の「ポート 465 の SMTP、ssl-dh-params」脆弱性が報告されました。この脆弱性を解消するにはどうすればよいでしょうか?

tag-icon • tag-icon ubuntu nmap vulnerabilities smtps
nmap 脆弱性スキャンにより、Ubuntu 20.04 Web サーバー上の「ポート 465 の SMTP、ssl-dh-params」脆弱性が報告されました。この脆弱性を解消するにはどうすればよいでしょうか?

私は Ubuntu 20.04 LEMP (Linux、Nginx、MariaDb、PHP) のメール/Web サーバーを実行しています。また、MacOS クライアント マシンから nmap 脆弱性テストも実行しています。MacOS では、nmap プラグインを有効にした Oh My Zsh! を使用しています。MacOS クライアント マシンから Ubuntu Server で脆弱性テストを実行するために、次のコマンドを発行しました。

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リンク出典: IETF.org、私が見つけたこの特定の脆弱性への参照は提供されていません。

私の質問は、この脆弱性が何を意味するのか、どのプロセスがそれを使用しているのか、そしてポート 456 を無効にせずに Ubuntu 20.04 サーバーでこの脆弱性を軽減するにはどうすればよいのかということです。postfix/dovecot SMTP サーバーの Diffie Hellman 問題を修正する必要がありますか。修正する必要がある場合、修正方法を教えてください。

答え1

匿名 TLS は、「証明書なしの TLS」とも呼ばれる構成の一種です。サーバーのキーペアに対する信頼チェーンがないため、MitM 攻撃から完全に保護されません。証明書はまさにこの問題に対抗するために発明されました。

関連するPostfixドキュメントページはTLS_README。

Postfix SMTPサーバー（TCPポート465で実行されるサービス）は証明書なしの操作をサポートしていますが、内部ホストのみ:

パブリック インターネット 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 は証明書なしの操作をサポートしていないことに注意してください。したがって、警告を消す 1 つの方法 (実際、良い方法です) は、古いものをすべて無効にすることです。

smtpd_tls_protocols = >=TLSv1.3

これに伴う問題は、一部の古いクライアントや非準拠のクライアント (TLS v1.3 をサポートしていないほど古いクライアント) が TLS 接続を確立できないことです。

他の方法は、証明書なしの操作を直接無効にすることです。

smtpd_tls_exclude_ciphers = aNULL

いずれにせよ、Postfix がこの aNULL を除外していなかったために nmap アラートが生成されたのであれば、Postfix マニュアルによると、これは誤報です。

リモート SMTP クライアントにサーバー証明書の確認を強制することはできないため、匿名暗号を除外することは通常不要です。

その理由は次のような考察によるものです。

サーバー上でこの機能が無効になっている場合でも、このaNULLスイートとTLS v1.2（またはそれ以下）のみを公開する中間者プロキシによるダウングレード攻撃は簡単に起こり得ます。この問題から完全に保護される唯一の方法は、クライアント匿名暗号や脆弱なプロトコルを使用しないようにし、サーバー証明書をチェックします。これは各クライアントで個別に設定する必要があるため、サーバーで無効にしても意味がありません。

答え2

最高バージョンのUbuntu 20.04 サーバーの Postfix現在はPostfixバージョン3.4.13。Postfixの最も安定したバージョンはPostfix v3.6です。したがって、これらの脆弱性を軽減する方法は、postfix のバージョンによって異なります。

どちらのバージョンのPostfixでもこれらの脆弱性を軽減するには、以下のものを無効にする必要があります。TLSv1.3Postfix で。

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バージョン3.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

smtpsTLS 暗号化を使用して電子メールを送信するためのポートです。このポートは SMTP サーバーによって使用されます。

脆弱性を解消するには、SMTP サーバーの設定を変更する必要があります。次の 2 つのオプションがあります。

  1. ポート 465 の使用を無効にします。電子メールの送信には他の SMTP ポートを引き続き使用できます。
  2. SMTP サーバーの DH 問題を修正します。

別の方法としては、ファイアウォールでポート 465 をブロックする方法があります。

関連情報