|
DMARC |
Scrollen Zurück Oberste Ebene Weiter Mehr |
"DMARC" steht für Domain-based Message Authentication, Reporting, and Conformance (domänengestützte Echtheitsbestätigung, Berichte und Übereinstimmung). Die Spezifikation für DMARC beschreibt ein anpassungsfähiges Verfahren, mit dessen Hilfe der Missbrauch von Nachrichten, beispielsweise durch eingehenden Spam und Phishing-Nachrichten, deren Absenderkopfzeile From: gefälschte Inhalte enthält, verringert werden kann. DMARC ermöglicht es den Domäneninhabern, das Domain Name System (DNS) zu nutzen, um Servern, die Nachrichten empfangen, die eigenen DMARC-Richtlinien bekannt zu machen. Diese Richtlinien geben empfangenden Servern Auskunft darüber, wie sie Nachrichten behandeln sollen, die angeblich von der Domäne stammen, für die die Richtlinien veröffentlicht sind, bei denen aber nicht festgestellt werden kann, dass sie tatsächlich von dieser Domäne stammen. Die empfangenden Server fragen die Richtlinien über eine DNS-Abfrage ab, während sie die eingehenden Nachrichten verarbeiten. Die Richtlinien können bestimmen, dass die Server Nachrichten in Quarantäne geben oder abweisen, falls sie nicht den Richtlinien entsprechen. Sie können aber auch bestimmen, dass keine besonderen Maßnahmen getroffen werden und die Nachrichten normal verarbeitet werden. Neben diesen Regelungen über die Behandlung von Nachrichten können die DNS-Einträge für DMARC auch Anforderungen enthalten, dass der empfangende Server an bestimmte Empfänger DMARC-Berichte senden soll. Diese Berichte enthalten Informationen über die Anzahl eingehender Nachrichten, die angeblich von der Domäne stammen, sowie Informationen über erfolgreiche und fehlgeschlagene Bestätigung der Echtheit der Nachrichten und Einzelheiten über Fehler in der Prüfung. Die Berichtsfunktionen von DMARC können hilfreich sein, um festzustellen, wie wirksam die eigenen Maßnahmen zur Sicherung der Echtheit von Nachrichten sind und wie oft der eigene Domänenname in gefälschten Nachrichten verwendet wird.
Der Konfigurationsdialog Sicherheit » Anti-Spoofing enthält drei Abschnitte, in denen die DMARC-Prüfung und die DMARC-Berichte für SecurityGateway konfiguriert werden können: DMARC-Prüfung, DMARC-Berichte und DMARC-Einstellungen.
DMARC-Prüfung
Während der DMARC-Prüfung fragt SecurityGateway die DMARC-Richtlinien durch eine DNS-Abfrage ab; diese Abfrage bezieht sich auf die Domäne in der Absenderkopfzeile From: (Von:) jeder eingehenden Nachricht. Die Abfrage prüft zunächst, ob die Domäne DMARC nutzt und ruft bejahendenfalls den DMS-Eintrag für DMARC ab. Diese DNS-Eintrag enthält die DMARC-Richtlinie und verwandte Informationen. DMARC nutzt außerdem das SPF und DKIM, um jede eingehende Nachricht zu prüfen, und die Prüfung durch SPF oder DKIM muss erfolgreich verlaufen, damit auch die DMARC-Prüfung erfolgreich sein kann. Besteht eine Nachricht diese Prüfungen, so wird sie durch den üblichen Filter- und Zustellvorgang in SecurityGateway normal weiterbearbeitet. Besteht eine Nachricht die Prüfung nicht, dann richtet sich ihre weitere Behandlung nach den DMARC-Richtlinien der angeblichen Absenderdomäne und danach, wie SecurityGateway für die Behandlung solcher Nachrichten konfiguriert ist.
Besteht eine Nachricht die DMARC-Prüfung nicht, und ist für die angebliche Absenderdomäne die DMARC-Richtlinie "p=none" veröffentlicht, so ergreift SecurityGateway keine Abwehrmaßnahmen, und die Nachricht wird normal weiterverarbeitet. Ist für die angebliche Absenderdomäne jedoch eine restriktive DMARC-Richtlinie veröffentlicht, also "p=quarantine" oder "p=reject", dann kann SecurityGateway die Nachricht automatisch in den Quarantäne-Ordner des Empfängers leiten, die Betreffzeile kennzeichnen oder die Nachrichten-Bewertung anpassen. In Nachrichten, für deren angebliche Absenderdomänen restriktive Richtlinien veröffentlicht sind, fügt SecurityGateway je nach veröffentlichter Richtlinie die Kopfzeilen "X-SGDMARC-Fail-policy: quarantine" oder "X-SGDMARC-Fail-policy: reject" ein. Hiermit können Sie durch ein Sieve-Skript oder durch den Inhaltsfilter weitere Maßnahmen auslösen, die diese Kopfzeilen auswerten und Nachrichten beispielsweise in einen besonderen Ordner zur genaueren Untersuchung leiten.
Die DMARC-Prüfung ist per Voreinstellung aktiv und wird für die meisten Einsatzgebiete von SecurityGateway empfohlen.
DMARC-Berichte
Die DMARC-Einträge, die SecurityGateway aus dem DNS abfragt, können Tags enthalten, durch die der Domäneninhaber anzeigt, dass er bestimmte zusammengefasste Statistik- und Fehlerberichte über die DMARC-gestützte Behandlung solcher Nachrichten erhalten will, die angeblich aus seiner Domäne stammen. Die Optionen im Konfigurationsdialog DMARC-Berichte bestimmen, ob Ihr System die angeforderten Arten von Berichten versenden soll, und welche Metadaten die Berichte enthalten sollen. Zusammengefasste Berichte werden jeden Tag um Mitternacht (UTC-Zeit) gesendet. Fehlerberichte werden für jede Nachricht dann gesendet, wenn eine fehlgeschlagene Prüfung den Fehlerbericht auslöst. Alle Berichte werden als XML-Dateien in ZIP-Archiven versandt, die als Dateianlage an die Berichtsnachrichten angehängt werden. Es stehen verschiedene Auswertungsprogramme zur Verfügung, mit deren Hilfe die Empfänger die Berichte einsehen und auswerten können. Per Voreinstellung versendet SecurityGateway nur zusammengefasste Berichte.
DMARC-Einstellungen
Der Konfigurationsdialog DMARC-Einstellungen enthält Optionen zur Aufnahme bestimmter Daten in DMARC-Berichte, zur Protokollierung von DNS-Einträgen für DMARC und zur Aktualisierung der Liste öffentlicher Domänenendungen, die SecurityGateway für DMARC nutzt.
Wechselwirkung zwischen DMARC-Prüfung und Mailinglisten
DMARC soll sicherstellen, dass die Domäne in der Absenderkopfzeile From: eingehender Nachrichten nicht gefälscht ist sondern dem wirklichen Absender entspricht. DMARC muss daher überprüfen, ob der Server, der die Nachricht übermittelt, zum Versand von Nachrichten für die Absenderdomäne auch wirklich berechtigt ist. Bei Mailinglisten kann dies zu einem besonderen Problem führen. Es ist nämlich bei Mailinglisten üblich, dass diese die Listennachrichten für alle, auch fremde, Listenmitglieder versenden, dass dabei die Absenderkopfzeile From: unverändert bleibt und noch die ursprüngliche Domäne des Absenders enthält. Empfängt ein Server eine solche Listennachricht, und führt er eine DMARC-Prüfung für die Nachricht aus, dann stellt er hierbei fest, dass ein Server die Nachricht versandt hat, der eigentlich gar nicht berechtigt ist, für die Domäne in der Absenderkopfzeile From: Nachrichten zu versenden. Ist für die Domäne in der Absenderkopfzeile From: eine restriktive DMARC-Richtlinie veröffentlicht, so kann dies dazu führen, dass der Server des Empfängers die Listennachricht in Quarantäne gibt oder sogar abweist. Außerdem kann in bestimmten Fällen der Empfänger der Listennachricht automatisch aus der Mailingliste entfernt werden. Um dieses Problem zu umgehen, ersetzt SecurityGateway den Inhalt der Absenderkopfzeile From: in Listennachrichten dann durch die E-Mail-Adresse der Mailingliste, wenn für die Domäne des Absenders eine restriktive DMARC-Richtlinie veröffentlicht ist. Sie können SecurityGateway aber auch so konfigurieren, dass Listennachrichten aus Domänen mit restriktiven DMARC-Richtlinien abgewiesen werden. Falls Sie MDaemon ab Version 14.5 als E-Mail-Server verwenden, werden per Voreinstellung die Absenderkopfzeilen From: durch die Adresse der Mailingliste ersetzt, falls für die Domäne des Absenders eine restriktive DMARC-Richtlinie veröffentlicht ist.
Die Nutzung von DMARC für Ihre Domänen
Die Nutzung von DMARC für eigene Domänen, die die Server der Nachrichtenempfänger in die Lage versetzt, DMARC zur Prüfung solcher Nachrichten einzusetzen, die angeblich aus den eigenen Domänen stammen, hängt von mehreren Voraussetzungen ab. Sie müssen zunächst sicherstellen, dass Sie für die betroffenen Domänen gültige DNS-Einträge für SPF und DKIM erstellt haben. SPF oder DKIM oder beide Verfahren zugleich müssen funktionsfähig eingerichtet sein, damit DMARC nutzbar ist. Falls Sie DKIM nutzen, müssen Sie auch die Signatur von Nachrichten über DKIM konfigurieren, damit SecurityGateway die Nachrichten der betroffenen Domänen signiert. Sie müssen außerdem für die betroffenen Domänen DNS-Einträge für DMARC anlegen. Diese Einträge sind TXT-Einträge in einem bestimmten, vorgegebenen Format, die die Server der Nachrichtenempfänger abfragen, um Informationen über die DMARC-Richtlinie und verschiedene weitere Parameter zu erhalten. Solche weiteren Parameter sind insbesondere die Art der Echtheitsbestätigung, die Sie nutzen, die Festlegung, ob Sie zusammengefasste Berichte erhalten wollen, und die E-Mail-Adresse, an die die Berichte gesendet werden sollen. Ist DMARC richtig eingerichtet, und erhalten Sie XML-Berichte für DMARC, so stehen Ihnen eine Reihe von Online-Werkzeugen zur Verfügung, mit deren Hilfe Sie die Berichte auswerten und mögliche Probleme erkennen können.
Erstellen eines DMARC-Ressourceneintrags vom Typ TXT
Nachfolgend finden Sie einen Überblick über grundlegende und häufig genutzte Bestandteile eines DMARC-Eintrags. Nähere Informationen und Hinweise zu fortgeschrittenen Konfigurationsmöglichkeiten erhalten Sie auf der Website www.dmarc.org.
Feld "Owner" (Inhaber)
Das Feld "Owner" (es wird auch als "Name" oder "left-hand" bezeichnet) im DMARC-Ressourceneintrag muss immer den Inhalt _dmarchaben. Falls Sie die Domäne oder Subdomäne angeben wollen, auf die sich der Eintrag bezieht, so können Sie das Format _dmarc.domänen.name hierfür nutzen.
Ein Beispiel hierzu:
Ein DMARC-Eintrag für die Domäne example.com
_dmarc IN TXT "v=DMARC1;p=none"
Dieser Eintrag wirkt für E-Mail-Nachrichten von benutzer@example.com und allen Subdomänen von example.com, also beispielsweise benutzer@support.example.com.
_dmarc.support.example.com IN TXT "v=DMARC1;p=none"
Dieser Eintrag wirkt nur für E-Mail-Nachrichten von benutzer@support.example.com, nicht jedoch beispielsweise für benutzer@example.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
Dieser Eintrag wirkt für E-Mail-Nachrichten von benutzer@support.example.com, benutzer@a.support.example.com, benutzer@a.b.support.example.com und so weiter.
Tags und Parameter für die DMARC-Einträge
Zwingend erforderliche Tags
Tag |
Parameter |
Erläuterung |
v= |
DMARC1 |
Dieser Tag bestimmt die Version. Er muss der erste Tag in dem Textfeld des Ressourceneintrags sein. DMARC-Tags sind üblicherweise unabhängig von Groß- und Kleinschreibung; dies gilt aber nicht für diesen Tag. Er muss immer in Großbuchstaben gesetzt sein: DMARC1. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=none" |
p= |
none quarantine reject |
Dieser Tag bestimmt die Richtlinie (p steht für policy). Er muss der zweite Tag in dem Textfeld des Ressourceneintrags sein und auf den Tag v= folgen. p=none (keine) bedeutet, dass der Server des Nachrichtenempfängers auf Grundlage der DMARC-Prüfung keine Aktion vornehmen soll. Nachrichten, die die DMARC-Prüfung nicht bestehen, sollen aufgrund der nicht bestandenen DMARC-Prüfung nicht in Quarantäne gegeben oder abgewiesen werden. Sie können aber aus anderen Gründen in Quarantäne gegeben oder abgewiesen werden, etwa wegen einer Spam-Bewertung oder aufgrund anderer Sicherheitsprüfungen als DMARC. Die Nutzung der Richtlinie p=none wird bisweilen als Überwachungs- oder Beobachtungsmodus bezeichnet, da die Richtlinie mit dem Tag rua= gemeinsam verwendet werden kann, um zusammengefasste Berichte über die Nachrichten zu erhalten, gleichzeitig aber Abwehrmaßnahmen nach dem Fehlschlagen von DMARC-Prüfungen zu verhindern. Solange Sie Ihre DMARC-Implementation noch nicht ausführlich und gründlich getestet haben und sicher sind, dass Sie Abwehrmaßnahmen verlangen sollen (wie etwa durch Nutzung der restriktiveren Richtlinie p=quarantine), sollten Sie diese Richtlinie nutzen. p=quarantine (Quarantäne) bedeutet, dass der Server des Nachrichtenempfängers Nachrichten als verdächtig behandeln soll, falls diese laut Absenderkopfzeile From: aus Ihrer Domäne stammen, aber die DMARC-Prüfung nicht bestehen. Je nach der Konfiguration des Servers des Nachrichtenempfängers können solche Nachrichten zusätzlichen Prüfmaßnahmen unterworfen werden, auch können Sie in die Spam-Ordner der Empfänger einsortiert, an einen anderen Server geleitet oder weiteren Maßnahmen unterworfen werden. p=reject (abweisen) bedeutet, dass der Server des Nachrichtenempfängers alle Nachrichten abweisen soll, die die DMARC-Prüfung nicht bestehen. Manche Server sind unter Umständen so konfiguriert, dass sie solche Nachrichten entgegen der Richtlinie annehmen, sie dann aber in Quarantäne geben oder zusätzlichen Prüfmaßnahmen unterwerfen. Diese Richtlinie ist die restriktivste Richtlinie; Sie sollten sie nur dann einsetzen, wenn sie endgültig sicher sind, dass Ihre E-Mail-Richtlinien und ihre Infrastruktur sowie die E-Mail-Dienste, die Sie nutzen wollen, und die Benutzerkonten richtig eingerichtet sind und funktionieren. Wollen Sie Ihren Benutzern beispielsweise gestatten, Mitglieder in Mailinglisten von Drittanbietern zu werden, Weiterleitungsdienste zu nutzen, Funktionen zum "Teilen" oder Weiterleiten von Website-Inhalten oder vergleichbare Leistungsmerkmale zu nutzen, dann führt die Nutzung der Richtlinie p=reject mit hoher Wahrscheinlichkeit dazu, dass auch legitime Nachrichten abgewiesen werden. Es kann auch dazu führen, dass Benutzer automatisch aus Mailinglisten entfernt oder gar nicht erst in sie aufgenommen werden. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-berichte@example.net" |
Optionale Tags
Die nachfolgend aufgeführten Tags sind wahlfrei. Enthält ein Ressourceneintrag diese Tags nicht, dann werden die jeweiligen Vorgaben angenommen und verwendet
Tag |
Parameter |
Erläuterung |
sp= |
none quarantine reject — Vorgabe: Falls sp= nicht verwendet wird, wirkt der Tag p= auf die Domäne und die Subdomänen. |
Dieser Tag bestimmt die Richtlinien, die für Subdomänen der Domäne wirken sollen, auf die sich der DMARC-Ressourceneintrag bezieht. Wird dieser Tag beispielsweise in einem Eintrag verwendet, der sich auf example.com bezieht, dann wirkt die Richtlinie aus dem Tag p= auf E-Mail-Nachrichten aus der Domäne example.com, und die Richtlinie aus dem Tag sp= wirkt auf E-Mail-Nachrichten aus Subdomänen von example.com, etwa mail.example.com. Wird dieser Tag nicht verwendet, so wirkt der Tag p= auf die Domäne und alle ihre Subdomänen. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Kommagetrennte Liste der E-Mail-Adressen, an die zusammengefasste DMARC-Berichte gesendet werden sollen. Die Adressen müssen als URIs im Format — Vorgabe: keine Falls dieser Tag nicht verwendet wird, werden keine zusammengefassten Berichte gesendet. |
Dieser Tag zeigt an, dass Sie zusammengefasste DMARC-Berichte von den Servern der Nachrichtenempfänger erhalten wollen, bei denen Nachrichten mit Adressen aus Ihrer Domäne in der Absenderkopfzeile From: eingehen. Geben Sie mindestens eine E-Mail-Adresse als URI im Format mailto:benutzer@example.com an, und trennen Sie mehrere URIs durch Kommata. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:benutzer01@example.com,mailto:benutzer02@example.com" Die E-Mail-Adressen gehören üblicherweise zu der Domäne, auf die sich der DMARC-Ressourceneintrag bezieht. Falls Sie die Berichte an eine E-Mail-Adresse in einer anderen Domäne senden wollen, dann muss die DNS-Zonendatei dieser anderen Domäne einen besonderen DMARC-Eintrag enthalten, der anzeigt, dass die Domäne die fremden DMARC-Berichte akzeptiert. Ein Beispielseintrag für die Domäne example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:nicht-lokaler-benutzer@example.net" Hierzu der erforderliche Eintrag für die Domäne example.net: example.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Kommagetrennte Liste der E-Mail-Adressen, an die DMARC-Fehlerberichte gesendet werden sollen. Die Adressen müssen als URIs im Format — Vorgabe: keine Falls dieser Tag nicht verwendet wird, werden keine DMARC-Fehlerberichte gesendet. |
Dieser Tag zeigt an, dass Sie DMARC-Fehlerberichte von den Servern der Nachrichtenempfänger erhalten wollen, bei denen Nachrichten mit Adressen aus Ihrer Domäne in der Absenderkopfzeile From: eingehen. Damit die Fehlerberichte versandt werden, müssen die Bedingungen aus dem Tag fo= erfüllt sein. Wird der Tag fo= nicht verwendet, so werden per Voreinstellung die DMARC-Fehlerberichte dann versendet, wenn bei einer Nachricht alle DMARC-Prüfungen (also SPF und DKIM) fehlschlagen. Geben Sie mindestens eine E-Mail-Adresse als URI im Format mailto:benutzer@example.com an, und trennen Sie mehrere URIs durch Kommata. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-failures@example.com" Die E-Mail-Adressen gehören üblicherweise zu der Domäne, auf die sich der DMARC-Ressourceneintrag bezieht. Falls Sie die Berichte an eine E-Mail-Adresse in einer anderen Domäne senden wollen, dann muss die DNS-Zonendatei dieser anderen Domäne einen besonderen DMARC-Eintrag enthalten, der anzeigt, dass die Domäne die fremden DMARC-Berichte akzeptiert. Ein Beispielseintrag für die Domäne example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:non-local-user@example.net" Hierzu der erforderliche Eintrag für die Domäne example.net: example.com._report._dmarc TXT "v=DMARC1" |
Ausführliche Informationen über die Spezifikation für DMARC erhalten Sie auf der Website www.dmarc.org.
