Tech Blog.

Thoughts, stories, ideas.

Mailserver Security

15. February 2018

Wenn es um SSL/TLS Konfigurationen geht, rücken Mailserver weniger schnell in den Blickpunkt als Webserver. Auch diese sollten eine solide SSL/TLS-Konfiguration mit gültigen Zertifikaten geniessen. In den Protokollen IMAP und POP3 fallen komplett falsch konfigurierte Mailserver schnell auf, in der Server-Server-Kommunikation jedoch sind oft unzureichende Standards gesetzt. Des Öfteren werden ungültige oder gar keine Zertifikate akzeptiert, da eine Verbindung wichtiger ist, als die Sicherheit.

SSL/TLS Konfiguration bei Postfix

Folgend ein Auszug aus der Postfix (htt Main Configuration, welcher sich allerdings jederzeit ändern kann. Sehr wichtige Optionen sind smtpd_tls_security_level und smtp_tls_security_level, welche standardmässig “none” sind. Das bedeutet, dass der Server nie TLS verwenden wird. Daher sollten diese Optionen immer auf may oder encrypt gesetzt werden

# TLS parameters
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

 

SSL/TLS Konfiguration bei Dovecot

Dies ist ein Auszug aus der Dovecot Configuration und zeigt eine mögliche Konfiguration der SSL/TLS-Parameter für Dovecot auf.

# DH parameters length to use. ssl_dh_parameters_length = 4096   # SSL protocols to use. ssl_protocols = !SSLv2 !SSLv3   # SSL ciphers to use ssl_cipher_list = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS   # Prefer the server's order of ciphers over client's. ssl_prefer_server_ciphers = yes

Sender Policy Framework (SPF)

Mit Hilfe von SPF (RFC 7208) kann validiert werden, ob ein Server, welcher eine E-Mail zustellen will, auch berechtigt ist von der entsprechenden Domain E-Mails zu versenden.

Beispielsweise baut der Server smtp.send.example.com eine Verbindung zum Server smtp.recv.example.com auf und versucht ihm eine E-Mail von user@mail.example.com zuzustellen. Anhand von SPF kann der Server smtp.recv.example.com überprüfen, ob der Server smtp.send.example.com ein gültiger E-Mail-Server für die Domain mail.example.com ist.

Der entsprechende SPF Record existiert im DNS-System und kann in etwa wie folgt aussehen:

mail.example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all"

Das heisst wenn eine der folgenden Bedingungen erfüllt ist, wird die E-Mail angenommen:

    • die IP Adresse des Servers smtp.send.example.com innerhalb von 192.0.2.0/24 oder 2001:db8::1 liegt
    • der DNS A Record mail.example.com der IP Adresse des Servers smtp.send.example.com entspricht

In allen anderen Fällen muss die E-Mail weitere Checks durchlaufen (welche selber definiert werden können).

DomainKeys Identified Mail (DKIM) Signaturen

Die Idee hinter DomainKeys Identified Mail (DKIM, RFC 6376) ist, zu prüfen, dass eine E-Mail während des Transports nicht verändert wurde. Um dies sicherzustellen, werden die Header, der Content und die Attachments einer E-Mail signiert. Dabei wird jedoch nicht der gesamte Header signiert, da sich dort beim Transport einer E-Mail gewisse Felder ändern können. Das RFC schlägt vor, folgende Werte zu signieren:

  • From (REQUIRED)
  • Reply-To
  • Subject
  • Date
  • To, Cc
  • Resent-Date, Resent-From, Resent-To, Resent-Cc
  • In-Reply-To, References
  • List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

DKIM-Signaturen werden im Header einer E-Mail abgelegt, das Feld nennt sich DKIM-Signature. Der Wert dieses Feldes beinhaltet mehrere Key-Value-Paare. Die Wichtigsten sind:

  • v: DKIM version
  • a: algorithm (e.g. rsa-sha256)
  • d: signing domain (origin Domain)
  • s: selector

Ein empfangender E-Mail-Server kann anhand der Domain und des Selectors den aktuellen Domain Key über DNS anfragen. Der DNS-Eintrag sieht in etwa wie folgt aus:

selector._domainkey.example.com IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )

Wird also eine E-Mail mit dem Header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.org; s=mail; t=1498137281; bh=ClzbA4T6yvpEouOct2aSAnFWcEUHTr6SDxrQizAy6ao=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=QTY/4jFXMH2piHJ478mtyQ6heutdCLw/VCrD3XcDVugITPSXnrEqiV07+N9YNQcTraCmyxT49upd8uz9fqRLz0VTZWoPF3+9eT9X2jdQU/1WpVtalFrQuBoXfzy4KZJdxp/DjwAB89CkmvRvv5aYSw0XrJsry1uMoVJx6NDCskA=

empfangen, so ist der entsprechende TXT-DNS-Eintrag, welcher den Key referenziert, “mail._domainkey.example.org“.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) erweitert die beiden Mechanismen DKIM und SPF. Wenn kein DKIM Header vorhanden ist oder kein SPF Record gefunden wird, wird bei diesen beiden Verfahren nichts gemacht und die E-Mail normal behandelt. DMARC bietet die Möglichkeit, zu sagen, was mit einer E-Mail, bei der eines oder beide Verfahren nicht vorhanden sind, gemacht werden soll. DMARC ist auch ein bisschen strikter, was das DKIM Handling angeht, so muss z.B. die From-Adresse mit der Domain im DKIM-Signature Feld übereinstimmen. Ein weiterer Punkt, den DMARC ermöglicht, ist das Reporting von falsch verschickten E-Mails. So können Reports von empfangenden E-Mail-Servern angefordert werden.

Wie auch DKIM wird DMARC im DNS publiziert. Ein möglicher Eintrag sieht in etwa wie folgt aus:

_dmarc.example.com IN TXT "v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com"

Wobei die einzelnen Werte folgende Bedeutung haben:

  • v: Version
  • p: Policy für diese Domain
  • sp: Policy für Subdomains
  • pct: Prozent der “schlechten” E-Mails, ab wann die Policy greifen soll
  • rua: DMARC Report URI Adresse

Testen

Manuell kann mit openssl getestet werden. Dies sind nur Basis-Befehle, welche den Inhalt des Server-Zertifikates in Textform darstellen. Es können auch Cipher-Suites getestet werden, da dies aber lange und vielzählige Commands sind, wird empfohlen, dies mit den vorhandenen Diensten (bspw. Hardenize) zu machen. Ist dies nicht gewünscht oder technisch nicht möglich, kann SSL Decoder auch lokal installiert werden, da die Software Open Source auf GitHub verfügbar ist.

  • SMTP
$ openssl s_client -connect example.com:25 -starttls smtp 2>/dev/null </dev/zero | openssl x509 -noout -text

 

  • IMAP
$ openssl s_client -connect example.com:143 -starttls imap 2>/dev/null </dev/zero | openssl x509 -noout -text

Zusätzliche Features wie SPF oder DMARC zu testen, kann zum einen sehr simpel gemacht werden, indem einfach die DNS Records überprüft werden:

# SPF Record $ dig +short TXT example.com "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all" # DKIM $ dig +short TXT mail._domainkey.example.com "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB"   # DMARC $ dig +short TXT _dmarc.example.com "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.com"

Um umfassendere Tests mit einer Auswertung des Inhalts zu machen, eignen sich diverse Anbieter, wie z.B. Hardenize oder MX Toolbox.

Weiterführendes

Des Weiteren ist anzumerken, dass DNS-based Authentication of Named Entities (DANE) auch bei E-Mail-Servern eingesetzt werden kann. Dies sprengt aber den Rahmen dieses Blog-Posts und wird in einem anderen behandelt werden. Es gibt auch sehr gute HowTo-Guides für E-Mail-Server, hier sollen die folgenden zwei genannt werden:

Links