Ein herzliches Moin Moin an alle Durchgeknallten. Ich finde es immer wieder lustig, traurig, anstrengend oder schön, bestimmte Dinge in meinem Job als Systemadministrator tun zu dürfen. Hier möchte ich meine Erfahrungen schildern und vielleicht den einen oder anderen anregen, Dinge zu implementieren, zu ändern oder mir Hilfestellung zu geben, falls ich einmal wo nicht weiterkomme.

Aber genug dem Vorgeplänkel. Ab zum ersten Thema. Das Chaos mit E-Mail und Authentifizierung.

E-Mail-Chaos: spf, dkim, dmarc, Spam und die Verantwortung der Hosting-Provider

Stellt euch folgendes Szenario vor. Server bei einem Anbieter – das Ganze managed per ISPconfig. Mail-Software: dovecot, postfix.

Der Server hat logischerweise eine IP und eine Subdomain beim Anbieter, die so ungefähr wie kunde.toller-provider.de aussieht. Dann haben wir unsere Domain toller-kunde.de, welche alle entsprechenden MX-Records gesetzt hat und seit Monaten, wenn nicht Jahren, erfolgreich und absolut Problemfrei Mails von A nach B über C und zurück schubst. Doch nun beginnt es, mein Chef und andere Mitarbeiter der Domain toller-kunde.de bekommen ständig Spam-Mails von einem ganz bestimmten russischen Server, mit wechselnden Mailadressen.

Für mich, da ich mich nie tiefer mit der Materie befasst hatte, eigentlich ganz einfach – Spamfilter aggressiver stellen. Fertig.

Pustekuchen. Nicht nur half es nichts, auch wurde das Problem noch schlimmer. Also wurde es Zeit, dem Ganzen nachzugehen. Nach genauerer Ansicht der Header der Mails wurde mir bewusst, dass die Mailadressen immer das gleiche Muster hatten. =?=utf8=123456abcde?=@kunde.toller-provider.de. WTF? Dazu muss man wissen, dass kunde.toller-provider.de bei uns keinerlei Mailadressen eingerichtet hatte und die Mailfunktion für diese Domain nicht einmal aktiviert ist.

Also packte ich das Problem beim Schopf und konfigurierte einen postfix-Blacklist-Eintrag und erhöhte noch einmal die Aggressivität von spamassasin im Bezug auf die gesamte Domain kunde.toller-provider.de. Doch mich interessierte immer noch, woran das am Ende lag.

Nun habe ich einige Tage ruhe von den Spam-Mails. Bevor sie wieder anfangen, ein wenig Analyse. Irgendwer verschickt über seinen Server Mails an unsere öffentlich erreichbaren Mailadressen. Das wären z.B. mitarbeiterxyz@toller-kunde.de, webmaster@toller-kunde.de oder sonstige. Dann spooft der Ersteller dieser Spam-Mails unseren Server und gibt die Mails aus, als wären sie von unserer Mailadresse gekommen.

Wie können wir dem entgegen wirken? Dafür gibt es drei Tools, die jedem Mail-Admin heutzutage ein Begriff sein sollten: spf, dkim und DMARC. Und das in der Reihenfolge. Ich las diese Sachen und dass ich sie unbedingt implementieren sollte, doch ich hatte keine Ahnung, wofür die gut sind. Diese Infos musste ich mir mühsam im Internet zusammenklauben. Daher einmal hier kurz und bündig, und für jeden verständlich.

spf, dkim, DMARC – was ist das und wofür brauche ich das?

SPF – das steht für Sender Policy Framework. Damit wisst ihr ja Bescheid, also DK… – ach Quatsch. Wenn dann schon vernünftig:

SPF = Sender Policy Framework. Das Sender Policy Framework stellt sicher, dass ein Mailserver, der Mails annimmt, verifizieren kann, dass die Mail auch wirklich vom entsprechenden Server kommt.

Ein SPF-Eintrag sieht etwa folgendermaßen aus:

v=spf1 a mx -all

v=spf1 steht hier für die Version des SPF-Protokolls. Anschließend folgen die zugelassenen Server. a steht hier dafür, dass ein Server mit der IP-Adresse unter dem A-Record der Domain Mails verschicken darf. mx ist hier das gleiche – nur für den MX-Record. -all bedeutet, dass die Richtlinie Streng umgesetzt wird. Das bedeutet: SPF passt nicht? Mail wird discarded. ~all würde hier bewirken, dass die Mail nur markiert wird.

Wir schauen uns hier mal die DNS-Records für toller-kunde.de (fiktiv!) an.

toller-kunde.de. IN A 203.0.113.154
www.toller-kunde.de. IN A 203.0.113.154
*.toller-kunde.de. IN A 203.0.113.154
mail.toller-kunde.de. IN A 198.51.100.77
toller-kunde.de. IN MX mail.toller-kunde.de
toller-kunde.de. IN TXT v=spf1 a mx -all

Wir sehen, dass der Server toller-kunde.de unter 203.0.113.154 läuft. Das Mailsystem läuft jedoch auf einem anderen Server, und zwar unter 198.51.100.77. Ein spf-Record, vom Typ txt – wie es die Richtlinie vorsieht – ist auch vorhanden.

Durch das a und mx im Record, sind jetzt Server mit den IP-Adressen 203.0.113.154 (A-Record toller-kunde.de) und 198.51.100.77 (MX-Record mail.toller-kunde.de) berechtigt, Mail von toller-kunde.de zu verschicken.

Versucht nun jemand, von einem anderen Server aus (nehmen wir mal als Beispiel boeser-bube.ru mit der IP 192.0.2.75) eine Mail mit einem modifizierten Header zu verschicken, die aussieht, als wäre sie von toller-kunde.de, wird diese abgewiesen werden. Das sieht dann folgendermaßen aus:

boeser-bube.ru verschickt Mail mit gespoofter Absenderadresse „chef@toller-kunde.de“ an unseren guten Freund „beispiel@unschuldiger-dau.de“.
Der annehmende Mailserver unter unschuldiger-dau.de fragt dann als erstes den Server unter toller-kunde.de an und fordert den TXT-Record an. Dort sieht er den vorhanden spf-Record. Er zieht sich über DNS die IP von boeser-bube.ru. Diese werden verglichen. Er stellt fest: Keine der im SPF-Record eingetragenen IPs passt! Der SPF-Record sagt: Ablehnen! Und schon wird die Mail niemals ankommen.

DKIM sieht für Domain-Keys Identified Mail und geht noch einen Schritt weiter. DKIM ist ein Verfahren, welches auf asymmetrischer Verschlüsselung basiert.

Auch hier wird ein TXT-Record angelegt und zur Verifizierung verwendet.
Jede von einem Server verschickte Mail wird mit einem privaten Schlüssel verschlüsselt und danach verschickt. Die Crux ist, dass der passende öffentliche Schlüssel im TXT-Record der Domain hinterlegt ist und ein annehmender Mailserver dann die Schlüssel vergleicht. Passen diese zusammen – toll! Passen sie nicht zusammen, dann entscheidet der Server, was damit zu tun ist.

Implementiert sieht das Ganze dann folgendermaßen aus. Der gleiche Versuchsaufbau wie vorhin wird verwendet.

toller-kunde.de. IN A 203.0.113.154
www.toller-kunde.de. IN A 203.0.113.154
*.toller-kunde.de. IN A 203.0.113.154
mail.toller-kunde.de. IN A 198.51.100.77
toller-kunde.de. IN MX mail.toller-kunde.de
toller-kunde.de. IN TXT v=spf1 a mx -all
default._domainkey.toller-kunde.de. IN TXT v=DKIM1;p=feewef+ksandkw/DJdsadf

Und wir sehen: Ein DKIM-Eintrag! Dieser ist immer unterschiedlich und hat einen öffentlichen Schlüssel (public-Key). Wenn wir annehmen, dass unser boeser-bube.ru es geschafft hat, SPF irgendwie zu umgehen, scheitert er spätestens hier. Denn den privaten Key kriegt er nicht, außer ihr hättet ihm mal eine Mail geschickt. Und wer würde dem bösen Buben denn eine Mail schicken?

DMARC steht für Domain-based Message Authentication, Reporting and Conformance und ist NUR in Verbindung mit sowohl SPF, als auch DKIM sinnvoll und funktioniert. Aufgrund dessen verstehe ich auch nicht, warum meistens in Titeln von Artikeln wie diesem „spf, DMARC and dkim!“ steht, denn eigentlich ist das falsch. DMARC KANN halt einfach ohne SPF UND DKIM nicht funktionieren! Deshalb kommt DMARC hier am Schluss.

DMARC macht im Prinzip nichts anderes, als dem empfangenden Mailserver zu sagen, was mit einer Mail passieren soll. Der empfangende Server wird sowieso prüfen, ob spf und dkim beide passen. Normalerweise würde er hier selbst entscheiden, was mit einer Mail zu tun ist, wenn eins von beiden nicht passt, oder sich eben den Eintrag im SPF-TXT-Record zur Hilfe heranziehen, um eine Entschiedung zu treffen. DMARC nimmt ihm diese ab.

So würde eine Konfiguration für toller-kunde.de mit aktiviertem DMARC, SPF und DKIM aussehen:

toller-kunde.de. IN A 203.0.113.154
www.toller-kunde.de. IN A 203.0.113.154
*.toller-kunde.de. IN A 203.0.113.154
mail.toller-kunde.de. IN A 198.51.100.77
toller-kunde.de. IN MX mail.toller-kunde.de
toller-kunde.de. IN TXT v=spf1 a mx -all
default._domainkey.toller-kunde.de. IN TXT v=DKIM1;p=feewef+ksandkw/DJdsadf
_dmarc.toller-kunde.de. IN TXT v=DMARC1; rua=postmaster@toller-kunde.de; p=reject

Toll! Wir haben DMARC eingerichtet! Und nu? Dröseln wir den Eintrag einmal auf. v= ist uns bereits bekannt, steht immer für die Version. rua=postmaster@toller-kunde.de bedeutet, dass ein Report der Konfiguration und ob alles passt, einmal pro Woche an postmaster@toller-kunde.de versendet wird. Kommt meistens von Google, manchmal von Yahoo! und ab und an von beiden. p=reject ist die Policy. Mit reject wird die Mail, wenn SPF und/oder DKIM nicht passen, hart abgebrochen. p=quarantine würde die Mail lediglich als Spam markieren, und p=none ist nur zum Troubleshooting da, um die Einträge zu überwachen.

Bei DMARC gibt es noch unendlich andere Features, aber realistisch gesehen kommt es in der Praxis nur auf die o.g. Einträge an! rua= ist sogar Optional. Wer also nicht genervt werden möchte, kann das nach einiger Zeit aus dem Record herausnehmen.

Das Spam-Problem – nun endlich im Griff?

Nachdem ich den Admin unseres Servers einmal angeschrieben habe und ihn gebeten habe, doch einen strikten spf-Record hinzuzufügen, antwortete dieser mir, dass das Problem bekannt sei und man momentan an einer standardisierten Lösung für alle Kunden arbeite. Freundlicherweise hat er das für mich kurz eingetragen.

Seitdem ist Ruhe. Trotzdem – auch wenn ihr vielleicht keine Spam-Problematik habt und euer Maillog sauber ist: Denkt darüber nach, es zu implementieren. Ihr habt es gesehen – es ist kein Hexenwerk, wenn man die Funktionsweise einmal verstanden hat.

Kategorien: Sysadmin-Blog