Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03456.jsonl.gz/1011

totemomail
Mark Zeman
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.
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:<ip-pii>/26 ip4:<ip-pii>/24 ip4:<ip-pii>/24 ip4:<ip-pii>/24 ip4:<ip-pii>/23 ip4:<ip-pii>/24 ip4:<ip-pii>/24 ip4:<ip-pii>/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.
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.
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:<email-pii>"
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.
Lassen Sie durch uns einen Social Engineering Test durchführen!
Mark Zeman
Marisa Tschopp
Tomaso Vasella
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv