[English]E-Mail-Sicherheit für Security Operations Center (SOC) Teams. Was versteckt sich hinter Begriffen wie DKIM, SPF und DMARC, die zur Absicherung der E-Mail-Kommunikation verwendet wird?
Mir ist die Tage ein Post mit einem Bild untergekommen, welches die Begriffe DKIM (Domain keys Identified Mail), SPF (Sender Policy Framework) und DMARC (Domain-based Message Authentication, Reporting and Conformance) in einem Bild zusammenfasst und erklärt.
Anzeige
Frohes neues Jahr und vielen Dank für diese kurze Übersicht.
Da aktuell immer mehr Systeme mit scharfgeschaltet DMARC ausgestattet werden wird es immer wichtiger sich mit diesen Themen zu beschäftigen.
Leider verstehen selbst einige große Anbieter ihr Handwerk nicht.
So hatten wir letztens einige Mails von einem Dienstleister, die immer wegen fehlerhaftem SPF Record abgelehnt wurden.
Er hatte die Mails über Google versendet, aber den Google SPF Record nicht bei seiner Domain eingetragen.
Google prüft das nicht, das muss der Nutzer selber prüfen und dann schauen, ob er das überhaupt in seinem DNS Eintrag anpassen kann.
Naja, mindestens folgende Dinge sollte der OP korrigieren:
"Sending server attaches a digital signature with a private key"
->
"Sending server attaches a digital signature USING a private key"
"Recipient servers are validated against this list."
->
"Recipient servers are VALIDATING against this list."
"They specify how to treat emails that fail SPF or DKIM checks."
->
"They specify how to treat emails that fail SPF AND DKIM checks."
Danke! Die Korrekturen verbessern das Verständnis.
SPF:
Setzt man in den DNS Einstellungen.
Kann man i.d.R. immer (mind. manuell selbst setzen), wenn man eine eigene Domain für seine E-Mail nutzt.
Macht Probleme mit Mailinglisten, weil dann der Listen-Server unter seiner IP mit der ursprünglichen Absenderadresse versendet.
Löschen auf Basis eines falschen SPF ist daher problematisch, weil es zu vielen Fehlfilterungen führt.
SPF hilft auch dann nicht gegen Spam, wenn der Absender einfach eine eigene Domain registriert, die er originalen ähnlich ist. D.h. der Angreifer kann zwar nicht mit gültigem SPF von opfer.de versenden, aber von opferr.de , opfer-support.de oder opfer.shop
SPF taugt daher nur sehr eingeschränkt für irgendwas.
DKIM:
Macht der Mailserver. Wer von seiner eigenen Domain E-Mails mit gültigem DKIM versenden möchte, betreibt entweder einen eigenen Mailserver unter Selbstverwaltung, oder er ist drauf angewiesen, dass der Mailserver von All Inkl, 1blu, OVH, Strato, etc. entsprechend konfiguriert ist und einen Schlüssel hinterlegt hat. Man selbst kann den Schlüssel nicht pflegen.
Ist brauchbar, um automatisch zu filtern, wenn auch die Quote der ausgefilterten Mails recht gering sein dürfte.
– Schützt nicht davor, dass der Angreifer den fremden Mailserver übernommen hat.
– Nicht gesetzte DKIM Header sind sehr häufig (ca. 30 – 50 %), hierauf kann man auch nicht filtern.
– 10 – 20% aller eintreffenden Spam E-Mails haben aber einen ungültigen DKIM. Diese Mails kann man ohne Rückfrage verwerfen. Diese sind nie seriös.
DKIM, SPF, DMARC sind nur begrenzt zum Spamfiltern tauglich, aber eignen sich hervorragend um die eigene Mail Domain zu sichern. Wenn korrekt eingerichtet kann niemand leicht die Maildomain missbrauchen, und der Mailserver kann gefälschte Mails gut erkennen.
Beides ist gerade bei der Bekämpfung von Phishing Mails usw. eine grosse Hilfe.
Mit DMARC hat man zusätzlich ein Tool um auch fehlerhafte Konfigurationen zu erkennen.
"SPF taugt daher nur sehr eingeschränkt für irgendwas."
Ich habe selten so einen Schwachsinn gelesen! SPF ist das wichtigste Element in der Mailkette, weil es Spoofing verhindert!
Es kommen schlicht keine Mails mehr mit gefälschtem Absender an.
Dies betrifft auch nicht nur die eigene Domain!
"Macht Probleme mit Mailinglisten, weil dann der Listen-Server unter seiner IP mit der ursprünglichen Absenderadresse versendet."
Dann muss deren Server einfach mit "include" mit in den SPF inkludiert werden.
Eine Frage an die Leserschaft:
Als wir die DMARC-Validierung bei unserem Maileingang scharf schalteten, mussten wir leider feststellen, dass viele, sogar namhafte Firmen ihr Ausgangs-Emails mit tenantname.onmicrosoft.com DKIM-signieren, obwohl mit der P2-HeaderFrom-Domain @firma.de versandt wurden. Dann geht das DKIM-Alignment HeaderFrom ungleich DKIM-Domain auf "fail". Wenn es sich dann noch um eine Out-of-Office-Meldung oder einen Non-Delivery-Report handelt (in denen der Envelope-From leer ist), dann geht die gesamte DMARC-Prüfung auf "fail" und der Empfang wird abgelehnt bei p=reject.
Solche abgelehnten Emails sind dann "false positive", und man muss sich mühsam mit der Absender-IT austauschen, um das Problem zu fixen.
Wir haben daher die DMARC-Validierung bei unseren Eingangs-Emails wieder abgeschaltet.
Haben andere dieses Phänomen der falschen DKIM-Signatur mit tenantname.onmicrosoft.com auch in größerem Maße beobachtet?
Ja falsche Konfig ist weit verbreitet.
Vor allem Marketing Firmen sind hier leider technisch meist vollkommen daneben.
Viele Firmen sind sich nicht bewusst dass diese Maßnahmen den Empfang der eigenen Mails verhindern.
Marketing-Firmen:
Also so eine Art Werbeblocker, klingt doch gut ;-)
Ja, haben wir schon vor Jahren beobachtet. Aber wir fahren hierbei, wie bei TLS und Cipher Suites eine 0% Toleranz. Wenn die IT/Verantwortliche des Absenders nicht fähig ist seine Mail Plattform sauber zu konfigurieren und kontinuierlich zu überwachen ist das nicht unser Problem.
Da wir sowas über Richtlinien im Konzern geregelt haben, kann auch nicht so einfach intern Druck aufgebaut werden. Weil das würde bedeuten, dass sich meine Menge Leute mit einer Ausnahmegenehmigung beschäftigen müssten. Somit ist der Hürde schon relativ hoch… :-)
Es meint doch jeder ITler heutzutage er könnte eine E-Mail-Plattform konfigurieren/betreuen. Was aber mit einem gewissen regelmäßigen Aufwand verbunden ist.
DW schreibt:
"Aber wir fahren hierbei, wie bei TLS und Cipher Suites eine 0% Toleranz. Wenn die IT/Verantwortliche des Absenders nicht fähig ist seine Mail Plattform sauber zu konfigurieren und kontinuierlich zu überwachen ist das nicht unser Problem."
Aber es ist das Problem Deines Konzerns, wenn legitime, aber technisch falsch konfigurierte Emails von Euch abgelehnt werden. Diese fehlenden Emails führen doch zu Problemen in Euren Geschäftsprozessen!
Was sind denn das für "Richtlinien", die Euch eine solch starke Stellung gegenüber den Endanwendern geben?
Da wir auch "eine Menge Leute" für die Ausnahmen hätten beschäftigen müssen, haben wir – wie schon geschrieben – die DMARC-Prüfung nach wenigen Stunden wieder abgeschaltet. Wir probieren es aber in Q1/2025 nochmals ;-)
"Was sind denn das für "Richtlinien", die Euch eine solch starke Stellung gegenüber den Endanwendern geben?"
Ich arbeite in einem größeren Laden (> 100.000 MA). Damit gibt es unzähliger Gesellschaften, die sowohl Shared Services der Group IT nutzen als auch eigene IT haben. Damit die Umgebungen mehr oder weniger gleich aussehen (Design, Namen, Aufbau, Produkte, Security, etc.) gibt es bei uns Richtlinien, welche die Group IT vorgibt. Das bedingt natürlich, dass die Umsetzung regelmäßig geprüft und ggf. zur Korrektur aufgefordert wird.
Möchte also jemand eine Ausnahme von einer Richtlinie, muss entsprechend ein Antrag bei der Group IT gestellt werden. Damit wird ein Workflow in Bewegung gesetzt, wo alle betroffenen Teams zur Stellungnahme (Dafür, Dagegen – Warum), Risikoanalyse, Auswirkungen aus nachgelagerte Systeme/Anwendungen, etc.). aufgefordert werden. Dann gibt es da Stellen (Datenschützer, CISO, PSO, die ein Veto Recht haben. Wird von dort ein Veto eingelegt, ist die Ausnahme abgelehnt. Und da hat auch ein Geschäftsführer einer Gesellschaft kaum eine Chance. :-)
@DW: Vielen Dank für die Erklärung. Das von Dir genannte Regelwerk mit seinem Genehmigungsprozess, Vetomöglichkeiten und Formalismus erklärt sehr gut, warum der "interne" Anwender kurzfristig keinen Druck aufbauen kann. Ihr verweist ihn einfach auf den "Dienstweg". Dort stirbt er den "Bürokratismus"-Tod ;-)
Im Gegenzug habt Ihr einen einheitlichen, strengen Sicherheitsregeln folgenden Zustand.
In einem mittelständischen Unternehmen, in dem der Vertriebschef sich direkt beim IT-Leiter beschwert und letzterer die Lösungssuche nach unten delegiert, ist ein solcher Zustand undenkbar :-(
wenn alle endlich DKIM verwenden würden, könnte auf die Notlösung SPF verzichten.
Technisch ist es ja egal wer die E-Mail anliefert, wenn die Signatur stimmt.
würde DKIM konsequent verwendet könnte wieder jeder wie früher jedem E-Mails schicken und müsste nicht über den smart Host seines Providers gehen.
Klar dass die Provider das nicht wollen.
naja
Schick die Grafik mal an die Telekom, die haben da noch nie von gehört. Entsprechend werden deren Mails von MS regelmäßig als Spam eingestuft.
Die haben nicht nur nicht davon gehört, die wollen stattdessen, dass sich jede Domain mit eigenem MX persönlich bei denen anmeldet. Sonst nehmen sie deine Mails an ihre Kunden gar nicht erst an.
Auch eine Möglichkeit, sich vom Rest des Internets abzukapseln. Die wollen vermutlich ohnehin ein isoliertes Telekomnet oder so ;)
Und jetzt müsste man manchen Firmen nur noch erklären, dass man mit DKIM versehene Mails im Nachgang nicht mehr verändern darf (automatische Disclaimer zum Beispiel sind häufige Kandidaten), weil das die DKIM Signatur bricht. Und das DKIM Fehler eigentlich immer Absenderseitig zu beheben sind.
Ich weiß nicht, wie oft ich schon mit irgendwelchen Leuten diskutieren durfte, die der Meinung waren, der Fehler läge bei uns als Empfänger, da deren IT nichts finden könne.
@Daniel A. schreibt:
"Ich weiß nicht, wie oft ich schon mit irgendwelchen Leuten diskutieren durfte, die der Meinung waren, der Fehler läge bei uns als Empfänger, da deren IT nichts finden könne."
Das ist leider auch unsere Erfahrung. Das Problem ist zweistufig:
(1) Finde zuerst einen geeigneten Ansprechpartner beim Absender – wie soll das funktionieren, außer man kennt den absendenden Partner schon aus der Geschäftsbeziehung?
(2) Hat man einen IT-ler bzw. einen externen IT-Supporter des Absenders gefunden, muss man das Problem auch noch so erklären, dass der Absender es fixen kann.
Der Link zum Bild funktioniert nicht mehr. Ist das Bild noch sonst irgendwo verfügbar? Das Bild war eine perfekte Übersicht…
probiere es noch mals, wenn ich wieder an Bord bin, binde ich es über den Blog ein