BEST PRACTICE | DNSBLs und E-Mail-Filter – so funktioniert‘s

Effizientes und effektives Filtern

Es gibt eine breit gefächerte Palette an E-Mail-Sicherheitsoptionen für Ihre Infrastruktur, vom Content-Filter und -Scan bis zu netzwerkbasierten Tools, die auf verteilte und kooperative Methoden setzen.

Leider sind die meisten sowohl ressourcenaufwendig als auch teuer.  Der Schlüssel zum richtigen E-Mail-Filter besteht darin, die Masse unerwünschter E-Mails schon zu Beginn des Prozesses abzufangen, noch bevor sie die ressourcenintensive Phase der Inhaltsprüfung erreicht.

Eine DNSBL-Prüfung ist die einfachste, schnellste und wirtschaftliche Methode, die Sie haben… also warum sollte man sie nicht nutzen?

Phasen, in denen DNSBLs nützlich sind

Wenn Sie eine E-Mail empfangen und verarbeiten, gibt es drei Bereiche, in denen Sie Blocklists einsetzen sollten:

1. Bei der ersten Verbindung – d. h. eine Prüfung der die Verbindung aufbauenden IP.
2. Während der Vor-Datenphase einer E-Mail, d. h. der SMTP-Transaktion
3. Sobald die E-Mail angenommen wurde, d. h. während der Untersuchung des Inhalts

Vorteile der DNSBL-Nutzung VOR dem Content-Filter

• Spart Bandbreite. Sie können die Anzahl der herunterzuladenden Nachrichten beträchtlich verringern.
• Spart offene Verbindungen. Es werden nicht so viele Verbindungen unnötigerweise offen gehalten.
• Spart Speicher. Wird eine E-Mail bereits vor dem Content-Filter abgewiesen, verbraucht sie keine Speicherressourcen (von einigen wenigen Protokollzeilen abgesehen).
• Spart Arbeitsspeicher, Speicher- und CPU-Anforderungen. Sie haben viel weniger E-Mails, die eine kostspielige Überprüfung des Inhalts benötigen.

1. Anwendung von DNS-Blocklists bei der ersten E-Mail-Verbindung

Direkt zu Beginn einer E-Mail-Transaktion versucht ein Remote Server, eine Verbindung zu Ihrem Server aufzubauen.  An diesem Punkt kann eine schnelle Abfrage bei einer Blocklist (fast) sofort Klarheit darüber geben, ob die Verbindung aufbauende IP-Adresse mit bösartiger Aktivität in Verbindung gebracht wird.

Ist die IP-Adresse in der Blocklist aufgeführt, können Sie entscheiden, die Verbindung sofort zu blockieren.  Zur Erinnerung: Diese Abfrage erfolgt noch vor dem Handshake mit dem Simple Mail Transfer Protocol (SMTP).

Diese Blocklists sollten Sie anwenden:

• Spamhaus Blocklist (SBL)
• eXploits Blocklist (XBL)
• Policy Blocklist (PBL)

2. Anwendung von DNS-Blocklists während der Vor-Datenphase

Was ist die Vor-Datenphase?

Alle E-Mail-Befehle nach dem Aufbau der ersten E-Mail-Verbindung (wie oben beschrieben) und vor dem DATA-Befehl während der SMTP-Verbindung bezeichnen wir als Vor-Datenphase.

DNS-Rückwärtssuche der die Verbindung aufbauenden IP-Adresse

Sobald die Verbindung offen ist, sollten Sie (der Empfänger), eine DNS-Rückwärtssuche der die Verbindung aufbauenden IP-Adresse starten.

Entspricht das Ergebnis der rDNS-Prüfung dem HELO-String?

Das Ergebnis der Abfrage sollte anhand der im HELO-String des Absenders enthaltenen Domain geprüft werden, z. B. (HELO mta-out.someisp.example). Stimmen die Daten nicht überein, sollte die Verbindung sofort blockiert werden.  Dies ist nämlich ein Hinweis darauf, dass der Absender nicht der ist, der er zu sein vorgibt: Es handelt sich z. B. um Spoofing.

Das rDNS-Ergebnis anhand der Blocklists überprüfen

Die erscheinende Domain sollte anhand der DBL und der ZRD geprüft werden.

Im HELO-String enthaltene Domain mit den Blocklists vergleichen

Die im HELO-String enthaltene Domain sollte anhand der DBL und ZRD geprüft werden. Außerdem sollte eine DNS-Vorwärtssuche in der SBL erfolgen.

Abfrage der MAIL-FROM-Domain (Return-Path)

Im Anschluss an den HELO-String erfolgt während der SMTP-Verbindung der „MAIL FROM“-Befehl.  Dieser wird häufig auch als „Envelope-From“ oder „Return-Path“ bezeichnet. Sie sollten die in diesem String enthaltene Domain abfragen, z. B. <[email protected]>.

Wenn die Abfrage anhand der DBL und ZRD positiv ausfällt, kann der Empfänger die E-Mail abweisen oder zur weiteren Untersuchung während des Content-Filter-Prozesses kennzeichnen.

Übertragung des E-Mail-Headers und Inhalts

Wenn der „RCPT TO“-Befehl ausgeführt wurde, folgt der „DATA“-Befehl, der die Übertragung der Daten, des E-Mail-Headers und des Inhalts auslöst. Wenn der Empfänger die erfolgreiche Ausführung bestätigt, übermittelt der Absender (vor oder nach der Prüfung des Inhalts) einen „QUIT“-Befehl, und die Verbindung wird geschlossen.

Wird die Verbindung bei der Prüfung des Inhalts offen gehalten?

Das hängt von Ihren Implementierungsentscheidungen und der gewählten Software ab.  Wie bei allen Optionen gibt es auch hier Vor- und Nachteile für beides:

Einige Implementierungen halten die Verbindung offen, bis das Ergebnis der Inhaltsprüfung vorliegt.

Vorteile: Absender werden immer von einer Abweisung benachrichtigt, was im Falle falsch positiver Einträge die beste Strategie ist.

Nachteile: Diese Vorgehensweise bindet Ressourcen, und Ihr MTA muss der Aufgabe auch in Spitzenzeiten gewachsen sein. Bei unzureichenden Ressourcen kann es zu Verzögerungen kommen.

Bei der Mehrzahl der Implementierungen wird die Verbindung vor der Prüfung des Inhalts geschlossen.

Vorteile: Geringere Kosten aufgrund des geringeren Ressourcenaufwands.

Nachteile: Wenn falsch positive Einträge vorliegen, wird der Absender nicht benachrichtigt.

Ein Blick auf die Vorteile der DNSBL-Nutzung VOR dem Content-Filter

Ihre Ressourcen werden weniger beansprucht

Wie schon erwähnt, stellen Content-Filter und Scanning hohe Anforderungen an Ihre Ressourcen. Wenn Sie die Anzahl der E-Mails reduzieren, die diesen Punkt des E-Mail-Filters überhaupt erreichen, sparen Sie Speicher, benötigen weniger Verarbeitungsleistung und verringern die Latenz.

Ihre Infrastruktur wird vor Spam-Kampagnen geschützt

Stellen Sie sich eine Situation vor, in der Sie bei einer anhaltenden oder eskalierenden Spam-Kampagne Hunderte von Nachrichten pro Sekunde erhalten.  Wenn Sie sich darauf verlassen, dass Ihre Content-Filter- und Scanning-Systeme den Angriff abfangen, bricht Ihre E-Mail-Infrastruktur möglicherweise unter der schieren Masse der eingehenden E-Mails zusammen.

Wenn Sie Glück haben und dies nicht passiert, entstehen Ihnen trotzdem hohe Kosten, weil jede E-Mail heruntergeladen und gescannt werden muss.

Absender können Probleme mit dem Mail-Relay beheben

Wenn eine E-Mail bei der ersten Verbindung oder dem SMTP-Handshake abgewiesen wird, wird eine Delivery Status Notification (DSN) in Echtzeit an den Absender übermittelt, die ihn darüber informiert, dass die Zustellung fehlgeschlagen ist.  Aus Perspektive des Absenders kann dies dazu beitragen, Mail-Relay-Probleme zu erkennen und zu beheben.

E-Mails bleiben nicht einfach in Spam-Ordnern liegen

Wenn E-Mails schon früh innerhalb der E-Mail-Transaktion abgewiesen werden, werden potenzielle Spam-E-Mails nicht heruntergeladen und möglicherweise im Spam-Ordner vergessen.  Endnutzer müssen nicht länger ihren Spam-Ordner mit Hunderten, wenn nicht Tausenden von Spam-E-Mails nach der einen legitimen Nachricht durchforsten.

Die Infrastrukturen unschuldiger Dritter werden nicht mit Rücksendenachrichten überflutet

Wenn die Absenderadresse gefälscht ist, wird der unschuldige Dritte, dessen E-Mail in der gefälschten Absenderadresse verwendet wurde, mit Rücksende-E-Mails überflutet.

Mehr Schutz vor Hailstorm- und Snowshoe-Spam-Kampagnen

Wenn Sie Domain Blocklists und IP-Blocklists nutzen, sind Sie zusätzlich vor Hailstorm- und Snowshoe-Spam-Angriffen und anderen Bedrohungen geschützt. Für detailliertere Informationen zu diesem Thema empfehlen wir Ihnen die Lektüre von MTA-Entwickler: Domain-DNSBLs auf SMTP-Ebene zulassen.

Es lohnt sich, daran zu denken, dass unsere Domain Blocklist viele Domains schon enthält, bevor sie live gehen!

3. Anwendung von DNS-Blocklists während der Nach-Datenphase

Wenn der DATA-Befehl ausgeführt wurde und der E-Mail-Header und der Inhalt an den Empfänger übertragen wurden, beginnt neben den SPF-, DKIM- und DMARC-Kontrollen die Prüfung des Inhalts.

E-Mail-Header enthalten strukturierte Daten, sodass ihre Analyse im Vergleich zum Textkörper einer E-Mail weitaus weniger ressourcenaufwendig ist. Für nähere Informationen über die E-Mail-Header- und Textkörperkomponenten empfehlen wir Ihnen die Lektüre von Den Quellcode bösartiger E-Mails verstehen.

Hier können die Blocklists bei der Header-Untersuchung eingesetzt werden:

Abfrage der Ursprungs-IP-Adresse:

Dies ist die IP-Adresse, die in der Empfangskette der ursprünglichen Transaktion enthalten ist, d. h. die Adresse, die ursprünglich die E-Mail generiert hat.  Diese Abfrage kann anhand der SBL und AUTH BL erfolgen. Auch eine rDNS-Suche kann anhand der DBL und ZRD durchgeführt werden.

Reply-To-Adresse abfragen:

Die vollständige E-Mail-Adresse in diesem Feld sollte mit der Hash Blocklist (HBL) verglichen werden, die kryptografische Hashes von E-Mail-Adressen enthält.

Sender-Adresse abfragen:

Diese Adresse, häufig auch als „Friendly-From“-Adresse bezeichnet, sollte anhand der HBL abgefragt werden, und die darin enthaltene Domain sollte anhand der DBL und ZRD und mit einer DNS-Vorwärtssuche anhand der SBL abgefragt werden.

Erst jetzt geht es an die Untersuchung des Inhalts. Überlegen Sie einmal, wie viele Gelegenheiten Sie (von oben auf der Seite bis hierher) schon hatten, E-Mails abzuweisen, bevor die Mails diesen kostspieligeren Teil des E-Mail-Filters überhaupt erreichen!

Im Textkörper der E-Mail enthaltene Domains

Website-URLs oder E-Mails im Textkörper sollten alle anhand der DBL und ZRD abgefragt werden. Außerdem sollte eine DNS-Vorwärtssuche anhand der SBL erfolgen.  Im Textkörper der E-Mail enthaltene E-Mails können ebenfalls anhand der HBL überprüft werden.

Im Textkörper der E-Mail enthaltene Bitcoin-Adressen

Fragen Sie diese anhand der HBL ab, die einen Cryptowallet-Abschnitt mit Hashes von Bitcoin- und anderen Kryptowährungsadressen enthält.

E-Mail-Anhänge

Alle Anhänge sollten anhand der HBL überprüft werden, in der neben E-Mail-Adressen und Kryptowährungsadressen auch Malware-Dateien gelistet sind.

Wie lässt sich all dies implementieren?

Leider ist es angesichts der vielen Varianten nicht möglich, auf alle spezifischen betrieblichen Details der verschiedenen Mailsysteme einzugehen.  Sollten einige unserer Kontrollen nicht zu implementieren sein, empfehlen wir Ihnen, sich mit dem Support-Desk des von Ihnen genutzten Produkts in Verbindung zu setzen.

Die gute Nachricht: Wir halten zwei Plugins für die Open-Source-Filter SpamAssassin und Rspamd sowohl für die Vor-Daten-Filterung (SMTP) als auch für die Inhaltsanalyse bereit.  Außerdem finden Sie hier die vollständige Aufstellung, welche Blocklists wo genutzt werden sollten.

Wenn Sie die DNS-Blocklists ausprobieren möchten und einen eigenen E-Mail-Server betreiben, registrieren Sie sich für den kostenlosen 30-tägigen Datenzugriff. Wir freuen uns auf Ihre Rückmeldung.

If you’d like to trial DNS Blocklists and run your own email server – then sign up to access the data free for 30 days. We’d love to hear how you get on.