Kampf dem Backscatter

Transkript

1 ITMAGAZINE Kampf dem Backscatter 26. September Wessen Mailserver automatisch auf Spam antwortet, macht sich selbst zur Spamschleuder. Mit etwas Know-how kann man sich selber und andere vor Backscatter schützen. 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 -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 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 s 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. - Ungenügend konfigurierte Backup Mailserver (Backup MX): Prüft der erste MTA einer Domain die Existenz eines Benutzers, so wird er s an unbekannte Benutzer abweisen. Der Versender wird wahrscheinlich die Zustellung der an einen anderen Mailserver für die Domain versuchen. Wenn dieser MTA die Existenz des Empfängers dann nicht prüft, so wird er die wahrscheinlich annehmen. Erst bei einem der nächsten Schritte wird dann auffallen, dass es den Empfänger nicht gibt was im Normalfall zu einer NDN führt. Einige Provider bieten ihren Kunden einen Backup MX Service an: Bei Ausfall des primären Mailservers speichert der Provider die s zwischen. Ist der eigentliche Mailserver wieder verfügbar, stellt der Backup MX die Nachrichten zu. Werden dabei die Mails abgewiesen, so wird der Provider selbst zum Backscatter. Nimmt der primäre Mailserver alle Mails vom Backup MX entgegen, so muss er die Non-Delivery Reports versenden. - Schlecht konfigurierte Viren und Spamfilter: Noch vor wenigen Jahren war es üblich, den Absender einer virenverseuchten darüber in Kenntnis zu setzen. Kaum ein aktueller -Virus versendet sich selbst mit der Absenderadresse des PC-Besitzers. Meist nimmt ein solcher Virus zwei zufällige -Adressen aus dem lokalen Adressbuch des infizierten Rechners und versendet sich selbst an die erste Adresse unter Nutzung der zweiten als Absender. Informiert ein Virenscanner dann den Absender, so erhält ein wahrscheinlich unbeteiligter aus dem Adressbuch den Backscatter. - Challenge / Response (C/R) Spamfilter: Trifft eine mit einem gefälschten Absender auf einen C/R Spamfilter, so erhält Bob eine Aufforderung, den Challenge zu beantworten, ohne je eine versendet zu haben. - Auto Acks: Dazu gehören Benachrichtigungen über eine überfüllte Mailbox, einen nicht mehr existenten Mitarbeiter und auch Out of Office Replies. Daher empfiehlt das RFC 3834, eine solche Mitteilung nur einmal alle sieben Tage an den gleichen Absender zu übermitteln. Grafik: Entstehung von Backscatter- s

2 Das Problem sitzt tiefer 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 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 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. Techniken, um nicht zum Backscatter zu werden 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 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 , 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 -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 -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 -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

3 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 Attacke drastisch. Manuelle Listen Natürlich kann man auch Listen gültiger -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 s 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. Viren- und Spamfilter...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. Was kann man tun, um sich zu schützen? Die bisher genannten Techniken schützen die eigene Infrastruktur vor s 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 -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 um einen bestimmten Wert erweitert (z.b. zu prvs= a=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 prüfen, ob die ursprüngliche 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

4 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 an einem Tag würde daher immer verzögert ausgeliefert. Des weiteren sei darauf hingewiesen, dass der lokale Teil einer -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= a=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 Appliance, Clearswift MIMEsweeper for SMTP, Sonicwall Security (früher: Mailfrontier) und Websense Security. Der Aladdin esafe erkennt Backscatter mit einer proprietären Methode. Die anderen genannten Produkte unterstützen hierzu BATV. Fazit Technologien wie BATV verhindern, von Backscatter- s 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 -Security-Produkte, die LDAP Lookups oder Recipient Callout Verification schützen und BATV beherrschen, ist daher dringend empfohlen. Tipps für die Microsoft-Exchange- und Active-Directory-Umgebung - Der Microsoft-Artikel KB beschreibt die Schritte, um LDAPS auf einem Domain Controller einzurichten. - KB aus der Microsoft Knowledge Base veranschaulicht, wie ein Exchange 2003 Server nur noch s an gültige Empfänger entgegennimmt. - Der Microsoft SMTP Server 2003 SP1 unterstützt Tar Pitting. Die Konfiguration hierzu findet sich im Microsoft-Artikel KB Der Autor Thomas Kretzschmar ist Technical Account Manager bei Infinigate (Schweiz) AG. Copyright by Swiss IT Media 2016

5 Copyright by Swiss IT Media 2016