Spamschutz für WordPress auf Serverebene

Spammer die Kommentare unter Blogpost loswerden wollen sind ebenso lästig wie Wespen im August auf dem Erdbeerkuchen.

Wie also verhinderst oder verminderst du Spam auf deinem WordPress Blog?
Eine Mögliche Antwort könnte lauten: dafür gibt es doch das AntispamBee Plugin von Sergej Müller ?
Ja, ein tolles Plugin, welches auch auf  jeder meiner WordPress Installationen einen sicheren Platz  inne hat.

Ja, aber das Problem ist: wenn das Plugin von Sergej seiner Bestimmung nachkommt, ist der Spammer bereits über den Apache-Webserver, die wp-comments-post.php bis zum AntispamBee  Plugin durchgedrungen. Bei vielen  Spamversuchen und / oder auch vielen laufenden Blogs auf einem Server summiert sich die “Last” PHP zu interpretieren.

Wie sieht nun die Lösung aus, WordPress auf Serverebene gegen Spam zu schützen?

Daher liegt die Idee nahe, erkannten Spam – der durchaus  seine Spuren im Webserver Logfile hinterlassen kann – schon VOR dem Zugriff auf den Apache-Webserver serverseitig mittels Firewallregeln (iptables) zu blockieren. Da Admins ja bequeme Menschen sind, ist Handarbeit an dieser Stelle einfach „to much“ und es muss eine automatisierte Möglichkeit her.

Mögliche Lösung: kombiniere AntispamBee mit Fail2ban.

Fail2ban ist ein in Python geschriebenes Analyse Tool, welches Logfiles mittels regulären Ausdrücken scannt und bei gefundenen Treffern eine Aktion -eine iptables Regel-  erstellt.
Dabei ist Fail2ban im Prinzip für jede Linux Distribution verfügbar.

Wie funktioniert die Kombination AntispamBee und Fail2ban nun im Detail?

Das ist recht einfach und auch fix eingerichtet: lediglich eine  AptispamBee Einstellungen muss passen, Fail2ban muss installiert sein und einige Fail2ban Konfigurationen müssen angelegt, bzw. angepasst werden.

1. AntispamBee Einstellungen

Das Plugin bietet im Dashboard unter „Einstellungen => AntispamBee => Erweitert“ die Möglichkeit erkannten Spam zu kennzeichnen und nicht löschen. Diese Option muss deaktiviert sein. Dann versieht AntispamBee jeden Zugriff auf die wp-comments-post.php mit dem HTTP-Status Code 403 (Forbidden). Dieser Statuscode wiederum wird im  Logfile des Webservers / virtuellen Hosts geloggt.

2. Fail2ban einrichten

Ich gehe davon aus, dass jeder Betreiber eines RootServers das Installationspaket seiner Distribution installieren kann, so dass ich mich an dieser Stelle lediglich auf die Implementierung der AntispamBee Regeln in Fail2ban beschränke. Falls das nicht der Fall ist, hilft die offizielle Fail2ban Dokumentation weiter.
Grunsdätzlich arbeitet Fail2ban mit Jails, in denen Filterregeln referenziert werden.
Um nun also Fail2ban mit dem 403 Forbidden-Logeintrag zusammen zu binden, legt man in der Datei /etc/fail2ban/jail.local einen zusätzlichen/neuen Jail an, der so aussehen könnte:

[apache-wordpressspam]
enabled = true
logpath = /var/log/apache2/*error.log
        /var/www/andererpfad/logs/access_log
filter = apache-wpcomment
maxretry = 1
bantime = 2592000

Möchte man fail2ban mehrere Logfiles füttern ist das mit der „logpath“ Angabe (Version 0.8.13) problemlos möglich.
Der Parameter „maxretry“ habe ich an dieser Stelle ganz hart auf Eins gesetzt, so dass Spamversuche minimiert werden.
Den Parameter „findtime“ habe ich in diesem Jail weggelassen, so dass Fail2ban den gesetzten Standardwert (2592000 Sekunden) benutzt.
Bei dem Parameter „filter“ gibt man den Namen (ohne Suffix) der Konfigurationsdatei unter /etc/fail2ban/filter.d/ an; in diesem Falle heisst das Konfigurationsfile apache-wpcomment.conf und kann folgenden Inhalt haben:

[Definition]
failregex = ^.* - - .*"POST /wp-comments-post.php HTTP.*" 403 [0-9]{1,} ".+" ".+"$
ignoreregex =

Dabei ist in Fail2ban eine predefinierte Entity, damit man Hostnamen/IP-Addressen von Spamern nicht immer mit dem regulären Ausdruck

(?:::f{4,6}:)?(?PS+)

beschreiben muss. Zum Abschluß wird Fail2ban noch neu geladen, damit der neue Jail auch angezogen wird.
Überprüfen kann man das erfolgreiche Anlegen des neuen Jails entweder mit

less /var/log/fail2ban.log

oder mit

iptables -nL

In beiden Fällen sollte der neue Jail „apache-wordpressspam“ dort zu sehen sein.
Ist dies nicht der Fall, so erhöht man in der /etc/fail2ban/fail2ban.conf den Loglevel auf Vier (4 = Debug) und startet Fail2ban danach neu um mehr Informationen im fail2bal.log zu bekommen.
Das war’s auch schon an Aufwand um WordPress  effizient auf  Serverebene vor Spammern zu schützen.
Ihr seht, dass ist fix gemacht und ich wünsche Euch zum Abschluss „happy spam hunting“ 🙂