seeseekey.net - Invictus Deus Ex Machina

Ab und an habe ich in diesem Blog Probleme mit Spam welcher nur einige Zeichen kurz ist. Diesem Problem wollte ich durch Mindestlänge für Kommentare unter WordPress lösen. Das hilft dann nicht nur gegen Spam, sondern kurbelt auch ein wenig die Kommentarkultur an (so die wage Hoffnung).

Die Einstellungen von Yoast Comment Hacks

Die Einstellungen von Yoast Comment Hacks

Da WordPress von Haus aus die Einstellung einer Mindestlänge für Kommentare nicht zulässt, bediene ich mich des Plugins Yoast Comment Hacks.

Preis: Kostenlos

In den Einstellungen des Plugins kann nach der Installation des Plugins unter anderem eine Mindestlänge für Kommentare eingestellt werden. Daneben unterstützt das Plugin noch ein Reihe von anderen Funktionen welche sich auf das Handling von Kommentaren beziehen.

Wenn man Artikel in einer MediaWiki löscht, so werden diese Artikel und deren Historie weiterhin vorgehalten. Problematisch wird dies wenn man z.B. eine größere Menge an Artikeln entfernt hat. So etwas kann unter anderem im Rahmen der Spam-Bekämpfung vorkommen. Im maintenance-Ordner der MediaWiki-Installation gibt es für solche Zwecke das Skript deleteArchivedRevisions.php. Wird dieses auf der Konsole ausgeführt:

php deleteArchivedRevisions.php --delete

wird die Datenbank um historische Einträge bereinigt. Die Historie von nicht gelöschten Artikeln wird dabei beibehalten, so das wirklich nur der unnötige Ballast entfernt wird.

Eine meiner MediaWikis welche ich betreibe wurde in den letzten Tagen zugespamt. So wurden mehrere zehntausend Seiten und Nutzer angelegt. Diese von Hand zu entfernen wäre ein sehr zeit- und nervenraubendes Unterfangen. Mit der Erweiterung BlockAndNuke, kann man diesen Vorgang beschleunigen.

BlockAndNuke listet die Spammer auf

BlockAndNuke listet die Spammer auf

Nach der Installation stellt die Erweiterung eine Spezialseite zur Verfügung. Dort sind die Nutzer aufgelistet, welche entfernt werden sollen. Bei der Entfernung werden auch die jeweiligen Beiträge des Nutzers entfernt. Problematisch wird das ganze bei mehreren tausend oder zehntausend Nutzern und Beiträgen. Dafür gibt es im Ordner BlockAndNuke die Kommandozeilenvariante mit dem Namen ban.php. Mittels:

php ban.php --hammer

kann der Vorgang auf der Kommandozeile ausgeführt werden. Dabei wird whitelist.txt Datei berücksichtigt in welcher sich die Nutzer befinden sollten welche nicht zu den Spammern zählen. Je nach Anzahl der löschenden Nutzer und Beiträge kann der Vorgang einige Zeit in Anspruch nehmen.

Manchmal kommt es vor das ein Server welchen man betreut oder betreibt auf einer DNS-based Blackhole List landet. In einem solchen Fall gilt es zu überprüfen ob man nur auf einer oder zwei dieser Listen steht, oder ob man global aufgeführt ist.

Der Dienst am Beispiel von seeseekey.net

Der Dienst am Beispiel von seeseekey.net

Mit dem Dienst MultiRBL welcher unter multirbl.valli.org/lookup/ zu finden ist, lässt sich schnell herausfinden auf welchen Listen der entsprechende Server aufgeführt ist – was der erste Schritt ist um das Problem einzugrenzen und abzustellen.

Spam in den WordPress-Kommentraren ist immer wieder ein Problem mit welchem man konfrontiert wird. Doch mittlerweile gibt es “die Lösung”. Das Plugin AntiSpamBee löst das Problem mit Kommentarspam im Idealfall so das keine einziger Spamkommentar mehr den Blog erreicht.

Die AntiSpam Einstellungen

Die AntiSpam Einstellungen

Es greift dabei auf keine externe Datenbank zu und funktioniert nach einem simplen Prinzip. Für die Spam Bots wird einfach ein zusätzliches Feld definiert, welche dieses mitausfüllen und sich damit als Spamschleuder zu erkennen geben. Geschrieben wurde AntiSpamBee dabei von Sergej Müller der für das eine oder andere WordPress Plugin bekannt ist. Die Pluginseite ist auf antispambee.de zu finden.

Unter Umständen möchte man seine eigene Blacklist direkt auf dem Mailserver führen. Für diesen Zweck gibt es unter Postfix die Einstellung “check_sender_access”. Dazu bearbeitet man die Datei “/etc/postfix/main.cf” mittels des gewünschten Editors:

nano /etc/postfix/main.cf

In der Abteilung “smtpd_recipient_restrictions” wird der Eintrag

check_sender_access hash:/etc/postfix/sender_access

ergänzt. In die neu anzulegende Datei “sender_access” werden nun Einträge nach folgendem Schema definiert.

webmaster@example.org REJECT
spam@example.org REJECT
spam@example.com REJECT

Mittels “postmap” wird anschließend die binäre Repräsentation erzeugt und mittels “reload” die Konfiguration neu geladen.

postmap /etc/postfix/sender_access
service postfix reload

Damit werden Mails von den definierten Adressen immer abgewiesen.

Wenn man Thunderbird benutzt, hat man die Möglichkeit den eingebauten Spamfilter zu benutzen. Dieser verschiebt die entsprechenden Mails nach der Erkennung in einen Ordner mit dem Namen “Junk”. Problematisch wird es aber, wenn man selber Mails als Spam markiert. Diese werden dann nicht verschoben.

Die entsprechende Option in den Einstellungen

Die entsprechende Option in den Einstellungen

In den Konteneinstellungen findet man dazu keinen Punkt der zu dem Problem passt. Die einzige Möglichkeit, die man dort vorfindet, ist die Einstellung in welchen Ordner der Spam verschoben wird. Für den Nutzer sieht es damit so aus, als ob Thunderbird an dieser Stelle fehlerhaft arbeitet. Wenn man genauer nachschaut entdeckt man die Einstellung, die sich dieses Problemes annimmt in den Einstellungen von Thunderbird. Dort gibt es den Tab “Sicherheit” und in diesem den Untertab “Junk”. Wird der entsprechende Haken bei “Wenn Nachricht manuell als Junk markiert werden” gesetzt, funktioniert die automatische Verschiebung für von Hand klassifizierten Mails.

Bis vor kurzem benutzte ich zur Spambekämpfung in meinem WordPress Blog das Plugin “TypePad AntiSpam” sowie für die ganz harten Falle eine IP basierte Sperre per “.htaccess” Datei:

#Wordpress Spam ausschließen
order allow,deny
deny from 95.156.238
deny from 178.63.199
deny from 178.216
allow from all

Mittlerweile bin ich zum Plugin “Antispam Bee” gewechselt, welches den Spam mit ein paar interessanten Techniken zurückhält. Ich hatte das Plugin vor einiger Zeit schon einmal getestet, damals funktionierte es aber nicht, sondern führte nur zu Fehlermeldungen. Nach ein paar Tagen intensiver Tests, ist der nicht erkannte Spam, dank “Antispam Bee”, erheblich gesunken.

Ich nutze ja zur Spambekämpfung Typepad AntiSpam und dieses Plugin erwischt auch einen Großteil, aber leider nicht alles. Meist sind es nervige Kommentare aller:

  • Wo ist der Like Button?
  • Habe einen RSS Reader. Wo ist der Feed?
  • Auf dem iPhone sieht es komisch aus.

Dem Blog BitBlokes ist dabei aufgefallen das diese Spammeldungen meist von der gleichen IP bzw. dem gleichen IP Bereich kommen und er liefert gleich den passenden Eintrag für die .htaccess Datei mit:

order allow,deny
deny from 128.204.197.19
deny from 95.156.238
allow from all

Damit ist dann Ruhe im Karton. Danke BitBlokes 🙂

Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/.htaccess
http://de.wikipedia.org/wiki/Wordpress
http://de.wikipedia.org/wiki/Spam

Vor ein paar Tagen schrieb ich einen Artikel wie man Spam in der MediaWiki bekämpft. Die Methode an sich ist nicht schlecht, weil keine Einträge mehr verändert werden. Allerdings gibt es immer noch einige Nutzer die sich angemeldet haben, allerdings klar als Spambots zu erkennen sind.

Um zu verhindern das sich solche Spambots überhaupt anmelden können gibt es die Extension ConfirmAccount welche unter http://www.mediawiki.org/wiki/Extension:ConfirmAccount zu finden ist. Die Extension sorgt dafür das ein MediaWiki Bürokrat den Account erst bestätigen muss. Das kann dabei so eingestellt werden, das dieser eine Mail bekommt sobald der Nutzer die Mailadresse bestätigt hat. Nach dem Download der Extension sollte diese entpackt werden und der Ordner ConfirmAccount in den extensions Ordner hochgeladen werden. Nun müssen noch die Einstellungen in der LocalSettings.php angepasst werden:

#ConfirmAccount
require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");
$wgUseRealNamesOnly=false;
$wgAccountRequestMinWords=0;
$wgAccountRequestToS=false;
$wgAccountRequestExtraInfo=false;
$wgConfirmAccountContact="admin@example.org";

Anschließend muss die MediaWiki noch geupdatet werden. Mittels Shellzugang sieht das ganze so aus:

php maintenance/update.php

Weitere Methoden für das Update sowie Optionen der Erweiterung sind auf der entsprechenden Seite beschrieben. Danach ist die Erweiterung installiert und sollte ihren Dienst verrichten.