Darf ich vorstellen: Backscatter
Letzte Woche traf mich eine riesige Flut an Backscatter Mails und spammte meine Mailbox zu. Tausende Emails von diversen MAILER-DAEMONs, Spam- und Virenscannern durfte ich aus meinem Postfach löschen.
Solche Rückläufer entstehen häufig durch fehlerhaft konfigurierte Mailserver, die eine Unzustellbarkeitsnachricht an den vermeintlichen – natürlich gefälschten – Absender der Spammail schicken, falls der Empfänger auf dem Zielsystem nicht existiert. Das richtige Verhalten besteht darin, die Mail bereits im SMTP Dialog abzuweisen und somit gar nicht erst in die Mailqueue aufzunehmen. Mit Postfix stehen u.a. folgende Möglichkeiten zur Verfügung, um nicht selbst zur Backscatter-Schleuder zu werden:
reject_unverified_recipient
Der verify Daemon überprüft, ob der Empfänger auf dem eigenen System existiert. Dafür muss auf dem Zielsystem VRFY erlaubt sein und nicht die Option disable_vrfy_command gesetzt sein. Doch Obacht: Spammer nutzen gerne VRFY, um echte Email Adressen zu finden. Der Zielhost sollte also nach Möglichkeit nicht öffentlich erreichbar sein und selbstverständlich auf Empfänger prüfen.
Kleiner Nachteil dieser Methode: Ist der Zielhost down, werden Emails generell abgelehnt und nicht in der Mailqueue aufgenommen. Der richtige Ort für diese Option findet sich bei den smtpd_recipient_restrictions.
reject_unlisted_recipient
Mit dieser Option wird die Email nur angenommen, wenn der Empfänger in einer der hier genannten Postfix Maps gelistet ist. Diese Lösung ist performanter als die vorherige, da hier nicht mehrere Systeme angefragt werden müssen. Entweder setzt man die Option bei den smtpd_recipient_restrictions oder als einzelnen Parameter mit smtpd_reject_unlisted_recipient.
Backscatter hat sich zunehmend als Problem herausgestellt, für das es auf Seite der gefälschten Absender kaum praxistaugliche Möglichkeiten zur Gegenwehr gibt. Unzustellbarkeitsnachrichten sind Teil des SMTP RFC und es ist keine gute Idee, solche Bounce Messages generell zu löschen bzw. herauszufiltern. Dennoch sollte man alles versuchen selber unnötige DSN und NDN Nachrichten zu vermeiden.
Links:
Postfix smtpd_recipient_restrictions
Postfix Address Verification README
Torsten
Hallo Matthias,
kamen die ganzen Backscatter Mails “rein zufällig” über eine IP der Telecom Italia? Würde mich jetzt nur einmal so interessieren. Bei mir war innerhalb von fünf Minuten die Mailbox recht gut gefüllt.
Grüße
- Torsten
matthias
Die IP des Übeltäters kann man leider nicht immer sehen, da manche Mailserver diese nicht mit in ihrer Bounce Message angeben. Aber bei mir war es meistens so, dass es viele verschiedene IPs sind, so dass man auch nicht einen body_check machen kann, in der Mails mit dieser IP als Inhalt zurückgewiesen werden. Handelt sich also häufig um ganze Botnetze, die nahezu zeitgleich ihre Absender neu fälschen.
Oliver
Mir ist das auch seit letzter Woche verstärkt aufgefallen. Gibt es nicht eine Möglichkeit zu schecken, ob überhaupt jemals eine Mail losgeschickt worden ist und erst dann diese “Backscatter” anzunehmen. Dazu müsste man natürlich die Rückläufer zweifelsfrei erkennen, was aber schon sehr schwierig ist.
matthias
Interessanter Ansatz. Andere Möglichkeit wäre ein intelligenter Filter, der die Bounce Message nach einer IP der möglichen SMTP Server (=eigener Postausgangsserver) prüft. Die wird ja meistens mit übergeben vom Mailserver, der die Bounce Message verschickt. Wenn dort nicht eine eingetragene IP steht, wurde die ursprüngliche Mail auch nicht vom eigenen Mailsystem verschickt und muss Backscatter sein.
jd
ich mag das exim system batv bzw prvs ziemlich gut leiden … das schützt einen genau vor solchen dingen ^^
geht auch gut in multiserver umgebungen … und in multiuser umgebungen kann auch noch jeder nutzer sich aussuchen ob er das machen will oder nicht … oder man schaltet es global für alle ein…
Oliver
Eine ähnliche Idee hatte ich auch schon. Sowas lässt sich bestimmt auch mit postfix umsetzen. Mal suchen.
matthias
@jd
Ganz guter Tipp – müsste es doch auch in ähnlicher Form für Postfix geben. Backscatter gibts ja nun nicht erst seit gestern, so dass da unzählige (Postfix) Mailserver von betroffen sein sollten…
@Oliver
Wenn du was gefunden hast, bitte melden
Oliver
Man findet doch recht schnell was. Hat mich ein wenig erstaunt. Aber so massiv hatte ich dieses Problem noch nicht wahrgenommen:
Hier mal was ich auf die Schnelle gefunden habe:
eine Anleitung für BATV mit Postfix: http://babel.de/batv.html
und hier auch noch ein Blackliste extra für Backscatter: http://www.backscatterer.org/?target=backscatter
matthias
Die BATV Geschichte klingt wirklich gut. Das muss ich mal testen.
Die Blackliste kann jedoch gefährlich sein – es gibt zu viele falsch konfigurierte Mailserver, mit denen man kommunizieren muss.
Danke jedenfalls für die Links
jd
backscatter.org wird von uceprotect betrieben die sich im letzten jahr nicht gerade mit rum bekleckert haben …
auch wenn es einen owner wechsel gegeben hat, werden da z.B. auch systeme aufgenommen die einen callout machen, welcher (je nach einstellung) nicht wirklich schadhaft ist und richtig konfiguriert sogar für weniger spam sorgen kann, gerade wenn es um weiterleitungen geht.
matthias
Ok, das erklärt einiges. UCEPROTECT ist wirklich der letzte Schei*.
Oliver
Ja, sorry, diese Blackliste sollte man wohl eher nicht einsetzen.
Frank
ich kann das setzte und auswerten von SPF einträgen empfehlen. Damit wird man den Backscatter Schrott wunderbar los
matthias
Problem an SPF:
So zeigen Studien, dass ein großer Teil der existierenden Domains mit SPF-Record Spammern gehören.
Quelle
Claus von Wolfhausen
Was bitte soll an den UCEPROTECT-Listen schlecht sein?
Die unabhängigen Statistiken des international bekannten Anti-Spam Experten Al Iverson aus Chicago zeigen jedenfalls etwas ganz anderes:
Und jetzt vergleicht das gegen die anderen bekannten Blacklisten.
Was lernen wir daraus?
Man sollte Blacklisten zunächts selbser (z.B. im Scoring) testen, bevor man sich von anderen Unsinn erzählen läßt und ihn auch noch glaubt.
Im übrigen ist ips.backscatterer.org nicht zum blocken aller Mails vorgesehen, steht aber auch auf der Website.
Wer sie mit garantiert 0% False positives benutzen will, verwendet sie wie empfohlen im “Safe-Mode”, das bedeutet, man fragt sie nur dann ab, wenn des Envelope From ein NULL SENDER ist.
Wie konfiguriert man Safe-Mode mit Postfix?
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_sender_access dbm:/etc/postfix/check_bounce_sender
...
/etc/postfix/check_bounce_sender:
...
<> reject_rbl_client ips.backscatterer.org
...
So wie von uns empfohlen kann jedenfalls keine Mail abgewiesen werden sondern es werden ausschließlich Bounces und Sender Callouts von auffälligen Systemen fehlschlagen.
Das Projekt UCEPROTECT kann jedenfalls nichts dafür, wenn jemand die Backscatterer Liste wie eine reguläre DNSBL einbindet und damit tonnenweise reguläre Mails abweist.
Warum?
Systeme die Backscattern oder Sender Callouts machen sind eben keine Zombies sondern in aller Regel richtige Mailserver.
@jd und @matthias:
Wenn sich Johann nicht mit Ruhm bekleckert hat ist das sein Problem.
Er wurde gefeuert und ich bin seit Juni 2007 verantwortlich für das Projekt.
In Sachen callouts möchte ich anmerken daß Ihr vielleicht nur deshalb so eine blauäugige Meinung davon habt, weil Ihr selbst nur ein paar kleine Hobbyserver betreut und daher in winzigen Dimensionen denkt.
Wärt Ihr verantwortlich für den Mailverkehr im Hause Microsoft würdet Ihr vermutlich etwas anders darüber denken.
Was glaubt Ihr eigentlich wie viele “Callouts” täglich gegen Domains wie etwa hotmail.com aufschlagen?
Das Problem ist nicht der eine Callout den DEIN System veranstaltet, wenn ein Spammer mal wieder ne hotmail adresse gefälscht hat, das Problem ist daß es genug andere auch so machen was dann eben schon eine Connectionflut auslöst,
die einen Server wie DU ihn zuhause hast, für Stunden bis Tage vom normalen Mailverkehr ausschließen würde.
Nicht weil es viel Traffic kosten würde, sondern weil es Dir wenn sich genügend Sender Callout Abuser an Deinem System versuchen für geraume Zeit alle Deine freien TCP-Sockets belegen würde.
Spätestens wenn Dir das einmal passiert findest Du Callouts nicht mehr lustig.
matthias
Dein Link ist nicht ganz mitgekommen:
http://stats.dnsbl.com/uceany.html
Hobbyserver betreut hier niemand, wenn auch sicher nicht in den Dimensionen von Hotmail und Co. Auch wenn AOL,Earthlink,Microsoft,Yahoo! als “Gründungsmitglieder” genannt werden, konnte ich auf die Schnelle keine verlässliche Quelle finden, die deren Nutzung von UCEPROTECT bestätigt. Darf man fragen, wer sonst noch so UCEPROTECT einsetzt?
Aber wie kommt es, dass es nirgends etwas Positives über UCEPROTECT zu lesen gibt? In Mailinglisten wurde schon häufig von Leuten, die es eigentlich wissen sollten, vor UCEPROTECT gewarnt.
Deine vorgeschlagene Maßnahme ausschließlich Emails mit NULL SENDER gegen die Backscatter Blacklist zu prüfen, klingt erst einmal sinnvoll. Ich werde das mal auf einem Testserver einsetzen und die Trefferquote beobachten.
Claus von Wolfhausen
@matthias
Danke für das Einfügen des Links.
Zur Frage wer UCEPROTECT einsetzt:
UCEPROTECT (Software und Appliances) zum Großteil Städte und Landratsämter in Bayern.
UCEPROTECT-Network (Die Blocklists) hat Anwender quer durch alle Schichten.
Es ist wirklich schwer Dir eine präzise Auskunft zu geben, weil wirklich vom kleinen Hobbysystem bis zu großen Providern alles dabei ist.
Zur Frage warum oft vor UCEPROTECT gewarnt wird:
Warnungen vor UCEPROTECT sprechen zum einen Leute aus, die unter Johnann’s Leitung die Listen probiert haben, damals waren FALSE Positive Raten von bis zu 8% offenbar keine Seltenheit. Dieses und einige andere Dinge waren letztendlich auch die Ursache dafür, daß er im Juni 2007 gekündigt wurde.
Leute die heute noch Warnungen vor UCEPROTECT aussprechen haben dafür zumeist “niedrige Beweggründe” oder sie wissen es einfach nicht besser.
Häufig stellt sich folgendes heraus:
1. Sie arbeiten bei einem im Level 3 gelisteten Provider.
Leider glauben auch heute noch viele Provider nicht dafür verantwortlich zu sein, was ihre User so anstellen und verteidgen die Mißstände in ihren Netzen wie Besitzstände anstatt sie einfach zu beseitigen.
2. Sie sind Kunde bei einem im Level 3 gelisteten Provider und haben noch immer nicht verstanden, daß man im Regelfall immer bekommt, wofür man bezahlt.
Wer bei der Wahl seines Providers eben nur auf “billig” schaut, darf sich nicht wundern, wenn dieser Provider kein funktionierendes Abuse Department hat und
gelistet wird, wenn der Abuse aus seinen Netzen Ausmaße annimmt die für Andere schlichtweg nicht akzeptabel sind.
3. Sie sind DAUs, die wenn sie Spam bekommen mal eben bei DNSSTUFF oder ähnlichen Services die betreffende IP reinwerfen und schauen welche Liste das geblockt hätte. Anschließend wird die betroffene Liste häufig scharf geschaltet, ohne die Policy gelesen, geschweige denn verstanden zu haben.
Wenn dann erwartungsgemäß etwas schief geht ist natürlich grundsätzlich die Liste schuld, die ja so viele “false positives” macht.
4. Sie haben vor Jahren mal die UCEPROTECT-Listen genutzt, schlechte Erfahrungen gemacht und noch nicht realisiert, daß UCEPROTECT mittlerweile neben SPAMHAUS und SPAMCOP zu dem besten gehört, was an Blacklisten verfügbar ist.
5. Sie sind Hersteller einer anderen Spamschutzlösung und bekommen bei dem Gedanken, daß (durch den Druck den Listen wie unser Level 3 auf Provider ausüben) irgendwann alle Provider Port 25 blocken könnten zurecht sowas wie Existenzängste.
Ich empfehle daher auch grundsätzlich jedem der (egal welche) Blacklisten einsetzen will, diese zunächst nur zum Scoren einzusetzen, und dann anhand der Logs die Performance auf dem eigenen Mailsystem auszuwerten.
Erst wenn ein solcher Test vernünftige Blockraten gegen Spam und akzeptabel niedrige False Positives ergibt würde ich eine Blackliste zum blocken einsetzen.
Warum?
Jeder Mailflow ist anders. Was beim einen funktioniert und sich bewährt kann bei einem anderen zu einem Supergau führen.
Beispiel:
ZEN.SPAMHAUS.ORG ist eine Liste die man in Westeuropa und den USA fast bedenkenlos zum Blocken einsetzen kann außer (und das wissen die wenigsten) man benötigt Mail auch aus China, Japan oder Korea.
Dann nämlich wird man erstaunt feststellen, daß auch SPAMHAUS beachtlich viele False Positives erzeugen kann.
Eine Kombination der UCEPROTECT-Levels 1 und 2 in Verbindung mit der CBL wäre in diesem Scenario wesentlich geigneter.
Selbiges gilt auch für einige ehemalige Ostblockländer.
Absolut ungeeignet ist UCEPROTECT-Level 3 z.B. wenn man Mails aus Italien, Polen, der Türkei oder Südamerika braucht, weil dort eben die großen nationalen Carrier wegen ihres übvermäßigen Abuse Aufkommens zumeist flächendeckend geerdet sind.
Dagegen ist eine Kombination aller 3 UCEPROTECT Levels offensichtlich sehr geeignet, wenn man (wie Al Iverson) in den USA sitzt und vorwiegend Mail von inländischen Servern benötigt.
Deshalb mein Statement: Erst lesen, dann testen und erst dann blocken.
Stefan
Oha, hatte ich ja garnicht gesehen!
Uns erstmal als Hobbyserverbetreiber runterzustufen ist ja ganz nett arrogant.
Das hier ist übrigens adminlife.net, nicht das Küchenserverblog…
Ich persönlich werde UCEPROTECT schon wegen des 7-Tage Limits und des vorher-nur-gegen-Geld-Entsperrens (das sich Spammer übrigens eigentlich locker leisten können) niemals einsetzen und jedem davon abraten…
Als weißer Ritter des Internets aufzutreten mag ja für einen selbst toll sein, zeugt aber auch von gewisser Ignoranz und dem Willen, Kollateralschäden zu akzeptieren (was anderes ist das “Erden” von großen, nationalen Carrieren ja nicht). Das ist inakzeptabel, von Mailservern wird nunmal erwartet, dass sie wie erwartet funktionieren. Erklär’ mal Kunde xy aus Asien, dass er seine Mail in 7 Tagen nochmal schicken soll, er bezahlen soll wenn sie schneller da sein soll, dass sie vielleicht nie ankommen wird, oder dass du ihn erst Whitelisten mußt – dann kommt nämlich “Oh, das hatten wir ja bisher noch NIE!” und wirkt ja TOTAL SUPER – vor allem bei Neukundenkontakt.
Klar muss man gucken was für Policies die Listen haben (grade darum setze ich UCEPROTECT nicht ein) und sollte Scoren statt hart zu blocken, aber naja, jeder muss halt selbst wissen, wieviel Mail er verlieren möchte…
BTW: M$ sollte vielleicht auch ausgehende Mails mehr überprüfen, dann würden sie auch weniger Backscatter bekommen.
Daniel
Solange mit dem Austragen von IPs von UCEPROTECT Geld verlangt wird (meiner Meinung nach ein modernes Raubrittertun) werden wir solche Listen nicht verwenden!
Claus von Wolfhausen
Um es freundlich zu formulieren: Wer lesen kann ist klar im Vorteil.
UCEPROTECT verlangt gar nichts. Wer etwas Gegenteiliges behauptet, der lügt schlichtweg.
1. Wir zwingen niemanden dazu die Backscatterer und die UCEPROTECT-Listen einzusetzen.
2. Wir zwingen niemanden dazu, Backscatter an unsere Server zu versenden oder unsere Server mit Verify Callouts zu mißbrauchen.
3. Wir zwingen niemanden dazu, Mails an unsere Spamtraps zu schicken.
4. Wir zwingen auch niemanden, seinen Internetzugang beim billigsten Provider ohne jegliche Präventivmaßnahmen gegen Spammer zu bestellen.
Das bedeutet nichts anderes, als daß wirklich jeder, der bei uns gelistet wird selber daran schuld ist.
Auf unseren Servern gelten eben unsere Regeln. Wer glaubt, dagegen verstoßen zu müssen, ist schlichtweg selber schuld.
Wir zwingen auch niemanden eine Gebühr für das Austragen zu bezahlen, ganz im Gegenteil.
Der Regelfall ist, daß gelistete IP’s automatisch verfallen, das macht ein Cronjob…
Wer darüber hinaus eine optionale Dienstleistung, sprich das manuelle sofortige Entlisten seiner IP erwartet, der muß halt auch bereit sein, diese Sonderleistung zu bezahlen.
In erster Linie generieren wir unsere Listen für unsere kommerziellen Kunden und uns selber, darüber hinaus veröffentlichen sie, um der Internet community eine kostenlose Hilfe gegen Spammer und sonstige Abuser anzubieten.
Es ist uns daher egal ob uns Leute wie Daniel einsetzen oder nicht.
Die Tatsache, daß in allen möglichen Blogs und Foren über uns gejammert wird beweist jedenfalls, daß genügend Leute mit unseren Regeln einverstanden sind und uns wahrscheinlich gerade deshalb einsetzen.
Das Projekt betreibt 165 Trapserver. Setzt man dies ins Verhältnis zu allen in Benutzung befindlichen IPv4 IP’s, dann hat man statistisch gesehen eine deutlich höhere Chance den Jackpot im Lotto abzuräumen, als von uns beim Spammen erwischt zu werden, solange man nicht extreme Mengen an Spam versendet.
Wenn man ein System 2 oder 3 Tage nicht spammen sieht, bedeutet dies noch gar nichts, es könnte durchaus sein, daß das System immer noch munter spammt, und lediglich unsere Traps verfehlt.
Wer also glaubt, daß z.B. 24 Stunden ohne festellbaren Abuse genug sind, um gelistete Systeme automatisch zu entfernen, der möge sich einfach mal die Histories von Listings und Entlistungen bei Spamcop oder PSBL ansehen, die teilweise ausgedruckt mehrere Seiten lang sind.
7 Tage sind auch noch kein Beweis, aber immerhin ein möglicher Hinweis darauf, daß ein gelistetes System aufgehört haben könnte, Spam zu versenden.
Dies ist der Grund für die 7 Tage Dauer bei automatischen Delistings.
Eine Option sich kostenlos selbst austragen zu können wie etwa bei der PSBL führt dazu, daß Spammer Austragungsbots schreiben oder gar Personen in Dritte Welt Ländern damit beauftragen, ständig deren Spambots auszutragen.
Wir betreiben exclusiv für die Listen eine 24/7 Hotline, was nicht unerhebliche Personalkosten nach sich zieht. Diese Kosten legen wir nach dem Verursacherprinzip auf die Sofortentfernungen um, mehr nicht.
Ja wir würden die Sofortentfernung auch gerne kostenlos anbieten, allerdings scheitert dies dann immer daran, daß Leute wie Daniel dann doch nicht bereit wären 24/7 kostenlos bei uns von Hand Listees auszutragen, um sie 5 Minuten später dann wieder spammen zu sehen …
Wer also hier von Raubrittertum spricht, sollte erstmal seine rosarote Brille abnehmen.
Daniels Freund :D
…und der Herr Raubritterverteidiger sollte seine Raubrittertätigkeiten vielleicht auch weniger rosa darstellen.
UCEProtect ist und bleibt Schrott.
Claus von Wolfhausen
Na das ist mir zu allgemein.
Daniels Freund (Traut sich Daniel jetzt nimmer selber zu schreiben?) sollte für so eine Behauptung schon Fakten auf den Tisch legen.
Also was ist an UCEPROTECT schrottig? – Und jetzt echte Fakten und kein zusammefantasierter Nonsense…
matthias
Da sich die Kommentare immer mehr vom eigentlichen Thema des Beitrages entfernen, deaktiviere ich ab sofort die Kommentarfunktion für diesen Beitrag.