DMARC lernen und testen

 (learndmarc.com)
2 Punkte von GN⁺ 2023-10-02 | 1 Kommentare | Auf WhatsApp teilen
  • LearnDMARC ermöglicht das Lernen und Testen von SPF, DKIM, DMARC, den Kernelementen der E-Mail-Authentifizierung, auf einem Bildschirm; die vollständige visuelle Erklärung ist auf dem Desktop verfügbar
  • Der Ergebnisbildschirm zeigt zunächst Verbindungsinformationen wie Source IP address, Hostname und Sender, damit der Ausgangspunkt der Authentifizierungsbewertung nachvollzogen werden kann
  • SPF und DKIM zeigen jeweils die zu authentifizierende Domain und das Ergebnis an und machen zusätzlich sichtbar, ob die für die DMARC-Bewertung notwendige Alignment-Prüfung erfüllt ist
  • Der DMARC-Bereich verknüpft RFC5322.From domain, Policy(p=), SPF- und DKIM-Ergebnisse zum abschließenden DMARC Result
  • Abschließend lässt sich über Final verdict die Gesamtbewertung prüfen; außerdem werden eine Anonymisierung der Ergebnisse und ein DMARC-Lernlink angeboten

Zweck von LearnDMARC

  • Eine Seite zum Lernen und Testen von SPF, DKIM, DMARC
  • Die vollständige visuelle Erklärung der DMARC-Funktionsweise ist nur sichtbar, wenn die Website auf dem Desktop geöffnet wird

Elemente im Ergebnisbildschirm

  • Connection parameters

    • Source IP address
    • Hostname
    • Sender

  • SPF

    • Domain
    • Identity
    • Auth Result
    • DMARC Alignment

  • DKIM

    • Domain
    • Selector
    • Algorithm
    • Auth Result
    • DMARC Alignment

  • DMARC

    • RFC5322.From domain
    • Policy(p=)
    • SPF
    • DKIM
    • DMARC Result

Endgültige Bewertung und Zusatzfunktionen

  • Der Ergebnisbildschirm zeigt die Gesamtbewertung über Final verdict an
  • Mit Anonymize results können die Ergebnisse anonymisiert werden
  • Ein Link zu Learn more about DMARC wird bereitgestellt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-02
Meinungen auf Hacker News

  • Das ist eine gute Art, zentrale E-Mail-Dienste voranzutreiben, die nötig sind, um Spam zu reduzieren. Ich habe mir bei den Unternehmen, mit denen ich gearbeitet habe, immer gewünscht, dass SPF, DKIM und DMARC allein Motivation genug wären, aber Reputation reicht oft nicht aus, um Investitionen zu priorisieren.
    Zum Glück gibt es für Unternehmen, die vertrauenswürdig mit ihren Kunden kommunizieren wollen, einen Standard, der Marketern gefallen dürfte: Brand Indicators for Message Identification (BIMI). Jetzt bekommt man nicht nur Sicherheit, sondern auch ein hübsches Logo: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    In mehreren Unternehmen habe ich BIMI mit der Begründung „Customer Experience“ genutzt, um DMARC richtig umzusetzen, also mit P=Reject.

    • Auch DMARC hat noch Probleme. Material von vor ein paar Jahren: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      Weder SPF noch DKIM lösen den Schutz vor E-Mail-Spoofing vollständig. SPF authentifiziert die HELO/MAIL-FROM-Identifikatoren, DKIM authentifiziert das Feld d= im DKIM-Signature-Header, aber beide authentifizieren nicht den From-Header, der dem Endnutzer angezeigt wird. Deshalb kann die From-Adresse weiterhin gefälscht werden, selbst wenn SPF- und DKIM-Prüfungen bestehen.
      Dass eine E-Mail-Domain kein DMARC+ hat, ist eindeutig ein Problem, aber DMARC+ allein löst das Problem „ist das wirklich der Absender?“ ebenfalls nicht.
    • Aus Sicht eines Angreifers frage ich mich, was ihn daran hindert, eine Phishing-Domain mit demselben Logo zu erstellen und BIMI einzurichten.
    • Kostet BIMI nicht ungefähr 1000 US-Dollar pro Jahr?

  • Verwandtes Material: Interaktiv sehen, wie DMARC, SPF und DKIM funktionieren – https://news.ycombinator.com/item?id=29869266 – Januar 2022, 108 Kommentare

  • Ich frage mich, ob jemand eine Open-Source- oder zumindest kostenlose Möglichkeit kennt, DMARC-Berichte zu verarbeiten.
    Ich habe ein paar E-Mail-Domains mit aktiviertem SPF, DKIM und DMARC; es funktioniert, aber bei DMARC gibt es zwei lästige Probleme.
    (1) Manche Sites schicken DMARC-Berichte im Stil von „Sie haben 3 Nachrichten gesendet, alle sind in Ordnung und alle Prüfungen wurden bestanden“.
    (2) Gelegentlich versucht jemand, über andere Server Spam mit meiner Domain zu verschicken, und ich bekomme Berichte wie „Jemand hat Ihre Domain in HELO/FROM eingetragen und Spam versucht, aber die Prüfungen sind fehlgeschlagen und es wurde blockiert“.
    Beides ist für mich nutzlos. Ich will nicht wissen, dass mein Nutzer eine Mail an @gmail.com oder @mail.ru geschickt hat, und im zweiten Fall kann ich nichts tun, weil es nicht die IP meines Servers ist.
    XML selbst zu entpacken und zu prüfen ist zu umständlich; Filter oder ein Dashboard wären daher sehr nützlich.

    • Ich habe ein Skript, das ich für mich selbst geschrieben habe: https://github.com/hannob/rpter
      Es zeigt Zusammenfassungen der Berichte und Details zu Fehlschlägen. Es ist nicht besonders ausgefeilt, sollte aber einfach genug sein, um es zu erweitern. Es parst auch SMTP-TLS-Berichte.
    • parsedmarc (https://github.com/domainaware/parsedmarc) habe ich mir für später mit einem Stern markiert, aber noch nicht selbst ausprobiert.
    • dmarcian hat einen kostenlosen Personal-Tier: https://dmarcian.com/pricing/

  • Die Erklärung „Damit DMARC besteht, müssen DKIM- und/oder SPF-Prüfungen bestehen und die Domains aligned sein“ ist meines Wissens falsch.
    Es ist nicht „and/or“, sondern or. Es reicht, wenn entweder DKIM oder SPF besteht; es gibt keine Methode, beide zu verlangen.

    • In diesem Zusammenhang gab es kürzlich ein Problem bei der Partnerschaft zwischen Cloudflare und MailChannels, wodurch E-Mail-Spoofing möglich war.
      Das grundlegende Problem war, dass MailChannels keine Authentifizierung verlangte. Cloudflare Workers konnten den API-Endpunkt von MailChannels aufrufen und E-Mails senden, und MailChannels verlangte, dass man einen include:-Record zur SPF-Policy hinzufügt. Dadurch wurde MailChannels zu einem gültigen Absender für alle Domains, und jeder konnte jeden imitieren.
      Von den 2 Millionen gehosteten Domains hatten nur etwa 400 DKIM eingerichtet, aber selbst mit DKIM hätte allein ein bestandener SPF-Check DMARC bestehen lassen.
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • Ich glaube, die Syntax wurde falsch interpretiert. Hier bedeutet and/or wohl ein inklusives OR. „and“ heißt nicht zwingend, dass es eine mögliche Auswahloption ist.
    • Ich weiß nicht, warum das Downvotes bekommt, aber die Aussage, dass nur or korrekt ist, stimmt.
    • Wenn man kein Geld für eine Domain ausgeben will und ein IP-Adressliteral verwendet, bekommt man SPF kostenlos.
      Sobald man in den Feldern From:/Reply-To: nur eine E-Mail-Adresse mit IP-Adressliteral hat, bekommt man „SPF“ und erhält einen deutlich besseren Score, um beim ersten Transaction Greylisting zu vermeiden. Noch besser, wenn im Body keine URL steht.
      Aber das ist Allgemeinwissen.

  • Mir gefällt wirklich, dass der Prozess iterativ Schritt für Schritt nachvollziehbar gemacht wird. Vor ein paar Jahren, als ich bei meinem früheren Unternehmen mit ordentlichen Sicherheitsmaßnahmen auf selbst gehosteten E-Mail-Versand umsteigen wollte, wäre so etwas sehr hilfreich gewesen.

  • Beim Senden einer E-Mail über Apples Dienst „Hide My Email“ trat ein Fehler auf: https://support.apple.com/en-us/HT210425
    Unhandled Promise Rejection:
    TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)
    dist.min.js:3:32767
    Er trat auf, nachdem das Interface begonnen hatte, „Here are the message headers and message body:“ und DKIM-Signature: d=icloud.com s=1a1hai anzuzeigen.
    Da es schon über ein Jahr her ist, seit diese Website auf Hacker News vorgestellt wurde, scheint der JavaScript-Code veraltet zu sein und nicht mehr zu funktionieren. Vielleicht wurde Safari von Anfang an nicht unterstützt, oder beides trifft zu. Trotzdem habe ich im ersten und zweiten Teil des DMARC-Tests viel gelernt und konnte ein Gefühl dafür bekommen, was in den späteren Schritten passieren würde.
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • Beim Testen gefälschter E-Mails tritt derselbe Fehler auch in Chrome auf.
      telnet learndmarc.com 25
      Trying 87.239.13.42...
      Connected to learndmarc.com.
      Escape character is '^]'.
      220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000
      HELO there
      250 allspark.uriports.com Hello []
      MAIL From: me@example.com
      250 OK
      RCPT To: ld-49101f55f6@learndmarc.com
      250 Accepted
      DATA
      354 Enter message, ending with "." on a line by itself
      .
      250 OK id=1qn4QF-00CUhd-5j
      Beim Eintippen war es witzig, so nach dem Motto: „Man muss ja keinen Liebesbrief schreiben.“ Vielleicht liege ich falsch, aber im Datenabschnitt muss man offenbar die Header From: und To: wiederholen.
      Es bringt mich immer noch zum Lachen, wenn ich daran denke, wie viele E-Mails ich über die Jahre mit HELO there statt mit einem Hostnamen verschickt habe. Und ich frage mich auch, welchen Anteil am Internet-Traffic Enter message, ending with . on a line by itself ausmacht.
    • Es ging kaputt, weil die E-Mail ohne from-Feld gesendet wurde. Der Programmierer hat nur nicht daran gedacht, den Fall zu testen, dass ein böser Nutzer böse Dinge tut; eine besondere Verschwörung steckt nicht dahinter.
    • DMARC hängt von der RFC5322.From-Adresse ab; fehlt diese Adresse, gibt es also einen Fehler. Um solche Fehler zu vermeiden, werden E-Mails ohne diese Adresse inzwischen ignoriert.

  • Es ist wirklich erstaunlich, dass wir im 21. Jahrhundert versuchen, Technologien weiterzubetreiben, die vor etwa 30 Jahren zu gutem Willen und Idealen passten, und uns dafür auf Schicht um Schicht aus Kompatibilitätsebenen und Hacks verlassen.
    Bei VOIP/Telekommunikation ist es genauso.
    Auch Microsoft hatte kürzlich Probleme mit der Zustellbarkeit von E-Mails, und bei den meisten unserer O365-Tenants erschien eine Benachrichtigung, SPF, DKIM und DMARC zu prüfen. Bei uns war alles bereits korrekt eingerichtet, aber einige Tenants hatten Probleme beim Versand an kleinere Mailanbieter (auf ISP-Ebene). Der Grund war, dass von derselben IP-Adresse oder demselben Mailserver Spam ausging und kleinere Anbieter deshalb ganze IPs und IP-Bereiche blockierten.

  • Kurios: sns.amazonaws.com hat immer noch keinen DMARC-Record. Wenn man keine Custom Domain verwendet, kommen AWS-SNS-Nachrichten von dort, und auch alle CloudWatch-Benachrichtigungen kommen von no-reply@sns.amazonaws.com.

  • E-Mail sollte eigentlich so funktionieren, aber in der Realität gibt es Allowlists.

    • Und es gibt auch Blocklists. Es gibt räuberische Blocklists, und es gibt Blocklists, die praktisch organisierter Erpressung gleichkommen.
    • Ich weiß nicht, wofür diese Allowlist gedacht sein soll. Es ist nicht üblich, Domains, die an meine Domain senden dürfen, im Voraus auf eine Allowlist zu setzen. Das würde den Zweck von E-Mail zunichtemachen.

  • Auch beim DNS-Failover darf man nicht vergessen, solche Prüfungen korrekt einzurichten.
    Ich habe ein Unternehmen gesehen, das durch die Standardeinstellungen von Exchange Online betrogen wurde.
    Als der Angreifer DNS kurzzeitig „nicht verfügbar“ machte, kamen alle Phishing-E-Mails durch. Der Grund war, dass die MS-Server mit einem DNS-temp error antworteten und alle E-Mails als nicht Spam durchließen.
    Genauer war es received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout), und DKIM wurde gegen die Domain des SMTP-Servers des Absenders geprüft, was in diesem Fall der für das Phishing verwendete Angreiferserver war.
    Danach verbrachte ich eine großartige Zeit mit dem IT-/Security-Support von MS; die Leute dort verstanden nicht einmal, wie E-Mail funktioniert. Eine sehr lustige und zugleich traurige Erfahrung, und ich hoffe, dass das Outsourcing für sie gut funktioniert.