Mail-Spoofing verhindern mit SPF, DKIM und DMARC
Mail-Spoofing verhindern mit SPF, DKIM und DMARC
Immer wieder gibt es Betrugsversuche mit Phishing-Mails, bei denen vorgetäuscht wird, dass eine Mail aus einem Unternehmen kommt, was gar nicht der Fall ist. Das Problem ist, dass in Mails der Absender frei vergeben werden kann. Damit sind für Betrugsmaschen grundsätzlich Tür und Tor geöffnet.
Um dem Problem Herr zu werden, gibt es verschiedene Möglichkeiten. Hier möchten wir exemplarisch ein paar erläutern:
SPF – Sender Policy Framework
Bei diesem Verfahren wird vom Domain-Inhaber ein Eintrag für die entsprechende Domain hinterlegt, von welchem Server aus E-Mails im Namen der Domain gesendet werden dürfen. Wird eine Mail empfangen, so überprüft der Empfangsserver die Einträge der Domain – darf der Server, von dem die Mail kommt, überhaupt in diesem Namen eine Mail versenden?
Ein beispielhafter SPF-Eintrag kann nun so aussehen (dieser wird als TXT-Eintrag für die Domain hinterlegt):
„v=spf1 a mx ip4:123.45.67.89 -all”
Dieser bedeutet konkret Folgendes:
Es dürfen Mails von Server, die im A-Eintrag oder MX-Eintrag hinterlegt sind, gesendet werden, und zusätzlich von der IP 123.45.67.89. Mit -all wird darauf hingewiesen, dass von keinem anderen Server die Mail akzeptiert werden soll. Wird statt -all ~all verwendet, so sollen Mails von anderen Servern nur gekennzeichnet werden (Spam)
DKIM – DomainKeys Identified Mail
Wie auch bei SPF, ist bei DKIM das Ziel, Spam und Phishing zu verhindern. Grundlage für dieses Verfahren ist eine asymmetrische Verschlüsselung bzw. Signatur. Das Besondere an asymmetrischer Verschlüsselung ist, dass es einen Schlüssel für die Verschlüsselung und einen separaten Schlüssel für die Entschlüsselung gibt. Ist man in Besitz eines der Schlüssel, kann man nicht auf den anderen Schlüssel schließen.
Für DKIM wird nun der öffentliche Schlüssel als DNS-Eintrag hinterlegt. Versendet ein Mailserver nun eine Mail, so wird die zu versendende Nachricht mit dem privaten Schlüssel signiert. Ein Empfangsserver kann anschließend über den öffentlichen Schlüssel (aus dem DNS-Eintrag) überprüfen, ob der Inhalt modifiziert wurde – bzw. überhaupt zur entsprechenden Domain passt.
DMARC – Domain-based Message Authentication, Reporting and Conformance
Diese Spezifikation baut auf SPF und DKIM auf. Hier kann definiert werden, wie Mails zu prüfen sind und im Fehlerfall weiter vorgegangen werden soll. Wie auch schon bei SPF und DKIM werden hier die gewünschten Einstellungen über einen DNS-Eintrag definiert.
Ein beispielhafter DMARC Eintrag ist folgender:
„v=DMARC1;p=quarantine;pct=100;ruf=mailto:postmaster@example.com;rua=mailto:postmaster2@example.com;sp=reject“
p=quarantine bedeutet, dass Policy-Verstöße der Haupt-Domain in Quarantäne (Spam) gestellt werden sollen. sp=reject weist an, Policy-Verstöße von Sub-Domains zurückzuweisen. pct=100 bedeutet, dass für alle Mails die DMARC-Einstellungen angewandt werden sollen. Sinn dieser Option ist es, neue Einstellungen nur für einen Teil der Mails anzuwenden, um bei Fehlkonfiguration nicht den gesamten Mailverkehr der Domain zum Stillstand zu bringen. Üblicherweise wird die pct-Einstellung schrittweise über mehrere Tage bzw. Wochen von 0 auf 100 erhöht. Über ruf bzw. rua, kann hinterlegt werden, an welche E-Mail Fehler-Reports gesendet werden sollen. An rua werden Aggregate Reports – also Zusammenfassungen – zugestellt. In ruf-Reports werden detailliertere Informationen gesendet.
Abschließend sei anzumerken, dass sämtliche Einstellungen niemals in Produktivsystemen „blind“ ausprobiert werden sollten, da eine Fehlkonfiguration den Mailverkehr der gesamten Domain stilllegen kann.
Keine Neuigkeiten mehr verpassen? Melden Sie sich hier für unseren Newsletter an!
