Phising und Spam durch SPF, DKIM und DMARC verhindern

Was würden Sie sagen, wenn ich Ihnen erzähle, dass Kriminelle Ihre Unternehmensdomain verwenden könnten, um Phishing-Emails in Ihrem Namen zu versenden?

In den Anfängen der „modernen E-Mail“ gab es nur begrenzte Mechanismen zur Unterstützung der Absenderüberprüfung. Fast alle Spams, Betrügereien und Viren, die sich per E-Mail verbreiteten, taten dies mit gefälschten Absenderangaben – und tun dies auch heute noch. Die Überprüfung der tatsächlichen Absender von E-Mails war und ist immer noch ein schwieriger Prozess.

Nur drei Akronyme?

SPF, DKIM und DMARC sind drei sich ergänzende Systeme. SPF und DKIM werden von E-Mail-Servern als Indikatoren dafür verwendet, ob es sich bei einer E-Mail um Spam handelt oder nicht. DMARC erfüllt zwei Aufgaben: Es teilt E-Mail-Servern mit, wie wichtig SPF und DKIM sind und was zu tun ist, wenn eine E-Mail die Tests nicht besteht.

Vor einiger Zeit bin ich auf ein Problem gestossen: Eine Domain meines früheren Arbeitgebers war für SPF, DKIM und DMARC nicht richtig konfiguriert.

Dies führte mich direkt zu einem weiteren Problem: Ich hatte zwar schon davon gehört, aber im Detail sagten mir diese Abkürzungen auch nichts. Es gab scheinbar noch keine Artikel im Internet, die SPF, DKIM und DMARC in einer Weise erklärten, die ein „normaler“ Mensch versteht, geschweige denn umsetzen kann. Jeder Artikel, den ich fand, war entweder zu technisch oder wollte mir etwas verkaufen.

Ich möchte Ihnen in diesem Blogbeitrag die Akronyme SPF, DKIM und DMARC auf eine verständliche Art näher bringen und Ihnen einen Anreiz geben, wie Sie Ihre E-Mails in Zukunft vor Spam- und Phishing-Attacken besser schützen können. In einem zweiten Blogbeitrag werden wir genauer auf die Implementierung eingehen.

SPF (Sender Policy Framework)

(SPF) ist ein Sender-Authentifizierungs-Verfahren. Kurz gesagt dient es dazu, zu überprüfen, ob ein E-Mail Server die Berechtigung besitzt, E-Mails mit einer ganz bestimmten Domainendung zu versenden.

So würde ein Beispiel für eine gültige E-Mail aussehen:

  1. Ich sende Ihnen eine Mail von info@gosecurity.ch und verwende unseren Postfix SMTP Server. Dieser hat beispielsweise die IP: 100.100.100.1.
  2. Ihr Online Exchange empfängt die E-Mail.
  3. Unter dem Aspekt, dass die E-Mail von gosecurity.ch kommt, überprüft Exchange nun die DNS Einträge dieser Domäne.
  4. gosecurity.ch besitzt dort einen Eintrag, welcher die SPF-Richtlinie definiert.

    gosecurity.ch. 5 IN TXT „v=spf1 mx ip4:100.100.100.1/23 include:spf.protection.outlook.com include:mail.myCRM.ch -all“

  5. Der Eintrag bedeutet, dass E-Mails unter anderem von den IP-Adressen in der Range 100.100.100.1/23 verschickt werden dürfen.
  6. Da unser Postfix Server eine dieser IP-Adressen verwendet, besteht die E-Mail den SPF Test.
  7. Die E-Mail landet in Ihrem Posteingang.

Die Domain gosecurity.ch berechtigt mit dem SPF Eintrag also den Mailserver, welcher im MX-Record steht, alle IP-Adressen in der Range 91.228.60.0/23 und inkludiert die Mailserver von Outlook und dem CRM. Mit ‚-all‘ (am Ende) werden alle anderen Hosts als unberechtigt ausgegeben. Die Alternative zu ‚all‘ wäre die Softfailvariante ‚~all‘. Dies ist eine weniger strenge Richtlinie und wird ausdrücklich nicht empfohlen.

Klingt doch gut bis jetzt, oder? Leider genügt SPF alleine nicht. Ohne die Systeme DKIM und DMARC besitzt es eine eher informative Wirkung. Empfangene Mailserver können der Empfehlung im SPF Eintrag folgen, tun dies aber nicht immer. Mit DKIM und DMARC können Sie diesem Nachdruck verleihen.

DKIM (DomainKeys Identified Mail)

DKIM kann man sich als eine Art kryptografischer Cousin von SPF vorstellen. Genau wie SPF, dient es einem Mailserver dazu zu überprüfen, ob er eine ankommende E-Mail als vertrauenswürdig oder als Spam bzw. Phishing einstufen sollte.

Es gibt zwei Hauptaspekte von DKIM: den DKIM-Eintrag, der in den DNS-Einträgen für die Domäne gespeichert wird, und den DKIM-Header, der an alle E-Mails von der Domäne angehängt wird.

Die DKIM-Signatur im E-Mail Header wird mithilfe eines privaten Schlüssels und dem Inhalt der E-Mail generiert. Der empfangene E-Mail-Server kann dann mithilfe des öffentlichen Schlüssels überprüfen, ob die Signatur im E-Mail Header mit dem Inhalt übereinstimmt. Den privaten Schlüssel hat nur der sendende SMTP-Server. Der öffentliche Schlüssel wird in einen TXT-Record der Domain geschrieben.

Wichtig zu wissen: Eine Domain kann mehrere DKIM-Schlüssel besitzen.

So könnte ein DKIM DNS-Eintrag aussehen:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjSjdDnKZMUntqJZ3ijYeZ1fR
QjkPTz9nz7WWDqO7r3lZagwKkHzUEfDatP1Bd5weNKh1MR8DNPbcwsckh7X6k5SiQ
/WzHn5BzLWpllDJp1QPqHrG/cflyzDnLTSOakfkQ6TLhOZdoZGZQxGqwAQNQAPji4
pdL9eepblrZgIxohQIDAQAB;


Hier ein praktisches Beispiel:

  1. Ich sende Ihnen eine E-Mail von info@gosecurity.ch an info@example.com.
  2. Die E-Mail wird über meinen Postfix SMTP Server verschickt.
  3. Der Postfix SMTP Server generiert mithilfe des privaten Schlüssels und des E-Mail-Inhalts eine digitale Signatur und hängt diese an den E-Mail-Header an.
  4. Ihr SMTP Server von example.com erhält die E-Mail von gosecurity.ch und überprüft daraufhin die DNS Einträge dieser Domain.
  5. Die E-Mail enthält eine eingebettete Signatur, und in den DNS-Einträgen für gosecurity.ch sind einige öffentliche DKIM-Schlüssel angegeben, die zur Überprüfung der Signatur verwendet werden können.
  6. Einer dieser DKIM-Schlüssel stimmt mit dem überein, der zur Erstellung dieser Signatur verwendet wurde – und zwar mit dem von Postfix bereitgestellten. Der DKIM-Test ist also erfolgreich.
  7. Die E-Mail landet im Posteingang von info@example.com.

Eine E-Mail, die nun an einem E-Mail-Server ankommt und den SPF und DKIM Test nicht besteht, wird also als Spam markiert. Vielleicht. Wie ich weiter oben schon erläutert habe, reicht SPF alleine nicht aus. Auch SPF und DKIM zusammen reichen noch nicht aus. Es liegt immer im Ermessen des empfangenen E-Mail-Servers, ob er die E-Mail als Spam bzw. Phishing klassifiziert. Daher benötigen wir den Dritten im Bunde. DMARC.

DMARC (Domain-based Message Authentication)

Im Kern handelt es sich bei DMARC um zwei Dinge, die in einem DNS-Eintrag zusammengefasst sind:

  1. DMARC gibt einem empfangenen E-Mail-Server klare Handlungsempfehlungen, wenn eine E-Mail die SPF- und DKIM-Tests nicht besteht.
  2. DMARC ist ein Meldesystem, mit dem Sie herausfinden können, wer versucht, Ihre Domäne zu fälschen.

Schauen wir uns einen DMARC Eintrag an:

v=DMARC1; p=none; rua=mailto:admin@myDomain.ch; ruf=mailto:admin@gosecurity.ch; fo=1; adkim=s; aspf=s

Die Implementierung von DMARC ist ein Prozess. Der «Reporting»-Teil von DMARC hilft Ihnen herauszufinden, welche Dienste Sie falsch konfiguriert haben und aktualisieren müssen.

Vergessen Sie z.B. einen SPF-Eintrag für einen E-Mail-Server, welcher geschäftskritische Benachrichtigungen an Kunden verschickt, werden diese E-Mails vielleicht nicht mehr ankommen. Selbes Spiel, wenn Sie einen DKIM-Schlüssel zu Ihrer Domain hinzugefügt haben, aber einer Ihrer E-Mail Dienste DKIM nicht unterstützt oder Sie versäumen es schlicht diesem Dienst einen Schlüssel hinzuzufügen. In beiden Fällen ist die Zustellung Ihrer E-Mails gefährdet.

Sie können den Berichtsteil aktivieren, ohne eine strenge SPF/DKIM-Richtlinie durchzusetzen. Mit anderen Worten: Sie können DMARC nutzen, um herauszufinden, welche E-Mails von Ihrer Domäne gesendet wurden und die SPF/DKIM-Tests nicht bestanden haben, ohne dem E-Mail-Server mitzuteilen, dass alle E-Mails, die diese Tests nicht bestanden haben, als Spam markiert werden sollten.

Das E-Mail-Protokoll (SMTP) ist fast 40 Jahre alt. Damals war der Schutz vor Absenderfälschung noch kein Thema. Obwohl wir heute noch dasselbe Protokoll einsetzen, kann die Absenderfälschung heute, wie aufgezeigt,  ziemlich gut eingeschränkt werden. Allerdings ist es wichtig zu verstehen, dass immer der Eigentümer einer Domäne aktiv werden muss. In meinem nächsten Blogbeitrag werde ich Ihnen zeigen, wie Sie alle drei Systeme implementieren und worauf dabei zu achten ist.

Informationen zum Autor: Jan Freymuth

Während meines Studiums und meiner Tätigkeit als IT Consultant für einen weltweit operativen Anbieter für Werkzeugmaschinen war für mich klar, dass meine berufliche Zukunft im Bereich der IT-Sicherheit sein wird. Im Frühjahr 2022 ist es mir gelungen, die goSecurity AG von meinen Fähigkeiten zu überzeugen. Seither erweitere ich mein Wissen im Bereich der IT-Sicherheit täglich und es bereitet mir Freude, dieses aktiv für die Steigerung des IT-Sicherheitsniveaus unserer Kunden einzusetzen.