Ich habe ja einen eigenen Server, der den ganzen Schnickschnack drauf hat, um eben diese (und ein paar Seiten von Freunde) zu generieren. Damit die Konfiguration für meine Freunde und mich etwas einfacher ist, nutze ich Confixx von SWSoft. Bei Confixx kann man über eine Weboberfläche Domainen anlegen, diesen Verzeichnisse zuordnen, etc. pp.. Dieses Confixx erstellt dann - nachdem man alle Eintragungen in der Weboberfläche gemacht hat - alle Konfigurationsdateien für den Webserver usw.

Confixx benötigt auch dringend PHP. Diese Skriptsprache, auf der auch diese Seite beruht. PHP kommt in verschiedenen Ausführungen daher. Einmal als Apache-Modul. Dieses hat den Vorteil, daß es sehr schnell ist, aber den Nachteil, daß jeder Benutzer auf dem Webserver jedem anderen in die Verzeichnisse schauen kann, weil alle PHP-Skripte unter einem einzigen Systemuser (dem des Webservers) ausgeführt werden.

Seit einiger Zeit kann Confixx auch mit suPHP umgehen. Hier ist der Vorteil, daß alle PHP-Skripte unter einem seperaten Systemuser ausgeführt werden, d. h. keiner kann dem anderen in die Karten schauen. Nachteil ist, daß jedesmal wenn eine Seite aufgerufen wird, ein grosser Overhead erzeugt wird, der in der Regel grösser ist, als das Ausführen des PHP-Skripts selbst, d. h. die Seiten werden sehr langsam und der Server ist immer sehr stark ausgelastet.

Der Kompromiss zwischen den beiden o. g. Möglichkeiten stellt fcgid dar (der Nachfolger von fastcgi). Es ist schnell, hat wenig Overhead und alle Skripte werden unter einem seperaten User ausgeführt. Der Nachteil ist, daß Confixx dies von Haus aus nicht unterstützt.

Ich habe mich zumindest daran gesetzt und ein kleines Skript erstellt, welches vor dem confixx_counter-Skript ausgeführt werden muß. Dieses erstellt für alle User die entsprechenden fcgid-Wrapper-Skripte, mit denen die PHP-Skripte ansich dann aufgerufen werden.

Zusätzlich wird eine weitere Apache-Konfigurations-Datei (confixx_special_vhost.php) erstellt, welche am Ende der httpd.conf eingefügt werden muss.

Wenn man soweit ist, trägt man in Confixx unter http-Special noch dies ein

# FCGI
AddHandler fcgid-script .php
AddHandler fcgid-script .php4
AddHandler fcgid-script .php5
AddHandler fcgid-script .phtml
#/suPHP_ConfigPath .*/
# FCGI

und die Sache sollte laufen.

Ich setzte dies nun seit ca. einer Woche ein, und der Server wurde merklich entlastet und die Seiten rauschen sehr viel schneller an.

Das Skript downloaden und auf dem Server ausführen. Wenn Fragen sind, diese in den Kommentaren stellen und ich werde ggfs. diese Ausführung erweitern.

Wie im vorherigen Beitrag beschrieben, sind Spambots extrem dumm, bzw. der Programmierer dieser hat in den Code der Bots nicht ausreichend Hirnschmalz gesteckt. Ist in der Regel auch nicht nötig, da Kommentarfelder und Gästebuchformulare sehr einfach aufgebaut sind.

Die hier nun weiter beschriebene Möglichkeit stammt nicht aus meiner Feder, sondern von dem Ersteller des Grundgerüsts meines Weblog-Systems Andreas Ahlenstorf. Vielen Dank nochmals, für diese - seit zwei Jahren - gut funktionierende Idee! Und es ist wieder nur ein Fingerzeig, wie man an das Thema herangehen kann und keine fertige Plugin Lösung. Falls jemand eine coded, egal für welches Weblogsystem, bin ich bereit, diese hier gern zu verlinken oder zu veröffentlichen.

Also, um es nochmals zu wiederholen und zusammenzufassen. Spambots sind dumm und füllen alles aus, was denen unterkommt. Spambots beherrschen aber keine Cookies und somit auch keine Sessions. Um es einfach auszudrücken, Spambots nehmen keine laufenden Daten mit, wenn diese auf deiner Webseite von einer Seite zur nächsten wandern.

Diese Tatsache ließ die Idee aufkommen, daß man den Input-Feldern nicht mehr den gleichen Namen, wie z. B. “author”, “commenttext”, “email” oder “website”, sondern diesen immer wieder ändernde Hashwerte gibt, welche erst über eine Session ihrer richtigen Bedeutung, wie “author”, “website”, etc. zugeordnet wird. Das alles zur Veranschaulichung in ein kleines Beispiel gepackt. Vorher sah es immer so aus:

<input type=”text” name=”author” />

Über name=”author” wird in dem dahinter liegenden Skript, welches dann den Kommentar wegspeichert, eine eindeutige Zuordnung hergestellt. Bei mir sieht es dagegen so aus:

<input type=”text” name=”79bb89ba1bb6fbc26af7b31198731d10f85cefa8″ />

Der Zufallswert hinter name= ändert sich bei jedem Aufruf der Seite, die das Kommentarfeld aufweist. Eine eindeutige, wiederkehrende Zuordnung ist also nicht gegeben. Da dies aber nötig ist, um den Inhalt auch richtig speichern zu können, wird bei mir in der Session diese Zuordnung hinterlegt, so daß beim abschicken des Kommentares erst einmal in der Sessionvariable “nachgeschaut” wird, daß z. B. der Input-Feld-Name 79bb89ba1bb6fbc26af7b31198731d10f85cefa8 für das Feld Author steht.

Ein Spambot, der keine Cookies beherrscht und somit auch die Session nicht mitführt, kann somit keinen Kommentar abgeben. Leider aber auch kein menschlicher Kommentator, der Cookies in seinem Webbrowser abgeschaltet hat. Aber kollaterale Schäden gibt es immer

Diese o. g. Hashwerte müssen für jedes Kommentarfeld erstellt, in der Session hinterlegt werden und eindeutig sein. Mit PHP erstellt man diesen eindeutigen Hashwert so:

sha1(uniqid(rand(), true));

Diesen, bzw. da man es ja für alle Inputfelder erstellen muß, diese Hashwerte sichert man dann in der Session, z. B. wie hier:

$_SESSION[‘field‘][‘author‘] = sha1(uniqid(rand(), true));
$_SESSION[‘field‘][‘email‘] = sha1(uniqid(rand(), true));
$_SESSION[‘field‘][‘website‘] = sha1(uniqid(rand(), true));
$_SESSION[‘field‘][‘comment‘] = sha1(uniqid(rand(), true));

und gibt diese, logischerweise, seinem Webseiten-Template mit, damit dieses diese dann anstelle von “author”, “email”, etc. einfügt.

Wird nun ein Kommentar abgegeben, muß nun zwingend eine Session vorhanden sein. Ist diese nicht da, ist es mit ziemlicher Sicherheit ein Spambot. Wenn es kein Bot ist, also die Session vorhanden ist, geht man beim speichern den umgekehrten Weg und ordnet den Hashwerten wieder die eindeutige Bedeutung zu. Hier ein beispielhafter PHP-Auszug, nur für das Author-Feld:

if (empty($_SESSION['fields']['author'])) {
echo “Possible Spam”;
exit;
}

if (!isset($_REQUEST[$_SESSION['fields']['author']])) {
echo “Possible Spam”;
exit;
}

$request_vars['author'] = strip_tags($_REQUEST[$_SESSION['fields']['author']]);

Soweit alles verstanden, was ich meine? Ich bin leider nicht der “Erklärbär”, aber ich möchte auch nur einen Ansatz geben, wie man noch gegen Kommentarspam vorgehen kann ohne den normalen Besucher unnötig zu belästigen. Und gegen Tipps, wie ich den Artikel auffrischen kann, bin ich auch dankbar.

Wer hieraus ein Plugin für eines der bekannten Weblogsysteme erstellt, soll sich bitte melden.

Der Admartinator und der Christoph wollen von mir ein Tutorial haben, wie man den Kommentarspam sich vom Leib halten kann. Bei den beiden ist / war es nötig, eine kleine, simple Matheaufgabe zu lösen, wenn man seinen Kommentar abgeben wollte. Hintergrund ist der, daß Spambots fleissig Formulare ausfüllen können, aber den Zusammenhang nicht erkennen, was genau in diese Formulare soll. Daher wird der Kommentar nur angenommen, wenn die Aufgabe richtig gelöst wurde. Dies hat aber den Nachteil, daß der Kommentator an diese Methode gewöhnen muß und dadurch evtl. überfordert sein kann (ja, Kommentatoren können auch dumm sein - fast wie Spambots )

Ich möchte hier eine sehr simple Methode beschreiben, wie bei mir Spam-Kommentare im Blog erkannt werden. Am Ende ergibt dies kein fertiges Wordpress-Plugin, oder eine Anleitung wie man so ein Plugin für seinen Blog coded, sondern es soll mehr ein Fingerzeig sein, wie man die (momentanen) Schwächen des Spambots zu seinem Vorteil ausnutzen kann.

Wie weiter oben schon angedeutet, sind Spambots dumm wie Brot - eigentlich noch dümmer. Deren einziger Sinn und Zweck ist es, in deinem Blog Kommentare zu hinterlassen, wie gefüllt sind mit Links zu irgendwelchen Webseiten, die Viagra oder sonstiges verkaufen. Findet also dieser Spambot eine Möglichkeit einen Kommentar zu hinterlassen, dann macht der das auch in aller Gründlichkeit, indem er alle vorhandenen Felder ausfüllt, wie z. B. Name, eMail-Adresse, Webseite und auch einen ausgiebigen Kommentar gibt er ab.

Na, aufgepasst? Er füllt alle Felder aus! Alle, die er findet. Nachteil des Spambots ist, was unser Vorteil sein kann, daß er -
soweit ich weiß - kein CSS kann. Bei mir ist es so, daß bei den Kommentaren ein weiteres Feld vorhanden ist, daß der normale, lebendige Kommentator nicht sieht, aber der Spambot fleissig ausfüllt.

<input class=”feld” type=”text” name=”megatext” size=”25″ style=”display:none;” />

Sobald der Kommentar abgegeben und dieses Feld ausgefüllt wurde, kann ich mir ziemlich sicher sein, daß kein Mensch mit graphischen Webbrowser es war, der seine Meinung abgeben wollte. Also kann ich getrost diesen Kommentar verwerfen.

Klingt einfach, oder? Ist es auch, daher die folgt mit etwas Abstand eine weitere Möglichkeit.

UPDATE 10 Minuten später
Dieses Input-Feld muß von dem Skript, welches die Kommentare in die Datenbank speichert, auch geprüft werden. Wenn es einen Inhalt aufweist, dann ist es Spam. Ein simpler Code in PHP wie dieser sollte reichen:

if ( !empty($_POST['megatext'])) {
echo “Ein Spambot;
exit;
}