WP fail2ban ist ein Plugin zum Schutz von WordPress-Installationen vor Brute-Force-Angriffen. Installation und Konfiguration habe ich bereits im Artikel WordPress mit Fail2Ban vor Brute-Force-Angriffen schützen dokumentiert. Dieser Text beschäftigt sich mit der offiziellen Dokumentation des Plugins, bzw. dem Text, der sich als Dokumentation ausgibt.

Ich stelle hier meine Erwartung an eine Dokumentation heraus, zeige die Schwächen der exemplarisch ausgewählten Dokumentation heraus und gebe einen Tipp, wie man weniger schlechte Dokus schreibt. Ich schließe mit Fragen an meine Leserinnen und Leser und freue mich auf eure Rückmeldungen.

In meinen Augen sind folgende drei Abschnitte zwingender Bestandteil einer jeden Dokumentation:

1. Was ist dies für eine Anwendung? Wofür wird sie verwendet und wofür nicht?
2. Wie wird diese Anwendung installiert?
3. Wie wird diese Anwendung konfiguriert?

Die ersten beiden Punkte mag ich als erfüllt betrachten. Beim dritten Punkt sehe ich ein Problem.

Die Installationsanleitung ist prägnant. Sie enthält einen Link, der suggeriert, zur Konfigurationsanleitung zu führen. Dort erwartet den neugierigen Leser folgendes Bild.

Hier gibt es noch keine nützlichen Informationen zu sehen. Die Seite ist in meinen Augen überflüssig. Aber gut, ein Satz tut nicht weh. Mit einem Klick auf „Next“ geht es weiter.

Hier steht im Wesentlichen, dass Nutzer, welche sich bereits auskennen, zum nächsten Abschnitt gehen können. Leider finden sich für neue Nutzer hier kaum brauchbare Informationen. Der Hinweis, die Datei wp-config.php zu sichern, bevor man diese bearbeitet, ist nett, mehr nicht. Es wird erwähnt, dass die freie (im Sinne von Freibier) Version des Plugins durch Definition von Konstanten in der Datei wp-config.php konfiguriert wird. Wie so eine Konstante aussieht oder wo man weiterführende Informationen dazu findet, steht hier nicht. Ich habe an dieser Stelle entsprechende Hinweise erwartet. Gut, ich kann ja noch auf „Next“ klicken.

Auch in diesem Abschnitt findet sich keine Information, was man nun mit der Datei wp-config.php soll. Immerhin gibt es in Abschnitt 4.2.1. einen Link, der Nutzer, welche nicht mit der Konfiguration vertraut sind, zur Konfigurationsanleitung führen soll. Ich habe ein Déja Vu und fühle mich langsam ver…hohnepiepelt. Also klicke ich auf den nächsten LInk. Es heißt ja schließlich: „Was lange währt, wird endlich gut.“

TL;DR: Auch auf der nächsten Seite erfahren wir nichts über die wp-config.php.

Zur Erinnerung: Ich nutze die freie Version des Plugins WP fail2ban, welches angeblich durch die Definition von Konstanten in der Datei wp-config.php konfiguriert wird. Welche Konstanten dies sind und wie man diese konfiguriert, wird auch auf Seite 4 immer noch nicht mit einem Wort erklärt.

Stattdessen lernt man in Abschnitt „4.3.1.1. Typical Settings“, dass die Dateien wordpress-hard.conf und wordpress-soft.conf in das Verzeichnis fail2ban/filters.d zu kopieren sind. Hier wurden in meinen Augen zwei Fehler gemacht:

1. Es wird nicht erwähnt, wie man die Dateien wordpress-,{hard,soft}.conf erhält bzw. erstellt. Als unerfahrener Nutzer strandet man hier. Zum Glück hatte ich mir das damals aufgeschrieben.
2. Es wird eine relative Pfadangabe fail2ban/filters.d genutzt. Dies ist nicht ganz so wild, ich persönlich bevorzuge es, wenn vollständige Pfadangaben genutzt werden, damit Nutzer das entsprechende Verzeichnis sicher finden.

Fazit

Eine Dokumentation sollte die notwendigen Informationen bereitstellen, mit denen auch neue Nutzer eine Anwendung installieren und konfigurieren können. Dies ist nicht so leicht, wie es auf den ersten Blick erscheint, leiden Autoren, welche die Anwendung bereits kennen, doch häufig unter Betriebsblindheit und können sich nur schwer in die Rolle des unerfahrenen Nutzers versetzen.

Wenn ich selbst Dokumentationen schreibe, gebe ich diese meist Kolleginnen und Kollegen zu lesen und arbeite deren Rückmeldungen mit ein. Dies hat in der Vergangenheit zu deutlich besseren Ergebnissen geführt.

Die hier kritisierte Dokumentation ist ein Beispiel dafür. Sie befindet sich damit leider in guter Gesellschaft im Internet.

Ohne meinen Eingangs erwähnten Artikel hier im Blog wäre ich nicht in der Lage gewesen, mir dieses Plugin wieder einzurichten. Nun werde ich einige Tage prüfen, ob es wie erhofft arbeitet und dann ggf. einen Merge-Request mit einigen Verbesserungsvorschlägen einreichen.

Fragen an meine Leserinnen und Leser

Wie steht ihr zu Dokumentation? Ist das eher etwas für alte weiße Männer mit grauen Bärten? Oder wünscht ihr euch ebenfalls belastbare und ausführliche Dokumentationen zu den von euch verwendeten Anwendungen?

Tragt ihr selbst zu Dokumentationen bei? Welche Erfahrungen habt ihr dabei gemacht? Welche Tipps könnt ihr Schreiberlingen geben, die ihr Projekt dokumentieren möchten?

Bitte hinterlasst mir eure Antworten in den Kommentaren oder im Chat.

In diesem Teil beschreibe ich die Konfiguration von NGINX als Reverse-Proxy für mein Wochenend-Projekt „Nextcloud im Container“. Und was so langweilig klingt, wie lediglich die Direktive proxy_pass in die NGINX-Konfiguration einzufügen, dauerte dann doch überraschend lange.

Darüber hinaus dokumentiere ich die Konfiguration von fail2ban, um die Anmeldemaske der Nextcloud vor Brute-Force-Angriffen zu schützen.

Falls ihr Teil 1 und Teil 2 dieser Reihe noch nicht kennt, empfehle ich euch, diese Teile zuerst zu lesen.

Die Fehlschläge

Bevor ich zur aktuellen Konfig komme, möchte ich kurz die Fehlschläge auf dem Weg dorthin festhalten.

Nextcloud im Unterverzeichnis nicht so einfach wie gedacht

Auf meinem Server läuft bereits ein Dienst, welcher unter der URL https://www.example.com/service1 erreichbar ist. Mir gefiel die Idee, die Nextcloud unter einer URL wie https://www.example.com/service2 erreichbar zu machen.

Die Dokumentation des Container-Repos [3] ist in meinen Augen zu kurz geraten und reicht für eine erfolgreiche Konfiguration längst nicht aus.

Nachdem ich einiges über die Generierung von Back-to-URLs und Redirects gelesen und im Nextcloud-Forum gestöbert hatte, ließ ich die Idee fallen. Ich warte mal ab, wie sich Issue #401 entwickelt. Vielleicht greife ich die Idee später nochmal auf.

Falsche Back-to-URLs und Protokoll-Probleme

Im nächsten Versuch, sollte Nextcloud unter einer eigenen Domain wie nextcloud.example.com erreichbar sein. Doch auch hier klemmte es zunächst. Zuerst stolperte ich in den bekannten Untrusted-Domain-Fehler.

Diesen Fehler konnte ich schnell abstellen, da ich lediglich vergessen hatte die Variable NEXTCLOUD_TRUSTED_DOMAINS mit einem Wert zu belegen. Als Wert ist der FQDN einzutragen, unter dem die Nextcloud erreichbar sein soll. Dieser ist explizit anzugeben, da der Apache-Prozess innerhalb des Nextcloud-Containers den FQDN, auf den der NGINX-Reverse-Proxy lauscht und welcher im HTTP-Header übertragen wird, nicht kennt.

Des Weiteren musste ich noch die Variablen NEXTCLOUD_OVERWRITEPROTOCOL und NEXTCLOUD_OVERWRITECLIURL in vars/main.yml mit Werten belegen, um die entsprechenden Umgebungsvariablen für die Container-Instanz zu setzen (vgl. [3]). Dies ist notwendig, da die Anwendung im Nextcloud-Container andernfalls Back-to-URLs für das HTTP-Protokoll generiert. Versucht der Browser diese aufzurufen, erscheint ein Fehler oder man landet in einer endlosen Redirect-Schleife.

Nachdem ich die Nextcloud mit Hilfe der Ansible-Rolle [2] erneut deployt habe, war der Login-Screen erreichbar:

Der Weg hierher war für meinen Geschmack aufwändiger als er hätte sein müssen. Nur durch Lektüre und Recherche der Quellen unter [4], [5] und [6] konnte ich mich von Problem zu Problem hangeln und diese lösen. Hier ist in meinen Augen noch Raum für Verbesserungen.

Die aktuell funktionierende Konfiguration

Meine NGINX-vHost-Konfiguration habe ich mir mithilfe von [4], [5] und [6] zusammengesucht und bin bei folgender Konfig gelandet (es werden nur relevante Abschnitte wiedergegeben):

server {
	listen 80;
	listen [::]:80;
	server_name nextcloud.example.com;
	root /var/www/nextcloud.example.com;
	index index.html;
[...]
	return 301 https://$server_name$request_uri;
	location ^~ /.well-known/acme-challenge/ {
	default_type "text/plain";
	root /var/www/nextcloud.example.com;
	}
	location = /.well-known/acme-challenge/ {
	return 404;
	}
}
server {
    # Listen on Port 443
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name nextcloud.example.com;
[...]
    root /var/www/nextcloud.example.com;
[...]
	location ^~ /.well-known/acme-challenge/ {
	default_type "text/plain";
	root /var/www/nextcloud.example.com;
	}
	location = /.well-known/acme-challenge/ {
	return 404;
	}

        location / {
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	add_header Front-End-Https on;
       	proxy_pass http://127.0.0.1:40231;
        }

	location /.well-known/carddav{
		return 301 $scheme://$host/remote.php/dav;
	}

	location /.well-known/caldav {
		return 301 $scheme://$host/remote.php/dav;
	}
}

Ob dies eine gute Konfiguration ist, mag ich nicht beurteilen. Sie funktioniert zumindest. Die Nextcloud ist erreichbar und über die Weboberfläche können weitere Einstellungen vorgenommen, Nutzerkonten erstellt und Apps installiert werden.

Fail2ban für Nextcloud

Nun steht die Nextcloud mit ihrer Login-Maske im Wind. Sie stellt damit ein schönes Ziel für Brute-Force-Angriffe dar. Um es den Angreifern nicht zu leicht zu machen, habe ich für den Nextcloud-Admin keinen einfach zu erratenen Namen wie Admin, Nextcloud-Admin oder meinen Namen verwendet. Um Angreifer weiter auszubremsen, konfiguriere ich fail2ban. Wie dies installiert wird, schlagt bitte in der Dokumentation eurer Distribution nach. Ich gehe hier nicht auf die Installation ein.

Damit fail2ban fehlgeschlagene Anmeldeversuche erkennt, habe ich die Datei /etc/fail2ban/filter.d/filter.d/jk_nextcloud.conf mit folgendem Inhalt erstellt:

[Definition]
_groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*)
failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:
            ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error.
datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"

Dieser Filter wird in der Datei /etc/fail2ban/jail.d/jk_nextcloud.local referenziert:

[jk_nextcloud]
backend = auto
enabled = true
port = 80,443
protocol = tcp
filter = jk_nextcloud
maxretry = 3
bantime = 86400
findtime = 43200
logpath = /home/tronde/.local/share/containers/storage/volumes/nc_data/_data/nextcloud.log

Wenn innerhalb der findtime von 43200 Sekunden von einer IP-Adresse mehr als drei fehlgeschlagene Anmeldeversuche (maxretry) registriert werden, wird die entsprechede IP-Adresse für 86400 Sekunden (bantime) gesperrt. Eine Statusabfrage ist wie folgt möglich:

$ sudo fail2ban-client status jk_nextcloud
[sudo] password for tronde: 
Status for the jail: jk_nextcloud
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	5
|  `- File list:	/home/tronde/.local/share/containers/storage/volumes/nc_data/_data/nextcloud.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	1
   `- Banned IP list:

Es ist zu erkennen, dass aktuell keine IP-Adresse gesperrt ist. In der Vergangenheit wurde jedoch bereits eine IP gebannt.

Für mich stellt fail2ban einen Baustein zur Sicherung der Nextcloud bereit. Zusätzlich werde ich eine Zwei-Faktor-Authentisierung konfigurieren, um die Sicherheit weiter zu steigern.

Zusammenfassung

An diesem Punkt meines Wochenend-Projekts kann ich eine Nextcloud-Instanz mit meiner Ansible-Rolle deployen und hinter einem Reverse-Proxy nutzen. Bisher schützt fail2ban vor Brute-Force-Angriffen. Zukünftig wird jedoch eine Zwei-Faktor-Authentisierung diesen Schutz verstärken.

Eine lauffähige Konfiguration zu erstellen, hat dabei länger gedauert, als ich mir vorgestellt habe. Dabei hat mir missfallen, dass dies nicht mit der Dokumentation allein gelang, sondern das Forum [5] und die Internetsuchmaschine meines geringsten Misstrauens zurate gezogen werden mussten. Damit ist dieses Projekt jedoch bei weitem kein Einzelfall.

307 offene Issues (Stand 05.02.2022) zeugen davon, dass hier noch längst nicht alles rund läuft. Von der Idee, dass es sich hierbei um ein Fire-and-Forget-Projekt handeln könnte, verabschiede ich mich lieber. So bin ich auch gleich in das unter [7] beschriebene Problem getreten. Erfreulicher Weise hat die dort beschriebene Lösung funktioniert, so dass meine Cloud mir jetzt E-Mails senden kann. Ich werde mir Gedanken machen, wie die entsprechenden Abschnitte in der Dokumentation verbessert werden können und dem Projekt einen Pull-Request senden. Mal schauen wie man darauf reagiert.

Damit sind die in Teil 1 formulierten Ziele 1-3 erreicht. In Teil 4 beschäftige ich mich mit einigen weiteren Steinen, über die ich gestolpert bin, bevor ich mich dann in Teil 5 dem Thema Backup & Recovery widme.

Quellen und weiterführende Links

1. Nextcloud im Container — Teil 1: Der Plan
2. Nextcloud im Container — Teil 2: Die Ansible-Rolle
3. Using the apache image behind a reverse proxy and auto configure server host and protocol
4. https://github.com/nextcloud/docker
5. https://help.nextcloud.com/
6. https://docs.nextcloud.com/server/latest/admin_manual/
7. Email settings gets wrong senEmail settings gets wrong sender domain, fails due to not RFC compliant