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 = .*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.

Etherpad unter Ubuntu installieren

Bei Etherpad handelt es sich um einen Editor für kollaboratives Schreiben, welcher selbst gehostet werden kann. Soll Etherpad unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend wird ein Nutzer für Etherpad angelegt und in diesen gewechselt werden und dort der Quellcode für Etherpad heruntergeladen und initial einmal gestartet und dann mittels Strg + C wieder beendet:

adduser --disabled-login --gecos "" etherpad
su - etherpad
git clone --branch master https://github.com/ether/etherpad-lite.git
cd etherpad-lite
npm install sqlite3
src/bin/run.sh

Nun werden einige Konfigurationen vorgenommen. Im Groben werden die Datenbank, die Authentifikation, Vorbereitungen für den Reverse Proxy, die Nutzer und die maximale Länge von einzufügendem Inhalt und das Log konfiguriert:

nano etherpad-lite/settings.json

Die Änderungen sind in ihrer Reihenfolge in der Konfigurationsdatei angegeben:

...

"dbType": "sqlite",
"dbSettings": {
  "filename": "var/sqlite.db"
},

...

"requireAuthentication": true,

...

"trustProxy": true,

...

"users": {
"admin": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": true
},
"user": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": false
}
},

...

"socketIo": {
/*
 * Maximum permitted client message size (in bytes). All messages from
 * clients that are larger than this will be rejected. Large values make it
 * possible to paste large amounts of text, and plugins may require a larger
 * value to work properly, but increasing the value increases susceptibility
 * to denial of service attacks (malicious clients can exhaust memory).
 */
"maxHttpBufferSize": 1048576
},

...

"logconfig" :
{ "appenders": [
    { "type": "console"
    //, "category": "access"// only logs pad access
    }

  , { "type": "file"
  , "filename": "etherpad.log"
  , "maxLogSize": 1024000
  , "backups": 3 // how many log files there're gonna be at max
    }

...

Anschließend wird der Kontext des Nutzers etherpad verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/etherpad.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Etherpad
After=syslog.target
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
Environment="NODE_ENV=production"
ExecStart=/home/etherpad/etherpad-lite/src/bin/run.sh
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable etherpad
systemctl start etherpad

Lokal ist der Service nun per HTTP unter dem Port 9001 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

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

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Etherpad port number
        proxy_pass http://localhost:9001;
    }
}

Damit steht Etherpad auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.

Foundry VTT unter Ubuntu als Service installieren

Bei Foundry VTT handelt es sich um eine Virtual Tabletop-Plattform, welche selbst gehostet werden kann. Daneben existieren Versionen für macOS und Windows. Soll Foundry VTT unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend kann ein Nutzer für Foundry VTT angelegt werden und in diesen gewechselt werden:

adduser --disabled-login --gecos "" foundryvtt
su - foundryvtt
mkdir foundry

Nachdem das aktuelle Release von Foundry VTT heruntergeladen wurde, sollte dieses im Ordner foundry entpackt werden:

cd foundry
unzip foundryvtt.zip
rm foundryvtt.zip

Anschließend wird der Kontext des Nutzers foundryvtt verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/foundryvtt.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Foundry VTT
After=syslog.target
After=network.target

[Service]
Type=simple
User=foundryvtt
Group=foundryvtt
ExecStart=/usr/bin/node /home/foundryvtt/foundry/resources/app/main.js --dataPath=/home/foundryvtt/foundrydata
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable foundryvtt
systemctl start foundryvtt

Lokal ist der Service nun per HTTP unter dem Port 30000 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

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

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Foundry VTT port number
        proxy_pass http://localhost:30000;
    }
}

Damit steht Foundry VTT auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt 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.