In den letzten Blog Artikeln dieser Reihe haben wir uns mit den beiden Mail-Authentisierungs-Verfahren SPF (siehe Teil 1) und DKIM (siehe Teil 2) auseinandergesetzt und dabei festgestellt (knapp zusammengefasst und etwas vereinfacht):
SPF
Schaut in einem DNS TXT Record, ob der einliefernde Mailserver berechtigt ist, Mails für die Adresse im „envelope sender“ zu verschicken.
Problem:
- Die empfangende Person sieht den „envelope sender“ gar nie, sondern der Mail Client zeigt ihr nur das „header from“ an. Absenderadressen können also trotzdem gefälscht werden, ohne dass der Empfänger etwas merkt.
DKIM
Signiert den Mail-Header inkl. dem „header from“ mit einem im DNS hinterlegten Key.
Probleme:
- Der verwendete DKIM Key muss nicht mit der Absender-Mailadresse übereinstimmen.
- DKIM sagt nichts darüber aus, was mit Mails mit gültigen oder ungültigen Signaturen geschehen soll.
Beide dieser Verfahren helfen nicht gegen Spam (entgegen der Aussage von Google, siehe Teil 1) oder gegen Mail-Fälschungen (Absender Spoofing). Denn SPF überprüft den für den Empfänger nicht sichtbaren „envelope sender“ und die DKIM Signatur überprüft keine Mailadressen.
Diese Mängel soll nun das dritte Verfahren DMARC beheben.
DMARC
Dieses Akronym steht für „Domain-based Message Authentication, Reporting and Conformance“.
- Basiert auf SPF und DKIM
- DMARC ist ok, wenn mindestens SPF oder DKIM ok ist.
- Identifier Alignment
- Prüfung des From-Headers bei SPF (SPF schaut sonst nur den Envelope Sender an).
- DKIM Signatur Domain muss mit From-Header übereinstimmen.
- Sender gibt Policy zu Behandlung der Mails durch den Empfänger bei Verstössen vor (im DNS hinterlegt)
- Benachrichtigungen des DMARC-Admins durch den Empfangenden Mailserver. So kann Domain-Missbrauch festgestellt werden.
DMARC stützt also auf SPF und DKIM ab. Als Mailadresse, welche für die Überprüfung durch SPF verwendet wird, wird nun nicht mehr der (für normale Benutzer unsichtbare) „envelope sender“ verwendet, sondern das im Mail Programm angezeigte „header from“. Weiter muss die in der DKIM Signatur verwendete Domäne mit dem „header from“ übereinstimmen. Dies nennt DMARC „Identifier Alignment“. Somit können wir nun endlich behaupten, dass eines der hier besprochenen Verfahren gegen Absender-Fälschungen hilft.
DMARC hat aber noch weitere Vorteile: Der Admin kann in einem DNS TXT Record angeben, was bei einer fehlgeschlagenen DMARC Überprüfung geschehen soll: gar nichts, das Mail wird in Quarantäne gestellt oder es wird abgewiesen (reject).
Weiter bietet DMARC die Möglichkeit, dass die empfangenden Mailserver dem DMARC-Admin Rückmeldungen über erfolgreiche oder fehlgeschlagene DMARC Überprüfungen geben. So sieht der Mailadmin, ob seine Maildomäne missbraucht wird. Oder auch, dass er z.B. vergessen hat, einen berechtigten Mailversender in den SPF Record einzutragen.
Beispiel
$ dig _dmarc.avantec.ch txt @1.1.1.1 +short
„v=DMARC1;p=none;rua=mailto:rua@avantec.ch;ruf=mailto:ruf@avantec.ch;fo=1“
v=DMARC1 besagt, dass es sich hier um einen DMARC Record handelt.
p=none bedeutet, dass aktuell noch keine Mails auf Grund einer fehlgeschlagenen Prüfung blockiert werden sollen.
Bei rua und ruf können Mailadressen für forensic und aggregate reports hinterlegt werden, wohin die empfangenden Mailserver Rückmeldungen schicken können.
fo=1 besagt schliesslich, dass ein forensic report geschickt werden soll, wenn eines der Verfahren SPF oder DKIM fehlschlägt. Bei einem Wert von 0 würde der Report nur geschickt, wenn beides gleichzeitig fehlschlägt.
Probleme
- Einschränkung: DMARC schaut sich ganz bewusst nur die „header from“ Mailadressen an und ignoriert „Sender“, „Reply-To“ und andere Header.
- Wie schon bei SPF und DKIM erwähnt, machen diese Verfahren Probleme mit Mailweiterleitungen und Mailinglisten.
Stellen wir uns mal folgendes Szenario vor:
- Ein User schickt ein DKIM signiertes Mail mit DMARC Policy = reject an eine Mailingliste.
- Die Mailingliste verändert das Subject und fügt ein [tag] ein. Dadurch wird die DKIM Signatur ungültig.
- Ein Empfänger dieser Mailingliste wendet die DMARC Policy korrekt an und rejected dieses Mail.
- Die Mailingliste sieht, dass das Mail abgewiesen wurde, geht darum davon aus, dass der Empfänger keine Mails empfangen kann und trägt ihn aus der Mailingliste aus.
Der korrekt handelnde Empfänger wird also aus der Mailingliste ausgetragen!
Damit dies nicht geschieht, muss die Mailinglisten-Software bzw. Konfiguration angepasst werden. So wird es noch viele bewährte Applikationen geben, welche nach jahrelangem reibungslosen Betrieb plötzlich Probleme machen, da sie noch nicht DMARC kompatibel sind.
Erfahrungen aus der Praxis
Ich möchte hier nun ein paar Beispiele auflisten, welche zeigen, was bei SPF/DKIM/DMARC schiefgehen kann. Dies sind keine erfundenen Fälle, sondern anonymisierte Auszüge aus unserem Maillog. Und nur von Mails, welche eigentlich legitim wären.
Beispiel 1
SPF fail: vergessener Mailserver
Envelope Sender: www-data@example.com
Header From: email@example.com
SPF: mailfrom identity www-data@example.com Fail (v=spf1)
Der einfachste Fall: Hier wurde bloss vergessen, den entsprechenden Mailserver in den SPF Record einzutragen. Hier handelt es sich wohl um einen extern gehosteten Webserver, welcher berechtigterweise Informationen verschickt.
Beispiel 2
SPF ok, DKIM fail, DMARC pass: Mail nach Versand verändert
Envelope Sender: user@example.com
Header From: user@example.com
SPF: mailfrom identity user@example.com Pass
DKIM: permfail body hash did not verify [final] (d=example.com s=selector i=@example.com)
DMARC: Message from domain example.com, DMARC pass (SPF aligned True, DKIM aligned False)
Hier ist also die SPF Überprüfung korrekt und die Namen stimmen überein (Alignment ok). Allerdings schlägt die DKIM Überprüfung fehl (im konkreten Fall, weil der Absender nach dem Anbringen der DKIM Signatur das Mail auf einem weiteren externen Gateway mittels S/MIME signiert und somit verändert hat). Trotzdem war DMARC erfolgreich, weil SPF korrekt war!
Beispiel 3
SPF ok, DKIM fail: Mailweiterleitung
Envelope Sender: vorname.nachname+caf_=nachname=example.com@gmail.com
Header From: account-security-noreply@accountprotection.microsoft.com
SPF: mailfrom identity vorname.nachname+caf_=nachname=example.com@gmail.com Pass
DKIM: permfail body hash did not verify [final] (d=accountprotection.microsoft.com s=selector1
i=@accountprotection.microsoft.com)
Ein User hat einen Passwort-Reset für sein Microsoft Konto angefordert. Hinterlegt war dazu seine Gmail Adresse. Diese Gmail Adresse wurde zu einer Firmenmailadresse weitergeleitet. Auf unserem Mailgateway wurde das Mail also von Google eingeliefert, dazu passt auch der SPF Record. Die DKIM Signatur wurde aber von Microsoft angebracht. Es scheint, dass das Mail von Google modifiziert wurde, entsprechend ist der DKIM Test nach der Weiterleitung fehlgeschlagen.
Beispiel 4
SPF ok, DKIM none, DMARC fail: Alignment falsch
Envelope Sender: support=example.com__0-1234@1234.u-abcd.na131.bnc.salesforce.com
Header Form: support@example.com
SPF: mailfrom identity support=example.com__0-1234@1234.u-abcd.abcd.bcd.salesforce.com Pass
DKIM: does not contain DKIM signature.
DMARC: Message from domain example.com, DMARC fail, (SPF aligned False, DKIM aligned False), DMARC policy is quarantine
Die SPF Prüfung war erfolgreich. Da aber der „envelope sender“ nicht mit dem „header from“ übereinstimmt, wurde das Mail auf Grund der Policy, welche der Absender esample.com vorgegeben hat, in die Quarantäne gestellt. Hier wurde also vergessen, dass der externe Dienstleister eine „falsche“ Absenderdomäne im Envelope verwendet.
Zusammenfassung
DMARC behebt einige der Mängel von SPF und DKIM. Dadurch wird es nun möglich Mail-Spoofing einigermassen zuverlässig zu erkennen. Trotzdem ist auch dieses Verfahren nicht ganz unproblematisch: Es ist nicht ganz einfach, all die benötigten Einträge für SPF zusammenzustellen und somit seine DMARC Policy korrekt abzubilden. Viele auch grosse Mailversender haben Ihre Policies nicht im Griff und verschicken Mails, welche durch SPF/DKIM/DMARC blockiert werden. Es wird wohl noch eine ganze Weile dauern, bis alle ihre Records korrekt erfasst haben.
In einem der nächsten Blog Artikel werden wir schildern, wie Sie vorgehen können, um SPF/DKIM/DMARC auszurollen und was dazu auf Ihrem Mailgateway nötig ist.
Links:
DMARC: tools.ietf.org/html/rfc7489
SPF/DKIM/DMARC oder warum Google meine Mails nicht mag, Teil 1: www.tec-bite.ch/warum-mag-google-meine-mails-nicht/
SPF/DKIM/DMARC oder warum Google meine Mails nicht mag, Teil 2: www.tec-bite.ch/warum-mag-google-meine-mails-nicht-teil-2/
Der Beitrag SPF/DKIM/DMARC oder warum Google meine Mails nicht mag, Teil 3 erschien zuerst auf Tec-Bite.