Was is DMARC?

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.

SPF

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:

DKIM

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

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:

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
HELO smtp.absender1.de
MAIL FROM:<alice@absender2.de>           <-- RFC5321.MailFrom  <--- ausgewertet von SPF
RCPT TO:<bob@empfaenger1.de>
DATA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=absender3.de; s=20161025;
        h=mime-version:from:date:message-id:subject:to;
        bh=GFOrCWTEu7KnAzxa5f+jRsPbA2HWWszHnEaaMNQyshU=;
        b=HzzNcsGTV7xkhyfznyWWcFXvH0tLy+2r1Rkir75hukvwngmzFXzITRTSn02cxDJdRg
.]
         D4Wg==
From: Charles <charles@absender4.de>   <--- RFC5322.From aka Display From    \
To: Eve <eve@empfaenger2.de>                                                 |
Subject: Wichtige Rechnung                                                   |
Date: Tue, 13 Aug 2019 19:32:56 +0500                                        |
                                                                             |
Hallo Johnnes,                                                               |
                                                                             | signiert
schauen Sie hier: http://ganzklarnichtboese.evil/rechnung.pdf.exe            | mittels
                                                                             | DKIM
MfG,                                                                         |
                                                                             |
David                                                                        |
                                                                             |
.                                                                            /
QUIT


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

oder


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

und

Dieses Domain Abgleichen wird auch “DMARC Aligmnet” genannt.

Wie schützt DMARC?

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.

Gefälschtes RFC5322.From

Hier sehen wir eine vermeintliche Gewinnmitteilung angeblich gesendet von support@1und1.de:

Phishing das 1und1.de als Absender fälscht

Phishing das 1und1.de als Absender fälscht

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:

Adressleiste der 1&1 Phishing Webseite mit HTTPS

Adressleiste der 1&1 Phishing Webseite mit HTTPS

1&1 Phishing Webseite

1&1 Phishing Webseite

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:

Header der 1und1.de Phishing-Email

Header der 1und1.de Phishing-Email

  1. Die Email wurde ursprünglich von apache@em-plan.com versendet.
  2. SPF schlug nicht fehl da der Sender berechtigt war Emails im Namen von em-plan.com zu versenden.
  3. Im 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.

DKIM selbst verifizieren

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:

Eine Amazon.de Email mit DKIM Signatur

Eine Amazon.de Email mit DKIM Signatur

Thunderbird’s DKIM-Verifier kann z.B. so konfiguriert werden dass Absender deren DKIM Signatur verifiziert werden kann grün markiert werden:

Echte Paypal Email

Echte Paypal Email

Emails deren Signatur zwar verifiziert werden kann, aber deren signierende Domain von der im Absender Feld abweicht werden orange markiert:

Signatur Domain ungleich Absender Domain

Signatur Domain ungleich Absender Domain

Absender ohne gültige DKIM Signatur können rot dargestellt werden:

WeChat Phishing

WeChat Phishing

Grenzen des DMARC Schutzes

Fehlkonfigurationen

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.

Display Namen fälschen

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:

Google Phishing Mail

Google Phishing Mail

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.

Ganz andere Domains

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.

Homoglyphe

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:

Eine Amazon.de Email mit DKIM Signatur

Eine Amazon.de Email mit DKIM Signatur

Wenn DMARC gar nicht verwendet wird

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.

Auswertung deutscher Domains

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.

Durchsuchbare Tabelle der einzelnen Daten

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.

Statistik

Viel interessanter als die einzelnen Ergebnisse ist eine statistische Auswertung der erfassten Daten.

Rohe Zahlen

In diesem Abschnitt werden erstmal nur die rohen Zahlenwerte gelistet.

Die Auswertung / Erklärung findet später in Auswertung / Erklärung statt.

Gesamt (.de der Alexa Top 1M + .de Behörden)

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

Behörden

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

.de der Alexa Top 1M

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

Alexa Top 14K

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

Auswertung / Erklärung

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:

Einstellung BSI zu DMARC

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:

Nur 3 Suchtreffer für DMARC auf der Seite bsi.bund.de via Google

Nur 3 Suchtreffer für DMARC auf der Seite bsi.bund.de via Google



Lediglich das CERT-Bund des BSI hat sich auf Twitter mal zu DMARC geäußert:

CERT-Bund Äußerungen bzgl. DMARC.

CERT-Bund Äußerungen bzgl. DMARC.

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:

CERT-Bund Äußerungen bzgl. SPF bei Domains die keine Mails versenden.

CERT-Bund Äußerungen bzgl. SPF bei Domains die keine Mails 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?

Domains die eigentlich gar keine Emails senden

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.

Schlusswort

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:

Facebook versendet auf Wunsch mit PGP signierte und verschlüsselte Emails

Facebook versendet auf Wunsch mit PGP signierte und verschlüsselte Emails



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&1 hat seit dem erfassen der Daten eine p=none DMARC Richtlinie veröffentlicht.

  2. Im folgenden werden sowohl Behörden als auch Domains von Kommunen als Behörden Domains bezeichnet.

  3. 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;"