Schlagwort: DMARC (Seite 2 von 2)

DMARC einrichten: Policy, Alignment und Reporting für deine Domain

30. November 2013 / Sebastian van de Meer / Keine Kommentare

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) baut auf SPF und DKIM auf. Es löst zwei Probleme, die SPF und DKIM allein offen lassen: Erstens kann der Absender festlegen, was mit Mails passieren soll, die weder SPF noch DKIM bestehen. Zweitens bekommt der Absender Berichte darüber, wie seine Mails bei den Empfängern ankommen.

DMARC-Record aufbauen

DMARC wird als TXT-Record unter _dmarc.domain.de im DNS veröffentlicht. Ein Beispiel:

_dmarc.kernel-error.de.  IN TXT  "v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de"

Die einzelnen Parameter:

`v=DMARC1`	Protokollversion (immer DMARC1)
`p=quarantine`	Policy für die Hauptdomain (siehe unten)
`sp=quarantine`	Policy für Subdomains (optional, erbt sonst von `p`)
`adkim=s`	DKIM-Alignment: `s` = strict, `r` = relaxed
`aspf=s`	SPF-Alignment: `s` = strict, `r` = relaxed
`pct=100`	Prozent der Mails, auf die die Policy angewendet wird
`rua=mailto:...`	Adresse für aggregierte Berichte (täglich, XML)
`ruf=mailto:...`	Adresse für forensische Berichte (pro Vorfall)

Alignment: Wofür DMARC wirklich da ist

SPF prüft den Envelope-From, DKIM prüft die signierende Domain. Beides sagt nichts über den From:-Header aus, den der Empfänger tatsächlich sieht. DMARC schließt diese Lücke mit dem sogenannten Alignment: Es verlangt, dass mindestens eine der beiden Prüfungen (SPF oder DKIM) zur Domain im From:-Header passt.

Strict (s) bedeutet: Die Domains müssen exakt übereinstimmen. Relaxed (r) erlaubt auch Subdomains (z.B. mail.kernel-error.de passt zu kernel-error.de). Für die meisten Setups ist strict die richtige Wahl, solange alle ausgehenden Mails über die Hauptdomain signiert werden.

Policy-Stufen

Der p-Parameter legt fest, was der Empfänger mit Mails machen soll, die weder SPF noch DKIM bestehen:

`p=none`	Nur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.
`p=quarantine`	Als Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.
`p=reject`	Ablehnen. Die Mail wird gar nicht erst angenommen.

Der empfohlene Weg: Mit p=none anfangen und die Reports auswerten. Wenn alles sauber aussieht, auf quarantine hochdrehen. Wenn auch das stabil läuft, auf reject gehen. Mit pct kann man die Policy schrittweise ausrollen, z.B. erst auf 10% der Mails anwenden und dann langsam erhöhen.

Reporting

Die aggregierten Reports (rua) kommen einmal am Tag als komprimierte XML-Dateien per Mail. Darin steht, welche IPs Mails mit deiner Domain versendet haben und ob SPF/DKIM bestanden oder durchgefallen sind. Das ist Gold wert: Man sieht sofort, ob jemand die Domain missbraucht oder ob ein legitimer Dienst falsch konfiguriert ist.

Die XML-Dateien sind nicht besonders lesefreundlich. Zum Auswerten eignet sich dmarcian.com (XML hochladen, menschenlesbare Übersicht bekommen) oder man baut sich eine eigene Auswertung. Für größere Setups gibt es Open-Source-Tools wie parsedmarc, die Reports automatisch verarbeiten und in Elasticsearch oder eine Datenbank schieben.

Die forensischen Reports (ruf) liefern Details zu einzelnen fehlgeschlagenen Mails. In der Praxis schicken die meisten großen Provider (Google, Microsoft) allerdings keine forensischen Reports mehr, aus Datenschutzgründen. Die aggregierten Reports reichen für die meisten Fälle aus.

Cross-Domain-Reporting

Wer mehrere Domains betreibt und die Reports zentral an eine Adresse schicken will, muss aufpassen. Soll der Report für kernel-error.com an postmaster@kernel-error.de gehen, muss die Empfänger-Domain das erlauben. Dafür braucht es einen zusätzlichen TXT-Record in der Zone von kernel-error.de:

kernel-error.com._report._dmarc.kernel-error.de.  IN TXT  "v=DMARC1"

Dieser Record sagt: „kernel-error.de akzeptiert DMARC-Reports für kernel-error.com.“ Ohne diesen Eintrag ignorieren Empfänger die Report-Adresse, weil sie in einer fremden Domain liegt.

DMARC testen

# DMARC-Record abfragen
dig TXT _dmarc.kernel-error.de +short

Einen vollständigen Check inklusive SPF und DKIM bekommt man über mxtoolbox.com oder ähnliche Online-Tools. Einfach eine Testmail an die Prüfadresse schicken und den Report abwarten.

Das Zusammenspiel

DMARC funktioniert nur zusammen mit SPF und DKIM. Alle drei zusammen ergeben eine vollständige E-Mail-Authentifizierung: SPF legt fest welche Server senden dürfen, DKIM signiert die Mail kryptografisch und DMARC verknüpft beides mit einer Policy und liefert Feedback. Wer das Ganze mit rspamd betreibt, hat Auswertung und Enforcement gleich mit dabei. Fragen? Einfach melden.

Zu pingelig?

18. November 2012 / Sebastian van de Meer / Keine Kommentare

Klar, nach RFC müssen bestimmte Dinge bei einem Mailserver zusammenpassen.

Nach RFC1912 – Section 2.1 muss der Rückwärts aufgelöster Hostname zu dessen Vorwärtsauflösung passen.

Als Beispiel:
Wenn ich nachfrage welcher DNS Name zur IPv4 Adresse 10.2.3.4 gehört und darauf die Antwort bekomme, es ist: test.example.com…. Ja dann muss auf die Frage welche IPv4 Adresse zum DNS Namen test.example.com gehört auch die Antwort kommen: 10.2.3.4

Aus Sicht des testenden ist die Wahrscheinlichkeit schon höher dass beide Systeme unter der gleichen Kontrolle stehen. Zusätzlich haben Bots in einem Botnetz extrem selten die Möglichkeit diese Einträge passend zu setzten und der Administrator des Systems hält sich nicht nur die RFCs sondern konfiguriert zudem ordentlich. Es ist daher ebenfalls wahrscheinlich dass er sich bei seinen sonstigen Konfigurationen auch Mühe gegeben hat. Dieses lässt sein System zusätzlich sicherer gegen Missbrauch erscheinen.

Weiter im Text…
Denn nach RFC 2821, Section 3.6 muss der im HELO/EHLO angegebene DNS Name nicht nur ein gültiger Fully Qualified Domain Name (FQDN) sein, sondern er muss zusätzlich zum Hostname des einliefernden Mailservers passen. So lässt sich nun ersehen dass nicht nur IP und DNS unter der gleiche Kontrolle zu sein scheinen, sondern gleichfalls das Mailsystem.

Der Admin scheint also zu wissen was er tut und hat auch die Kontrolle über das System.

Ich prüfe dieses nun bei jeder einzuliefernden E-Mail. Ist nicht alles korrekt, wird die E-Mail abgelehnt. In den letzten Wochen tauchen genau hier gehäuft Unstimmigkeiten auf und dieses nicht bei kleinen „Wurstbuden“ sondern auch bei den ganz Großen! Natürlich ist es kein zwingender Grund E-Mails auf dieser Basis abzuweisen…. Da die Sysadmins der Mailserver, vor allem der ganz GROSSEN, ja Fachleute sind… Sollte man von diesen erwarten können sich an diese einfachen Vorgaben zu halten, oder? — Oder ist es wirklich zu pingelig?

Siehe auch: DMARC einrichten

Fragen? Einfach melden.

RBL und DNSBL in Postfix: Spam auf Verbindungsebene abweisen

2. Juni 2010 / Sebastian van de Meer / Keine Kommentare

Realtime Blackhole Lists (RBL) bzw. DNS-based Blackhole Lists (DNSBL) sind eine der ältesten und effektivsten Methoden gegen Spam. Das Prinzip ist simpel: Der sendende Server wird gegen eine Liste bekannter Spam-Quellen geprüft, noch bevor die Mail angenommen wird. Steht die IP auf der Liste, wird die Verbindung sofort abgelehnt. Der Server muss die Mail gar nicht erst annehmen, filtern oder speichern.

Vorteile und Nachteile

Der große Vorteil: Die Abweisung passiert auf SMTP-Ebene, bevor Ressourcen verschwendet werden. Bei hohem Mailaufkommen macht das einen spürbaren Unterschied. 80 bis 90 Prozent des Spam-Verkehrs lassen sich so schon beim Verbindungsaufbau abfangen.

Der Nachteil: Man verlässt sich auf Dritte. Wer auf einer RBL landet, kommt nicht immer schnell wieder runter. Und wenn ein RBL-Betreiber seinen Dienst einstellt, kann das zu Problemen führen (dazu weiter unten mehr). RBLs ersetzen keinen Content-Filter, sie ergänzen ihn.

Postfix konfigurieren

Die RBL-Abfragen werden in smtpd_recipient_restrictions in der main.cf eingetragen. Zwei Typen:

`reject_rbl_client`	Prüft die IP-Adresse des sendenden Servers gegen die Liste
`reject_rhsbl_sender`	Prüft die Domain des Absenders (rechte Seite der Adresse) gegen die Liste

Eine bewährte Kombination:

# /etc/postfix/main.cf (Auszug)
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client ix.dnsbl.manitu.net

zen.spamhaus.org ist die wichtigste Liste. Sie fasst mehrere Spamhaus-Listen zusammen (SBL, XBL, PBL) und deckt bekannte Spammer, Exploits und dynamische IP-Bereiche ab. bl.spamcop.net reagiert schnell auf aktuelle Spam-Wellen. ix.dnsbl.manitu.net (NiX Spam) ist eine deutsche Liste die besonders gut bei deutschsprachigem Spam funktioniert.

Die Reihenfolge ist wichtig: permit_mynetworks und permit_sasl_authenticated müssen vor den RBL-Checks stehen, damit eigene Benutzer und authentifizierte Verbindungen nicht gegen die Listen geprüft werden.

Tote RBL-Server erkennen

Stellt ein RBL-Betreiber seinen Dienst ein, werden DNS-Anfragen entweder nicht beantwortet oder liefern für jede IP einen Treffer zurück. Beides ist schlecht. Im ersten Fall laufen die Anfragen in Timeouts und bremsen alle DNS-Auflösungen aus. Im zweiten Fall wird plötzlich jede eingehende Mail abgewiesen.

Im Postfix-Log (/var/log/mail.log) erkennt man das an Timeout-Warnungen oder an plötzlich massenhaften Ablehnungen. Die Lösung: Tote Listen sofort aus der Config entfernen. Es lohnt sich, die RBL-Listen alle paar Monate zu prüfen. Bekannte Leichen aus der Vergangenheit: dnsbl.njabl.org (2013 abgeschaltet), rhsbl.ahbl.org (2015 abgeschaltet), dnsbl.sorbs.net (mehrfach instabil).

RBL-Ablehnungsmeldung anpassen

Standardmäßig schickt Postfix eine generische Fehlermeldung. Mit default_rbl_reply lässt sich eine aussagekräftigere Antwort konfigurieren, die dem Admin des sendenden Servers hilft:

default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}

RBL und rspamd

Wer rspamd einsetzt, kann RBL-Checks auch dort konfigurieren statt in Postfix. rspamd fragt die Listen asynchron ab und verrechnet das Ergebnis mit dem Gesamtscore der Mail. Das ist flexibler als die harte Ablehnung in Postfix: Eine IP auf einer einzelnen Liste führt nicht sofort zur Ablehnung, sondern erhöht den Spam-Score. Erst wenn mehrere Indikatoren zusammenkommen, wird die Mail abgewiesen.

Beide Ansätze lassen sich auch kombinieren: Die wichtigsten Listen (Spamhaus) direkt in Postfix für die sofortige Ablehnung, weitere Listen in rspamd für die feinere Bewertung.

RBLs sind ein Baustein im Gesamtsystem. Zusammen mit SPF, DKIM und DMARC decken sie verschiedene Angriffsvektoren ab. Fragen? Einfach melden.