Was sind DMARC-Berichte?
DMARC steht für Domain-based Message Authentication, Reporting, and Conformance. Es handelt sich um ein Protokoll zur E-Mail-Authentifizierung, das zum Schutz vor Phishing und Spoofing beiträgt.
Beim Versand einer E-Mail ermöglicht DMARC dem Domaininhaber die Einrichtung eines DNS-Eintrags, der angibt, welche Authentifizierungsmethoden wie SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail) verwendet werden, um die Echtheit der E-Mail zu überprüfen. Wenn die E-Mail diese Authentifizierungsprüfungen nicht besteht, weist DMARC den E-Mail-Anbieter des Empfängers an, wie er die Nachricht behandeln soll, indem er sie entweder unter Quarantäne stellt oder sie ganz abweist.
DMARC ist angesichts der heutzutage immer raffinierteren und häufigeren Phishing- und Spoofing-Angriffe auf E-Mails im Internet immer wichtiger geworden. Durch die Implementierung von DMARC können Domaininhaber ihre Marke und ihre Kunden vor den negativen Auswirkungen dieser Angriffe schützen, einschließlich Vertrauensverlust, Rufschädigung und finanziellem Verlust.
DMARC schützt nicht nur vor Phishing- und Spoofing-Angriffen, sondern bietet auch Berichtsfunktionen. Domaininhaber können Berichte über Aktivitäten zur E-Mail-Authentifizierung erhalten, z. B. darüber, welche Nachrichten die DMARC-Prüfung bestanden haben und welche nicht, und auch darüber, woher diese Nachrichten stammen.
Die DMARC-Verwaltung umfasst die Konfiguration und Pflege der DMARC-Richtlinien für eine Domain. Eine effektive DMARC-Verwaltung erfordert eine laufende Überwachung und Analyse der Aktivitäten zur E-Mail-Authentifizierung sowie die Fähigkeit, DMARC-Richtlinien bei Bedarf anzupassen und zu aktualisieren.
Zu den wichtigsten Komponenten einer effektiven DMARC-Verwaltung gehören:
- Einrichtung von DMARC-Richtlinien: Dazu gehört die Konfiguration des DMARC-Eintrags der Domain, um die geeigneten Authentifizierungsmethoden und Richtlinien für die Behandlung von Nachrichten festzulegen, die die Authentifizierungsprüfungen nicht bestehen. So sieht ein DMARC DNS-Eintrag aus:
v=DMARC1; p=reject; rua=mailto:[email protected]
Hier wird festgelegt, dass wir DMARC-Version 1 verwenden werden, dass unsere Richtlinie darin besteht, E-Mails abzuweisen, wenn sie die DMARC-Prüfungen nicht bestehen, und dass die E-Mail-Adresse angegeben wird, an die Provider DMARC-Berichte senden sollen.
- Überwachung der Aktivitäten zur E-Mail-Authentifizierung: DMARC-Berichte sind ein wichtiges Instrument für Domaininhaber, um die Sicherheit und Zustellbarkeit von E-Mails sowie die Einhaltung von Branchenstandards und Vorschriften zu gewährleisten. Durch die regelmäßige Überwachung und Analyse von DMARC-Berichten können Domaininhaber E-Mail-Bedrohungen erkennen, E-Mail-Kampagnen optimieren und die E-Mail-Authentifizierung insgesamt verbessern.
- Anpassungen nach Bedarf vornehmen: Auf der Grundlage der Analyse von DMARC-Berichten müssen Domaininhaber möglicherweise Anpassungen an DMARC-Richtlinien oder Authentifizierungsmethoden vornehmen, um sicherzustellen, dass E-Mail-Nachrichten ordnungsgemäß authentifiziert und vor Phishing- und Spoofing-Angriffen geschützt werden.
- Zusammenarbeit mit E-Mail-Anbietern und Drittanbietern: Eine effektive DMARC-Verwaltung kann die Zusammenarbeit mit E-Mail-Anbietern und Drittanbietern erfordern, um sicherzustellen, dass die DMARC-Richtlinien ordnungsgemäß umgesetzt und durchgesetzt werden.
Heute haben wir DMARC-Management lanciert. So haben wir es entwickelt.
So haben wir DMARC-Management entwickelt
Als führender Anbieter von cloudbasierten Lösungen für Sicherheit und Performance verfolgen wir bei Cloudflare einen besonderen Ansatz, um unsere Produkte zu testen. Wir probieren unsere eigenen Tools und Dienstleistungen selbst aus, d.h. wir nutzen sie in unserer operativen Geschäftstätigkeit. So können wir etwaige Probleme oder Fehler erkennen, bevor unsere Kunden davon betroffen sind.
Wir verwenden intern unsere eigenen Produkte, wie Cloudflare Workers, eine serverlose Plattform, die es Entwicklern ermöglicht, ihren Code in unserem globalen Netzwerk auszuführen. Seit seiner Einführung im Jahr 2017 ist das Workers-Ökosystem erheblich gewachsen. Heute gibt es Tausende von Entwicklern, die Anwendungen auf der Plattform entwickeln und bereitstellen. Die Stärke des Workers-Ökosystems liegt darin, dass es Entwicklern die Möglichkeit bietet, anspruchsvolle Anwendungen zu erstellen, die zuvor nicht möglich oder nicht praktikabel waren, wenn sie so nah am Kunden ausgeführt werden sollten. Workers können dazu verwendet werden, APIs zu erstellen, dynamische Inhalte zu generieren, Bilder zu optimieren, Echtzeitverarbeitung durchzuführen und vieles mehr. Die Möglichkeiten sind praktisch unbegrenzt. Wir haben Workers verwendet, um Dienste wie Radar 2.0, oder Softwarepakete wie Wildebeest zu betreiben.
Vor kurzem haben wir unser E-Mail-Routing-Produkt mit Workers zusammengeführt, um die Verarbeitung eingehender E-Mails über Workers-Skripts zu ermöglichen. Wie in der Dokumentation beschrieben: „Mit E-Mail-Workers können Sie die Leistung von Cloudflare Workers nutzen, um jede Logik zu implementieren, die Sie zur Verarbeitung Ihrer E-Mails benötigen, und komplexe Regeln erstellen. Diese Regeln bestimmen, was passiert, wenn Sie eine E-Mail erhalten.“ Regeln und verifizierte Adressen können allesamt über unsere API konfiguriert werden.
So sieht ein einfacher E-Mail-Worker aus:
export default {
async email(message, env, ctx) {
const allowList = ["[email protected]", "[email protected]"];
if (allowList.indexOf(message.headers.get("from")) == -1) {
message.setReject("Address not allowed");
} else {
await message.forward("inbox@corp");
}
}
}Ziemlich einfach, oder?
Durch die Möglichkeit, eingehende E-Mails programmatisch zu verarbeiten, schien es die ideale Lösung zu sein, um eingehende DMARC-Berichts-E-Mails auf skalierbare und effiziente Weise zu verarbeiten, wobei das E-Mail-Routing und die Worker die schwere Arbeit des Empfangs einer ungebundenen Anzahl von E-Mails aus der ganzen Welt übernehmen. Eine grobe Beschreibung dessen, was wir benötigen, ist:
- E-Mail empfangen und Bericht extrahieren
- Veröffentlichung relevanter Details auf der Analytics-Plattform
- Speichern des Rohberichts
Mit E-Mail-Workers können wir #1 ganz einfach umsetzen. Wir müssen nur einen Worker mit einem email()-Handler erstellen. Dieser Handler erhält die SMTP-Umschlagelemente, eine zergliederte (pre-parsed) Version der E-Mail-Kopfzeilen und einen Stream zum Lesen der gesamten Roh-E-Mail.
Für #2 können wir auch einen Blick auf die Workers-Plattform werfen, wo wir die Workers Analytics Engine finden. Wir müssen lediglich ein geeignetes Schema definieren, das sowohl von den in den Berichten enthaltenen Daten als auch von den Abfragen abhängt, die wir später durchführen möchten. Anschließend können wir die Daten entweder über die GraphQL oder die SQL-API abfragen.
Für #3 genügt ein Blick auf unseren R2-Objektspeicher. Es ist trivial, von einem Worker aus auf R2 zuzugreifen. Nachdem wir die Berichte aus der E-Mail extrahiert haben, speichern wir sie in R2 für die Nachwelt.
Wir haben dies als verwalteten Service eingerichtet, den Sie in Ihrer Zone aktivieren können, und der Einfachheit halber eine Dashboard-Oberfläche hinzugefügt. In Wirklichkeit stehen Ihnen jedoch alle Tools zur Verfügung, um Ihren eigenen DMARC-Berichtsprozessor zusätzlich zu Cloudflare Workers in Ihrem eigenen Konto einzusetzen, ohne dass Sie sich um Server, Skalierbarkeit oder Performance kümmern müssen.
Architektur
E-Mail-Workers ist eine Funktion unseres E-Mail-Routing-Produkts. Die E-Mail-Routing-Komponente läuft auf allen unseren Knoten, so dass alle Knoten in der Lage sind, eingehende E-Mails zu verarbeiten. Das ist wichtig, weil wir das BGP-Präfix für den E-Mail-Eingang von allen unseren Rechenzentren aus ankündigen. Der Versand von E-Mails an einen E-Mail-Worker ist so einfach wie das Einrichten einer Regel im E-Mail-Routing-Dashboard.
Wenn die E-Mail-Routing-Komponente eine E-Mail empfängt, die einer Regel entspricht, welche die Zustellung an den Worker vorsieht, kontaktiert sie unsere interne Version der kürzlich als Open-Source veröffentlichten workerd-Laufzeitumgebung, die ebenfalls auf allen Knoten läuft. Das RPC-Schema, das diese Interaktion regelt, ist in einem Capnproto-Schema definiert und ermöglicht es, den Text der E-Mail beim Lesen an Edgeworker zu streamen. Wenn das Worker-Skript beschließt, diese E-Mail weiterzuleiten, kontaktiert Edgeworker das E-Mail-Routing über eine in der ursprünglichen Anfrage gesendete Fähigkeit.
jsg::Promise<void> ForwardableEmailMessage::forward(kj::String rcptTo, jsg::Optional<jsg::Ref<Headers>> maybeHeaders) {
auto req = emailFwdr->forwardEmailRequest();
req.setRcptTo(rcptTo);
auto sendP = req.send().then(
[](capnp::Response<rpc::EmailMetadata::EmailFwdr::ForwardEmailResults> res) mutable {
auto result = res.getResponse().getResult();
JSG_REQUIRE(result.isOk(), Error, result.getError());
});
auto& context = IoContext::current();
return context.awaitIo(kj::mv(sendP));
}
Im Rahmen der DMARC-Berichte behandeln wir die eingehenden E-Mails folgendermaßen:
- Abrufen des Empfängers der zu verarbeitenden E-Mail, d.h. der verwendeten RUA. RUA ist ein DMARC-Konfigurationsparameter, der angibt, wohin das aggregierte DMARC-Verarbeitungsfeedback in Bezug auf eine bestimmte Domain gemeldet werden soll. Diesen Empfänger finden Sie im Attribut „to“ der Nachricht.
const ruaID = message.to
- Da wir DMARC-Berichte für eine unbegrenzte Anzahl von Domains bearbeiten, verwenden wir Workers KV, um einige Informationen über jede einzelne Domain zu speichern und diese Informationen im RUA zu verschlüsseln. So wissen wir auch, ob wir diese Berichte erhalten sollten.
const accountInfoRaw = await env.KV_DMARC_REPORTS.get(dmarc:${ruaID})
- An dieser Stelle wollen wir die gesamte E-Mail in einen arrayBuffer einlesen, um sie zu parsen. Je nach Größe des Berichts stoßen wir hier möglicherweise an die Grenzen des kostenlosen Workers-Tarifs. In diesem Fall empfehlen wir Ihnen, auf das Ressourcenmodell Workers Unbound zu wechseln, bei dem dieses Problem nicht auftritt.
const rawEmail = new Response(message.raw)
const arrayBuffer = await rawEmail.arrayBuffer()
- Das Parsen der Roh-E-Mails beinhaltet unter anderem das Parsen der MIME-Teile. Es gibt mehrere Bibliotheken, mit denen Sie dies tun können. Sie können zum Beispiel postal-mimeverwenden:
const parser = new PostalMime.default()
const email = await parser.parse(arrayBuffer)
- Nachdem wir die E-Mail geparst haben, haben wir nun Zugriff auf die Anhänge. Diese Anhänge sind die DMARC-Berichte selbst und können komprimiert werden. Als Erstes möchten wir sie in ihrer komprimierten Form in R2 speichern, um sie langfristig aufzubewahren. Sie können später für die erneute Verarbeitung oder Untersuchung interessanter Berichte nützlich sein. Dies geschieht ganz einfach durch den Aufruf von put() in der R2-Bindung. Um den späteren Abruf zu erleichtern, empfehlen wir Ihnen, die Berichtsdateien auf der Grundlage der aktuellen Uhrzeit auf verschiedene Verzeichnisse zu verteilen.
await env.R2_DMARC_REPORTS.put(
`${date.getUTCFullYear()}/${date.getUTCMonth() + 1}/${attachment.filename}`,
attachment.content
)
-
Nun müssen wir uns den Mime-Typ des Anhangs ansehen. Die Rohform der DMARC-Berichte ist XML, aber sie können komprimiert werden. In diesem Fall müssen wir sie zunächst dekomprimieren. DMARC-Berichtsdateien können mehrere Komprimierungsalgorithmen verwenden. Wir verwenden den MIME-Typ, um zu wissen, welcher zu verwenden ist. Für Zlib-komprimierte Berichte kann pako verwendet werden, während für ZIP-komprimierte Berichte unzipit eine gute Wahl ist.
-
Nachdem wir die XML-Rohform des Berichts erhalten haben, hat fast-xml-parser beim Parsen einwandfrei funktioniert. So sieht die XML-Datei des DMARC-Berichts aus:
<feedback>
<report_metadata>
<org_name>example.com</org_name>
<[email protected]</email>
<extra_contact_info>http://example.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335521200</begin>
<end>1335652599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>business.example</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>business.example</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>business.example</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>business.example</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
- Wir haben jetzt alle Daten des Berichts zur Hand. Was wir dann als nächstes machen, hängt stark davon ab, wie wir die Daten präsentieren wollen. Für uns bestand das Ziel darin, aussagekräftige, aus den Berichten extrahierte Daten in unserem Dashboard anzuzeigen. Daher brauchten wir eine Analytics-Plattform, auf der wir die angereicherten Daten veröffentlichen konnten. Hier kommt die Workers Analytics Engineins Spiel. Die Analytics Engine eignet sich perfekt für diese Aufgabe, da sie es uns ermöglicht, Daten von einem Worker an sie zu senden, und eine GraphQL API bereitstellt, um anschließend mit den Daten zu interagieren. So erhalten wir die Daten, die in unserem Dashboard angezeigt werden sollen.
Für die Zukunft erwägen wir auch die Integration von Warteschlangen in den Workflow, um den Bericht asynchron zu verarbeiten und nicht darauf zu warten, dass der Client ihn fertigstellt.
Wir konnten dieses Projekt vollständig mit der Workers-Infrastruktur umsetzen und haben damit bewiesen, dass es möglich und vorteilhaft ist, nicht-triviale Anwendungen zu entwickeln, ohne sich Gedanken über Skalierbarkeit, Performance, Speicherung und Sicherheit machen zu müssen.
Open Sourcing
Wie wir bereits erwähnt haben, haben wir einen verwalteten Dienst entwickelt, den Sie aktivieren und nutzen können und den wir für Sie verwalten werden. Aber alles, was wir gemacht haben, kann auch von Ihnen in Ihrem Konto implementiert werden, so dass Sie Ihre eigenen DMARC-Berichte verwalten können. Das ist einfach und kostenlos. Um Ihnen dabei zu helfen, veröffentlichen wir eine Open-Source-Version eines Workers, der DMARC-Berichte auf die oben beschriebene Weise verarbeitet: https://github.com/cloudflare/dmarc-email-worker
Wenn Sie kein Dashboard haben, auf dem Sie die Daten anzeigen können, können Sie die Analytics Engine auch von einem Worker aus abfragen. Und wenn Sie die Daten in einer relationalen Datenbank speichern möchten, dann können Sie D1 zu Hilfe nehmen. Die Möglichkeiten sind endlos und wir sind gespannt darauf, was Sie mit diesen Tools entwickeln werden.
Bitte wirken Sie mit, erstellen Sie Ihre eigenen, wir sind schon gespannt.
Ein paar Worte zum Abschluss
Wir hoffen, dass dieser Beitrag Ihr Verständnis für die Workers-Plattform gefördert hat. Heute nutzt Cloudflare diese Plattform für die Entwicklung der meisten unserer Dienste, und wir denken, Sie sollten das auch tun.
Sie können gerne zu unserer Open-Source-Version beitragen und uns zeigen, was Sie damit machen können.
Das E-Mail-Routing arbeitet auch daran, die E-Mail-Workers-API funktional zu erweitern, aber dazu gibt es demnächst einen eigenen Blogbeitrag.