MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Online mit MTA-STS und SMTP DANE

Man kann Microsoft vorwerfen, einige Dinge eher zu spät als zu früh umzusetzen, aber große Provider müssen für viele Kunden funktionieren. Daher finde ich es interessant, dass Microsoft in der Vergangenheit mit DKIM schneller war, als einige Webhoster und auch bei SMTP DANE und MTA-STS ziemlich weit vorne ist.

Exchange Online unterstützt MTA-STS und SMTP DANE. Sinnvoll aber muss manuell aktiviert werden.

Warum SMTP DANE und MTA-STS?

Wenn ein Mailserver eine Nachricht an eine Domain senden möchte, dann löst er normalerweise den "MX-Record" zu einer Domäne aus, um die Zielserver zu finden und übermittelt seine Mail. Zwei Dinge weiß er dabei aber nicht:

  • Ist er beim richtigen Server gelandet?
    Er kann ja nur die DNS-Anfrage machen und sich mit der IP-Adresse verbinden, DNS-Abfragen kann ein Provider, und damit auch ein Staat, verändern und auch das IP-Routing könnte er umbiegen, um die Mails zu einem anderen Server zu senden und nach einer Inspektion weiter zu reichen. Weder der Absender noch der Empfänger würde dies "einfach" erkennen. Vielleicht würde beim Empfänger ein SPF-Check fehlschlagen, aber wenn der Absender eine DKIM-Signatur aufgebracht hat und der Empfänger dies prüft, ist der SPF-Fail kein Problem.
  • TLS optional oder notwendig?
    Beim SMTP-Handshake sendet der Absender ein "EHLO" und das Zielsystem kann mit einem STARTTLS anzeigen, dass es eine TLS-Verschlüsselung anbietet. Die meisten Absender nutzen dies dann, damit die Mails auf dem Kabel verschlüsselt sind. Allerdings kann auch hier ein Angreifer sich dazwischen stellen, da die Absender meist ein "opportunistisches TLS" nutzen, d.h. einen Fehler beim Zertifikat oder das Fehlen von STARTTLS verhindert nicht den Versand.

Als Betreiber und Nutzer von Email möchten wir sicherstellen, dass eine Mail wirklich bei dem Server ankommt, der dafür zuständig ist. IP-Pakete könnten durch einen Netzwerkprovider problemlos umgeleitet oder über einen Proxy geleitet werden und auch DNS-Abfragen nach dem MX-Record können an verschiedensten Stellen verändert werden. DNS ist prinzipiell Klartexts und ungesichert. Erst mit DNSSEC wird dies anders.

Wie funktionieren SMTP DANE und MTA-STS?

SMTP DANE und MTA-STS sind zwei Ansätze, genau dies besser abzusichern, indem der empfangende Mailserver per DNS (DNSSEC erforderlich) oder HTTPS eine Information bereitstellt, wie er empfangen möchte. Als Empfänger könnte ich veröffentlichen, dass alle Mails an mich zwingend verschlüsselt sein müssen und ich auch noch das Zertifikat vorgebe. Damit ist es einem Angreifer auf dem Übertragungsweg nicht mehr möglich, die Verbindung zu kapern oder aufzubrechen. Die beiden Verfahren SMTP DANE und MTA-STS haben sich parallel entwickelt und gegen das Thema unterschiedlich an:

Merkmal

SMTP DANE

MTA-STS

Funktionsweise

TLSA-Eintrag im DNS, der per DNSSEC abgesichert ist

Datei auf Webserver mit HTPS-Abruf der Datei

https://mta-sts.<empfängerdomain>/.well-known/mta-sts.exe

Schutz gegen DNS-Manipulation

Sehr hoch, da DNSSEC

Mittel, da kein DNSSEC und staatliche Akteure HTTPS durchaus nachbauen können

Schutz gegen Downgrade, d.h. eine durch STARTTLS initiierte TLS-Verbindung verhindern

Ja

Ja

Verbreitung

Noch gering, da viele Zonen noch kein DNSSEC machen

Höher, da einfacher umzusetzen.

Komplexität

Höher, DNSSEC und TLSA-Record müssen vom DNS-Server unterstützt werden

Moderat

Fallback

Wenn kein TLSA-Record vorhanden ist, nutzen die meisten Mailserver opportunistisches TLS

Wenn keine MTA-STS-Richtlinie vorhanden ist, nutzen die meisten Mailserver opportunistisches TLS

Wenn ihr SMTP-Server, auf die ihr MX-Record verweist, ein Zertifikat anbieten, können Sie sehr einfach mittels MTA-STS und vielleicht sogar schon per SMTP DANE der Welt Bescheid sagen, dass Sie alle Mails gerne per STARTTLS auf dem Transport verschlüsselt bekommen möchten. Beim Versand können Sie je nach Produkt steuern, ob Vorgaben der Empfängerseite berücksichtigt werden.

Exchange Online ausgehend

Microsoft hat seine Unterstützung für SMTP DANE und MTA-STS kräftig ausgebaut. Schon immer hat Exchange Online Mail per TLS versendet und empfangen, wenn die Gegenseite dies erwünscht hat und Exchange konnte auch mit Client-Zertifikate umgehen, die bei einer eingehenden Verbindung mit gesendet wurden (MTLS). So können sich Mailserver authentifizieren und die Konfiguration eines passenden Inbound Connectors anwenden. Beim Versand können Sie beim Outbound-Connector per PowerShell über zwei Parameter das Verhalten steuern.

Wenn Sie keine Outbound Connector zum Internet angelegt haben, dann nutzt Exchange den MX-Record per Default. Um MTA-STS und SMTP DANE zu konfigurieren, müssen Sie einen Outbound-Connector für den Adressraum "*" anlegen, der den MX-Record nutzt.

Set-OutboundConnector `
   -Identity "Mail zum Internet" `
   -MtaStsMode "Opportunistic" `
   -SmtpDaneMode "Opportunistic"

Beide Parameter können einen der drei Werte annehmen:

Wert Bedeutung

None

Exchange ignoriert entsprechende DNSSEC und HTTPS-Policies. Microsoft rät von dieser Einstellung, denn sie schwächt die Sicherheit. Aus meiner Sicht ist diese Einstellung nur temporär eine Hilfe, wenn die befreundete Gegenseite einen Konfigurationsfehler hat und eine Korrektur länger braucht. Der Fehler ist aber dann wohl einer ein Problem der Gegenseite, da alle kompatiblen Absender dann den Versand solange blockieren.

Opportunistic

Standardverhalten, Wenn die Gegenseite entsprechende Einträge veröffentlicht, dann richtet sich Exchange danach. Wenn Sie aber nicht passen, dann macht er ein Fallback auf STARTLS

Mandatory

Die Gegenstelle muss die Einträge bereitstellen. Wenn Sie nicht zu finden sind oder unpassend sind, wird die Mail nicht zugestellt

Wir können also mehrere Connectoren anlegen, um je nach Zieldomain oder über Transportregeln unterschiedliche Konfigurationen zu erzwingen. Sie sollten sich aber vorab auf ein Konzept festlegen. Sie könnten einen Connector wie "Internet mit DANE/MTASTS required" anlegen und die Werte für "MtaStsMode" und "SmtpDaneMode" entsprechend setzen. Sie müssen nur überlegen, ob Sie dann über die Domainliste bestimmten, welche Mails diesen Weg gehen müssen.

New-OutboundConnector `
   -Identity "Mail2Internet with SMTPDANE/MTASTS-Required" `
   -MtaStsMode "Required" `
   -SmtpDaneMode "Required" `
   -RecipientDomains msxfaq.de,msxfaq.net `
   -Enabled $true

Alternativ könnten Sie einen Connector auch anlegen, der dann in Transportregeln angesteuert wird.

New-OutboundConnector `
   -Identity "Mail2Internet with SMTPDANE/MTASTS-Required" `
   -MtaStsMode "Required" `
   -SmtpDaneMode "Required" `
   --IsTransportRuleScoped True `
   -Enabled $true

Denken Sie aber daran, dass der Speicherbereich für Transportregeln beschränkt ist. Viele Outbound-Connectoren sind dann die bessere Wahl.

Leider können Sie diese Funktion noch nicht über ECP einrichten. Der Assistenz würde dann erst einen "Test-Connector" anlegen und eine Testmail senden. Sie können aber einen Connector erst einmal mit einer Transportregel einrichten, um einen Absender über den Connector zu senden, ehe Sie dann den Connector wieder auf "RemoteDomains" umstellen.

Exchange Online SMTP-DANE eingehend

Wenn Sie externen Absendern einen Support für MTA-STS und SMTP-DANE anbieten wollen, dann müssen Sie in Exchange Online natürlich auch konfigurieren. Für jeden der beiden Einstellungen müssen Sie mehrere Schritte durchlaufen. Wir starten also wieder eine kleine Checkliste für SMTP-DANE

Tätigkeit  Erledigt

DNS mit DNSSEC 

Damit ein Absender per DNSSEC den TLSA-Record lesen kann, muss ihre DNS-Zone der Maildomain per DNSSEC aktiviert sein. Dies sollte ihnen ihre DNS-Provider sagen können oder Sie nutzen verschiedene Dienste im Internet, um dies zu prüfen. Ein Weg ist der Microsoft Remote Connectivity Analyzer unter https://testconnectivity.microsoft.com/tests/O365DaneValidation/input

 

Hier sehen Sie gut, dass meine Domain "msxfaq.de" noch kein DNSSEC aktiviert war.

Solange ihre Maildomain noch nicht DNSSEC-aktiviert ist können Sie hier nicht weiter machen. Aktivieren Sie über ihren DNS-Provider erst DNSSEC. Wenn der Provider dies nicht kann, ist ein Umzug zu eine, anderen Provider erforderlich.

 

Ein zweiter Dienst ist der DNSDebugger von Verisignlabs. https://dnssec-debugger.verisignlabs.com/  

MX-Record und TTL

Wir werden zu einem späteren Schritt den MX-Record auf einen anderen Namen umstellen müssen. Damit solche Änderungen schnell aktiv werden aber im Fehlerfall auch schnell wieder rückgängig gemacht werden können, sollten Sie mit ausreichend Vorlauf den TimetoLive (TTL) ihres MX-Records reduzieren. Oft steht er auf 3600 (=1h) oder noch höhere Werte. Viele Firmen nutzen mittlerweile als Default schon 5 Minuten oder weniger, um schnell schwenken zu können. Je kürzer je besser aber einige DNS-Provider erwartet eine Mindestgültigkeit.

  

DNSSEC aktivieren

Nun müssen wir die Domain für DNSSEC in der Exchange Online PowerShell aktivieren. Ich habe hier exemplarisch für meine Domain "msxfaqlab.de" den DNSSEC-Support aktiviert. Die Funktion gibt es nur für eigene Domain aber nicht die Microsoft Domains.

Beachten Sie die Ausgabe des Befehls "Enable-DnssecForVerifiedDomain". Er liefert den neuen MX-Record. 

msxfaqlab-de.q-v1.mx.microsoft
  

MX-Record addieren

Den neuen Mailserver addieren wir nun in unserer offizielle DNS-Zone. Allerdings ersetzen wir nicht vorhanden Server, sondern addieren den Eintrag mit einem höheren Wert bei der Preferenz und natürlich wieder dem kleinstmöglichen TTL. Absender nutzen normalerweise immer die Server mit der niedrigsten Nummer. So sollte diese Änderung erst noch keine Auswirkungen haben.

RCA: Kontrolle mit Remote Connectivity Analyzer

Über die vielen Administratoren bekannte Webseite https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input prüfen wir nun, ob alles seine Richtigkeit hat. Der RCA liest zur angegeben Mailadresse die Domain und darüber die MX-Records und versucht zu jedem Server eine Verbindung. Hier können wir dann auch sehen, ob DNSSEC funktioniert hat und ein TLSA-Record für den neuen Zielserver gefunden wurde. Wenn Sie Exchange Online nutzen, dann sollte es hier keine Probleme geben, Sie können aber so auch die Erreichbarkeit von anderen Mailservern prüfen.

MX-Record anpassen

Nun können wir die bisherigen MX-Records entfernen, so das nur noch der neue Eintrag übrig bleibt.

SMTP-DANE aktivieren

Nun können wir die zweite Konfiguration in der Exchange Online PowerShell vornehmen, damit die entsprechenden TLSA-Einträge anglegt werden

Vor dem nächsten Schritt sollten Sie ein paar Minuten vergehen lassen, bis die Änderungen im DNS auch überall bekannt werden. 

RCA: DNSSEC testen

Unter der Adresse https://testconnectivity.microsoft.com/tests/O365DaneValidation/input können Sie mit dem Remote Connectivity Analyzer auch DANE und DNSSEC testen. Wir geben einfach die Domain ein

 

Es kann, wie hier, durchaus mehrere TLSA-Einträge geben. Es muss nur ein Eintrag vorhanden sein, der auch zum Zertifikat des Servers passt.

Absender entscheidet

Sie haben nun alle Vorarbeiten geleistet und veröffentlichen die Informationen über die zu erwartenden Zertifikate mittels DNS in einer DNSSEC-gesicherten Zone. Ob allerdings ein Absender diese Information liest und auswertet, können Sie nicht sehen. Aus SMTP-Sicht sehen Sie als Empfänger nur, ob der Absender eine STARTTLS-Verbindungen genutzt hat. Sie sehen aber nicht, ob der Absender das ausgelieferte Zertifikat auch verifiziert hat. Bei besonders kritischen Geschäftsverbindungen könnten Sie aber ihrem Gegenüber anschreiben, dass er bei die Verbindung mit SMTP-DANE-Zwang über einen Connector zusätzlich absichern kann.

Inbound Connector

Wenn Sie als Mailadmin aber 100% sicherstellen wollen, dass einige oder alle Domains zwingend eine TLS-Verbindung nutzen, dann können Sie dies per "Inbound Connector" für diese Domains vorgeben, indem sie TLS erzwingen. Damit können Siei aber nicht beeinflussen, ob die Gegenseite das Zertifikat streng prüft. Sie könnten damit zumindest unterschlüsselte Verbindungen verbieten. Kontrollieren Sie vorher ihre Empfangslogs, der noch unverschlüsselt sendet

Exchange Online MTA-STS eingehend

Analog zu SMTP-DANE müssen Sie auch für MTA-STS ein paar Vorarbeiten machen. Die Information zum Zertifikat wird hier aber über eine Datei auf einem Webserver bereitgestellt

Tätigkeit  Erledigt

Datei mtas-sts.txt erstellen

Zuerst erstellen wir eine Datei, in der die Richtlinien für die Mailserver meiner Domain enthalten sind. Sie hat folgenden Aufbau

version: STSv1 
mode: enforce 
mx: *.mail.protection.outlook.com 
max_age: 604800

Das Feld "max_age" gibt vor, wie lange die Daten maximal in einem Cache gehalten werden dürften.

Webserver

Die Datei muss unter der folgenden URL erreichbar sein:

https://mta-sts.<EMailDomainname>/.well-known/mta-sts.txt

Für die meisten Firmen bedeutet das nun etwas Arbeit, denn sie brauchen:

  • WebServer
    Das kann ihr normaler öffentlicher Marketing-Webserver sein oder sie hosten diese Information auf einer Azure Webseite o.ä. Die Anforderungen sind minimal, denn es ist nur diese eine statische Seite erforderlich
  • Zertifikat
    Aber der Abruf erfolgt per HTTPS und dazu brauchen Sie entweder ein Wildcard-Zertifikat oder ein Zertifikat für den Namen. Dank Let's-Encrypt kostet das auch nicht die Welt aber es ist einzurichten und aktuell zu halten.
  • DNS-Name für Webserver
    Erst dann können Sie in ihrer DNS-Zone einen A-Record für den Host "mta-sts" addieren und auf die Webseite zeigen lassen.

Verifizierung

Prüfen Sie die Erreichbarkeit des Webservers und der  Datei aus dem Internet. Das geht einfach per Browser oder Powershell. Bei Microsoft sehen wir:

Per PowerShell  ist der Content wichtig

Sie sehen, dass hier neben der Policy noch ein "max_age"-Wert enthalten ist. So lange darf ein Mailserver die erhaltene Informationen cachen.

TXT-Record

Ein Mailserver ruft aber nicht blind eine HTTPS-URL auf, ohne zu wissen, dass es dort etwas gibt. Er nutzt vorher eine viel günstigere DNS-Anfrage, um die Bereitstellung einer mta-sts-Datei zu prüfen. Wir legen dazu einen TXT-Record in der Zonendatei der Maildomäne mit folgendem Inhalt an.

_mta-sts 3600 IN TXT v=STSv1; id=20260527080000Z;  

Die ID ist dabei eine eindeutige Nummer, die bei einer Änderung der Textdatei auch geändert werden muss. Es hat sich eingebürgert, dort einfach einen Zeittempel zu verwenden. 

Absender entscheidet 

Wie auch bei SMTP DANE liegt es Mailsystem des Absenders, ob er diesen DNS-Eintrag lädt und dann auch noch die Policy lädt und in der Folge die Policy befolgt. Im Exchange Online Protokoll kann ich nur sehen, ob eine TLS-Verbindung genutzt wurde oder nicht. Ich habe aber erst einmal keine Aussage dazu, wie genau der Absender das Zertifikat geprüft hat. Ich kann wichtige Partner aber einmal darauf ansprechen, wie sie mit MTA-STS umgehen

Inbound Connector

Wenn Sie als Mailadmin aber 100% sicherstellen wollen, dass einige oder alle Domains zwingend eine TLS-Verbindung nutzen, dann können Sie dies per "Inbound Connector" für diese Domains vorgeben, indem sie TLS erzwingen. Damit können Siei aber nicht beeinflussen, ob die Gegenseite das Zertifikat streng prüft. Sie könnten damit zumindest unterschlüsselte Verbindungen verbieten. Kontrollieren Sie vorher ihre Empfangslogs, der noch unverschlüsselt sendet

Exchange OnPremises

Die Funktionen SMTP DANE und MTA-STS wurden bei Exchange OnPremises bislang weder auf dem normalen Exchange Server noch dem Exchange Edge Server implementiert. Exchange OnPremises kann beim Versand die Vorgaben des Empfängers hinsichtlich SMTP DANE und MTA-STS nicht berücksichtigen. Beim Empfang kann Exchange natürlich STARTTLS anbieten und sie können sogar konfigurieren, dass STARTTLS erzwungen wird.

Set-ReceiveConnecor <name> `
   -RequireTLS $trude

Aber das ist keine Garantie, dass die Gegenseite das Zertifikat "streng" prüft. Die erforderlichen Einträge für SMTP-DANE und MTA-STS müssen Sie selbst anlegen. Bei Exchange Online nimmt Microsoft ihnen einige Aufgaben ab, da Microsoft die DMS-Zone des Exchange Online Servers selbst mit DNSSEC sichert und die erforderlichen TLSA-Records addiert. Ausgehend kann Exchange OnPremises selbst weder SMTP-DANE noch MTA-STS. Insofern bleibt ihnen hier nur die Option ein eigenes Relay zwischen Internet und Exchange OnPremises zu stellen, welches die erforderlichen Richtlinien auswertet und durchsetzt.

Weitere Links