Sicherung von Email Ihrer Domain - SPF, DKIM und DMARC

Sicherung von Email Ihrer Domain

SPF, DKIM und DMARC

Eleanore Young
von Eleanore Young
am 09. November 2017
Lesezeit: 7 Minuten

Das Simple Mail Transfer Protocol (SMTP) besitzt keine intrinsische Methoden, um die Authentizität, Integrität und Vertraulichkeit einzelner Nachrichten zu gewährleisten. Somit ist es für Dritte relativ einfach, den Ursprung einer Email vorzutäuschen, eine Email abzufangen oder gar zu verändern. Es ist sogar so, dass es allen erlaubt ist, eine beliebige Domäne als Quelle der Email anzugeben.

Über die Jahrzehnte wurden mehrere zusätzliche Protokolle entwickelt, um die vorhin genannten Schwachstellen von Email anzugehen. Einige sind dafür gedacht, die Identität einzelner Nutzerinnen zu beweisen (z.B. PGP/GPG oder andere Public Key Kryptographie auf Basis von Individuen), während sich andere Methoden darauf konzentrieren, die Authentizität und Integrität aller Email Nachrichten einer bestimmten Domäne zu gewährleisten. In diesem Artikel werden wir drei Protokolle der letzteren Kategorie betrachten.

SPF – Sender Policy Framework

Das SPF wurde dafür entwickelt, damit die Besitzerin einer Domäne explizit aufführen kann, welche Hosts von dieser Domäne aus Email versenden dürfen. Empfängerinnen (oder deren Server) können die SPF-Einträge verwenden, um die Authentizität einer erhaltenen Email mittels mehreren Domain Name System (DNS) Abfragen zu überprüfen. Das SPF vermag jedoch nicht die Authentizität von Email kryptographisch zu sichern, sondern besteht lediglich aus einer Abfolge von Regeln, die Hostnamen und IP-Adressen verbinden.

Eine Domäne kann ihre SPF-Regeln mittels eines DNS TXT Eintrags spezifizieren. Im Falle, dass die Domäne nicht ihre eigenen Email-Server betreibt, sieht der SPF-Eintrag meist wie folgt aus:

"v=spf1 include:spf.protection.outlook.com -all"

Hier ist zu beachten, dass der SPF-Eintrag mit einem Header beginnt, der die Version von SPF angibt (v=spf1). Dieser Header wird dann gefolgt von Direktiven (od. Mechanismen), welche die SPF-Policy in einer links-nach-rechts Richtung angeben. Das SPF erkennt acht solcher Direktiven, welche wir später im Detail anschauen werden. Eines der zwei in der obigen SPF-Regel enthaltenen Direktiven, nämlich include, bindet die SPF-Konfiguration einer anderen Domäne mit ein. Die SPF-Policy dieser Domäne ist bedeutend länger und bindet selbst zwei andere Domänen rekursiv ein. Es ist zu beachten, dass der SPF Proposed Standard vorsieht, dass die Gesamtzahl an DNS-Abfragen beschränkt werden soll (meist 10 Abfragen).

"v=spf1 ip4:207.46.101.128/26 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 ip4:213.199.180.0/24 include:spfa.protection.outlook.com -all"

Abgesehen von include, erkennt das SPF zusätzlich die Direktiven ip4, ip6, a, ptr, mx, exists und all. Die all Direktive ist eine Sammelklausel, die immer erst am Ende eines Regelwerks verwendet werden sollte. Die Direktiven ip4 und ip6 erlauben die Angabe von IP-Adressen, deren zugehörige Hosts Email versenden dürfen. Die Direktiven a und mx geben an, dass der zugehörige DNS-Eintrag (A oder MX) mit der Quelladresse der überprüften Email übereinstimmen muss, ehe diese als gültige Email erkannt wird. Die Direktive ptr erfordert, dass eine zweistufige DNS-Abfrage (IP-Adresse ⇒ Domainname ⇒ IP-Adresse) dieselben IP-Adressen aufweist, ehe eine Email anerkannt wird. Die Direktive exists erfordert schlussendlich, dass der Angegebene DNS-Name (A Eintrag) existiert. Der grosse Vorteil dieser Direktive ist, dass Makro-Erweiterungen erlaubt sind.

Die eben genannten Direktiven können jeweils mit einem der Qualifizierer + “Pass”, - “Fail”, ~ “SoftFail” oder ? “Neutral” vorangestellt werden. Diese verändern die Art und Weise eines Zutreffens der genannten Direktive. Der Qualifizierer - führt zu einer gänzlichen Abweisung einer Email bei einem Zutreffen der Regel. Der Qualifizierer ~ stellt bei einem Zutreffen der Regel die Empfehlung aus, dass eine Email zwar akzeptiert, aber als SPAM behandelt wird. Der Qualifizierer ? enthält sich schlussendlich jeglicher Empfehlung gegenüber der verifizierenden Partei. Falls kein Qualifizierer angegeben ist, wird + angenommen.

Zusätzlich zu den Qualifizierer, können Modifikatoren verwendet werden, um eine SPF-Policy mittels redirect an eine andere Domäne verschoben werden oder um eine Ablehnung einer Email gegenüber der Endnutzerin zu erklären (exp). Letzterer erlaubt zusätzlich Makro-Erweiterungen.

DKIM – Domain Keys Identified Mail

Weil das SPF keine kryptographische Absicherung bzgl. der Authentizität von Email bereitstellt, sollte das Protokoll DKIM verwendet werden, um dies zu für legitime Emails zu tun. DKIM stellt dies sicher, indem jede von einer Domäne ausgehende Email von der Besitzerin der Domäne kryptographisch signiert wird. Damit DKIM funktioniert, bedarf es zweierlei Dinge. Einerseits muss die betrachtete Domäne in einem DNS TXT Eintrag des namens {selector}._domainkey.example.com. den Public Key der Besitzerin der Domäne enthalten.

"v=DKIM1; k=rsa; p=[Base64-encoded public key]"

Andererseits muss jede authentische Email den Header Dkim-Signature enthalten. Dessen Wert besteht aus mindestens 8 Parameter: Die DKIM Protokollversion, der Signaturalgorithmus, welche Teile der Email signiert wurden, der Selector zum Auslesen des Public Keys der Domäne und die Kryptographische Signatur der Email.

Somit erlaubt das DKIM-Protokoll die Validierung der Authentizität und Integrität der signierten Teile erhaltener Emails. Dabei ist zu beachten, dass der Email-Body nicht immer signiert wird. Weil aber das DKIM-Protokoll nicht für alle Email durchgesetzt werden kann, schützt es nicht vor gefälschten Nachrichten und sollte immer im Zusammenhang mit dem SPF verwendet werden.

DMARC – Domain-based Message Authentication, Reporting and Conformance

Das DMARC Protokoll vereint das SPF und DKIM dadurch, dass DMARC die Möglichkeit des Monitoring einführt. Dies bedeutet auch, dass sowohl das SPF wie auch DKIM bereits umgesetzt werden müssen, bevor DMARC funktionsfähig wird. DMARC baut auf einem DNS TXT Eintrag für den Namen _dmarc.example.com., um dessen Policy zu spezifizieren:

"v=DMARC1;p=reject;pct=100;rua=mailto:aggrep@example.com"

Abgesehen vom Protokoll und Versionsparameter, kennt DMARC zehn Parameter. Der Parameter p spezifiziert, wie mit Emails umgegangen wird, wenn Sie entweder die SPF- oder DKIM-Validierung nicht bestehen. Dessen Werte none, quarantine oder reject, haben eine ähnliche Bedeutung wie die SPF-Qualifizierer ?, ~ und -. Die Angabe dieses Parameters ist notwendig für die sachgemässe Funktion von DMARC. Der Parameter sp erlaubt das Setzen von separaten Policies für Subdomänen. Die Parameter adkim und aspf bestimmen, wie Email von Subdomänen behandelt wird, wenn Regeln für SPF und DKIM nur für die Hauptdomäne existieren. Die Parameter rua und ruf bestimmen, wohin DMARC-Berichte gesendet werden sollen. Erstere Adresse erhält aggregierte Berichte über ausgewertete Emails, während letztere Adresse für jede Auswertung einen Bericht erhält. Die Parameter pct, rf und ri erlauben das feine Einstellen des Verhaltens der DMARC-Policy. Zu beachten ist, dass die Parameter p und pct dazu verwendet werden können, um DMARC graduell zu aktivieren.

Über die Autorin

Eleanore Young

Eleanore Young hat ihren Master in Elektrotechnik und Informationstechnologie im Jahr 2014 an der ETH Zürich abgeschlossen. Zu ihren Fachgebieten gehören Rechnerarchitekturen, Betriebssysteme sowie angewandte Forschung.

Links

Sie wollen die Awareness Ihrer Benutzer prüfen?

Lassen Sie durch uns einen Social Engineering Test durchführen!

×
Crypto-Malware

Crypto-Malware

Ahmet Hrnjadovic

TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv