Open Source im professionellen Einsatz

© pixelquelle.de

Perl-Skript bewahrt Webforen und Blogs vor Spamflut

Schädlingsbekämpfung

Spammer senden nicht nur E-Mails, sie nisten sich auch in Diskussionsforen und Blogs ein, um mit Link-reichen Pseudopostings die großen Suchmaschinen hinters Licht zu führen. Ein Perl-Skript macht sauber.

Mein kleines Diskussionsforum auf [usarundbrief.com] wird immer häufiger von Link-Spammern heimgesucht. Diese Parasiten des Internet setzen ihre Bots gezielt auf bekannte Forumsoftware wie PHP-BB (Abbildung 1) oder Blog-Applikationen wie Wordpress an, um sie mit Beiträgen zuzumüllen, die fast nur Links zu Poker- und Sexseiten enthalten. So versuchen sie zweierlei: Diskussionsteilnehmer zu animieren, auf die Webseiten ihrer Auftraggeber zu klicken und zudem die großen Suchmaschinen hinters Licht zu führen, die die Relevanz einer Seite anhand der auf sie zeigenden Links berechnen.

Abbildung 1: Ein Spammer hat sich ins Forum des Perlmeisters geschlichen und überflutet es mit seinen zweifelhaften Angeboten.

Abbildung 1: Ein Spammer hat sich ins Forum des Perlmeisters geschlichen und überflutet es mit seinen zweifelhaften Angeboten.

Sand im Spambot-Getriebe

Der so genannte Comment Spam [2] lässt sich eindämmen, wenn nur registrierte User posten dürfen. Doch diese Hürde schreckt auch legitime Nutzer ab, die Datenschutz-Bedenken haben. Wird jedes Posting zuerst von einem Moderator gecheckt, bevor es auf der Website erscheint, bleiben zwar die Spammer draußen, aber das Prüfen kostet viel Mühe und verursacht diskussionslähmende Verzögerungen.

So genannte Captchas ("Tippen Sie diese Nummer ab") sollen sicherstellen, dass am anderen Ende der Leitung tatsächlich ein Mensch und kein Computer sitzt. Sie müssen gar nicht mal so schwer zu knacken sein wie die der großen Registrierungs-Sites. Ein verblüffend einfaches Beispiel zeigt Jeremy Zawodnys Blog, auf dem der User einfach »Jeremy« in ein zusätzliches Feld eintragen muss. Die meisten Bots scheitern daran, weil sie sich auf den Massenmarkt konzentrieren und nicht auf seltene individuelle Anpassungen eingehen.

Auch verstehen manche Bots die Interaktionen zwischen Javascript und dem Document Object Model (DOM) des Browsers nur unvollständig, sodass sie zuweilen bereits eine triviale lokale Anpassung der Forumsoftware, zum Beispiel mit etwas verschleierndem Javascript, zum Aufgeben zwingt.

Die Abbildungen 2 und 3 zeigen eine einfache Erweiterung von PHP-BB, die einen Schalter einfügt, der den Poster zunächst als Spammer klassifiziert. Ein Spam-Bot wird den Schalter einfach ignorieren oder den eingestellten Defaultwert übernehmen, was ihn entlarvt. Falls ein menschlicher User den zusätzlichen Button übersieht, teilt ihm eine freundliche Fehlermeldung (Abbildung 3) mit, dass auf der vorhergehenden Seite noch ein Knopf umzustellen ist, damit das Posting durchgeht.

Abbildung 2: Ein neuer Schalter legt die automatischen Bots der Spammer aufs Kreuz. Bleibt die Option »Spammer« angekreuzt, ist der Bot enttarnt.

Abbildung 2: Ein neuer Schalter legt die automatischen Bots der Spammer aufs Kreuz. Bleibt die Option »Spammer« angekreuzt, ist der Bot enttarnt.

Abbildung 3: Sollte der Anwender vergessen, von »Spammer« auf »User« umzustellen, macht ihn diese Fehlermeldung darauf aufmerksam.

Abbildung 3: Sollte der Anwender vergessen, von »Spammer« auf »User« umzustellen, macht ihn diese Fehlermeldung darauf aufmerksam.

Ein weiterer Ansatzpunkt, Comment-Spam zu erkennen, ist die Nachricht selbst. Steht dort nur wenig Text vielen Links gegenüber, handelt es sich mit hoher Wahrscheinlichkeit um Spam. Ein Problem stellen freilich die Fehler zweiter Art (falsche Positive) dar, zu denen es kommt, wenn eine als Spam eingestufte Nachricht tatsächlich von einem legitimen Benutzer stammt. Wandern solche Nachrichten unprüft in die Mülltonne, verärgert das die User, die dann zu anderen Foren abwandern.

Post für Entscheider

Hält sich der Forumsverkehr in Grenzen, eignet sich die im Folgenden vorgestellte Moderation per E-Mail zur Spam-Eindämmung. Das per Cronjob gestartete Skript »posting-watcher« fragt auf dem Forumsrechner regelmäßig die MySQL-Datenbank des Forumsystems PHP-BB ab, entdeckt noch nicht gesichtete Einträge in der Tabelle »PHP-BB_posts« und speichert deren IDs zusammen mit einem generierten Zufallsschlüssel in einem lokalen Cache auf der Platte ab. Es schickt anschließend eine E-Mail zum Moderator (Abbildung 4), die die wichtigsten Daten des Postings enthält.

Abbildung 4: Anhand dieser E-Mail kann der Forumverwalter entscheiden, ob er das Posting behalten oder löschen will.

Abbildung 4: Anhand dieser E-Mail kann der Forumverwalter entscheiden, ob er das Posting behalten oder löschen will.

Mails mit legitimen Postings ignoriert der Moderator einfach. Falls er ein Posting hingegen als Spam klassifiziert, betätigt er kurzerhand die Reply-Funktion des Mailclients und schickt die Mail zurück zum ursprünglichen Skript. Das greift sich den in der Mail gespeicherten Zufallsschlüssel, ermittelt über den File-Cache das zugehörige Posting in der Datenbank und setzt einen Scraper an, um es über die Webschnittstelle der Forumsoftware zu löschen.

Anschließend schickt das Skript eine Bestätigung zurück an den Moderator. In Abbildung 6 ist der gesamte Ablauf skizziert. Nach diesem Verfahren stellt PHP-BB alle Postings (also einschließlich Spam) zunächst einmal dar, danach löscht der Moderator aber ohne großen Aufwand den Spam. Da die Moderation über eine Schnittstelle läuft, die viele Bulletin-Board-Betreiber sowieso dauernd nutzen (E-Mail), hält sich der Zusatzaufwand bei geringer Forumsaktivität in Grenzen.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook