Versenden Spammer ihren Werbemüll, verwenden sie oftmals eine real existierende Adresse eines unbeteiligten Dritten, um einige Arten von Spamfiltern zu umgehen. Die Folgen für den Dritten sind mehr als unangenehm: Er wird mit tausenden Unzustellbarkeitsnachrichten, Abwesenheitsmeldungen oder Nachrichten über gefundene Viren überflutet — und das oftmals ganz ohne Not. Ursache sind schlecht konfigurierte Mailserver, Virenscanner, Abwesenheitsmeldungen oder Weiterleitungen, die die Entstehung solcher Backscatter-Mails begünstigen. Die ohnehin schon grosse Belästigung durch Spam wird dadurch ins Unerträgliche gesteigert und kann ganze E-Mail-Infrastrukturen lahmlegen.
Anders als im Deutschen, lässt sich das Phänomen im Englischen kurz umschreiben mit: «Backscatter is a message you receive informing you that E-Mail you did not send was not delivered to someone you do not know.» Folgende Konstellationen können Backscatter an unbeteiligte Dritte verursachen:
- Ungenügend konfigurierte Mail Transfer Agents (MTA): Nimmt der erste MTA einer Domain E-Mails entgegen, ohne zu prüfen, ob der Empfänger existiert, so wird spätestens der Mailserver mit den Postfächern der Benutzer (Mail Delivery Agent, MDA) feststellen, dass es den Empfänger nicht gibt. Laut RFC 821 muss er dann eine Unzustellbarkeitsnachricht (Non-Delivery Notification, NDN) an den ursprünglichen Absender ausstellen.
Grafik: Entstehung von Backscatter-E-Mails
Das RFC 821, das SMTP beschreibt, schreibt nicht vor, welche Inhalte in einer NDN enthalten sein müssen. Es gibt lediglich die Empfehlung, genügend Informationen beizufügen, um die nicht zustellbare Mail zu identifizieren. Einige Mailserver agieren dabei übereifrig: die Non Delivery Notification wird der ursprünglichen E-Mail als Kopie beigefügt. Somit erhält der unbeteiligte Dritte NDNs, die mindestens genauso gross sind wie die ursprünglichen Nachrichten. Dadurch sind einfache «Denial of Service»(DoS)-Angriffe auf eine Mailbox denkbar: Verfügt das Kontingent einer Mailbox noch über 500 MB freien Speicherplatz, so kann man diese mit 50 Mails à 10 MB Grösse zum Überlaufen bringen – danach erhält dieser Benutzer erst einmal keine Nachrichten mehr, bis er sein Postfach bereinigt hat. Einige Mailserver versenden nicht nur eine Kopie der Originalnachricht im Anhang, sondern erstellen den NDN auch noch für jeden einzelnen nicht existenten Empfänger. Eine 10 MB grosse E-Mail mit 50 nicht existenten Empfängern führt somit zu 50 Non Delivery Notifications à 10 MB an den gefälschten Absender. Damit lässt sich erstens die Inbox, zweitens die Leitung des Opfers und drittens die Leitung des Backscatter kräftig auslasten.
Damit die eigene Mailinfrastruktur keine Backscatter-Mails versendet, sollte schon der erste MTA (der MX-Eintrag) die Existenz des Empfängers prüfen. Gibt es den Empfänger nicht, so wird die E-Mail abgewiesen. Dann obliegt es dem Mailsystem des Absenders, einen NDN zu generieren.
LDAP
Relativ einfach lassen sich gültige Empfänger mit einer LDAP-Abfrage auf das Benutzerverzeichnis (z.B. Active Directory) herausfinden. Dadurch kann der empfangende Mailserver prüfen, ob ein interner Adressat auch wirklich existiert.
Damit das LDAP-Passwort nicht im Klartext zwischen MTA in der DMZ und dem internen LAN übertragen wird, empfiehlt sich der Einsatz der TLS-verschlüsselten LDAPS-Variante.
Recipient Callout Verification
Viele MTAs unterstützen die Überprüfung des Empfängers durch die sogenannte Recipient Callout Verification. Der Mail Transfer Agent baut dazu eine SMTP-Verbindung zum nächsten Mailserver in der Kette auf und prüft für jeden Empfänger der E-Mail, ob dieser beim «RCPT TO:»-Befehl akzeptiert wird. Je nach Implementation merkt sich ein MTA gültige und ungültige Adressen für eine bestimmte Zeit. So können Server auch ohne Verzeichnisdienst-Zugang Empfänger verifizieren
.
Recipient Callout Verification und Tar Pitting
Einige Mailserver nehmen Nachrichten für alle Empfänger entgegen, auch für ungültige. Die Recipient Callout Verification eines MTA vor einem so konfigurierten Server wäre somit nutzlos. Daher ist es wichtig, dass der nachfolgende Mailserver nur gültige E-Mail-Adressen annimmt, wenn Recipient Callout Verification zum Einsatz kommt.Allerdings sei hier auch gleich auf einen Nachteil dieser Einstellung hingewiesen: Lehnt ein Mailserver einen Empfänger ab, so ist sichergestellt, dass es den Empfänger nicht (mehr) gibt. Wird eine andere E-Mail-Adresse dann angenommen, so steht fest, dass es die entsprechende Mailbox und wohl auch einen zugehörigen Benutzer gibt. Diesen Mechanismus kann nun ein Spammer ausnutzen, um die gültigen E-Mail-Adressen eines Unternehmens herauszufinden: Mit einer Liste häufig vorkommender Namen wird geprüft, ob Nachrichten hierfür angenommen werden. Die gültigen Adressen haben für die Versender von Spam einen wesentlich höheren Wert als Adressen, bei denen die Gültigkeit nicht nachgewiesen ist. Gerade grössere Unternehmen sind aufgrund höherer Trefferwahrscheinlichkeit oft Ziel solcher Directory Harvest Attacks. Eine Schutzmassnahme gegen diese Angriffe ist das sogenannte Tar Pitting. Dabei werden alle SMTP-5xx-Antworten eines Servers stark verlangsamt ausgegeben: Ein «RCPT TO:» an eine nicht existente Adresse wird dann beispielsweise erst nach fünf Sekunden Wartezeit mit einer Fehlermeldung (SMTP Response Code 550) beantwortet. Durch die Wartezeit sinkt die Effizienz einer solchen At-
tacke drastisch.
Manuelle Listen
Natürlich kann man auch Listen gültiger E-Mail-Adressen manuell am ersten MTA hinterlegen, falls es Gründe gegen beide der bereits genannten Techniken gibt.
Transparent SMTP Proxy
Anders als ein Mail Transfer Agent speichert ein Transparent SMTP Proxy die E-Mails nicht in einer Warteschlange (Queue), sondern gibt jeden SMTP-Befehl an den nächsten Mailserver weiter. Daher verhält sich der Transparent SMTP Proxy so wie der Mailserver dahinter. Ist auf dem Mailserver Tar Pitting aktiviert, so verlangsamt auch der SMTP Proxy die Verbindung automatisch beim Auftreten von ungültigen Adressen.
Diese Techniken schützen unschuldige Dritte nicht vor allen Auto-Replies. Ist ein Benutzer in den Ferien, so verlaufen alle genannten Checks positiv. Der Absender, ob gefälscht oder nicht, erhält eine Abwesenheitsmeldung zurück. Glücklicherweise versenden die meisten Mailserver solche Auto-Replies nicht für jede einkommende Mail, sondern nur beim ersten Auftreten eines Absenders innerhalb von sieben Tagen.
...sollte man nach Möglichkeit so konfigurieren, dass diese Malware und Spam gar nicht erst entgegennehmen, sondern schon während der SMTP-Transaktion überprüfen und dann gegebenenfalls mit einem SMTP-Error vor Transaktionsende abweisen. Dadurch obliegt es dem sendenden Mailserver, für einen Unzustellbarkeitsbericht zu sorgen. Leider erlauben nicht alle Scanner diese Einstellung.
Weitere Techniken wie die Nutzung von Realtime Blackhole Lists, Sender Policy Framework und Domain Keys Identified Mail können generell helfen, das Aufkommen an Spam zu verringern und sorgen nebenbei für weniger NDNs.
Die bisher genannten Techniken schützen die eigene Infrastruktur vor E-Mails an nicht existente Benutzer und sind daher auch eine Vorkehrung gegen unerwünschte NDNs an unbeteiligte Dritte. Werden allerdings die eigenen Adressen von Spammern und E-Mail-Viren als Absender missbraucht, so erhalten mit hoher Wahrscheinlichkeit die eigenen Benutzer eine Vielzahl von Non Delivery Reports über Nachrichten, die sie niemals versendet haben.
BATV
Der sicherlich bekannteste Selbstschutz ist das sogenannte Bounce Address Tag Validation. Dabei wird der lokale Teil der «Reply To»-Adresse (z.B. vorname.nachname) einer E-Mail um einen bestimmten Wert erweitert (z.B. zu prvs=123456789A=vorname.nachname). Die Erweiterung wird mit Hilfe des BATV Secret und einer Zeitangabe errechnet. Wenn das Mailsystem des Empfängers dann z.B. aufgrund einer Unzustellbarkeit eine NDN generiert, so kann der eigene Mailserver anhand der Erweiterung der zurückkommenden Adresse der E-Mail prüfen, ob die ursprüngliche E-Mail wirklich vom eigenen Mailsystem versendet wurde. Fehlt der Tag oder ist dieser falsch, so verweigert der eigene Mailserver die Annahme der NDN. Der BATV Draft schlägt vor, die Erweiterung einmal pro Tag zu erneuern. Setzt die Gegenseite Greylisting ein, so kann es zu Problemen kommen, wenn die Greylisting-Implementierung die Erweiterung nicht als solche erkennt und somit jeden Tag eine neue Absenderadresse erkennt. Die erste E-Mail an einem Tag würde daher immer verzögert ausgeliefert. Des weiteren sei darauf hingewiesen, dass der lokale Teil einer E-Mail-Adresse laut RFC2821 nur maximal 64 Zeichen lang sein darf. Bei Verwendung von BATV verbleiben somit nur noch 48 Zeichen für den lokalen Teil.
Auch Anti-Spam-Systeme, die ein Challenge-Response-Verfahren verwenden, bereiten unter Umständen Probleme, wenn der Challenge auf «prvs=123456789A=vorname.nachname» anstelle auf vorname.nachname versendet wird.
Weitere Techniken
Die Betreiber von Mailinglisten können mit Variable Envelope Return Path (VERP) nicht mehr existente Teilnehmer automatisch ausfindig machen. Weniger verbreitet sind Domain Cryptographic Bounce Authentication (DCBA) und Signed Envelope Sender (SES). Die Mechanismen ähneln denen von BATV.
Produkte
LDAP Lookups bieten unter anderem folgende Produkte: Aladdin eSafe, Astaro Security Gateway, Astaro Mail Gateway, Clearswift E-Mail Appliance, Clearswift MIMEsweeper for SMTP, Sonicwall E-Mail Security (früher: Mailfrontier) und Websense E-Mail Security. Der Aladdin eSafe erkennt Backscatter mit einer proprietären Methode. Die anderen genannten Produkte unterstützen hierzu BATV.
Technologien wie BATV verhindern, von Backscatter-E-Mails getroffen zu werden. Wichtiger ist allerdings die Prüfung gültiger Empfänger, um nicht selbst auf eine Backscatter Blacklist zu gelangen. Es wird noch einige Jahre dauern, bis nahezu alle Mailsysteme im Internet ausreichend konfiguriert sind. Ähnlich war die Situation vor etwa 10 Jahren mit Open Relays: auch dort gab es lange Zeit schwarze Schafe trotz Blacklists. Der Einsatz aktueller E-Mail-Security-Produkte, die LDAP Lookups oder Recipient Callout Verification schützen und BATV beherrschen, ist daher dringend empfohlen.
- Der Microsoft-Artikel KB321051 beschreibt die Schritte, um LDAPS auf einem Domain Controller einzurichten.
- KB886208 aus der Microsoft Knowledge Base veranschaulicht, wie ein Exchange 2003 Server nur noch E-Mails an gültige Empfänger entgegennimmt.
- Der Microsoft SMTP Server 2003 SP1 unterstützt Tar Pitting. Die Konfiguration hierzu findet sich im Microsoft-Artikel KB842851.
