5.6.2009

Blacklists und wie man sich damit das Bein amputieren kann

Ich hatte Tobias Klausmann gebeten, einmal aufzuschreiben, wie sich das Problem mit Blacklists aus der Sicht eines System-Administrators darstellt. Das hat er dankenswerter Weise auch getan - in seinem Text finden sich zahlreiche Hinweise, die mir durchaus neu sind.

Von Tobias Klausmann

RBL (Realtime Blackhole Lists) gibt es schon eine ganze Weile, so wie es den ursprünglichen Beweggrund dafür auch schon länger gibt: Spam. Allerdings sind auch sie kein Allheilmittel (sonst gäbe es ja keinen Spam mehr). Ferner sind sie trefflich dazu geeignet, sich in den Fuss zu schiessen - und es unter Umständen noch nicht einmal zu merken.

Aber bevor ich erkläre, warum das so ist, beschreibe ich erst mal, wie die Dinger überhaupt funktionieren, denn dort liegen einige der Gründe begraben, warum man mit ihnen vorsichtig sein muss.

Das grundsätzlicher Szenario ist, dass irgend eine Software automatisiert entscheiden soll, ob ein bei ihr abgelieferter Happen Text Spam (oder im weitesten Sinne unerwünscht) ist oder nicht. Ob diese Software ein Mailserver oder eine Blogsoftware wie Wordpress ist, ist ziemlich egal. Die meiste Software ist in der Lage, einige primitive Checks selber zu machen, aber das ist rudimentär und macht die User und Admins nicht auf Dauer glücklich. Also kam die Idee auf, eine zentrale Stelle zu fragen, ob es sich nun um Spam handelt oder nicht. Dabei kann man nun noch zwischen zwei Sorten Daten unterscheiden: zum einen die, die der Absender nicht (leicht) fälschen kann (zum Beispiel die IP, mit der er die Daten anliefert) und jenen, die er sich aussuchen kann (also der Content). RBLs befassen sich praktisch immer mit den ersteren und hier de facto nur mit der IP. Es gibt auch Systeme (wie Razor), die nach dem Content gefragt werden können, aber die sollen hier nicht Gegenstand sein. Wir stellen also fest: eine RBL sagt mir im Allgemeinen nicht, ob das, was ich da habe, Spam ist. Vielmehr kann ich sie fragen, ob ein bestimmter Einlieferer (nicht der Mail-Absender, der ist trivial zu fälschen) "als Spammer bekannt" ist.

Der Mechanismus, mit dem die RBL abgefragt wird ist, im Allgemeinen DNS. Dieses Protokoll hat den Vorteil, dass es so gut wie immer durch Firewalls kommt und an den Endpunkten nur wenig Overhead bereitet. Normalerweise haben IPs im Internet eine sogenannte Rückwärtsauflösung, in DNS-Sprech einen PTR (Pointer to Record). Der ist vor allem für Menschen gedacht, die halt wissen wollen, was zum Beispiel 193.99.144.80 denn nun genau ist. Dafür delegiert zum Beispiel die europäische IP-Vergabestelle (RIPE) ein Netz an denjenigen der IPs braucht. Ferner sorgt das RIPE dafür, dass mein DNS-Server herausfinden kann, wen er nach Informationen zu 193.99.144.80 fragen soll. Aber ich kann natürlich auch irgendwen anderen nach 193.99.144.80 fragen, zum Beispiel einen Cache bei meinem Provider (das ist genaugenommen der Normalfall). Ebenso kann ich auf diesem Wege den Betreiber einer RBL fragen, ob 193.99.144.80 denn in der Vergangenheit unangenehm als Spammer aufgefallen ist. Dazu frage ich den RBL-Server nach dem PTR zu 193.99.144.80. Der kann mir dann sagen "Kenn ich nicht" (in DNS-Sprech NXDOMAIN), wenn das nicht der Fall ist oder mir eine Antwort geben wie spammer.example.com, wobei 'example.com' eine Domain ist, die dem RBL-Betreiber gehört. Einige RBLs geben dann verschiedene Antworten, je nachdem, was die IP böses getan hat (Spam verschicken, auf Abuse-Anfragen nicht reagieren und noch ein ganzer Stapel andere Dinge).

Was nun meine Software mit dieser Information anfängt, ist natürlich wieder meine eigene Sache. So kann man Mail während der Einlieferung direkt ablehnen, sie als Spam markieren, einen Spam-Score erhöhen oder einige andere Dinge. Die häufigste Massnahme ist die erste: man lehnt Content von der IP rundweg ab. Wenn man ein netter Admin ist, schreibt man in die Ablehnung auch hinein, warum man das tut.

Eine Frage die bleibt, ist: woher weiss denn ein RBL-Betreiber, wer ein Spammer ist und wer nicht? Das übliche Verfahren ist, dass User einfach Spammer melden können (i.A. über ein Webformular). Der RBL-Betreiber nimmt diese Meldung und überprüft, ob das stimmt (zum Beispiel, ob es eine antwortende Abuse-Abteilung gibt). Diese Überprüfung kann durchaus mit menschlichem Input passieren, was natürlich die üblichen Vor- und Nachteile hat. Ebenso kann jemand, der auf einer solchen Liste gelandet ist, den RBL-Betreiber anschreiben und erklären, dass das Problem gelöst ist. Der Betreiber wird dann im allgemeinen die IP überprüfen und entsprechend reagieren. Manche RBLs setzen den Status zunächst auf "Proband" und überprüfen einen Monat lang zu zufälligen Zeitpunkten, ob das Problem wirklich repariert ist. In extremen Fällen werden IPs auch "für immer" gesperrt, zum Beispiel bei ISPs, die damit werben, dass sie Spammern eine Heimat bieten (ja, die gibt es).

Bei dieser ganzen Betrachtung fällt auf, dass ich als jemand, der eine RBL benutzt, die Grundlage (bzw. das Finden derselben) einer Entscheidung delegiere. Ich vertraue darauf, dass der RBL-Betreiber das richtige (oder das was ich für richtig hielte) tut. Das hat neben dem üblichen Problem, dass auch Menschen Fehler machen, noch weitere Punkte, die man beachten muss. Zum einen muss ich mir Klaren darüber sein, was genau der RBL-Betreiber für Ansichten hat: was genau ist Spam? was ist Abuse? Es gibt ausserdem einige RBLs, die in Internet-Standards geforderte Aspekte von IPs und Domains abfragen. Ein gutes Beispiel ist, dass es bei jeder Domain, zu der es einen Mailserver gibt, der Account postmaster@ vorhanden sein und gelesen werden muss (bis hierhin ist das noch vielen Admins klar) - ausserdem muss auch Postmaster@ auf die selbe Art existieren. Es gibt eine ganze Reihe solcher Anforderungen, die zum Teil eher akademisch sind (die Funktionalität wird heute schlicht nicht mehr benutzt) oder deren Auslegung mehr als schwammig ist (mache argumentieren zum obigen Beispiel, dass auch pOstMAsteR@ und ähnliches existieren muss). Indem ich die Suche nach und Entscheidung über diese "Nickeligkeiten" abgebe, begebe ich mich (und meine User) in die Hand des RBL-Betreibers. Die Entscheidung, die darauf basiert, bleibt natürlich bei mir. Dennoch kann sich die Politik des RBL-Betreibers bezüglich eines Aspektes auch ändern, ohne dass er mir das mitteilt.

Ein weiteres Problem ist Gruppenstrafe. Da ISPs im Allgemeinen Pools von IPs für die Einwahl benutzen, ist es mit dem Anprangern einer IP nicht getan: bis die Übertretung gemeldet und überprüft ist, sitzt auf der IP längst ein anderer Nutzer und der Spammer lacht sich eins. Also werden von RBLs manchmal auch ganze Netze gesperrt. Das kann je nach ISP also ganz schnell ein paar tausend oder noch mehr User erwischen. Zeitweise waren alle Reseller-IPs der Telekom (gut 4 Millionen IPs) auf manchen RBLs gesperrt, weil sich die Telekom-Reseller nicht um Abuse gekümmert haben. Den Mist an der Backe haben natürlich die Endkunden. Der RBL-Betreiber hofft, dass der entstehende Druck seitens der Kunden den ISP (oder den Reseller oder wen auch immer) dazu zwingt, den Spammer rauszuwerfen. Leider gibt es auch ISPs, denen das alles egal ist, da seine Lieblingskunden (der doofe Einwahl-Michel) ja eh keine Dienste betreibt und Webmail benutzt, weswegen er gar nicht merkt, dass er auf einer RBL gelandet ist. Die Kunden des ISPs, die aber gerne Mails direkt versenden wollen, schauen in die Röhre, denn sie werden geflissentlich ignoriert. Hierbei darf man aber nicht vergessen, dass manche RBL-Betreiber ganz extreme Eiferer sind, die sofort einen ISP listen, wenn er etwas tut, was sie für eine Verletzung irgend einer angeblichen Regel ist. Und schon sind wir wieder beim Problem der delegierten Einschätzung eines Sachverhalts: klar will ich keine Mail von Systemen, wo ich niemals einen Admin oder Abuse erreichen kann - aber ist beschwerden@ nun ein Abuse-Kontakt oder nicht? Es gibt beispielsweise auch RBLs, die nur eine Aussage treffen, ob es sich bei einer IP um eine Einwahl-IP handelt. Viele Provider von grossen Mailsystemen (also mit User-Zahlen deutlich jenseits von einer Million) nehmen Mails von Einwahl-IPs nicht an, da auf diesem Weg zu viel gespammt wird. Was zunächst als Harsch erscheint, ist eigentlich pragmatisch: Einwahl-Nutzer können praktisch immer den Mailserver ihres ISPs zum Mailversand nutzen, oft authentisiert (via SMTP AUTH). Das führt dazu, dass der ganze Abuse-Fall beim Einwahlprovider bleibt und der grosse Email-Provider nichts damit am Hut hat. Vor allem, weil man einen echten MX im allgemeinen nicht auf einer dynamischen IP betreiben will. Mailclients wiederum brauchen oft ohnehin einen ausgehenden Mailserver. Schliesslich gibt es noch ein ganz besonders fieses Problem mit RBLs: sie werden manchmal auch dichtgemacht (zum Beispiel, weil dem Betreiber ganz konkret und en Detail Gewalt angedroht wird). Dann hat der Betreiber das Problem, dass er entweder zu allem "ist kein Spam" sagen kann, zu allem "das ist Spam" oder er reagiert gar nicht mehr (was etwa dem ersten Teil entspricht). Da einfaches Abschalten den Nutzern der RBL nichts mitteilt (es gibt auf einmal keinen Spam mehr), stellen RBL-Betreiber in solchen Fällen ihr System für einige Zeit (Monate) auf "alles ist Spam" und hoffen, dass die Admins der nutzenden Systeme es so schneller merken. Nur dumm, wenn der Admin gar nicht existiert und so eine Firma eine Woche lang keinerlei Mails mehr empfangen kann.

Letztendlich gibt es bei all den RBLs und verwandten Systemen zwei Punkte, auf die man achten sollte. Zum ersten sollte man jede neu konfigurierte RBL sehr genau im Auge behalten. Das heisst, dass man sie zunächst nur als Markierungshilfe benutzen sollte - Mails gehen dann in einen Ordner und man sieht, was die RBL als "böse" qualifiziert und wie oft sie daneben liegt (in beide Richtungen: eine RBL, die böses niemals erkennt ist fast genauso wertlos wie eine, die alles als böse markiert). Zum zweiten sollte man nur die ganz krassen Fälle (zum Beispiel Absenderdomains, die gar nicht existieren) direkt und ohne menschliche Interaktion verwerfen. Alles andere kann man prima mit Scoring-Regeln versehen und je nach erhaltenem Score dann in Eimern sammeln, die man mehr oder minder oft kontrolliert. Das hat auch den Vorteil, dass man RBLs kombinieren kann: keine der RBLs kann einer Domain den "Todesstoss versetzen", aber wenn vier von fünfen die Gegenstelle als Spammer gelistet haben, könnte etwas dran sein.

(Kommentarfunktion z.Zt. deaktiviert.)