In der Umfrage von Netcraft monatlich gemessenen Verbreitung von Webservern hat im März 2024 Nginx vor Apache den Spitzenplatz verteidigt.

Der langjährige Nginx-Entwickler Maxim Dounin hat mit Freenginx einen Fork des populären freien Webservers Nginx angekündigt. Dounin zeigt sich unzufrieden mit dem Nginx-Eigner F5.

Maxim Dounin, einer der Hauptentwickler des Webservers Nginx stellt mit Freenginx einen Fork vor, um die Software frei von willkürlichen Firmenentscheidungen zu halten.

Quelle

DigitalOcean, ein Cloudservice Anbieter, bietet auf seiner Webseite eine kleine Toolsammlung an. Teil dieser Sammlung ist NGINXConfig, ein auf nodeJS basierendes Nginx Konfigurations-Tool.

Als Vorbild diente unter anderem der Mozilla SSL Config Generator, denn genauso wie das Mozilla Tool bietet NGINXConfig einige extra Optionen an.

Angefangen von PHP Unterstützung, bis zur Certbot Einbindung oder dem Reverse Proxy lassen sich granular Optionen setzen. Selbst Security Optionen wie Request Limiter oder Beschränkungen für GET/POST sind konfigurierbar.

Alleine als Übersicht für verfügbare Nginx Features ist das Tool sehr praktisch:

• HTTPS
• HTTP/2
• IPv6
• certbot
• HSTS
• security headers
• SSL profile
• OCSP
• resolvers
• caching
• gzip
• brotli
• fallback
• routing
• reverse
• proxy
• www/non-www
• redirect
• CDN
• PHP (TCP/socket WordPress, Drupal, Magento, Joomla)
• Node.js support
• Python (Django) server
• etc.

Nachdem du alle gewünschten Optionen gesetzt hast, kannst du die komplette Konfiguration herunterladen oder kopieren. Parallel dazu kannst du die Setup Routine durchlaufen, die dich Schritt für Schritt bis zum Anschalten deiner Konfiguration führt.

Praktischerweise ist NGINXconfig Open Source und du kannst es auf deinen eigenen Server packen oder verbessern und aktualisieren.

Zusätzlich findest du noch weitere praktische Tools in der Digital Ocean Sammlung:

• SPF Explainer
• DNS Lookup
• Bandwidth Calculator
• JavaScript Minify Tool

 

Sicherheit in der Cloud und auf Servern generell hält viele Administratoren ständig auf Trab. Wie immer bei Linux führen auch hier viele Wege zum Ziel.

Quelle

Netcraft hat in seiner Webserver-Analyse für den November 2022 die Antworten von rund 1.13 Milliarden Webseiten mit rund 271 Millionen Domains und 12,3 Millionen Computern im Web ausgewertet. Nginx bleibt trotz Verlusten bei Webseiten und Domains führend bei den Webseiten insgesamt.

Der November hat laut Netcraft gegenüber dem Vormonat einen Zuwachs von 4,7 Millionen Websites ergeben und einen Verlust von 194.480 Domains und einem Zuwachs von 6685 im Internet sichtbaren Computern gebracht.

Das größte Wachstum m November habe Cloudflare hingelegt und 8,3 Millionen Websites (plus 8,91 Prozent) und 490.000 Domains (plus 1,94 Prozent) hinzugewonnen.

Nginx habe Verluste bei der Zahl der Websites und Domains hinnehmen müssen und 8,5 Millionen Websites und 490.000 Domains verloren. Dennoch bleibe Nginx mit einem Marktanteil von 26,51 Prozent die am weitesten verbreitete Webserver-Software. Apache habe mit einem Marktanteil von 21,40 Prozent die zweitgrößte Anzahl von Websites. Es folgen Cloudflare mit 8,9 Prozent und OpenResty mit 8 Prozent.

Der Beitrag Webserver Survey: Nginx bleibt führend erschien zuerst auf Linux-Magazin.

NGINX ist ein beliebter Webserver und Reverse Proxy, der in Konkurrenz zum Apache Webserver steht. Jetzt steht ein Fork bereit, der mehr Funktionalität bieten möchte.

Quelle

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