RSS Feed  •  Profil  •  Private Nachrichten  •  Registrieren  •  Login 
  
 
im Forum




Blog-Übersicht -> Postfix: Backscatter durch "Delivered-To" Header netcup präsentiert RPaaS :: Kurz notiert: Lockfile für Arme
Postfix: Backscatter durch "Delivered-To" Header
Verfasst am: 01.08.2018, 15:35   Autor: killerbees19
Was würdest du antworten, wenn dich jemand fragt, ob dein Mailserver (Postfix) im Normalzustand Backscatter ermöglicht?

Bisher wäre meine Antwort, ohne lange nachzudenken, sofort gewesen: "Natürlich nicht! Das ist ein absolutes No-Go."
Mittlerweile sehe ich das etwas anders und würde wohl eher so antworten: "Das ist kompliziert, es kommt drauf an..."


Vorwort: Delivery Status Notifications (DSN)

Die Sache ist eigentlich relativ einfach: Eine Mail sollte bereits während des SMTP-Dialogs abgewiesen werden. Normalerweise erreicht man das mit diversen Checks während der SMTP-Transaktion, häufig unterstützt durch diverse Milter für Viren-/Spamfilter. Sobald die Mail durch den Server angenommen wurde und in der eigenen Queue landet, würde jede danach folgende Abweisung zum Versand einer Delivery Status Notification sorgen. Das grundlegende Problem daran ist, dass der vermeintliche Absender der Mail und somit Empfänger einer DSN beliebig gefälscht werden kann. Das ist eine weit verbreitete Masche der Spamversender. Es gilt somit, dass der Versand einer DSN an externe Adressen immer vermieden wird. Sobald eine Mail in die eigenen Queue aufgenommen wurde, darf sie nicht mehr abgewiesen werden! (Von temporären Systemfehlern o.ä. einmal abgesehen.)

Davon unterscheiden sollte man explizite DSN-Requests des Versenders. Diese haben ihre Daseinsberechtigung allerdings meistens nur für (authentifizierte) Benutzer des eigenen Mailservers. Das Missbrauchspotential durch Außenstehende ist andernfalls zu groß. Wie man angeforderte DSN komplett deaktiviert oder einschränkt, erklärt die Postfix Dokumentation. Darum geht es in diesem Blogbeitrag nicht.


Delivered-To Header als Loop Detection

Häufig genutzte Transports bzw. Befehle bei Postfix sind z.B. local, virtual und pipe. Und überall gibt es eine Erkennung für Endlosschleifen. Realisiert wird das meistens über den Delivered-To Header, in den die Adresse des Zielpostfachs eingetragen wird. Nachfolgend einige Auszüge aus der Dokumentation...

local(8) hat Folgendes geschrieben:
In order to stop mail forwarding loops early, the software adds an
optional Delivered-To: header with the final envelope recipient
address. If mail arrives for a recipient that is already listed in a
Delivered-To: header, the message is bounced.


pipe(8) hat Folgendes geschrieben:
Prepend a "Delivered-To: recipient" message header with
the envelope recipient address. [...]

The D flag also enforces loop detection (Postfix 2.5 and
later): if a message already contains a Delivered-To:
header with the same recipient address, then the message
is returned as undeliverable.


Postfix weist eine Mail ab, wenn ein passender Delivered-To Header mit der gleichen Postfachadresse bereits vorhanden ist.
Das ist prinzipiell keine schlechte Idee! Aber was passiert, wenn ein Spammer genau diesen Header von selbst bereits setzt?


Einsturz des Kartenhauses...

Eine Mail mit vorhandenem Delivered-To Header und passendem Inhalt löst bei einer Standardkonfiguration nun das aus, was die Dokumentation beschreibt:

Syslog hat Folgendes geschrieben:
[...] status=bounced (mail forwarding loop for user@example.net)


Das ist unschön. Extrem unschön! Ein Außenstehender kann Bounce-Nachrichten an beliebige Empfänger auslösen, allgemein als Backscatter bekannt. Er muss dafür nur die genaue Adresse eines E-Mail Postfachs kennen, Aliasadressen reichen dafür nicht! Wirklich schlimm wird es aber erst dadurch, dass sich viele Postfix-Admins nicht bewusst sind, welche gefährliche Funktion im System schlummert. Ich gehörte bis vor wenigen Tagen ebenfalls zu dieser Gruppe. In zahlreichen Anleitungen wird dieses Verhalten sogar noch explizit aktiviert, siehe z.B. der LDA-Beitrag im Dovecot Wiki.


Die Lösung? Es gibt mehrere...

Es gibt mehrere Möglichkeiten, um dieses Verhalten abzuschwächen oder ganz zu deaktivieren. Eines haben alle mir bekannten Lösungen leider gemeinsam: Entweder man deaktiviert damit die Bounce-Versendung ganz bzw. teilweise oder die Loop-Detection wird ausgehebelt. Die Alternative, zur Quelle für Backscatter zu werden, gefällt mir persönlich allerdings noch weniger!

  • bei Verwendung des local-Transports: Deaktivierung von prepend_delivered_header.
    Software und Filterregeln, die diese Headerzeile benötigen, könnten Probleme verursachen.

  • bei Verwendung des pipe-Befehls: Entfernung des D-Flags und glücklich sein.
    Nervend wird es erst, wenn ein Filter oder eine Software darauf angewiesen ist.


Alternativ gibt es einige Methoden, die unabhängig vom verwendeten Transport/Befehl arbeiten und den Delivered-To Header unverändert einfügen. Einige davon, wenn nicht sogar alle, sind aus rechtlicher und technischer Sicht allerdings bedenklich.

  • Durch die Aktivierung von soft_bounce könnte man die Bounces z.B. mit einem Script löschen oder freigeben. (sehr aufwändig)

  • Durch Deaktivierung des bounce-Dienstes könnte man den Versand von Bounce-Nachrichten komplett unterbinden. (nicht empfohlen!)

  • Ein eigener Wrapper für den LDA könnte den Header überprüfen und Mails verwerfen, die sich in einer Schleife befinden. (nicht empfohlen!)

  • Man könnte Mails noch während des SMTP-Dialogs abweisen, die im Delivered-To Header eine der Zieldomains enthalten. (nicht empfohlen!)

  • Bei Verzicht auf das Loop-Detection-Feature könnte man den Header bei eingehenden Mails z.B. durch X-Delivered-To ersetzen lassen.


Letzteres lässt sich mit header_checks und einer PCRE-Tabelle realisieren. Unter Debian muss dafür das Paket postfix-pcre installiert sein. Die Überprüfung kann durch eigene Cleanup-Services sogar je Port anders geregelt werden. Das würde allerdings den Rahmen dieses Blogbeitrags deutlich sprengen.

Code:
header_checks = pcre:${config_directory}/pcre/delivered-to.cf


Als Inhalt der soeben eingetragenen Datei könnte so etwas dienen:

Code:
/^(Delivered-To:.*)$/ REPLACE X-${1}


Dadurch wird automatisch ein "X-" vorangestellt. Die Aktion wird übrigens detailliert ins Protokoll von Postfix (z.B. Syslog) geschrieben.


Persönliches Fazit

Mailserver sind und bleiben ein fragiles sowie kompliziertes Thema. Backscatter lässt sich nie zu 100% vermeiden.

  • Ist die Lösung schön? Nicht wirklich, aber...

  • Ist die Alternative Backscatter besser? Nein!

  • Nutzen Spammer das überhaupt aus? Vielleicht.

  • Braucht man die Loop-Detection wirklich? Nein!


Beim letzten Punkt beziehe ich mich auf das Hopcount-Limit, das standardmäßig bei 50 liegt. Dabei werden die enthaltenen Received Header (inkl. der neu eingefügten Received Zeile) gezählt und mit einem Limit verglichen. Sollte es durch eine Fehlkonfiguration von Weiterleitungen zu einer Endlosschleife zwischen mehreren Servern kommen, schlägt normalerweise immer noch diese allerletzte Sicherheitsfunktion an. Das Gute daran: Dabei kommt es zu keinem Bounce! Wenn das Hoplimit erreicht wurde, wird die Nachricht noch während des SMTP-Dialogs abgewiesen:

Syslog hat Folgendes geschrieben:
[...] host example.net[10.0.0.1] said: 554 5.4.0 Error: too many hops (in reply to end of DATA command)


Seltsamerweise findet man diese Meldung nicht im Protokoll des Mailservers, der die Ablehnung erzeugt. Aber das ist eine andere Geschichte.


Weiterführende Links

Es gibt zu diesem Thema einige ältere Beiträge im Internet...



Feedback bitte in den Kommentaren (nur für registrierte User), im Forum oder per E-Mail abgeben.



Autor Nachricht
Für diesen Beitrag können zur Zeit keine neuen Kommentare verfasst werden.

Kontaktiere den Autor des Beitrages, falls du Fragen dazu hast.


 

Alle Zeiten sind GMT + 2 Stunden (Sommerzeit)
Aktuelles Datum und Uhrzeit: 19.10.2018, 22:21
Nach oben
Valid HTML 4.01 Transitional
Valid CSS!

netcup - Internetdienstleistungen
 
 
[ happytec.at | forum.happytec.at | blog.happytec.at | esports.happytec.at | event.happytec.at ]