Seite 1 von 1

Gästebuch-Spam, Kommentar-Spam, Foren-Spam - Lösungsansätze

Verfasst: 01.02.2005 14:48
von bruno
muss gerade feststellen das diese Spammer immer schlimmer werden, siehe: http://www.modrewrite.de/visitors/ (Gästebuchspam vom feinsten)

Das bringt zwar hier nichts, da keine <a> tags im Gästebuch zugelassen sind, und der Homepage-Link wird über eine "out.php" redirected, welche in der robots.txt ausgeschlossen ist, aber das wissen ja diese madigen Scripten der Spammer nicht...

Ich überlege gerade wo man hier ansetzen kann...
folgende Ansätze sind mir bis jetzt eingefallen:

IP sperren (.htaccess deny)
die IP oder den IP-Kreis vom Spammer komplett aussperren. Nachteil: Dynamische IP-Adressen müssen einzeln erfasst werden, bevor man sie aussperren kann. IP-Kreise sperren bedeutet möglicherweise unschuldigen Benutzern den Zugang zu verwehren.

Referer Check mittels mod_rewrite
Wenn kein Referer übergeben wird, oder der Referer nicht von der eigenen Seite ist wird der Zugriff gesperrt.

Stichwörter im Script filtern
Der übergebene Text wird auf "Spamwords" wie Casino, Pharmacy, u.s.w. überprüft. Wird ein "Spamword" erkannt wird ein Fehler ausgegeben und die Eingabe wird zurück gewiesen oder auf Spam-Status gesetzt und nicht angezeigt. Diese Methode würde sich auch mit einer IP-Sperre oder ähnlichem verbinden lassen. Wordpress wehrt sich z.B. auf diese Weise gegen den Spam im Blog (Blogs sind anscheinend stark betroffen).

Jetzt stellt sich für mich die Frage was die beste Möglichkeit darstellt. Wenn jemand schon die eine oder andere Methode ausprobiert hat möge er mich es bitte wissen lassen. Am besten mit Vor- und Nachteilen.

Weitere Vorschläge sind natürlich auch gerne gesehen.

So Far...

Verfasst: 01.02.2005 15:16
von bruno
Hier übrigens der Auszug aus den Logfiles für diese 4 Spam-Postings:

Code: Alles auswählen

dsl-200-67-79-230.prod-empresarial.com.mx - - [22/Jan/2005:06:13:10 +0100] "POST /visitors/sign.php HTTP/1.1" 200 4636 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" "modrewrite.de"
dsl-200-67-79-230.prod-empresarial.com.mx - - [22/Jan/2005:06:13:13 +0100] "POST /visitors/sign.php HTTP/1.1" 200 4572 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" "modrewrite.de"
dsl-200-67-79-230.prod-empresarial.com.mx - - [22/Jan/2005:06:13:15 +0100] "POST /visitors/sign.php HTTP/1.1" 200 4603 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" "modrewrite.de"
dsl-200-67-79-230.prod-empresarial.com.mx - - [22/Jan/2005:06:13:17 +0100] "POST /visitors/sign.php HTTP/1.1" 200 4654 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" "modrewrite.de"

nur so als info

Verfasst: 08.02.2005 16:00
von Bob
Bot-Trap nutzen
Und alle Bots direkt aussperren, die Regel der Robotx.txt missachten und in die Falle trappen. Ein wenig Programmieraufwand, fürs Forum aber unnötig solange eine Registrierung vorgeschrieben ist und noch keine Bots mit einer automatischen Registrierung vorbeikommen, sonst

autom. generitertes Bild aus Ziffern/Buchstaben
nutzen, die der Benutzer in ein Feld zur Bestätigung eingeben muss. Geeignet bei Gästebucheinträgen und der Registrierung im Forum zur Verifizierung, ob ein "echter User" unterwegs ist.

Referer Check mittels mod_rewrite ist die schlechteste Methode von allen, habe dazu gestern oder vorgestern was im Forum geschrieben.

Je nach dem wie schlimm die derzeitige Lage ist, sollte
-> Stichwörter im Script filtern + Bot-Trap reichen oder wenn ganz extreme Bots kommen sollten auch noch
-> autom. generitertes Bild aus Ziffern/Buchstaben dazu.

Grüße
Robert

Verfasst: 18.02.2005 23:22
von tox1c
Mir erscheint

Referer Check mittels mod_rewrite
Wenn kein Referer übergeben wird, oder der Referer nicht von der eigenen Seite ist wird der Zugriff gesperrt.

am sinnvollsten.. Denn warum sollte jemand von ausserhalb der Website direkt auf das GB zugreifen wollen? :)

Verfasst: 19.02.2005 00:14
von Bob
es wird auch von vielen www-cache Servern oder InternetSecutity Software der Referer entfernt, Einzelheiten s. http://www.modrewrite.de/foren/viewtopi ... =1118#1118
Daher kann das Blocken von Seiten, wo im HTTP-Request kein Referer übermittelt wird, keine Lösung sein.