Spambekämpfung ein paar Lichtpunkte
- Grischa hat einen langen Artikel über die Möglichkeit der Abwehr von Trackback SPAM Bots mittels .htaccess geschrieben, der auch für S9y BloggerInnen passend ist.
- In der Version 1.2 Beta von Serendipity gibt es die Möglichkeit IPs von Spammern mittels .htaccess zu sperren. Dazu aktiviert man im Spamschutz der Verwaltungsoberfläche diese Funktion. Die IPs werden automatisch monatlich dem .htaccess hinzugefügt.
- Ebenfalls seit der 1.2: Ich erhalte für jeden Kommentar den es zu moderieren gilt eine E-Mail. Auch per Akismet abgefangene Kommentare habe ich auf moderieren gestellt, da hin und wieder doch ein “false positive” dabei ist. Nunmehr wird per E-Mail angezeigt, wenn das Kommentar von Akismet abgefangen wurde. So sieht man gleich ob Akismet überhaupt einen nutzen hat und welche Kommentarspams ins Netz geraten.
- in Serendipity
- am Sonntag, 29. Juli 2007
- um 21:40
37 Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Nun, bei mir funktioniert der bei mir beschriebene Ansatz schon mal absolut perfekt. Und das schon seit mehreren Tagen ohne dass ich irgendwie eingreifen oder moderieren müsste. Also voll automatisch. Dieser Ansatz macht übrigens auch den von Dir als 2. beschriebenen überflüssig, Akismet bleibt weiterhin interessant für noch unbekannte Bots. Bei mir ist das allerdings nicht eingeschaltet und trotzdem: Kein SPAM mehr! Hach, kann das Bloggerleben schön einfach sein.. ;-)
.. und neue Botnamen. Bei Dir scheint ja wohl gerade ein neuer aufgetaucht zu sein, wenn ich Deine EMail richtig interpretiere.
Und nebenbei: Ich wüsste sofort, wie ich die bei mir genannte Methode als Botprogrammierer komplett aushebeln könnte. Ist eigentlich ziemlich einfach, um ehrlich zu sein (ich sag jetzt nicht wie.. ;-)). Aber es ist rein wirtschaftlich offenbar unsinnig. Es kostet mehr, den Bot zu ändern, als die paar wenigen gesicherten Blogs Verluste bringen.
Ich rate unbedingt dazu, bei s9y.org vorzuschlagen, dass jemand eine IP-Prüfung via Plugin realisiert. Ich habe das im [url=http://sw-guide.de/wordpress/plugins/simple-trackback-validation/]Simple Trackback Validation Plugin[/url] für das Blog-System WordPress realisiert. Nahezu jeder Spammer schickt von einer anderen Maschine / IP-Adresse aus die Spam-Trackbacks, so dass ein simpler IP-Vergleich per PHP das sehr zuverlässig aufdeckt.
Bei mir (und jedem anderen der das Plugin einsetzt) kommt dadurch nahezu kein einziger Trackback-Spam mehr durch, z.B. alleine die letzte Stunde kamen fast 50 Trackback-Spam-Versuche rein.
Das umgesetzt, dann braucht es auch keine manuelle Filterung per .htaccess oder Blacklist-Einträge mehr. Trackback-Spam hat einfach keine Chance mehr. In der 2. Stufe prüft das Plugin optional noch, ob die Ausgangs-Webseite auch wirklich das Ziel-Blog verlinkt…
Gerne kann der Quellcode von meinem Plugin als Basis dienen (steht eh unter GPL ;), ich kann mir gut vorstellen dass nicht viel geändert werden muss, damit es auch unter Serendipity läuft.
Hmm.. Verdammt guter Vorschlag! Ehrlich gesagt hätte ich vermutet, dass das S9Y Plugin das alles schon unterstützt. Aber in der Tat, nur der 2. von Dir genannte Mechanismus wird unterstützt.
Au Backe.. Das muss dann natürlich unbedingt noch rein.
Aber hast Du keine Timeout Last Probleme? Ich muss ja für alle SPAM Trackbacks eine DNS Abfrage durchführen, dass kann bei Roberts 3 Millionen SPAM Trackbacks schon recht Server fordernd sein, oder?
Nein, keinerlei Performance-Probleme bei mir, und ich hatte wirklich Phasen mit zum Teil 500 und mehr Trackback-Spams pro Stunde. Das ganze unter Shared-Hosting-Umgebung, also kein dicker Server nur für mich ;)
Die Prüfung in PHP erfolgt BTW via gethostbyname(), wobei mir ein Blogger noch eine evtl. zuverlässigere PHP-Function geschickt hat, die ich aber (noch) nicht einbaute, da es mit gethostbyname() wirklich zuverlässig läuft was ich die letzten Wochen so beobachten konnte…
Würde mich freuen, wenn dieser Wissenstransfer funktioniert. Ein schönes Beispiel, dass es zwischen WP und S9y Bereiche gibt, die man durchaus gemeinsam angehen kann. Ich hatte da mal ein Stöckchen wo ich genau dies abfragt – freut mich, dass hier vielleicht ein Schritt gesetzt wird. Sorry, wenn ich ein bisschen pathetisch klinge. Aber die Spammerei geht mir fürchtlich auf die Nerven und da bin ich über jede Kooperation mehr als glücklich.
Ich habe die IP Validierung jedenfalls mal in die bei mir installierte Version des SpamBlock Plugins eingebaut.
Ich warte mal die kommende Nacht ab und hoffe nun dringlichst auf Bots um den Code zu verifizieren! ;-)
Danke noch einmal für den Tipp, Michael!
An Robert: Wenn Du mutig bist, kann ich Dir natürlich mal meine erweiterte Version des Plugins zukommen lassen. Ist aber definitiv ALPHA WARE. Sollte funktionieren, aber ich hatte mangels Bot Zugriffen noch keine Chance, das zu testen.
Mit Mut hat das wenig zu tun ;-) Eher damit, dass ich mich damit nur begrenzt auskenne und daher erst bei Reaktionen der LeserInnen ev. merke, dass im Hintergrund etwas schief läuft etc.
Aber mit Unterstützung würde ich es ev. wagen. Mailen wir halt mal drüber.
#2.1.1.2.1 • • Homepage • am 30.07.2007 17:55 • Antwort
Du kannst die IP Validierung ja erst einmal in den Moderationsmodus setzen, so wie ich es eine Zeit gemacht habe. Dann kannst Du schon einmal beobachten, dass/ob die Methode Dir echte Trackbacks raus schmeißt. Aber auch im Löschmodus kann man das Plugin immer noch nachträglich überprüfen anhand des SPAM Logfiles, das in der Default Konfiguration in der Datenbank liegt, man kann es aber auch in eine Datei loggen lassen. Bei mir wurde jedenfalls ausschließlich nur echte SPAM heraus gefiltert.
Leider ist das bei dem Spamschutz Plugin so, dass immer nur die letzte Methode, die gegriffen hat, als Ursache in der Moderationsmail gelistet wird (im Logfile hingegen dann alle), somit selten die IP Validierung. Ich musste z.B. erst einmal das Moderieren nach X Tagen ausschalten, um die neue Funktion korrekt beobachten zu können.
#2.1.1.2.2 • • Homepage • am 01.08.2007 12:03 • Antwort
Es braucht noch. Im Moment kommen noch einige Spams durch, die Akismet – und die anderen Mechanismen – gut abfangen. Grischa ist schon dabei – siehe sein Trackback weiter oben, die Methodik zu verbessern und zu verfeinern. Mehrere Methoden nebeneinander werden aber wohl immer das bessere Mittel der Wahl bleiben.
Zur Zeitfrage. Ich lasse mein Mailprogramm diese Moderationsankündigungen in ein eigenes Postfach legen. Die meisten sind schon in ein, zwei Sekunden identifiziert. Daher braucht das “durchscannen” der Mails ein bis drei Minuten. Das schaffe ich noch.
Ich verstehe eines nicht. Die Bots werden “umgeleitet”, in ein Nirvana. Aber allein ihr versuchter Zugriff löst doch schon eine Session aus, die dann nicht mehr geschlossen wird (also im sleep-Modus bleibt).
Gibt es nicht ein Script, das diese Sessions beendet? Meinetwegen beschränkt auf etwa 500 Sekunden sleepy time?
Ich glaube nämlich langsam, dass es manchen Bots gar nicht mehr um das Absetzen von Trackbacks geht, sondern dies eine Vorstufe zum generellen Hack von Websites (=Foren + Blogs) sein wird.
Wieso wird denn die Session nicht geschlossen? Das müsste doch der Server übernehmen? Die BotTrap funktioniert doch einfach nur so, dass Bots, die die robots.txt nicht akzeptieren, auf eine andere Seite extra für Spam Bots geleitet wird. Das ist aber doch ein normaler Seitenaufruf am Server. Ich verstehe nicht, wieso danach noch eine Session oben bleiben sollte?
[quote]Ich verstehe nicht, wieso danach noch eine Session oben bleiben sollte?[/quote]Das weiß ich auch nicht und mir konnte bislang auch noch keiner eine vernünftige Antwort darauf geben. Stattdessen wurde die Schuld immer wieder zwischen Hoster und s9y-Programmieren hin und her geschoben. Es wäre wirklich schön, es mal erklärt zu bekommen, warum und weshalb….
Ich hatte vor Tagen (es war letztes Wochenende) einen massiven Angriff seitens der Bots, und da war eine Session, die mehr als 5600 Sekunden (!!!) im Sleep-Modus war. An dem Tag löschte ich im Handumdrehen und binnen 30 Minuten rund 80 Bots, die genau dieses Phänomen hervorriefen.
Die Tmp-Datei, die mir der Hoster zur Kontrolle auf mein Verzeichnis legte, zeigte eine Latte von Sessions, die nur so einprasselten. Und hier vermute ich, liegt u.a. ein Problem mit der Serverlast.
Ich kann es im Augenblick nicht zeigen, aber ich bekam die Angriffwellen dann mit, wenn ich bei einer Aktion im Admin-Bereich auf einmal die Meldung bekam, dass zuviele Sessions offen wären, was dann zum Abbruch führte.
Meine Geschichte mit den Spams ist wirklich schon recht alt, schon seit letztem Jahr kämpfe ich mit den Dingern und versuche auch nur ansatzweise Jemanden zu finden, der mir wirklich hilft! Aber bis jetzt habe ich immer noch das Gefühl, allein als Ruferin im Wald zu stehen, und die anderen ganz schnell Land ergreifen, wenn es darum geht, hier mal einzugreifen.
Nun ja. Es gibt ja einige, die sich darum kümmern. Robert in diesem Artikel z.B. und ich habe auch schon 2 ausführliche Artikel bei mir geschrieben, wie man erfolgreich den Spam Bots Herr werden kann. Bei mir kommen keine SPAM Bots mehr durch.
Bei Dir scheint aber irgendein spezielles Problem zu sein, dass die Session bei irgendeinem Aufruf nicht geschlossen wird.
1.) Kannst Du mal das Logfile posten (oder einen Ausschnitt daraus), welcher Aufruf eigentlich diese nicht schließende Session produziert?
2.) Das Temp File des Hosters: Was ist das? Eine Logdatei? Dort waren viele Sessions gelistet. Waren die alle ca. 1,5 Stunden offen?
3.) Du erzählst von einer BotTrap. Diese ist für sich erst einmal nicht befähigt, Spam Bots auszuschließen, sondern nur dazu, Spam Bots zu erkennen. Was für eine BotTrap hast Du denn wie genau installiert?
4.) Du beschreibst, dass Du “Bots gelöscht hast”. Was meinst Du damit? Was hast Du getan? Ihnen den Zugriff verwehrt? Oder nur die Posts dieser Bots gelöscht?
5.) Hast Du Dein Problem eigentlich schon mal im s9y Forum beschrieben? Dort sind einige sehr fähige Leute dabei, die meist extrem schnell Ideen haben, was man auf welche Weise bei Problemen machen kann.
Hi Grischa,
ich kann dir, wenn du magst, nur aus den Logfiles etwas zu den Bots posten. Zu den Sessions muss ich sagen, dass ich da nicht daran gedacht hatte, Screenshots zu machen. Ich hatte auch ihre gefakten IPs anschließend über die htaccess per deny from IP-Range gesperrt.
Ich hatte sie in PhpMyAdmin gekillt, also “beendet”, um wieder Raum für neue Besucher zu schaffen. Bemerkt hatte ich diese Attacken immer dann, wenn ich entweder nicht auf meine Domain kam oder im Adminbereich keine Aktion vollziehen konnte.
Eine Bottrap hatte ich nicht installiert, sondern immer nur meine Logfiles, die ich mir sehr genau diesbezüglich angesehen hatte. Um die “angeblichen” Herkünfte der IPs zu finden, verwende ich div. Tools aus dem Web.
Hier mal ein Auszug aus einem Log vom 29.7.:
[quote]www.martina-kausch.de Bangkok – - [29/Jul/2007:05:23:47 +0200] “POST /comment.php?type=trackback&
www.martina-kausch.de Bangkok – - [29/Jul/2007:05:23:48 +0200] “POST /comment.php?type=trackback&
www.martina-kausch.de Bangkok – - [29/Jul/2007:05:23:51 +0200] “POST /comment.php?type=trackback&
www.martina-kausch.de Bangkok – - [29/Jul/2007:05:23:53 +0200] “POST /comment.php?type=trackback&
(...)
www.martina-kausch.de Bangkok – - [29/Jul/2007:05:24:06 +0200] “POST /comment.php?type=trackback&entry_id=1345 HTTP/1.1” 200 196 ““ ““
www.martina-kausch.de Taiwan – - [29/Jul/2007:05:24:30 +0200] “POST /comment.php?type=trackback&entry_id=854 HTTP/1.1” 200 196 ““ ““ www.martina-kausch.de Bangkok – - [29/Jul/2007:05:24:59 +0200] “POST /comment.php?type=trackback&entry_id=854 HTTP/1.1” 200 196 ““ ““ www.martina-kausch.de Taiwan – - [29/Jul/2007:05:25:11 +0200] “POST /comment.php?type=trackback&entry_id=1345 HTTP/1.1” 200 – ““ ““ www.martina-kausch.de Bangkok – - [29/Jul/2007:05:25:37 +0200] “POST /comment.php?type=trackback&entry_id=1345 HTTP/1.1” 200 196 ““ ““(...)[/quote]
Die IP aus “Bangkok” war / ist: 202.29.240.14
Bei diesem quote handelt es sich wirklich nur um einen kleinen Ausschnitt meines Logs vom 29.7., der txt-Datei rund 600 kb groß ist. Mag sein, dass diese Größe im Vergleich zu manch anderen Logs noch recht winzig ist, aber mir reicht(e) es.
Und ja (zu 5.) Ich hatte es mehrfach im Forum beschrieben.
So. Also die Zeilen des Logfile Auszugs scheinen nicht alle vollständig zu sein, man erkennt nicht immer den UserAgent, der angegeben wurde. Aber in den Zeilen, in denen das angegeben ist (”-”), kann ich erkennen, dass bei Dir offenbar der selbe Bot aufschlägt, der auch bei mir den meisten Traffic produziert hatte. Diesen kann man ganz einfach aus seinem Blog ausschließen. Er ist daran zu erkennen, dass er keinen UserAgent beim Post auf Deine comment.php angibt. Das ist unüblich, normaler Weise wird immer ein User Agent angegeben.
Wie man diese Bots aus seinem System heraus hält, habe ich bei mir recht ausführlich beschrieben, der Artikel ist hier auf dieser Seite gleich als erstes verlinkt. Die in dem Artikel beschriebene Methode wird die in Deinem Log zu erkennenden Bots alle vom System fern halten, es wird für diese gar nicht erst eine Session geöffnet!
Hattest Du meinen Artikel bereits gelesen? An dem Log kann man erkennen, dass Du diese Methode jedenfalls noch nicht benutzt. Falls Du Probleme beim Realisieren dieser Methode in Deinem Blog hast, dann sag noch einmal Bescheid, dann können wir (ich) Dir sicher helfen.
Zu 5.): Komisch, das ist wohl an mir vorbei gegangen, ich hätte sicher sofort geantwortet, weil ich mich gerade etwas ausführlicher mit dem Thema beschäftigt hatte.
Zu 5.) Das ist manchmal das “Problem” des S9y Forums, dass an manchen Tagen zu viele Postings auftauchen und rasch durch “neue” ersetzt werden, sodass man manches auch einfach übersieht. Aber das ist das grundsätzliche Problem von Forensoftware.
Aber nun zurück zum Hauptproblem. Hoffe, die Lösung passt auch für Martina.
[quote]Wie man diese Bots aus seinem System heraus hält, habe ich bei mir recht ausführlich beschrieben, der Artikel ist hier auf dieser Seite gleich als erstes verlinkt.[/quote]
Dein Artikel erschien erst, NACHDEM ich die Attacken verspürte. Inzwischen habe ich bei meiner anderen Website (der des Bouleclubs) die htaccess entsprechend deinen Anweisungen geändert. Hoffentlich ist die Seite erstmal sicher.
Um meine anderen Domains kümmere ich mich per htaccess dann, wenn es soweit ist, wenn sie aktiv sind und laufen.
Was mich an der ganzen Sache ärgert, ist, dass erstmal die Schuld bei uns Bloggern gesucht wird anstatt sich die Hoster zusammenschließen und offensiv gegen die Spammer vorgehen!
Ich bin nun eine Leidtragende, und das ganze Geschehen heute hat mir wirklich den Tag verhagelt! Bis vorhin, also bis ich der Linkliste von Robert gefolgt bin, wusste ich mir wirklich nicht zu helfen!
Soll ich bei allen Blogs, die mir unterstehen, nun doch nochmal vorsichtshalber das Spam-Plugin ausschalten?
Ich verstehe dich. Auch ich war bei den ersten Angriffen die mir mein Provider meldete vor den Kopf gestossen. Aber ich fand in der S9y Community einige gute Tipps und Hilfestellungen (Grischa sei hier natürlich besonders erwähnt) und mein Provider war dann durchaus kooperativ.
Wie ich schon schrieb: Einzelne Blogger “rauszuschmeißen” wird über kurz oder lang sinnlos werden, da es immer wieder andere treffen wird. Meine Blogsoftware sitzt ja ganz am Schluss der Kette vor der noch Hoster etc. ihre Server,.. plaziert haben. Daher würde ich mir ein entsprechendes umdenken wünschen. Aber vielleicht müsste der Druck der User hier noch stärker werden.
#6.1.2.2.1 • • Homepage • am 04.08.2007 00:35 • Antwort
Das ist natürlich Mist! Dass Dich der Provider gleich mal aussperrt, ohne selbst etwas gegen den Spam zu tun, deutet auf einen ziemlich schlechten Provider hin. Mein Provider verhält sich in solchen Fällen ganz anders, so habe ich ihm sogar aktv berichtet, dass es durch mein Blog wegen Spam Angriffen zu Lastspitzen kommen könnte. Das hat ihn gar nicht beunruhigt, ganz im Gegenteil, er war sofort hilfreich bemüht!
Das Spam Plugin ausschalten würde ich nicht. Nein, auf keinen Fall! Ich persönlich würde nur diese eine AntiSpam Methode nicht verwenden, aus unten beschriebenen Gründen. Wenn Du die Möglichkeit hast, würde ich Dir empfehlen, das AntiSpam Plugin aus der 1.3 Version zu installieren und statt dessen die IP Validierung einzuschalten. Die produziert im Prinzip keine Last (dazu habe ich bei mir auch einen Artikel).
Ansonsten: Wenn Du die .htaccess Modifikation, die bei mir beschrieben wurde, bereits vollzogen hast, hast Du wahrscheinlich 99% aller Trackback Spam komplett draußen, ohne irgendwelche Last zu produzieren. Bei mir sind es sogar 100%. Ich würde dann noch dringend Captchas aktivieren, um den Spam auch aus den normalen Kommentaren los zu werden. Diese beiden Methoden alleine (User Agent Check für Trackbacks und Captchas für Kommentare) haben mich seit dem Einbau 100% vor SPAM geschützt, ohne dass ich irgendwie (auch nicht per Moderation) eingreifen musste.
Zu Captchas muss man allerdings sagen, dass die (im Ggs zur UA Modifikation) keine Last verhindern (aber auch nicht extra erzeugen), sondern nur verhindern, dass der Spam Bot in Deine DB posten kann. Deine Seite aufrufen kann er natürlich weiterhin.
#6.1.2.2.2 • • Homepage • am 04.08.2007 02:54 • Antwort
Danke für deine Kommmentare, ich lerne einiges dazu.
Zu den grafischen Captchas von S9y muss man jedoch erwähnen, dass sie die Kriterien der Acccessibility (wie fast alle anderen grafischen C.) nicht erfüllen. Sprich Blinde und ev. auch Sehbeeinträchtigte Menschen haben keine Chance an dieser Sperre vorbeizukommen. Das sollte man nur wissen bevor man diese Entscheidung trifft. Um nicht künstlich ein Hindernis aufzubauen moderiere ich halt den Rest der noch reinkommt (dies ist meine persönliche Entscheidung). Ist natürlich Arbeit. Daher hoffe ich doch noch ein paar weitere Unterstützungsmöglichkeiten zu finden. Nebstbei: Akismet leistet hier recht gute Arbeit, ist aber natürlich auch nicht fehlerfrei.
#6.1.2.2.2.1 • • Homepage • am 04.08.2007 07:34 • Antwort
Eines fällt mir noch zusätzlich ein: Benutzt Du das SPAM Plugin? Verwendest Du da die Methode, die überprüft, ob der aufrufende Tracker Dich überhaupt verlinkt? Diese Methode zu benutzen halte ich für überaus riskant, weil Du da eine Seite des Botservers aufrufst. Diese könnte dann ein ewiges Timeout und damit ein vorrätig halten der Session produzieren. Auch dagegen wurden bereits im Spam Plugin Vorkehrungen getroffen, allerdings erst ab einer bestimmten Version des Plugins. Hier wurde der Timeout begrenzt, aber es bleibt der Serveraufruf. Bei älteren Versionen des Plugins gibt es gar keine Timeout Begrenzung. Falls Du die alte Version benutzt, würde man mit der Methode exakt das Verhalten beobachten, das Du beschreibst.
Grischa, das war auch meine Überlegung. Aber ich hatte erst wenige Wochen davor eine komplette Neuinstallation der aktuellen stable-Versions durchgeführt, mit einer komplett neuen Installation aller Plugins, auch der Event-Plugins. Außerdem habe ich mir angewöhnt, regelmäßig nach Updates zu schauen und diese sofort zu laden.
Das Spam-Plugin war versionsmäßig schon vorinstalliert. Welche Einstellung ich hatte, kann ich jetzt nicht mehr nachvollziehen, da mir auch der Zugang zum Admin-Bereich gesperrt wurde.Da ich aber eine Neuinstallation durchgeführt hatte (wg. der bekannt gewordenen Sicherheitslücke) wird es sich dabei wohl um die aktuellste Version gehandelt haben. Und die Neuinstallation führte ich etwa 2 Tage nach der ebigen Freigabe durch.
Grischa, etzt muss ich aber auch nachfragen. Meinst du es wäre besser diese Überprüfungsfunktion überhaupt auszuschalten? Langsam denke ich mir wir bräuchten für das/die Spam Plugin/s eine wirklich gute Doku damit auch Nichttechniker wie ich die richtigen Einstellungen finden.
Eine gute DOku für so manche Features ist dringend erforderlich. Ich hatte mich ja bereit erklärt, die Anwendung mancher Seitenleistenplugins zu erklären. Aber bislang bin ich dazu noch nicht gekommen.
(Ich hatte für ein großes mittelständisches Unternehmen die komplette Webstruktur weltweit incl. der Schulung der künftigen Onlineredakteure im CMS gemacht. Ich weiß also, was CMS eigentlich können (sollten).) ;)
#6.1.3.2.1 • am 04.08.2007 00:15 • Antwort
Robert: Ein klares Jein! :-)
Diese Methode verursacht auf jeden Fall einen Aufruf beim Spam Server (bzw. beim Server des beworbenen Kunden). Hier ist zwar bei den neueren Versionen des Spam Plugins ein Timeout eingestellt, aber jeder Aufruf benötigt dann mindestens die Zeit dieses Timeouts, wenn der Werbeserver nicht korrekt reagiert. Mal ganz abgesehen davon, dass das Blog dann auch die (beliebig große) vorgefundene Seite herunter laden und nach Links durchsuchen muss.
Ich habe aus diesem Grund diese Methode schon immer abgeschaltet gehabt. Die neue IP Validierung ist nun deutlich effizienter (und nebenbei auch schlagkräftiger!), weil sie den Werbehost gar nicht aufrufen muss, sondern nur einen DNS Server. DNS Server sind aber darauf ausgelegt, besonders schnell zu antworten , sie benutzen z.B. geeignete Caching Strategien.
Unterm Strich: In Deinem Fall mit den vielen Spam Bot Attacken würde ich dieses Feature ausschalten. Allerdings kommen inzwischen ja die Trackback Bots bei Dir gar nicht mehr durch (wegen dem UA Test in der .htaccess), wenn ich das richtig in Erinnerung habe, sondern nur die normalen Kommentar Bots, weil Du auf ein Captcha verzichtest. Die genannte kritische AntiSpam Methode schlägt aber nur bei Trackback Spam zu, somit macht das (inzwischen) bei Dir keinen Unterschied mehr. Sie dürfte aber vorher ohne den UA Check zur erheblichen Last bei Dir beigetragen haben.
#6.1.3.2.2 • • Homepage • am 04.08.2007 02:40 • Antwort
Grischa, wärst du so nett und führst mal alle von dir hier empfohlenen event-Plugins mit Namen auf und beschreibst, wo welche Einstellung wie vorgenommen werden sollte?
Ich habe mir eben mal das serendipity_event_spamblock angesehen und bin recht ratlos aufgrund der knappen Beschreibung. Wie z.B. hier: [quote]Falls aktiviert, wird ein spezieller Hash-Wert sicherstellen, dass nur Benutzer Kommentare hinterlassen dürfen , die eine gültige Session-ID haben. Dies wird Spam etwas eindämmen und es unmöglich machen, dass Sie ungewollt Kommentare via CSRF-Angriffen hinterlassen, aber es wird auch dazu führen dass nur Benutzer mit aktivierten Cookies kommentieren können.[/quote]Was das andere Spam-Event (RBL) anbelangt, ist es bei mir noch nicht aktiv, da ich die Beta 1.2 noch nicht installiert habe.
Ja, ich war schon am überlegen, ob ich nicht mal einen Artikel zum Spam Plugin schreiben sollte, nachdem ich mich ein wenig damit befasst habe. Ich muss aber sagen, dass mir die Abkürzung CSRF auch unbekannt ist, dazu müsste ich dann auch erst einmal recherchieren bzw. Garvin mal eine Mail schreiben.
Und was ist das RBL Spam Plugin? Das (oder den Namen) kenne ich glaube ich noch nicht..
#6.1.3.3.1 • • Homepage • am 04.08.2007 12:00 • Antwort
Du wirst wahrscheinlich schon nachgesehen haben, aber zur Sicherheit:
[quote]Spamschutz (RBL) Blockiert SPAM Anhand von IP-Blacklists. Wird diese Option aktiviert, werden Kommentare abgewiesen die von IPs stammen, die in einer RBL/Blacklist geführt werden. Die Aktivierung hiervon kann Dial-Up oder Proxy-User betreffen![/quote]
Und dann gibt es noch
[quote]Spamschutz (SURBL) URL abweisen die als SPAM geblacklistet sind.[/quote]
Sofern man Akismet verwendet sollte man aber – soweit ich es gelesen haben – anderweitige “Blacklists” deaktivieren. Aber ob das der Stand der Dinge ist ist mir nicht geläufig.
#6.1.3.3.1.1 • • Homepage • am 04.08.2007 14:40 • Antwort
SURBL habe ich bei mir BEWUSST de-aktiviert, da es mehr Probleme verursacht als löst. :(
Aber seit ich die htaccess bearbeitet habe, habe ich zwar noch viel Zugriffe, aber die werden inzwischen nicht mehr mitgezählt, da “403”.
Endlich habe ich eine halbwegs bereinigte Logfile-Datei und halbwegs echte Zugriffszahlen. :) Und damit glaube ich, zu einer der Wenigen zu gehören, die einen Überblick über ihre “echten” Besucher hat. :)
#6.1.3.3.1.1.1 • • Homepage • am 21.08.2007 20:44 • Antwort
4 Trackbacks
Trackback-URL für diesen Eintrag