dyingeyes weblog: das persönliche Weblog von Boris Stumpf aus Frankfurt am Main

Anders als bei den Vorversionen (1.2.x) wird in Bad Behavior 2 bei den blockierten Zugriffen nicht mehr offen in die Datentabelle geschrieben, warum der jeweilige Zugriff blockiert wurde. Und auch die HTTP-Antwortcodes (200, 400, 403, 412 etc.) sind nicht mehr sichtbar.

Stattdessen schreibt das Plugin pro Eintrag lediglich einen Zahlencode in das Feld »Key« der angelegten Datentabelle.

In einer Antwort des Entwicklers (Kommentar Nr. 32) als einzige Fundstelle auf eine Anfrage per Kommentar (Nr. 21) konnte ich nur die folgende Differenzierung entnehmen:

Steht im Feld »Key« der Zahlenwert 00000000, so heißt das, dass der Request geloggt, aber nicht blockiert wurde. Laut Entwickler loggt ›Bad Behavior‹ auch solche Zugriffe, die nicht eindeutig als Spamkommentar eingestuft werden, die aber trotzdem aufgrund bestimmter Kriterien an der Schwelle zum Verdacht stehen.

Alle anderen Zahlenwerte (z.B. 17566707 oder 17f4e8c8) stehen für blockierte Zugriffe. Mehr noch: Sie stehen für klar definierte Antworten des Plugins auf den jeweiligen Request, samt HTTP-Antwortcode.

Und wo finde ich nun diese Informationen?

Im Verzeichnis, welches die Dateien des Plugins beherbergt, findet sich eine Datei ›responses.inc.php‹. Dort sind alle Key-Codes zu finden nebst den im jeweiligen Fall generierten Plugin-Antworten.
(Diese Key-Antwort-Zuordnung werde ich nun in vernünftig menschenlesbarer Form in eine Textdatei extrahieren, um bei Bedarf schnell nachgucken zu können…)

Und einen gibts beim Autor auch noch. Den ich mir gleich unten rechts verlinkt in die Seitenleiste baue…

Vergangenen Monat hatte ich schon auf ein hochinteressantes Antispam-Plugin für WordPress geschrieben, welches ich seitdem höchst erfolgreich einsetze:

Bad Behavior, inzwischen ganz frisch erhältlich in Version 2.

Nochmal kurz zur Funktionsweise:

Das Plugin erkennt in Richtung des Blogs eingehende Spam-Attacken anhand der Analyse der HTTP-Header, welche die erzeugende Software übermittelt. Darüberhinaus werden auf diese Weise auch einige bekannte aggressive Web-Spider sowie E-Mail-Harvester erkannt und gebannt.

Der Witz dabei ist, dass dieses Tool schon die Anfragen der fraglichen Software-Tools (die Seitenaufrufe oder Requests) blockiert und mit 403-Fehlermeldungen oder selbstgenerierten 412-Fehlern beantwortet. Dies spart gerade bei den massiven Spamattacken, die viele von uns Bloggern inzwischen täglich heimsuchen, enorm Datenverkehr, da eben keine Dateien auf Requests mehr zurückgeliefert werden, sondern bloß Fehlermeldungen.

Auf diese Weise entlastet ›Bad Behavior‹ ganz nebenbei nachgeschaltete Plugins wie Akismet oder Spam Karma, die ja bekanntlich die eingegangenen Kommentare inhaltlich analysieren und ›bearbeiten‹.

Ich habe die Vorversion recht regelmäßig per Blick in die Datentabelle, in die ›Bad Behavior‹ die geblockten Requests protokolliert, kontrolliert. Mir sind dabei bisher keine »False Positives« aufgefallen. Das heißt, es sind wohl keine Anfragen blockiert worden, die von ›normalen‹ Besuchern meines Blögchens kamen. Die neue Version soll hier laut Entwickler noch etwas differenzierter zu Werke gehen.

Im Zweifelsfall aber sollte es durchaus möglich sein – ich meine das irgendwo gelesen zu haben – dass man gezielt bestimmte Zugriffe (User-Agents etc.) manuell per Konfiguration zulassen kann.

Dank eines Artikels von Sascha Carlin bin ich auf ein interessantes WordPress-Plugin gestoßen, welches angetan ist, Spambots direkt beim Zugriff auf Blog-Dokumente abzufangen und zurückzuweisen.

(Spambots sind Skripte, die Spammer verwenden, um Weblogs nach interessanten Informationen – E-Mailadressen – abzugrasen, sowie Skripte, die zum Zwecke des Absonderns von Kommentar-, Trackback- und Refererspam auf Weblogs losgelassen werden.)

Das Bad-Behavior-Plugin besteht aus einer Reihe von Dateien, die darauf angesetzt sind, unerwünschte User-Agents aufgrund ihrer auffälligen Besonderheiten in den übermittelten HTTP-Headern und anderer Kriterien zu erkennen und unverzüglich mit einer Fehlermeldung abzuweisen.

Die blockierten Zugriffe werden dabei mitgeloggt und in einer zusätzlichen Datenbanktabelle abgelegt, wo sie mit geeigneten Mitteln (z.B. phpmyadmin) überprüft werden können. Eine ›Whitelist‹ ist möglich, um im Zweifelsfall falsch erkannte, erwünschte User-Agents durchlassen zu können.

Wie Sascha Carlin schreibt, sollte das Plugin bei gutem Funktionieren eine angenehme Entlastung für Akismet darstellen. Dem pflichte ich uneingeschränkt bei.

Außerdem reduziert die Blockade unmittelbar beim Zugriff auf ein Dokument tatsächlich den Datenverkehr, wogegen Akismet ja erst im Nachhinein – nach erfolgtem Zugriff – tätig wird.

Ich habe das Plugin installiert und werde es die nächsten Tage genauer beobachten. Sollte einer meiner geneigten Leser ab sofort beim Zugriff auf dieses Blögchen abgewiesen werden, so möge er/sie es mir bitte mitteilen. Per Kommentar hier oder per E-Mail.