#DKIM, #SPF, #DMARC – Um den guten Namen meines Unternehmens zu schützen

Menu:Home/#DKIM, #SPF, #DMARC – Um den guten Namen meines Unternehmens zu schützen

#DKIM, #SPF, #DMARC – Um den guten Namen meines Unternehmens zu schützen

Vor nicht allzulanger Zeit musste ich jemanden helfen, dessen Mailadresse missbraucht wurde. Mit seiner Absenderadresse wurden aus einem Botnetz heraus fleißig Mails mit Microsoft Office Dokumenten verweisend auf fragwürdige Inhalte versendet. Das bei Öffnen des Office-Dokuments freundlicherweise ohne Zutun des Nutzers installierte Programm erhöhte durch Verschlüsselung sämtlicher Daten den „Datenschutz“ selbiger so gut, dass diese auch vor dem Nutzer selbst geschützt wurden.

Dummerweise wurde nicht nur seine Absenderadresse, sondern auch der gesamte „Footer“ (Mit freundlichen Grüßen, Absender, HR-Eintrag, usw.) in der Malware-Mail mißbräuchlich verwendet. Ich hatte damals das Gefühl, die gesamte Menschheit war zu blöd zu begreifen, dass mein Bekannter diese Email gar nicht versendet hatte. Auch die Staatsanwaltschaft war nicht in der Lage, den Header einer Email auszuwerten, bzw. wusste noch nicht einmal, was das ist. Ich (John) kollidiere dann gewöhnlich mit „normalen“ Anwendern, die meinen, Technologie nutzen zu dürfen – unwissend, wie sie tatsächlich funktioniert. Lassen wir das mit meiner Inkompatibilität zu „Menschen“, das ist Philosophie…

Es war also meine Aufgabe, zunächst zu erklären, dass eine Email tatsächlich nichts anderes als eine Postkarte ist, auf die jeder draufschreiben kann, was er will. Also kann ich heute Bill Gates und morgen Angela Merkel sein. Besagte „Menschen ohne technischen Sachverstand“ scheint dieser Umstand bislang offenbar nicht klar zu sein. Zu dieser Zeit liefen infolge dieses „Missverständnisses“ bei dem entsprechenden Unternehmen die Telefonleitungen heiß, Drohungen kamen an, ja selbst der Eingangsbereich desselben wurde in fehlgeleiteter Selbstjustiz verschönert und in sozialen Medien wurde ein Boykottaufruf für deren Produkte gestartet. Der Betrieb konnte für eine gewisse Zeit nur eingeschränkt fortgeführt werden.


Warum ist das passiert? Nunja, „Menschen“ klicken halt auf alles, was blinkt und glitzert. Muss an ihren Urinstinkten aus der Zeit der Jäger und Sammler stammen. Sie machen das ohne Rücksicht auf Verluste. Der Schaden, den ein Unternehmen durch Missbrauch der eigenen Domain für Malware-Emails erleidet, ist fast irreparabel – wie ich damals lernen musste.

Wie kann ich das verhindern und wie konnte ich den Ausbruch der gefälschten Malware-Email des Unternehmens eindämmen?

Es gibt hier mehrere Techniken. Bleiben wir erst mal beim Beispiel der deutschen Politik. Der Bundestag zum Beispiel ist erreichbar unter

Die Domain bundestag.de hat also Postämter (MX=Mailserver), die öffentlich erreichbar sind, wenn ich DNS befrage (eine Art öffentliches Telefonbuch für Dienste im Internet). Zu bundestag.de gehören also die nachfolgenden Postämter:

In Wahrheit sind es nur zwei, denn das Telefonbuch DNS wirft mir nur zwei Telefonnummern (IP-Addressen zurück). Wenn wir jetzt davon ausgehen, dass die dort aufgelisteten Mailserver auch diejenigen für den Versand sind (was für den klassischen Mittelstand in der Regel zutrifft), so müsste rein theoretisch eine Email vom Bundestag von den folgenden, beiden Telefonnummern (IP-Adressen) kommen:

Was sie aber nicht tut, denn die Bundesregierung verwendet für den ausgehenden Versand der Nachricht andere Mailserver, als diese beiden, dort aufgeführten Mailserver für den eingehenden Empfang. Wie kann ich also jetzt herausfinden, ob ein Server tatsächlich für die entsprechende Domain Emails versenden darf?

Nun, der Bundestag schützt sich leider nicht gegen Missbrauch der eigenen Domain „bundestag.de“, er verwendet nämlich nachfolgendes nicht:

Sender Policy Framework (SPF).

Im DNS (Telefonbuch) – Server der jeweiligen Domain (im Regelfall – beim Mittelstand – der „Webhoster“) für das entsprechende Unternehmen wird ein simpler „TXT“-Eintrag gesetzt, in jenem geschrieben steht, welche IP-Adresse jetzt für die entsprechende Domäne Emails versenden darf und was zu tun ist, wenn dem nicht so ist.

Da mir ja bekanntlich die Domäne „johnlose.de“ gehört, können wir hier also mal nachschlagen:

Hier steht geschrieben, dass für den Domänennamen „johnlose.de“ die entsprechenden „MX“ (= in der Domäne hinterlegten Postämter), dazu die IP Adresse 85.13.137.36 (der Webserver, auf dem Ihr gerade surft) und zusätzlich alle Mailserver, die das Unternehmen „mailbox.org“ (mein Dienstleister für Mails) in seinem eigenen SPF-Eintrag hinterlegt hat, Emails im Namen von „@johnlose.de“ versenden dürfen. Wird jetzt eine Email in meinem Namen versendet, die auf jenen Eintrag nicht zutrifft, habe ich mit „-all“ in dem SPF-Eintrag auch aufgeschrieben, dass die EMail vom gegnerischen Mailserver sofort abgelehnt werden soll. Tut er das nicht, ist er falsch konfiguriert.

Mit diesem SPF-Eintrag wurde im übrigen die Anrufanzahl bei dem zuvor besprochenen Unternehmen binnen 2 Tagen nach Setzen des Eintrags im öffentlichen DNS auf ein erträgliches Minimum reduziert, eine äußerst wirksame Methode.

Hinweise zum Thema SPF:

  • Wenn Du mehr über SPF-Einträge wissen möchtest, schau Dich doch einmal hier um: Link.
  • Für das Testen der DNS-Einträge einer Domain verwende ich übrigens MXToolbox.com

DKIM – Eine „digitale Signatur“ für Mailserver

Wenn man es auf die Spitze treibt, dann lassen sich Adressen auch fälschen, ebenso kann auf dem gesamten Weg von A nach B eine Nachricht auf links gedreht werden. Wie kann ich also sicherstellen, das die Email jetzt tatsächlich vom gegnerischen Mailserver stammt? Nun ich kann Elemente des Mail-headers (=Briefkopf) „digital unterschreiben“ lassen. Mit einem „asymmetrischen Verschlüsselungsverfahren“, also einem öffentlichen und einem privaten Schlüssel, kann ich sicherstellen, dass nur exakt mein eigener Mailserver den privaten Schlüssel besitzt. Den öffentlichen Schlüssel hinterlege ich ebenfalls im DNS.

So kann ich ausschließen, dass irgendjemand anders auf diesem Planeten Nachrichten unterschreibt, die zu meinem eigenen öffentlichen Schlüssel passen. Denn nur Nachrichten, welche mit meinem privaten Schlüssel unterschrieben worden sind, passen auch zu dem öffentlichen Schlüssel, welchen ich für jedermann lesbar hinterlegt habe. Ein weiterer, positiver Vorteil ist: Meine Nachricht bleibt seltener in anderen Spamfiltern stecken, da diese meine Nachricht von meinem Server mit passender Signatur automatisch höher gewichten. Ich bin also auf der linken Spur der Datenautobahn im Mailserver des Empfängers unterwegs und bleibe seltener im Stau (Spam-Postfach) des Empfängers stecken…

Wenn ich jetzt mehrere Mailserver betreibe – wie z.B. der Mailserver des Bundestags, benötigt jeder Mailserver einen eigenen Schlüssel, den ich wiederrum öffentlich hinterlegen und in sogenannten Selektoren unterscheiden muss. Der Mailserver 1, jenen ich zum Beispiel für das fiktive Unternehmen „domain.tld“ verwende, trägt den Selektor „mail1„. Der öffentlich hinterlegte Schlüssel für den Selektor „mail1“ sieht dann wie folgt aus:

Und so kommt es, dass die mail, die ich versendet habe, tatsächlich vom gegnerischen Mailserver als „echt“ eingestuft wird:

Es gibt hunderte von Plugins für DKIM für Mailserver. Einige davon sind zum Beispiel schon in Security Gateways eingebaut. Andere zum Beispiel kann man in Exchange Server einbauen.

Beispiele für DKIM-Plugins für Microsoft Exchange:

Ein wunderbares Tool, um die Funktionsfähigkeit von DKIM zu testen gibt’s bei Appmaildev.com: Link

Und woher weiß ich, ob meine Bemühungen mit SPF und DKIM funktionieren? Das ganze geht mehr oder weniger mit

DMARC

Das Ding schimft sich „Domain-Based Message Auhtentication, Reporting and Conformance“. Im DNS der entsprechenden Domain steht also für die Hauptdomain und auch für die Unterdomains geschrieben, was Mailserver denn nun tun sollen und wo sie Bescheid sagen dürfen, wenn sich irgendwer daneben benimmt. Im großen und ganzen ist dort noch einmal ein Verweis auf DKIM und SPF zu finden, jedoch zusätzlich auch eine entsprechende Adresse, bei denen gegnerische Mailserver petzen dürfen. Je nach Konfiguration habt Ihr dann täglich oder wöchentlich von den jeweiligen Diensten eine Mail, in der drinsteht, wer wann wie viele Spam-Emails in Deinem Namen versendet hat.

Der Kollege bei MSXFAQ hat eine ganz ordentliche Erklärung dafür, wie das mit DMARC so alles funktioniert. So muss ich das nicht alles noch einmal schreiben und verweise einfach auf MSXFAQ.de: Link

Weiter unten bei MSXFAQ findest Du auch ein paar Empfehlungen für Dienstleister, welche die für manche kryptischen – „Petz-Nachrichten“ in hübsche Tortengrafiken, Diagramme, verständliche Listen und vor allem verständliche Texte aufhübschen.

Fazit:

Man kann sich also doch sehr gut dagegen wehren, dass der eigene Name gegen Spamversand geschützt wird. Filterprodukte für Mailserver sind heute so intelligent, dass sie die entsprechenden Abfragen (sofern korrekt konfiguriert) machen und sich an die Gepflogenheiten halten. Auch die meisten großen Freemailanbieter setzen das inzwischen um.

Die Antwort auf die Frage lautet also nicht „Da kann man nichts machen“ sondern endet eher in einer weiteren Frage: „Warum hast Du das nicht schon längst so umgesetzt?“. Es ist also auch völlig egal, welches Mailserverprodukt Du einsetzt, oder ob Du – zum Leidwesen aller – bereits mit Deinen Emails in die Wolke gegangen bist: Die Domäne gehört immer noch Dir und da kannst Du reinschreiben, was Du möchtest. In diesem Fall wäre es etwas sinnvolles, was Deinen Arbeitgeber und schlussendlich auch Dich selbst schützt. Es zu unterlassen, könnte heute schon als grobe Fahrlässigkeit (i.S.v „hat seinen Job nicht gemacht“) gewertet werden. Peinlich wird’s, wenn die Mitarbeiter eines entsprechenden Unternehmens z.B. bei Appmaildev selbst rausfinden wollen, ob die eigenen Administratoren oder Dienstleister ihren Job vernünftig gemacht haben.

Mindestens aber SPF sollte schon gesetzt sein. Lies‘ dich in das Thema ein, es gibt hunderte gute Webseiten, die Dir das in aller Ausführlichkeit beschreiben.

###
John

By | 2017-03-11T20:40:45+00:00 09.03.2017|Sicherheit, Techbla|Kommentare deaktiviert für #DKIM, #SPF, #DMARC – Um den guten Namen meines Unternehmens zu schützen

About the Author:

John Lose
John Lose ist Informationstechnologe und Datenreisender. Manche mögen ihn als "Aluhut-Träger" bezeichnen, denn er mag nur kleine Rechenzentren, die er selbst kennt. Public Clouds kommen für Ihn höchstens für Webseiten in Frage. John ist Katzenliebhaber, hat aber keine Katze, fährt gerne nach Südfrankreich und hört Tech-House. Mehr über John Lose erfährst Du in seiner Vita.  Wenn Dir dieser Beitrag gefallen hat, so kannst Du auch Danke sagen, wenn Du möchtest:  >> Dankeschön <<.