nmap 취약점 스캔은 Ubuntu 20.04 웹 서버의 "포트 465 ssl-dh-params의 smtps" 취약점을 보고합니다. 취약점을 해결하는 방법은 무엇입니까?

nmap 취약점 스캔은 Ubuntu 20.04 웹 서버의 "포트 465 ssl-dh-params의 smtps" 취약점을 보고합니다. 취약점을 해결하는 방법은 무엇입니까?

저는 Ubuntu 20.04 LEMP(Linux, Nginx, MariaDb, PHP) 이메일/웹 서버를 실행하고 있습니다. 또한 MacOS 클라이언트 시스템에서 일부 nmap 취약성 테스트를 수행하고 있습니다. MacOS에서는 Oh My Zsh를 사용하고 있습니다! nmap 플러그인이 활성화되어 있습니다. 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 링크https://www.ietf.org/rfc/rfc2246.txt, 제가 ​​발견한 특정 취약점에 대한 참조를 제공하지 않습니다.

제 질문은 이 취약점이 무엇을 의미하는지, 어떤 프로세스가 이를 사용하고 있는지, 포트 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은 인증서 없는 작업을 지원하지 않습니다. 따라서 경고(실제로 좋은 것)를 제거하는 한 가지 방법은 오래된 것을 비활성화하는 것입니다.

smtpd_tls_protocols = >=TLSv1.3

이에 대한 문제는 일부 오래되었거나 부적합한 클라이언트(TLS v1.3을 지원하지 않을 만큼 오래됨)가 TLS 연결을 설정할 수 없다는 것입니다.

다른 방법은 인증서 없는 작업을 직접 비활성화하는 것입니다.

smtpd_tls_exclude_ciphers = aNULL

어쨌든, 단순히 Postfix가 이 aNULL 항목을 제외하지 않았기 때문에 nmap 경고가 발생한 경우 Postfix 매뉴얼에 따르면 이는 잘못된 경보입니다.

원격 SMTP 클라이언트가 서버 인증서를 확인하도록 강제할 수 없으므로 일반적으로 익명 암호를 제외하는 것은 불필요합니다.

그 이유는 다음과 같은 고려 때문이다.

서버에서 이 기능이 비활성화된 경우에도 이 NULL 제품군 및 TLS v1.2(또는 그 이하)만 게시하는 MitM 프록시인 다운그레이드 공격이 쉽게 가능합니다. 문제로부터 완전히 보호할 수 있는 유일한 방법은 다음을 구성하는 것입니다.클라이언트익명 암호 및/또는 취약한 프로토콜을 사용하지 않고 서버 인증서를 확인하십시오. 이를 각 클라이언트에서 개별적으로 구성해야 하므로 서버에서 비활성화할 필요가 없습니다.

답변2

가장 높은 버전의Ubuntu 20.04 서버의 Postfix현재는 Postfix입니다v3.4.13. 그만큼Postfix의 가장 안정적인 버전은 Postfix v3.6입니다., 따라서 이러한 취약점을 완화하는 방법은 postfix 버전에 따라 다릅니다.

두 버전의 postfix 모두에 대해, 이러한 취약점을 완화하려면 아래 항목을 비활성화해야 합니다.TLSv1.3포스트픽스에서.

버전 3.6 미만의 Postfix파일 을 편집하면 됩니다 /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

버전 3.6 미만의 Postfix, 위의 변경 사항으로 인해 postfix는 TLSv1.3 이상 연결만 "만" 허용하여 이 취약점을 성공적으로 완화할 수 있습니다.

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

smtpsTLS 암호화를 사용하여 이메일을 보내기 위한 포트입니다. 포트는 SMTP 서버에서 사용됩니다.

취약점을 해결하려면 SMTP 서버 구성을 변경해야 합니다. 두 가지 옵션이 있습니다:

  1. 포트 465가 사용되지 않도록 비활성화합니다. 이메일 전송을 위해 다른 SMTP 포트를 계속 사용할 수 있습니다.
  2. SMTP 서버의 DH 문제를 해결하세요.

또 다른 대안은 방화벽으로 포트 465를 차단하는 것입니다.

관련 정보