Fail2ban für WordPress einrichten

Beim Betrieb eines Servers wird der Nutzer schnell feststellen, dass er nicht der einzige ist, der gerne Zugriff auf den Ser­ver hätte. Um zu häu­fige Log­in­ver­su­che abzu­blo­cken, gibt es Fail2ban. Die­ses Pro­gramm­pa­ket durch­sucht die ent­spre­chen­den Logs und blockiert bös­wil­lige Ver­su­che, in das Sys­tem ein­zu­bre­chen. Damit gehört Fail2ban zu den Intru­sion Preven­tion-Sys­te­men. Damit kann es auch zur Auswertung von Login-Versuchen auf die eigenen WordPress-Installationen genutzt werden. Wer in die Logs schaut, wird dort ähnliche Zeilen finden:

18.217.216.181 – – [23/Nov/2021:19:32:40 +0100] „POST /wp-login.php HTTP/1.1“ 200 8408 „https://seeseekey.net/wp-login.php“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0“

Um WordPress mit Fail2ban zu verheiraten muss ein einsprechender Jail und ein Filter angelegt werden. Was mich im Vorfeld in Bezug auf WordPress irritierte war der Statuscode 200, wenn ein Login in WordPress fehlschlägt. Hintergrund ist hier das WordPress bei einem erfolgreichen Login stattdessen den Statuscode 302 (Found) nutzt. Damit kann im ersten Schritt der Jail für Fail2ban erstellt werden:

nano /etc/fail2ban/jail.d/wordpress.conf

Diese Datei wird nun wie folgt befüllt:

[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 3

Anschließend muss der genutzte Filter ebenfalls angelegt werden:

nano /etc/fail2ban/filter.d/wordpress.conf

Der entsprechende Filter sieht wie folgt aus:

# Filter for WordPress login

[INCLUDES]

before = common.conf
 
[Definition]

failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).* 200

datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

Nach einem Neustart von Fail2ban mittels:

service fail2ban restart

ist der neue Jail aktiv. Über das Log kann die Arbeit desselben betrachtet werden:

tail -f /var/log/fail2ban.log

Damit sind die WordPress-Installationen gegen den Versuch unbefugter Logins besser abgesichert. Nach drei Fehlversuchen, wird die entsprechende IP-Adresse gesperrt, sodass weitere Verbindungsversuche von dieser IP-Adresse vom Server nicht mehr beantwortet werden.

Redirect 301 vs. 302

Wenn von einer Webseite auf eine andere Webseite umgeleitet wird, so wird hierfür meist der HTTP-Statuscode 301 oder 302 genutzt. Der Statuscode 301 leitet eine Anfrage permanent zur angegebenen URL um, während der Statuscode 302 früher für die temporäre Umleitung gedacht war. Unter Nginx könnte eine solche Umleitung wie folgt aussehen:

server {
  listen   443 ssl;
  listen [::]:443 ssl;

  server_name .example.com;

  return 301 https://example.org;
}

In diesem Fall würde alle Anfragen von example.com auf die URL https://example.org umgeleitet. Der Statuscode 301 zeigt dem Client hierbei an, dass die Umleitung permanent ist. Dies ist z.B. wichtig bei Suchmaschinen; sie würden der neuen URL mehr Beachtung schenken und die alte URL unter Umständen schneller aus dem Index entfernen. Der Statuscode 302 ist mittlerweile nicht mehr als Moved Temporarily, sondern als Found definiert.

Neben diesen Statuscodes, existieren eine Reihe weitere Statuscodes wie 303 (See Other), 307 (Temporary Redirect) und 308 (Permanent Redirect). Im Gegensatz zu den Statuscodes 301, 302 und 303 wird bei den neueren Statuscodes 307 und 308, das angefragte HTTP-Verb beibehalten. Fragt der Clients in einem solchen Fall mit dem HTTP-Verb POST an, so bleibt dieses bei der Weiterleitung bestehen.