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

Warum versucht eigentlich dieser dauerstörende Vollpfosten-Spambot, der seit langer Zeit im Abstand von jeweils einigen Tagen Blogs mit mehr-hunderfachen POST-Attacken behelligt (nebst ebenso vielen GET-Attacken dazwischen, meist auf ältere Artikel), seit ein paar Monaten, massiv dorthin zu POSTen:

/cgi-bin/sys/htdig/htsearch?

Hat das bei irgendeinem anderen Blogsystem als WordPress eine Relevanz?

Die Attacken sehen im Einzelnen so aus:

201.21.216.132 - - [24/Oct/2006:04:03:27 +0200] "POST /cgi-bin/sys/htdig/htsearch HTTP/1.1" 200 925 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Die IP-Adressen wechseln nach Belieben, der User Agent ist immer derselbe. Woran man übrigens den Marodeur klar erkennen kann.

Der Dreck wird übrigens vollständig von Bad Behaviour abgefangen und mit nur ca. 900 Byte kleinen »Fehlermeldungen« beantwortet.

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.