IT-Blog von Sebastian van de Meer

Schlagwort: Exchange

Windows Server mit Exchange: SSL Labs A+ erreichen

Qualis A+ Icon.

Ich hatte hier einen Windows Server 2012 R2 mit Exchange 2016 stehen. Out of the Box sprach das Ding TLS 1.0, SSLv3 und RC4. Da gehen einem die Haare hoch. Kann man so ein System auf ein A+ bei Qualys SSL Labs bekommen und es funktioniert danach noch? Kleiner Spoiler: Ja, geht.

Ich muss zugeben, Microsoft-Produkte strengen mich in dieser Hinsicht immer an. Die haben ihre Daseinsberechtigung, keine Frage. Aber TLS-Hardening unter Windows fühlt sich an wie Zahnmedizin mit Handschuhen aus Pappe.

Hinweis: Windows Server 2012 R2 und Exchange 2016 sind inzwischen End of Life. Der Ansatz (Registry-Änderungen für TLS, HSTS im IIS) funktioniert auf Windows Server 2016/2019/2022 aber genauso.

HSTS im IIS setzen

Für ein A+ braucht man neben sauberen Ciphern und Protokollen auch HTTP Strict Transport Security (HSTS). Das ist im Grunde nur ein HTTP-Response-Header. Im IIS-Manager konfiguriert man ihn ganz oben auf Server-Ebene, damit er überall vererbt wird:

IIS-Manager → HTTP-Antwortheader → Hinzufügen:

Screenshot der Internetinformationsdienste (IIS)-Manager.
Name:  strict-transport-security
Wert:  max-age=31536000; includeSubdomains

TLS-Protokolle und Cipher härten

Jetzt der eigentlich spannende Teil. Man muss eine ganze Reihe von Registry-Änderungen vornehmen: MD5 und RC4 deaktivieren, SSLv3, TLS 1.0 und TLS 1.1 abschalten, TLS 1.2 aktivieren, schwache Cipher raus und eine sinnvolle Cipher-Reihenfolge vorgeben. Ich habe dafür ein Registry-File vorbereitet. Herunterladen, ausführen, Server neu starten (Microsoft halt).

Download: Registry-File Download

Ergebnis

Qualis A+ Wertung.
Qualis Wertung mit Blick auf Cipher Suites und Protocols.

A+ steht. Ich hätte gerne noch schönere Cipher gehabt, aber mehr war mit diesem Setup nicht drin. Immerhin: Kein RC4, kein 3DES, kein TLS unter 1.2. Und Exchange funktioniert danach noch, was bei Microsoft-Produkten ja nie selbstverständlich ist.

Wer auch die VPN-Cipher auf dem Windows Server härten will, findet die Anleitung im Beitrag RRAS mit sicheren Cipher Suites. Fragen? Einfach melden.

Postfix: EECDH mit 2048-Bit DH und spezifischen Kurven konfigurieren​

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„). 

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein. Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden.

So long….

Siehe auch: Perfect Forward Secrecy

Fragen? Einfach melden.

Exchange Online und Office 365: DNS-Einträge für eine BIND-Zone

Bei mir ist die Frage aufgeschlagen, was man in seine BIND-Zone schreiben muss, wenn man Exchange Online, Lync/Skype for Business oder Office 365 nutzen will. Microsoft zeigt einem während der Einrichtung eine Tabelle mit DNS-Einträgen an. Für Webinterface-Hoster kein Problem, für BIND-Admins aber erstmal Übersetzungsarbeit.

Ich liebe es, wenn Microsoft solche Dinge ins Deutsche übersetzt. „Verweist auf die Adresse“ statt „Points to“. „Gültigkeitsdauer“ statt „TTL“. Aber gut.

Hinweis: Lync heißt inzwischen Teams, die SRV-Records für Lync Federation sind aber weiterhin nötig, solange Skype for Business im Tenant aktiv ist.

Was Microsoft verlangt

Für eine Domain (hier kernel-error.com als Beispiel) werden folgende Records benötigt:

# Exchange Online
MX    0  kernel-error-com0i.mail.protection.outlook.com
TXT      "v=spf1 include:spf.protection.outlook.com -all"
CNAME    autodiscover → autodiscover.outlook.com

# Lync / Skype for Business / Teams
SRV      _sip._tls           443  1 100  sipdir.online.lync.com
SRV      _sipfederationtls._tcp 5061 1 100  sipfed.online.lync.com
CNAME    sip → sipdir.online.lync.com
CNAME    lyncdiscover → webdir.online.lync.com

# Office 365 allgemein
TXT      "MS=ms12345678"   (Domain-Verifikation)
CNAME    msoid → clientconfig.microsoftonline-p.net

Das BIND-Zonefile

Und so sieht das dann als BIND-Zone aus:

$ORIGIN .
$TTL 86400
kernel-error.com  IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                      2014010101 ; serial
                      15000      ; refresh
                      1800       ; retry
                      604800     ; expire
                      86400      ; minimum
                  )
                  NS  ns1.kernel-error.de.
                  NS  ns2.kernel-error.org.

$TTL 1H
                  IN TXT "MS=ms12345678"
                  IN TXT "v=spf1 include:spf.protection.outlook.com -all"
                  IN MX  0 kernel-error-com0i.mail.protection.outlook.com.

_sip._tls.kernel-error.com.              IN SRV 1 100 443  sipdir.online.lync.com.
_sipfederationtls._tcp.kernel-error.com. IN SRV 1 100 5061 sipfed.online.lync.com.

$ORIGIN kernel-error.com.
$TTL 1H
autodiscover  IN CNAME autodiscover.outlook.com.
sip           IN CNAME sipdir.online.lync.com.
lyncdiscover  IN CNAME webdir.online.lync.com.
msoid         IN CNAME clientconfig.microsoftonline-p.net.

Prüfen

Die gesetzten Records lassen sich mit dig prüfen:

dig +nocmd +noall +answer kernel-error.com IN MX @ns1.kernel-error.de
dig +nocmd +noall +answer kernel-error.com IN TXT @ns1.kernel-error.de
dig +nocmd +noall +answer _sip._tls.kernel-error.com IN SRV @ns1.kernel-error.de
dig +nocmd +noall +answer autodiscover.kernel-error.com IN CNAME @ns1.kernel-error.de

Viel Spaß mit den Microsoft-Online-Produkten. Fragen? Einfach melden.

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑