Domain-based Message Authentication, Reporting and Conformance (kurz DMARC) ist ein Protokoll zur Email Authentifizierung welches Empfängern von Emails ermöglicht gefälschte Absender zu erkennen, die Annahme dieser Emails zu verweigern, und den Betreiber der Domain als die sich ausgegeben wurde über den Betrugsversuch zu informieren.
DMARC nutzt hierzu SPF und DKIM.
Sender Policy Framework (SPF) ist ein Richtlinienwerk das es einem Mailserverbetreiber erlaubt festzulegen welche IP Adressen im Namen seiner Domain Emails versenden dürfen.
Hierzu veröffentlicht der Mailserverbetreiber die Liste der IP Adressen in einem DNS Eintrag zusammen mit einem Vermerk wie strikt Empfänger sich an diese Liste halten sollen. Die möglichen Präferenzen sind:
-all
: Keine außer die genannten IP Adressen darf Emails für diese Domain verschicken.~all
: Es sollten eigentlich keine anderen IP Adressen als die genannten Emails verschicken.?all
: Wird so behandelt als wäre kein SPF Eintrag mit IP Liste vorhanden.+all
: Es ist jedem explizit erlaubt Emails im Namen der Domain zu verschicken.DomainKeys Identified Mail (DKIM) ist ein Signatur Verfahren welches es Mailservern erlaubt zu versendende Emails zu signieren und dem Empfänger somit durch Verifizierung der Signatur die Echtheit des angeblichen Absenders einer Email zu prüfen.
Die hierzu nötigen öffentlichen Schlüssel werden wie SPF in einem DNS Eintrag veröffentlicht.
DMARC kombiniert nun SPF und DKIM um eingehende Emails auf deren Authentizität zu prüfen, diese ggf. Abzuweisen, und den Betreiber der echten Domain als die sich ein betrügerischer Absender ausgegeben hat zu informieren.
Hierzu veröffentlicht der Mailserverbetreiber einen weiteren DNS Eintrag. Dieser Beinhaltet die DMARC Richtlinie (engl. Policy). Hier gibt es 3 Möglichkeiten:
p=none
: Keine Richtlinie, d.h. Email soll in jedem Fall normal zugestellt werden.p=quarantine
: Email die nicht authentifiziert werden kann soll in Quarantäne, z.B. den Spam Ordner. verschoben werden.p=reject
: Email die nicht authentifiziert werden kann soll beim Empfang abgelehnt werden.DMARC geht beim authentifizieren wie folgt vor:
Nehmen wir an ein Mailserver empfängt folgende Email Anfrage von einem Klienten:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
SPF stellt sicher dass die IP des sich mit dem Server verbundenen Klienten Emails im Namen der in Zeile 2 im sogenannten RFC5321.MailFrom
genannten Domain (in diesem Beispiel absender2.de
) versenden darf.
SPF gilt als bestanden wenn der Sender IP erlaubt ist im Namen der Domain des RFC5321.MailFrom
Feldes Emails zu verschicken.
Das RFC5321.MailFrom
Feld ist jedoch nur zu vergleichen mit dem Absender außen auf einem Briefumschlag. Der Absender der innen auf dem Briefkopf steht kann anders lauten. Bei Emails ist dieser “Absender im Briefkopf” in Zeile 12 im sogenannten RFC5322.From
Feld auch Display From (da es der Absender ist der dem Nutzer am Computer später angezeigt wird ist) genannt.
DKIM signiert nun den eigentlichen Inhalt der Email. Das ist vergleichbar wie mit der Signatur (Unterschrift) auf einem Brief bei der man davon ausgeht dass die unterzeichnende Person bestätigt dass der Inhalt auf der Seite mit der Unterschrift von ihr stammt. Hierzu wird die DKIM Signatur in Zeile 5 bis 11 gesendet. In der Signatur ist die Identität der unterschreibenden Domain im d=
Feld genannt. Im Beispiel lautet diese absender3.de
. Die Unterschrift kann also auch von einer ganz anderen Domain stammen als einer der in RFC5321.MailFrom
(Zeile 2) oder RFC5322.From
(Zeile 12) genannten. Bei einem Brief kann ja auch jemand anderes als der Absender unterschrieben.
DKIM gilt als bestanden für die in d=
genannten Domain wenn die Signatur kryptografisch mit dem öffentlichen Schlüssel dieser Domain verifiziert werden kann.
DMARC gilt als bestanden wenn entweder
RFC5321.MailFrom
der Domain im RFC5322.From
entsprichtoder
d=
Feld der DKIM Signatur der Domain im RFC5322.From
entspricht.
Dies stellt sicher dass die dem Benutzer angezeigte Absender Adresse im RFC5322.From
Feld nicht gefälscht wurde, sondern tatsächlich mit Berechtigung des Domaininhabers dort verwendet wird.
Im Beispiel hätte die Email DMARC nicht bestanden, da
RFC5321.MailFrom
Domain absender2.de
nicht der RFC5322.From
Domain absender4.de
entsprichtund
d=
absender3.de
ebenfalls nicht der RFC5322.From
Domain absender4.de
entspricht.Dieses Domain Abgleichen wird auch “DMARC Aligmnet” genannt.
Um zu verstehen wie DMARC Endnutzer vor Phishing schützen kann schauen wir uns ein paar Beispiele an:
HINWEIS: Die Beispiele wurden einer Spamtrap (dt. Spam Falle) entnommen und waren zufällig die neuesten Exemplare einer bestimmten Art von Phishing. Äußerungen über etwaige Firmen sind nicht als Werbung zu verstehen… Negatives aber durchaus als Kritik.
Hier sehen wir eine vermeintliche Gewinnmitteilung angeblich gesendet von support@1und1.de
:
Sie enthält leider keine DKIM Signatur. Der Empfänger kann somit nur anhand von anderer Anzeichen festzustellen dass dies wahrscheinlich keine legitime Email von 1&1 ist. Ein mögliches Indiz dafür ist z.B. der Link in der Email der auf eine Domain eines URL Verkürzungsdienstes verweist. Würde man diesem folgen sähe man eine 1 zu 1 Kopie des “1&1 Control-Center” mit validem HTTPS:
Leider verwenden auch Firmen in legitimen Emails diese URL Verkürzungsdienstes so dass es für normale Benutzer oft überhaupt nicht mehr möglich ist gefälschte Emails so einfach zu erkennen.
Schaut man sich jedoch die Header der Email an erfährt man folgendes:
apache@em-plan.com
versendet.em-plan.com
zu versenden.RFC5322.From
wurde dann aber einfach support@1und1.de
als Absender eingetragen.Hätte 1und1.de
eine veröffentlichte DMARC Richtlinie gehabt1 hätte der Mailserver die Email direkt verwerfen können, da SPF zwar für die em-plan.com
Domain valide war aber nicht für 1und1.de
und eine DKIM Signatur gar nicht exiliert hat.
Kann man nicht die Email einfach so verwerfen ohne das 1und1.de eine DMARC Richtlinie veröffentlicht? Ja. Dann würde man aber auch echte Emails von 1&1 verwerfen. DMARC braucht sowohl SPF als auch DKIM denn wird eine Email weitergeleitet ist der Weiterleitende nicht mehr berechtigt Emails im Namen der 1und1.de Domain zu verschicken. Er wird somit (wie im Phishing Email Beispiel) den RFC5321.MailFrom
mit seiner eignen Domain benennen, da er ja die weitergeleitete Email sendet. Damit könnte eine Email nur noch über deren DKIM Signatur verifiziert werden.
1&1 macht es seinen Kunden also unnötig schwer sich gegen diese Art von Phishing mit gefälschten Absendern zu schützen.
Obwohl Emails bereits vom Mailserver verworfen werden könnten weil DMARC nicht erfüllt ist stellen viele Anbieter diese Emails trotzdem zu.
In Thunderbird kann man als Nutzer z.B. das Add-On DKIM-Verifier installieren. Das Plug-in zeigt bei jeder Email an ob und von wem eine Email DKIM-signiert wurde.
Hier z.B. eine Email von Amazon.de:
Thunderbird’s DKIM-Verifier kann z.B. so konfiguriert werden dass Absender deren DKIM Signatur verifiziert werden kann grün markiert werden:
Emails deren Signatur zwar verifiziert werden kann, aber deren signierende Domain von der im Absender Feld abweicht werden orange markiert:
Absender ohne gültige DKIM Signatur können rot dargestellt werden:
Die erste offensichtliche Grenze von DMARC sind Fehlkonfigurationen. Wenn Emails zwar via DKIM signiert werden aber von einer anderen Domain als der im Absender verwendeten bestehen diese nicht den DMARC Test. Deshalb verwenden viele Sender lieber erst gar kein DMARC… oder DKIM.
Eine beliebte Methode dem Problem das Domains abgeglichen werden zu entgehen besteht darin diese einfach nicht zu fälschen, sondern nur den sogenannten Display Namen zu fälschen.
Das von DMARC geprüfte RFC5322.From Feld, auch Display From genannt ist wie folgt auf gebaut:
From: "Display Name" <Display Email>
Ein Angreifer kann also als im Display Email
Teil der von DMARC abgeglichen wird die korrekte Adresse stehen lassen und nur den Display Name
Teil fälschen.
Das sieht dann wie folgt aus:
Der Display Name
wird hier auf “GoogleNotify” gesetzt. Die Absender Email bleibt aber ungefälscht.
Dieser Trick funktioniert leider oft sehr gut da einige Email Programme nur den Display Name
anzeigen und die eigentliche Email vor dem Benutzer verbergen. DMARC verifiziert aber eben nur die Domain der Email.
DMARC bestätigt zwar einwandfrei einen Absender, gibt aber keine Auskunft darüber ob die Domain auch wirklich z.B. zu einer bestimmten Firma gehört. Ein Angreifer könnte sich z.B. 1-und-1.org
registrieren und von dort aus Phishing Emails versenden die SPF, DKIM und DMARC bestehen.
DMARC bestätigt zwar einwandfrei einen Absender, da Menschen aber schlechter als Computer im genauen Abgleich von Zeichen sind können Empfänger oft durch sogenannte Homoglyphen getäuscht werden. Homoglyphen sind ähnlich aussehende Zeichen, z.B. 0
(Null) und O
(großes o), oder l
(kleines l) und I
(großes i).
Verschickt ein Angreifer z.B. eine Email von paypaI.de
(i anstatt l) oder G00GLE.COM
(0 anstatt o) kann er dafür (wenn er diese Domains besitzt) auch valide DKIM Signaturen produzieren. Diese würden dann z.B. bei der Verwendung der Thunderbird DKIM-Verifier Add-Ons ebenfalls grün erscheinen.
Eine Gegenmaßnahme ist es bekannte Absender im Adressbuch zu hinterlegen. Diese werden dann in Thunderbird mit einem blauen Stern gekennzeichnet, z.B. hier die bereits gezeigte Amazon.de Email:
DMARC kann selbst verständlich nur schützen wenn von den Domains aktiv eine Richtlinie gesetzt wird.
Deshalb schauen wir uns einfach mal an wie verbreitet DMARC denn überhaupt so ist.
Hier folgt eine Überblick über die Verbreitung von DMARC (und andere mittels DNS Einträgen veröffentlichten Sicherheitsmechanismen) im deutschen Raum. Hierzu wurden zum einen alle .de Domains in den Alexa Top 1M (4,927) und alle Domains deutscher Behörden (und Kommunen)2 (8,821) analysiert. Die Behörden Domains stammen von https.jetzt!, einem Projekt welches die HTTPs Konnektivität zu Behörden Webseiten analysiert. https.jetzt! hat seine Daten wiederum von https://github.com/robbi5/german-gov-domains. Wer also einen Fehler in den Domains findet kann diesen dort melden. Mir geht es hier nicht darum eine 100 % genau Betrachtung einzelner Domains zu bieten, sondern um den generellen Trend der Adaption der verschiedenen Sicherheitsmaßnahmen welche DNS involvieren.
Insgesamt umfasst der Datensatz 13,748 Einträge. Und sollte sowohl alle populären Domains, als auch alle relevanten behördlichen Domains enthalten.
Im folgenden können einzelne Datensätze gesucht und verglichen werden:
Die Daten wurden am 2019-08-13 erhoben und stellen den Zustand zu diesem Datum dar und werden nicht aktualisiert.
UPDATE 1: Die in der Tabelle gelisteten TLSA Einträge für Ports 25 stammen von den MX Einträgen der jeweiligen Domain. Nicht von der Domain selbst.
Wählen den Datensatz aus:
Domain | MX | SPF | Sender ID | HIBP | DKIM | DMARC | ASDP | MTA-STS | CAA | DNSSEC | TLSA | ||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
policy | rua | ruf | issue | iodef | valid | DNSKEY | |||||||||
Domain | MX | SPF | Sender ID | HIBP | DKIM | DMARC | ASDP | MTA-STS | CAA | DNSSEC | TLSA | ||||
policy | rua | ruf | issue | iodef | valid | DNSKEY |
Es kann sowohl nur nach der Domain, z.b. “sparkasse.de
” gefiltert werden, aber auch Kombinationen wie z.B. “-all p=reject
” sind möglich um alle Domains mit einer SPF Richtlinie von -all
und einer DMARC Richtlinie von p=reject
anzuzeigen.
Viel interessanter als die einzelnen Ergebnisse ist eine statistische Auswertung der erfassten Daten.
In diesem Abschnitt werden erstmal nur die rohen Zahlenwerte gelistet.
Die Auswertung / Erklärung findet später in Auswertung / Erklärung statt.
TOTAL: 13748
TOTAL: NO MX record 708 = 5 %
SPF: NO POLICY 9891 = 71 %
SPF: all 3857 = 28 %
SPF: -all 1713 = 12 %
SPF: ~all 1529 = 11 %
SPF: ?all 480 = 3 %
SPF: +all 36 = 0 %
SPF: illegal (multiple all tags) 34 = 0 %
(missing % use a pure redirect policy)
SPF: NO POLICY while no MX 678 = 95 % of domains without MX record
SPF: -all while no MX 23 = 3 % of domains without MX record
DKIM: NO _domainkey. 7734 = 56 %
DKIM: YES a _domainkey. exists 6014 = 43 %
(missing % are rounding errors)
DMARC: NO POLICY 13145 = 95 %
DMARC: p= 603 = 4 %
DMARC: p=none 459 = 3 %
DMARC: p=reject 90 = 0 %
DMARC: p=quarantine 53 = 0 %
DMARC: rua 426 = 3 %
DMARC: ruf 265 = 1 %
DMARC: illegal (contradicting) 0 = 0 %
DMARC: p=none 459 = 76 % of domains with DMARC
DMARC: p=reject 90 = 14 % of domains with DMARC
DMARC: p=quarantine 53 = 8 % of domains with DMARC
DMARC: rua 426 = 70 % of domains with DMARC
DMARC: ruf 265 = 43 % of domains with DNARC
DMARC: illegal (contradicting) 0 = 0 % of domains with DNARC
ASDP: NO POLICY 13716 = 99 %
MTA-STS: 9 = 0 %
CAA: issue 244 = 1 %
CAA: iodef 128 = 0 %
DNSSEC: 201 = 1 %
DNSKEY: 252 = 1 %
TLSA: port 25/tcp or 443/tcp 721 = 5 %
TLSA: but no DNSSEC 630 = 4 %
TLSA: but not even DNSKEY 626 = 4 %
TLSA: but no DNSSEC 630 = 87 % of domains with TLSA records
TLSA: but not even DNSKEY 626 = 86 % of domains with TLSA records
TOTAL: 8821
TOTAL: NO MX record 432 = 4 %
SPF: NO POLICY 7238 = 82 %
SPF: all 1583 = 17 %
SPF: -all 762 = 8 %
SPF: ~all 543 = 6 %
SPF: ?all 217 = 2 %
SPF: +all 35 = 0 %
SPF: illegal (multiple all tags) 11 = 0 %
(missing % use a pure redirect policy)
SPF: NO POLICY while no MX 423 = 97 % of domains without MX record
SPF: -all while no MX 8 = 1 % of domains without MX record
DKIM: NO _domainkey. 5390 = 61 %
DKIM: YES a _domainkey. exists 3431 = 38 %
(missing % are rounding errors)
DMARC: NO POLICY 8629 = 97 %
DMARC: p= 192 = 2 %
DMARC: p=none 153 = 1 %
DMARC: p=reject 27 = 0 %
DMARC: p=quarantine 12 = 0 %
DMARC: rua 116 = 1 %
DMARC: ruf 50 = 0 %
DMARC: illegal (contradicting) 0 = 0 %
DMARC: p=none 153 = 79 % of domains with DMARC
DMARC: p=reject 27 = 14 % of domains with DMARC
DMARC: p=quarantine 12 = 6 % of domains with DMARC
DMARC: rua 116 = 60 % of domains with DMARC
DMARC: ruf 50 = 26 % of domains with DNARC
DMARC: illegal (contradicting) 0 = 0 % of domains with DNARC
ASDP: NO POLICY 8810 = 99 %
MTA-STS: 2 = 0 %
CAA: issue 94 = 1 %
CAA: iodef 63 = 0 %
DNSSEC: 73 = 0 %
DNSKEY: 96 = 1 %
TLSA: port 25/tcp or 443/tcp 620 = 7 %
TLSA: but no DNSSEC 577 = 6 %
TLSA: but not even DNSKEY 574 = 6 %
TLSA: but no DNSSEC 577 = 93 % of domains with TLSA records
TLSA: but not even DNSKEY 574 = 92 % of domains with TLSA records
TOTAL: 4927
TOTAL: NO MX record 276 = 5 %
SPF: NO POLICY 2653 = 53 %
SPF: all 2274 = 46 %
SPF: -all 951 = 19 %
SPF: ~all 986 = 20 %
SPF: ?all 263 = 5 %
SPF: +all 1 = 0 %
SPF: illegal (multiple all tags) 23 = 0 %
(missing % use a pure redirect policy)
SPF: NO POLICY while no MX 255 = 92 % of domains without MX record
SPF: -all while no MX 15 = 5 % of domains without MX record
DKIM: NO _domainkey. 2344 = 47 %
DKIM: YES a _domainkey. exists 2583 = 52 %
(missing % are rounding errors)
DMARC: NO POLICY 4516 = 91 %
DMARC: p= 411 = 8 %
DMARC: p=none 306 = 6 %
DMARC: p=reject 63 = 1 %
DMARC: p=quarantine 41 = 0 %
DMARC: rua 310 = 6 %
DMARC: ruf 215 = 4 %
DMARC: illegal (contradicting) 0 = 0 %
DMARC: p=none 306 = 74 % of domains with DMARC
DMARC: p=reject 63 = 15 % of domains with DMARC
DMARC: p=quarantine 41 = 9 % of domains with DMARC
DMARC: rua 310 = 75 % of domains with DMARC
DMARC: ruf 215 = 52 % of domains with DNARC
DMARC: illegal (contradicting) 0 = 0 % of domains with DNARC
ASDP: NO POLICY 4906 = 99 %
MTA-STS: 7 = 0 %
CAA: issue 150 = 3 %
CAA: iodef 65 = 1 %
DNSSEC: 128 = 2 %
DNSKEY: 156 = 3 %
TLSA: port 25/tcp or 443/tcp 101 = 2 %
TLSA: but no DNSSEC 53 = 1 %
TLSA: but not even DNSKEY 52 = 1 %
TLSA: but no DNSSEC 53 = 52 % of domains with TLSA records
TLSA: but not even DNSKEY 52 = 51 % of domains with TLSA records
Zum internationalen Vergleich die Zahlen der Top 14.794 der Alexa Top 1M:
TOTAL: 14794
TOTAL: NO MX record 2432 = 16 %
SPF: NO POLICY 5026 = 33 %
SPF: all 9768 = 66 %
SPF: -all 3220 = 21 %
SPF: ~all 5526 = 37 %
SPF: ?all 579 = 3 %
SPF: +all 9 = 0 %
SPF: illegal (multiple all tags) 173 = 1 %
(missing % use a pure redirect policy)
SPF: NO POLICY while no MX 2130 = 87 % of domains without MX record
SPF: -all while no MX 159 = 6 % of domains without MX record
DKIM: NO _domainkey. 6969 = 47 %
DKIM: YES a _domainkey. exists 7825 = 52 %
(missing % are rounding errors)
DMARC: NO POLICY 11062 = 74 %
DMARC: p= 3732 = 25 %
DMARC: p=none 2195 = 14 %
DMARC: p=reject 958 = 6 %
DMARC: p=quarantine 577 = 3 %
DMARC: rua 3191 = 21 %
DMARC: ruf 1907 = 12 %
DMARC: illegal (contradicting) 1 = 0 %
DMARC: p=none 2195 = 58 % of domains with DMARC
DMARC: p=reject 958 = 25 % of domains with DMARC
DMARC: p=quarantine 577 = 15 % of domains with DMARC
DMARC: rua 3191 = 85 % of domains with DMARC
DMARC: ruf 1907 = 51 % of domains with DNARC
DMARC: illegal (contradicting) 1 = 0 % of domains with DNARC
ASDP: NO POLICY 14546 = 98 %
MTA-STS: 17 = 0 %
CAA: issue 710 = 4 %
CAA: iodef 230 = 1 %
DNSSEC: 482 = 3 %
DNSKEY: 886 = 5 %
TLSA: port 25/tcp or 443/tcp 45 = 0 %
TLSA: but no DNSSEC 18 = 0 %
TLSA: but not even DNSKEY 18 = 0 %
TLSA: but no DNSSEC 18 = 40 % of domains with TLSA records
TLSA: but not even DNSKEY 18 = 40 % of domains with TLSA records
Global / international (Alexa Top 14K Datensatz) haben nur 25 % der Domains eine DMARC Richtlinie. Das erscheint wenig. Bei den .de Domains (.de der Alexa Top 1M Datensatz) sind es jedoch sogar nur 8 % und bei den Behörden (Behörden Datensatz) sogar nur 2 %.
Doch warum ist das so?
Betrachtet man die Statistiken für SPF und DKIM, so ist bei den internationalen Domains bei 66 % SPF und 52 % DKIM verfügbar, doch nur bei 25 % DMARC verfügbar. D.h., nur rund die Hälfte der Domains mit den Voraussetzungen für DMARC nutzen es auch. Im Bereich der .de Domains haben 46 % SPF und 52 % DKIM (was auch wie bei den internationalen Domains in etwa der Hälfte entspricht), aber nur 8 % nutzen DMARC. D.h., nur rund jede 5. Domain mit den Voraussetzungen für DMARC nutzt dies auch.
Ein möglicher Grund für das fehlen einer DMARC Richtlinie selbst wenn SPF und DKIM vorhanden sind könnte die Angst sein das Emails dadurch nicht mehr zugestellt werden. Dies könnte auch erklären warum 35 der Behörden Domains und 1 der .de Domains in den Alexa Top 1M eine SPF Richtlinie mit +all
veröffentlichen.
Zur Erinnerung +all
ist eine explizite Anweisung das jede IP Adresse Emails mit der Identität dieser Domain verschicken darf. Ein ?all
entspräche einer neutralen Behandlung als wäre gar kein SPF Eintrag vorhanden. Hier wird also explizit sogar zu einer Verschlimmerung durch den SPF Eintrag erreicht da ein Empfänger ja explizit von der legitimen Domain selbst mitgeteilt bekommt das es welcher IP auch immer die jeweilige Email versendet dies auch darf. Ein Schutz vor gefälschten Absendern mit technischen Mitteln wird dadurch quasi unmöglich.
Von den Alexa Top 14,794 haben zum Vergleich nur 9 eine +all
Richtlinie. Bei den 8,821 Behörden Domains wie gesagt 35!
Diese Theorie wird weiter unterstützt durch die Tatsache das bei allen deutschen Domains (der Testgruppe) bei 74 % der Domains mit DMARC eine p=none
Richtlinie gesetzt ist, d.h. dass kein Eingreifen bei der Zustellung der Email selbst bei Fehlschlagen der DMARC Prüfung erfolgt. International liegt der Anteil von p=none
Richtlinien an den gesamten DMARC Einträgen bei 58 %.
Eine Angst der Verschlechterung der Zustellbarkeit von Emails durch einen SPF Eintrag ist nur begründet wenn man nicht weiß wie die IP Adressen seiner eigenen Mailserver lauten… in welchem Fall man aber ohne hin andere Probleme hat.
Eine weiterer großer Unterschied zwischen den .de Domains und den Internationalen ist die Verwendung der Reporting Option rua
bei DMARC. Diese wird international von 85 % der Domains die DMARC haben genutzt. In gesamt .de bei 75 % und bei Behörden nur 60 %. Aber gerade das Reporting gibt den meisten Aufschluss darüber von welchen IPs Emails im Namen der eigenen Domain versendet werden. Kann also dazu dienen zu Evaluieren wie groß gerade die Gefährdungslage bzgl. gefälschter Emails ist.
Selbst wenn einzelne Behörden und Kommunen nicht an den Daten der Reports interessiert sind könnte man diese dennoch als Telemetrie z.B. an das BSI übermitteln lassen und dieses kann die Informationen in sein Lagebild einfließen lassen.
Doch die Einstellung des BSI zu DMARC wird an folgendem Beispiel klar:
Auf Twitter wurde das BSI schon des öfteren auf den Mangel an DMARC angesprochen hat sich dazu aber nie geäußert. Aus den vom BSI veröffentlichten Empfehlungen (und besonders dem dortigen Video) scheint es als ob dort die ganze Verantwortung nicht auf Phishing Emails hereinzufallen auf den Empfänger abgewälzt werden soll. Doch wie soll der Empfänger den Absender einer Email auf Echtheit prüfen wenn der Absender keine prüfbaren Merkmale mit sendet? Das ist wie Geld ohne Sicherheitsmerkmale in Umlauf zu bringen, den Bürgern aber zu empfehlen das Geld auf Echtheit zu prüfen. Wie denn?!
Auf der Webseite des BSI wird die Nennung von DMARC von Google gerade einmal 3 mal gefunden:
Lediglich das CERT-Bund des BSI hat sich auf Twitter mal zu DMARC geäußert:
CERT-Bund bezieht sich hier auf das Problem dass DMARC nicht davor schützt wenn nur der Display Name gefälscht wird (siehe den Abschnitt Display Namen fälschen).
Diese Einstellung bezeichnet man als “Security Nihilismus”. Hierbei wird jede Maßnahme die keinen perfekten Schutz bietet eben genau mit der Begründung abgelehnt dass die Maßnahme keinen perfekten Schutz bietet. Wenn das konsequent verfolgt würde wäre eine Frage warum 90 % der Behörden Domains die einen TLSA Eintrag für DANE haben kein DNSSEC haben… Aber das ist eine ganz andere Baustelle.
UPDATE 1: Anmerkung: Diese Daten beinhaltet TLSA Einträge der MX Domains der genannten Domains und nicht nur der genannten Doamins selbst, d.h., ein Großteil der Domains mit solchen TLSA Einträgen verwendet wahrscheinlich Mailserver die DANE implementieren. Die Domains selbst verwenden jedoch kein DANE. Die Emailkommunikation dieser Domains sind daher nicht vollständig gegen MitM Angriffe geschützt.
CERT-Bund äußerte sich ebenfalls zu SPF Einträgen für Domains die gar keine Emails versenden:
Hier muss ich CERT-Bund jedoch deutlich widersprechen. Gerade Domains die gar keine Emails versenden sind prädestiniert für SPF und DMARC Einträge. Denn Fehlen diese Einträge kann jeder Angreifer nach belieben Emails mit gefälschten Absendern dieser Domains versenden und der Empfänger hat nur wenig Chancen herauszufinden ob die Email legitim oder nicht ist. Denn woher soll man denn wissen dass eine Domain die 2 Mailserver im DNS stehen hat gar keine Emails versendet?
Hat man eine Domain nomail.com
von der man keine Emails versenden möchte setzt man dort folgenden SPF Eintrag:
nomail.com. IN TXT "v=spf1 -all"
Dieser enthält keine freigegebenen IPs sondern nur die Direktive -all
. Das heißt niemand darf Emails im Namen der Domain versenden.
Den DMARC Eintrag setzt man idealerweise wie folgt:
_dmarc.nomail.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-23@yesmail.com; ruf=mailto:dmarc-reports-23@yesmail.com"
Mit der p=reject
Richtlinie weißt man alle Empfänger an Emails von dieser Domain zu verwerfen wenn diese weder SPF noch DKIM erfüllen. SPF kann nicht erfüllt werden (siehe oben) und da kein DKIM Eintrag gesetzt wird kann auch nie eine valide Signatur zustande kommen.
Optional weißt man mit rua=mailto:dmarc-23@yesmail.com
und ruf=mailto:dmarc-reports-23@yesmail.com
alle Empfänger die dennoch Emails im Namen der nomail.com
erhalten die IPs der Sender in Reporten an die Email Adresse dmarc-23@yesmail.com
zu melden.3
Derzeitig kann jeder im Namen von bund.de
Emails verschicken. Es liegt dann am Empfänger rauszufinden das bund.de
gar keine Emails verschickt.
Es wäre sehr zu begrüßen dass gerade behördliche Domainbetreiber mehr DMARC verwenden würden, da dies z.Z. den aktuelle Stand der Technik bzgl. Schutz vor gefälschten Emails darstellt. Ohne diese technischen Maßnahmen ist es einem Empfänger leider nur schwer bis gar nicht möglich gefälschte Emails zu erkennen.
Bürgern könnte man Empfehlen bei jeder Email die Sie von einer Behörde erhalten die nicht DKIM signiert ist bei der jeweiligen Behörde anzurufen und dort nach zu Fragen ob eine derartige Email von dort versendet wurde und darum bitten diese doch das nächstemal mit DKIM zu signieren… vielleicht würde dass die Adaption von DMARC beschleunigen. Diese würde nebenbei bemerkt auch der Empfehlung des BSI folgen “vor dem Öffnen persönlich beim Absender nachfragen, ob er eine E-Mail geschickt hat.” Das so ein Vorgehen nicht skaliert sollte jedem klar sein.
Es geht hierbei aber nicht nur um Kommunikation von Behörden zu Bürgern sondern auch von Firmen zu Kunden oder Firmen zu Firmen oder Behörden zu Behörden oder Behörden zu Firmen die ebenfalls vom Problem den Absender ohne DMARC nicht einwandfrei authentifizieren betroffen sind wenn nicht z.B. bereits eine Verwendung von z.B. S/MIME oder PGP vorliegt. Hier könnte man sich ein Beispiel an Facebook nehmen. Dort kann man sich seine Benachrichtigungen und Passwortreset Emails bereits PGP signiert und verschlüsselt senden lassen:
Um das ganze nicht zu negativ enden zu lassen ein paar Lichtblicke:
datev.de, elster.de, gelsenkirchen.de, ruhr-uni-bochum.de und viele andere sind vorbildlich aufgestellt was die durch DNS kontrollierten Sicherheitsmechanismen angeht.
1&1 hat seit dem erfassen der Daten eine p=none
DMARC Richtlinie veröffentlicht.↩
Im folgenden werden sowohl Behörden als auch Domains von Kommunen als Behörden Domains bezeichnet.↩
Damit die Report Emails auch ankommen muss man in yesmail.com
folgenden DNS Eintrag veröffentlichen: nomail.com._report._dmarc.nomail.com. IN TXT "v=DMARC1;"
↩