Seit der letzten Spam-Statistik am 13.06. sind nochmals knapp 10.000 Spameinträge dazugekommen. Der Server war aufgrund der zahlreichen Spamversuche seit Donnerstag fast völlig blockiert. Mittlerweile ist das Problem einigermaßen im Griff. Ausschließen kann man solche Attacken nicht, da sie auf verteilten IPs basieren, also eigentlich echten DOS-Attacken sehr ähneln. Wie soll man das auch abwehren letztlich? Jedes Bot-Netzwerk (die teilweise hundertausende von PC-Zombies kontrollieren) kann oW mE jedes Weblog der Welt lahmlegen, es sei denn, man attackiert Firmen wie Google, Yahoo, MSN oder dergleichen Kolosse. Meine Spamattacken waren so gebaut, dass jede IP immer nur 1-5x vorkam, die IP-Bereiche waren völlig unterschiedlich, ebenso wiesen die Header-Daten keine bestimmte Signatur auf, an der man sich orientieren konnte.
So oder so, was wurde getan?
– Anfragen begrenzt
Die Anzahl maximal erlaubter Requests wurde dem zur Verfügung stehenden RAM des Servers angepasst (war zu hoch eingestellt)
– Update auf WP2
Das Blog hier und Living in WoW wurden von WP 1.5 auf WP 2 angehoben, da angeblich WP 2 performanter laufen soll. Vor allen Dingen musste ich Living in WOW updaten, da sämtliche Inhalte für nicht registrierte User unsichtbar waren! Wir hatten weder in den Templates noch in der DB den Fehler finden können. Das Problem trat ab Do/Freitag auf, also zeitlich mit den Spamattacken einhergehend. Nach dem Update war das Problem bereinigt.
– SpamKarma deaktiviert
SpamKarma wurde deaktiviert. Es erzeugt zu viel Rechenpower. Immerhin waren die SK-Tables >25.000 Einträge groß und bei jedem Spamcheck schaut SK in den Datensätzen nach. Bei starken Spamattacken zieht das den Server natürlich runter.
– Akismet
Akismet läuft momentan als einiziges Anti-Spamtool. Es wird zusätzlich ein Preview-Plugin für Kommentare eingebaut. Das erschwert Kommentar-Spambots die Arbeit. Ich überlege zZt, ob ich stattdessen nicht eine Sonderlösung einbauen soll, die mir schon damals beim MEX Blog super geholfen hat. Ein zusätzliches Feld, in das man einfach nur ein vorgegebenes Stichwort eingeben muss. Weil das super wenig Blogs verwenden, lohnt sich die Anpassung der Spammerskripte nicht.
– Bad Behavior
Bad Behavior ist ein prima Notnagel, um Zugriffe radikal zu sperren, die auch nur ansatzweise nach Spam riechen. Das verschafft dem Server etwas Luft in Notzeiten. Sperrt aber auch nicht wenige User aus. Daher läuft BB nur dann, wenn mans braucht. Schade, denn besser wäre es, dass BB den User statt zu blocken eine Sesam-Öffne-Dich Frage stellt. Wird die Frage falsch beantwortet oder reagiert das Spamskript falsch, müsste man eigentlich der IP mehrere IP Pakete zurückschicken, na ja…
– Feedburner Redirect
durch das Update auf WP 2 ging zeitweise der Redirect aller RSS Anfragen auf Feedburner nicht mehr. Was das für die Last bedeutet, habe ich heute Morgen gesehen: Just nach 02:00 Uhr ging die Datendurchsatzrate vehement hoch. Zu diesem Zeitpunkt hatte ich auch auf WP2 umgestellt. Also schnell Feedburner-Plugin upgedatet und gut ist (siehe dazu Nutzen von Feedburner und Feedburner per ModRewrite)
– WP Cache
WP Cache habe ich ausgeschaltet, da es bei Spamattacken uninteressant ist. Es bringt nur was, wenn Massen echter User (grob ab +5.000 Besuchern pro Tag) auf dem Blog aufschlagen.
– WordPress DB-Connect Errors
WP neigt dazu, ungenaue Meldungen abzugeben. Wenn der Server ausgelastet ist, erscheint die klassische Fehlermeldung, dass die DB nicht erreichbar ist. Das stimmt aber nicht, die DB reagiert eben nur sehr langsam. Offensichtlich wartet WP eine bestimmte Zeit und je nachdem, was intern passiert (to many connections etc…) kommt immer nur diese eine Meldung.
– Nothinweis
Blogverzeichnis umbenennen (zB von ../blog/ auf ../blogstop/). Das stoppt die Spammer mit einem 404. In den ursprünglichen Blog-Pfad eine index.html legen, die den Usern erklärt, das man Probleme hat. Und möglicherweise auf ein Ersatzblog hinweisen, das noch läuft. Ich werde daher als Ausweichsquartier eines meiner Test-WordPress.com Accounts aktivieren, um dort via Blog mit den Lesern weiter kommunzieren zu können, sollte es wieder länger dauern, bis die Probleme bereinigt sind. Guter Hinweis, Frank, merci!
– in Planung
Einsatz von MOD Evasive geplant, Umstieg auf stärkeren Server mit mind. 1 GB RAM, Einsatz von Debian 3.x statt Suse 9.x, Einsatz von MySQL /PhP-Caching-Mechanismen.
Insgesamt also eine sehr zeitraubende Geschichte. Die einen manchmal richtiggehend abkotzen lässt, weil man ein Hobby betreibt, nicht aber einen Shop oder dergleichen, wo man das eben schlichtweg einkalulieren muss. An dieser Stelle ein mächtiges Dankeschön an Stebu, der meinen Blogarsch gerettet hat, ebenso an Jan, Mike und Stefan W.!!!
Weil ich keinen Bock mehr drauf habe, dass andere und ich Zeit für wildgewordene Spammerskripte zu investieren , wird es demnächst einen Werbepartner auf dem BT Blog (und anderen Blogs) geben. Damit kann ich die Zeitaufwendungen Dritter, die gestiegenden Hostingkosten wie auch meiner einer besser finanzieren.
