Warum Webanwendungen zusätzlichen Schutz benötigen

Ob Nextcloud, Kundenportal, Webshop oder eine individuell entwickelte Unternehmensanwendung: Immer mehr geschäftskritische Dienste sind über das Internet erreichbar. Damit steigen auch die Anforderungen an den Schutz dieser Systeme.

Eine klassische Netzwerk-Firewall ist dabei ein wichtiger Bestandteil der IT-Sicherheit. Sie regelt, welche Netzwerkverbindungen erlaubt sind. Angriffe, die über reguläre HTTPS-Verbindungen erfolgen, lassen sich damit jedoch nicht automatisch erkennen.

Eine zusätzliche Sicherheitsebene kann eine Web Application Firewall (WAF) schaffen. Eine interessante Open-Source-Lösung dafür ist BunkerWeb.

Was ist BunkerWeb?

BunkerWeb ist eine auf NGINX basierende Web Application Firewall, die gleichzeitig als Reverse Proxy eingesetzt werden kann.

Die Software nimmt eingehende HTTP- und HTTPS-Anfragen entgegen, untersucht sie anhand verschiedener Sicherheitsmechanismen und leitet zulässige Anfragen an den eigentlichen Webserver weiter.

Dadurch entsteht eine zusätzliche Schutzschicht zwischen dem Internet und der Webanwendung.

BunkerWeb lässt sich beispielsweise unter Linux, in Docker-Umgebungen oder mit Kubernetes betreiben. Zur Verwaltung steht eine Weboberfläche zur Verfügung.

Wie schützt BunkerWeb Webanwendungen?

1. ModSecurity und OWASP Core Rule Set

Eine zentrale Sicherheitsfunktion ist die Integration von ModSecurity mit dem OWASP Core Rule Set (CRS).

Das Regelwerk untersucht HTTP-Anfragen auf bekannte Angriffsmuster. Dazu zählen unter anderem:

SQL-Injection-Angriffe
Cross-Site Scripting (XSS)
Manipulierte HTTP-Anfragen
Verdächtige Parameter und Eingaben
Versuche, bekannte Anwendungsschwachstellen auszunutzen

Bei entsprechenden Treffern können Anfragen protokolliert oder blockiert werden.

Ein wichtiger Punkt ist die Abstimmung der Sicherheitsregeln auf die jeweilige Anwendung. Nicht jede ungewöhnliche HTTP-Anfrage ist automatisch ein Angriff.

Gerade Anwendungen mit WebDAV oder speziellen API-Aufrufen benötigen gegebenenfalls gezielte Regelausnahmen, damit legitime Funktionen nicht beeinträchtigt werden.

2. CrowdSec: Verhaltensbasierte Angriffserkennung

Eine weitere interessante Ergänzung ist CrowdSec.

CrowdSec analysiert unter anderem Protokolldaten und erkennt verdächtiges Verhalten, beispielsweise automatisierte Angriffsversuche oder wiederholte Zugriffe auf bekannte Schwachstellen.

Erkannte Angreifer können durch entsprechende Sperrentscheidungen vom weiteren Zugriff ausgeschlossen werden.

Über die Integration in BunkerWeb lassen sich diese Entscheidungen direkt bei eingehenden Webanfragen berücksichtigen.

Zusätzlich kann CrowdSec AppSec HTTP-Anfragen anhand von Anwendungssicherheitsregeln untersuchen.

Die Kombination aus OWASP CRS und CrowdSec verbindet damit regelbasierte Prüfungen mit verhaltensbasierter Angriffserkennung.

3. Geoblocking und IP-Filter

Nicht jede Unternehmensanwendung muss weltweit erreichbar sein.

BunkerWeb ermöglicht eine geografische Einschränkung von Zugriffen. Beispielsweise kann der Zugriff auf bestimmte Anwendungen auf ausgewählte Länder begrenzt werden.

Darüber hinaus lassen sich IP-Blacklists verwenden, um bekannte unerwünschte Quellen oder bestimmte automatisierte Zugriffe zu blockieren.

Auch bekannte Tor-Exit-Nodes können über entsprechende Listen berücksichtigt werden.

Solche Filter reduzieren potenziell unerwünschten Datenverkehr, bieten jedoch keinen vollständigen Schutz vor Angriffen. Auch IP-Adressen aus erlaubten Ländern können für Angriffe verwendet werden.

4. Schutz vor automatisierten Angriffen

BunkerWeb bietet weitere Sicherheitsfunktionen wie Verbindungsbegrenzungen, Request-Limits und die Erkennung auffälligen Verhaltens.

Damit lassen sich beispielsweise bestimmte Formen automatisierter Zugriffe oder wiederholte verdächtige Anfragen einschränken.

Die Konfiguration muss allerdings zur Anwendung passen. Zu strenge Limits können insbesondere bei Synchronisierungsdiensten oder größeren Dateiübertragungen zu Problemen führen.

5. HTTPS und Zertifikatsverwaltung

Für eine sichere Verbindung zwischen Browser und Webserver ist HTTPS unverzichtbar.

BunkerWeb unterstützt die Verwendung von TLS-Zertifikaten und die automatisierte Zertifikatsverwaltung über Let's Encrypt.

Bei der Einrichtung müssen die verwendeten Validierungsverfahren und die Erreichbarkeit der dafür notwendigen Endpunkte berücksichtigt werden.

Praxisbeispiel: Nextcloud durch eine WAF schützen

Ein mögliches Einsatzgebiet von BunkerWeb ist die Absicherung einer selbst gehosteten Nextcloud-Instanz.

In dieser Architektur wird BunkerWeb als Reverse Proxy zwischen das Internet und den Nextcloud-Server geschaltet.

Die eingehenden HTTPS-Anfragen werden zunächst von der WAF überprüft. Erst anschließend werden zulässige Anfragen an Nextcloud weitergeleitet.

Auf diese Weise kann die Angriffsfläche durch verschiedene Sicherheitsmechanismen zusätzlich reduziert werden.

Besonderheiten bei Nextcloud

Nextcloud nutzt verschiedene HTTP-Methoden, WebDAV-Schnittstellen, Datei-Uploads und Synchronisierungsverfahren.

Eine ungeprüfte Standardkonfiguration einer WAF kann deshalb legitime Anfragen blockieren. Diese sogenannten False Positives können beispielsweise dazu führen, dass Dateiübertragungen oder Synchronisierungsvorgänge fehlschlagen.

Für OWASP CRS existieren spezielle Nextcloud-Regelausnahmen, die bekannte Kompatibilitätsprobleme berücksichtigen.

Trotzdem sind nach der Einrichtung ausführliche Funktionstests notwendig, insbesondere für:

Anmeldung und Mehrfaktor-Authentifizierung
Datei-Uploads und Downloads
WebDAV und Desktop-Synchronisierung
Mobile Nextcloud-Anwendungen
Kalender- und Kontakte-Synchronisierung
Zusätzlich installierte Nextcloud-Apps

Welche Vorteile bietet die Open-Source-Lösung?

Ein Vorteil von BunkerWeb ist die Verfügbarkeit einer Open-Source-Version mit zahlreichen Sicherheitsfunktionen.

Die Lösung lässt sich flexibel in unterschiedliche IT-Umgebungen integrieren und mit weiteren Sicherheitssystemen kombinieren.

Daneben existieren kommerzielle Zusatzfunktionen und Supportangebote.

Open Source bedeutet allerdings nicht, dass der Betrieb ohne Aufwand möglich ist. Installation, Sicherheitsupdates, Zertifikatsmanagement, Überwachung und laufende Regelpflege müssen weiterhin gewährleistet sein.

Ersetzt eine Web Application Firewall andere Sicherheitsmaßnahmen?

Nein. Eine WAF ist eine zusätzliche Schutzmaßnahme, aber kein Ersatz für eine sichere Webanwendung.

Regelmäßige Sicherheitsupdates, sichere Authentifizierung, eine durchdachte Rechtevergabe, Netzwerksegmentierung und zuverlässige Backups bleiben unverzichtbar.

Auch eine korrekt konfigurierte WAF kann nicht jede Schwachstelle oder jede Angriffstechnik zuverlässig erkennen.

Den größten Nutzen bietet sie als Bestandteil eines mehrstufigen IT-Sicherheitskonzepts.

Fazit: BunkerWeb als zusätzliche Sicherheitsebene

BunkerWeb ist eine interessante Möglichkeit, öffentlich erreichbare Webanwendungen mit einer zusätzlichen Schutzschicht abzusichern.

Besonders die Kombination aus ModSecurity, OWASP Core Rule Set, CrowdSec und anwendungsspezifischen Sicherheitsregeln bietet vielfältige Möglichkeiten, verdächtige Zugriffe zu erkennen und zu blockieren.

Entscheidend sind jedoch eine fachgerechte Einrichtung, die Anpassung an die jeweilige Webanwendung und eine regelmäßige Kontrolle der Sicherheitsereignisse.

Unterstützung durch Systemhaus Schulz

Systemhaus Schulz unterstützt Unternehmen bei der Planung, Einrichtung und Absicherung ihrer IT-Infrastruktur.

Dazu gehören auch die Bereitstellung und Härtung von Webanwendungen, Reverse-Proxy-Systemen sowie die Integration geeigneter Sicherheitslösungen.

Sie betreiben Nextcloud, ein Kundenportal oder andere öffentlich erreichbare Webanwendungen?

Gerne unterstützen wir Sie dabei, bestehende Sicherheitsmaßnahmen zu überprüfen und geeignete Schutzkonzepte umzusetzen.

Kontaktieren Sie Systemhaus Schulz für eine individuelle Beratung.

Webserver sicher veröffentlichen: Welche WAF-Lösungen gibt es?

Wer einen Webserver aus dem Internet erreichbar machen möchte, sollte sich nicht ausschließlich auf eine einfache Portweiterleitung verlassen.

Das gilt für zahlreiche Anwendungen: WordPress-Webseiten, Onlineshops, Nextcloud, Kundenportale, ERP-Systeme, Web-APIs und individuell entwickelte Unternehmensanwendungen.

Eine klassische Netzwerk-Firewall kann den Zugriff auf bestimmte Ports begrenzen. Eine einfache Destination-NAT-Regel (DNAT) leitet jedoch nur Verbindungen weiter und prüft nicht automatisch, ob eine HTTP-Anfrage einen Angriff auf die Webanwendung enthält.

Eine Web Application Firewall (WAF) kann hier eine zusätzliche Sicherheitsebene schaffen. Je nach Infrastruktur kommen verschiedene Betriebsmodelle infrage.

Option 1: Integrierte WAF einer bestehenden Firewall

Einige professionelle Firewall-Systeme bieten bereits Funktionen zum Schutz veröffentlichter Webanwendungen.

Ein Beispiel ist die Web Server Protection beziehungsweise Web Application Firewall geeigneter Sophos-Firewall-Systeme.

Damit können HTTP- und HTTPS-Anfragen über eine Reverse-Proxy-Funktion geprüft werden, bevor sie den eigentlichen Webserver erreichen.

Wer eine solche Funktion bereits zur Verfügung hat, benötigt nicht zwangsläufig einen zusätzlichen BunkerWeb-Server.

Vor der Einrichtung sollten jedoch die unterstützten Funktionen, die Firmware-Version, die Lizenzbedingungen und die Kompatibilität mit der jeweiligen Webanwendung überprüft werden.

Option 2: Eigene Web Application Firewall mit BunkerWeb

Verfügt die vorhandene Netzwerk-Firewall nicht über eine geeignete WAF-Funktion, kann eine separat betriebene Web Application Firewall eingesetzt werden.

Hierfür eignet sich beispielsweise BunkerWeb als NGINX-basierter Reverse Proxy mit ModSecurity, OWASP Core Rule Set und optionaler CrowdSec-Integration.

BunkerWeb kann auf einem eigenen Linux-Server oder einer virtuellen Maschine betrieben werden. Auch containerbasierte Bereitstellungsformen sind möglich.

Die Vorteile einer selbst betriebenen Lösung sind die Kontrolle über die Konfiguration, die Integration in die bestehende Infrastruktur und die Möglichkeit, Sicherheitsregeln an eigene Anwendungen anzupassen.

Demgegenüber stehen der zusätzliche Betriebsaufwand für Updates, Monitoring, Ausfallsicherheit, Zertifikate und regelmäßige Sicherheitsprüfungen.

Option 3: Cloud-WAF ohne eigene virtuelle Maschine

Wer keine zusätzliche VM betreiben möchte, kann eine cloudbasierte Web Application Firewall verwenden.

Bei einer solchen Lösung wird der öffentliche Webverkehr zunächst über den Dienst eines externen Anbieters geleitet. Dort können HTTP- und HTTPS-Anfragen auf verdächtige Muster untersucht werden, bevor sie den eigentlichen Webserver erreichen.

Cloudflare Web Application Firewall

Ein bekanntes Beispiel ist Cloudflare. Über den Cloudflare-Reverse-Proxy lassen sich Webseiten und Webanwendungen mit verschiedenen Sicherheitsfunktionen schützen.

Je nach Tarif und aktivierten Funktionen stehen unter anderem verwaltete WAF-Regeln, individuelle Filter, Bot-Schutz und Schutzmechanismen gegen bestimmte DDoS-Angriffe zur Verfügung.

Für den Betrieb ist keine separate lokale WAF-VM erforderlich. Allerdings muss die Domain korrekt über Cloudflare geleitet und der Ursprungsserver entsprechend abgesichert werden.

Weitere Informationen: Cloudflare WAF

Weitere Cloud-WAF-Alternativen

Neben Cloudflare existieren andere Anbieter, die Webanwendungen über vorgelagerte Sicherheitsdienste schützen können:

Sucuri Website Firewall: Cloudbasierter Reverse Proxy mit WAF-Funktionen, insbesondere für Webseiten und Content-Management-Systeme.
Fastly Next-Gen WAF: Bietet verschiedene Betriebsmodelle, darunter Edge- und Cloud-WAF-Bereitstellungen.
AWS WAF: Kann beispielsweise in Verbindung mit Amazon CloudFront eingesetzt werden, um HTTP-Anfragen anhand definierter Regeln zu prüfen.

Die Produkte unterscheiden sich hinsichtlich unterstützter Anwendungen, Funktionsumfang, Kosten, Konfigurationsmöglichkeiten und Integration in bestehende Infrastrukturen.

Bei der Auswahl sollten auch Datenschutzanforderungen, Auftragsverarbeitung, Datenstandorte und die Verarbeitung von Protokoll- und Anfragedaten berücksichtigt werden.

Wichtig bei Cloud-WAF-Lösungen: Den Ursprungsserver schützen

Eine Cloud-WAF bietet nur dann einen wirksamen vorgelagerten Schutz, wenn Angreifer den eigentlichen Webserver nicht einfach direkt über dessen öffentliche IP-Adresse erreichen können.

Deshalb müssen die Zugriffe auf den Ursprungsserver entsprechend eingeschränkt werden.

Je nach Anbieter und Infrastruktur können hierfür Firewallregeln, authentifizierte Verbindungen zum Ursprungsserver oder geeignete Tunnel-Lösungen eingesetzt werden.

Bei Cloudflare kommen beispielsweise die Einschränkung auf vertrauenswürdige Proxy-Verbindungen, Authenticated Origin Pulls und Cloudflare Tunnel infrage.

Die sichere TLS-Konfiguration zwischen Cloud-WAF und Ursprungsserver ist ebenfalls wichtig.

Welche Lösung ist die richtige?

Lösung	Eigene WAF-VM	Besonderheit
Integrierte WAF, beispielsweise Sophos	Nein	Einbindung in eine vorhandene Firewall
BunkerWeb	Bei VM-Betrieb ja	Selbst verwaltete WAF mit flexibler Konfiguration
Cloudflare WAF	Nein	Cloudbasierter Schutz über Reverse Proxy
Sucuri, Fastly oder AWS WAF	In den genannten Cloud-Betriebsmodellen nein	Weitere vorgelagerte Sicherheitsangebote

Welche Variante sinnvoll ist, hängt unter anderem von der bestehenden Firewall, den betrieblichen Anforderungen, den verfügbaren Ressourcen und den gewünschten Sicherheitsfunktionen ab.

Eine einfache NAT-Portweiterleitung ist nicht automatisch unsicher. Sie bietet aber für sich genommen keine anwendungsspezifische Angriffserkennung durch eine WAF.

Unabhängig von der gewählten Lösung bleiben regelmäßige Sicherheitsupdates, eine sichere Authentifizierung, restriktive Zugriffsrechte und eine sorgfältige Serverkonfiguration erforderlich.

Im folgenden Praxisbeispiel: BunkerWeb mit Nextcloud

Nachdem die grundsätzlichen Möglichkeiten zur Absicherung öffentlich erreichbarer Webserver vorgestellt wurden, konzentriert sich die folgende technische Anleitung auf die Installation und Konfiguration von BunkerWeb.

Als Beispielanwendung dient Nextcloud. Das dargestellte Sicherheitskonzept lässt sich jedoch grundsätzlich auch auf andere Webserver und Webanwendungen übertragen. Die jeweils benötigten WAF-Regelausnahmen müssen an die betreffende Anwendung angepasst werden.

Praxisanleitung: BunkerWeb als Web Application Firewall für Nextcloud einrichten

Im folgenden Praxisbeispiel zeigen wir, wie eine selbst gehostete Nextcloud mit BunkerWeb, dem OWASP Core Rule Set und CrowdSec abgesichert werden kann. Die dargestellten IP-Adressen und Domains sind Beispiele und müssen für die jeweilige IT-Umgebung angepasst werden.

Die Anleitung orientiert sich an BunkerWeb 1.6.15 mit nativer Installation unter Ubuntu. Sie ersetzt keine Prüfung der individuellen Netzwerktopologie oder Sicherheitsanforderungen.

1. Aufbau der Infrastruktur

Eine mögliche Architektur besteht aus einer Firewall, einem separaten BunkerWeb-Server und dem eigentlichen Nextcloud-Server.

Internet
    |
    v
Netzwerk-Firewall
    |
    | TCP 80 / 443
    v
BunkerWeb WAF
192.0.2.10
    |
    | HTTPS
    v
Nextcloud
192.0.2.20

Die Netzwerk-Firewall leitet die notwendigen HTTPS-Verbindungen an BunkerWeb weiter. BunkerWeb nimmt die Anfragen entgegen, prüft diese und leitet erlaubte Zugriffe an Nextcloud weiter.

Der Nextcloud-Server sollte möglichst nicht zusätzlich direkt aus dem Internet erreichbar sein. Für produktive Umgebungen empfiehlt sich eine geeignete Netzwerksegmentierung, beispielsweise über ein separates Server- oder DMZ-Netz.

2. BunkerWeb unter Ubuntu installieren

Für die Bereitstellung wird ein aktueller, unterstützter Ubuntu-Server verwendet. Die Sicherheitsupdates des Betriebssystems sollten installiert und die erforderlichen Netzwerkregeln festgelegt sein.

Die native Installation erfolgt über die von BunkerWeb dokumentierten Linux-Pakete beziehungsweise die offiziellen Installationsanweisungen. Repository-Adressen, Paketnamen und Signaturschlüssel sollten immer aus der Dokumentation der tatsächlich verwendeten Version übernommen werden.

BunkerWeb-Dokumentation

Nach der Installation sollten der BunkerWeb-Dienst, der Scheduler und die Administrationsoberfläche kontrolliert werden.

sudo systemctl status bunkerweb
sudo systemctl status bunkerweb-scheduler
sudo systemctl status bunkerweb-ui

Je nach Installationsvariante können Dienstnamen oder verfügbare Komponenten abweichen. Die Verwaltungsoberfläche sollte ausschließlich über ein geschütztes Administrationsnetz oder einen VPN-Zugang erreichbar sein.

3. Nextcloud als Reverse-Proxy-Dienst einrichten

In der BunkerWeb-Weboberfläche wird ein neuer Dienst mit dem öffentlichen DNS-Namen der Nextcloud-Installation erstellt.

Ein einfaches Konfigurationsbeispiel:

SERVER_NAME=cloud.example.com
IS_DRAFT=no
USE_REVERSE_PROXY=yes
REVERSE_PROXY_URL=/
REVERSE_PROXY_HOST=https://192.0.2.20
REVERSE_PROXY_CUSTOM_HOST=cloud.example.com
REVERSE_PROXY_SSL_SNI=yes
REVERSE_PROXY_SSL_SNI_NAME=cloud.example.com

Die Anfragen erreichen BunkerWeb über den öffentlichen Hostnamen und werden anschließend an den internen Nextcloud-Server weitergeleitet.

Wichtig: Bei einer HTTPS-Verbindung zum Backend sollte auch das Zertifikat des Nextcloud-Servers überprüft werden. Dafür müssen Zertifikatskette, vertrauenswürdige Zertifizierungsstelle und Servername zusammenpassen. Das dauerhafte Abschalten der Backend-Zertifikatsprüfung ist keine empfehlenswerte Produktionskonfiguration.

4. OWASP ModSecurity und Core Rule Set aktivieren

BunkerWeb unterstützt die Integration von ModSecurity und dem OWASP Core Rule Set (CRS).

Damit werden eingehende HTTP-Anfragen auf verschiedene bekannte Angriffsmuster untersucht.

SECURITY_MODE=block

USE_MODSECURITY=yes
USE_MODSECURITY_CRS=yes
MODSECURITY_CRS_VERSION=4
MODSECURITY_SEC_RULE_ENGINE=On
MODSECURITY_SEC_AUDIT_ENGINE=RelevantOnly

Der Blockiermodus sollte erst nach einer Prüfung der vorgesehenen Anwendung und ihrer HTTP-Schnittstellen produktiv aktiviert werden. Gerade bei Nextcloud können bestimmte reguläre Anfragen von allgemeinen WAF-Regeln zunächst als verdächtig eingestuft werden.

5. Offizielle OWASP-Ausnahmen für Nextcloud einbinden

Nextcloud verwendet WebDAV, verschiedene HTTP-Methoden und spezielle Upload-Verfahren. Dadurch können bei generischen WAF-Regeln sogenannte False Positives entstehen.

Ein Beispiel ist die OWASP-CRS-Regel 920420 mit der Meldung Request content type is not allowed by policy. Sie kann bei legitimen Nextcloud-Anfragen mit dem Content-Type text/plain ausgelöst werden.

Das OWASP-CRS-Projekt stellt ein offizielles Plugin mit anwendungsspezifischen Regelausnahmen für Nextcloud bereit.

Bei BunkerWeb 1.6.x lässt sich das Plugin folgendermaßen aktivieren:

USE_MODSECURITY=yes
USE_MODSECURITY_CRS=yes
MODSECURITY_CRS_VERSION=4

USE_MODSECURITY_CRS_PLUGINS=yes
MODSECURITY_CRS_PLUGINS=nextcloud-rule-exclusions

BunkerWeb kann das angegebene CRS-Plugin automatisch herunterladen und in das Regelwerk einbinden. Voraussetzung ist, dass der Download erfolgreich durchgeführt und die Konfiguration ohne Fehler übernommen wurde.

Eine zusätzliche manuelle Installation von GitHub ist bei erfolgreichem automatischem Download nicht erforderlich.

Das offizielle Nextcloud-Plugin enthält bereits spezielle Ausnahmen für die Regel 920420 bei bestimmten POST- und PUT-Anfragen. Die gesamte Regel sollte deshalb nicht pauschal deaktiviert werden.

Weitere Informationen:

6. Zulässige HTTP-Methoden für Nextcloud konfigurieren

Nextcloud benötigt neben GET und POST verschiedene WebDAV-Methoden. Diese müssen in der WAF-Konfiguration berücksichtigt werden.

ALLOWED_METHODS=GET|POST|HEAD|OPTIONS|PUT|DELETE|PATCH|QUERY|PROPFIND|PROPPATCH|MKCOL|MOVE|COPY|REPORT|MKCALENDAR|LOCK|UNLOCK

Die tatsächlich benötigten Methoden hängen von den eingesetzten Nextcloud-Funktionen und Apps ab. Nicht benötigte Methoden sollten nach einer Funktionsprüfung entfernt werden.

7. Große Datei-Uploads berücksichtigen

Bei Nextcloud sind größere Uploads üblich. Die Größenbegrenzungen von BunkerWeb, NGINX, ModSecurity und Nextcloud müssen deshalb aufeinander abgestimmt werden.

Beispielsweise kann für die erlaubte maximale Anfragegröße ein hoher Wert konfiguriert werden:

MAX_CLIENT_SIZE=10G

Achtung: Dieser Wert alleine garantiert keine funktionsfähigen Uploads von 10 GB. Insbesondere das Puffern großer Request-Bodys durch ModSecurity kann erhebliche Arbeitsspeicherbelastung verursachen.

Für die produktive Einrichtung müssen deshalb das Upload-Verhalten von Nextcloud, die Chunk-Größe, der verfügbare Arbeitsspeicher und die relevanten ModSecurity-Body-Limits geprüft werden. Unnötig hohe Body-Limits sind zu vermeiden.

8. CrowdSec als zusätzliche Sicherheitsschicht integrieren

CrowdSec kann Protokolldaten analysieren und auf verdächtige Aktivitäten mit Sperrentscheidungen reagieren. Diese Entscheidungen können durch die CrowdSec-Integration von BunkerWeb berücksichtigt werden.

Für eine lokale CrowdSec-Installation können beispielsweise folgende Endpunkte genutzt werden:

USE_CROWDSEC=yes
CROWDSEC_API=http://127.0.0.1:8080
CROWDSEC_MODE=live

CROWDSEC_APPSEC_URL=http://127.0.0.1:7422
CROWDSEC_ALWAYS_SEND_TO_APPSEC=yes

Zusätzlich benötigt BunkerWeb einen gültigen CrowdSec-Bouncer-API-Schlüssel. Dieser ist geheim zu halten und sollte nicht in Screenshots, Blogbeiträgen oder öffentlichen Konfigurationsdateien erscheinen.

Ein Bouncer kann auf dem CrowdSec-Server erstellt werden:

sudo cscli bouncers add bunkerweb-nextcloud

Der anschließend ausgegebene Schlüssel wird sicher in der BunkerWeb-Konfiguration hinterlegt.

Die Verbindung lässt sich unter anderem mit folgenden Befehlen kontrollieren:

sudo systemctl status crowdsec
sudo cscli bouncers list
sudo cscli decisions list
sudo cscli metrics show appsec

Ein registrierter Bouncer und vorhandene Sperrentscheidungen sind gute erste Hinweise. Für den Nachweis einer funktionierenden Blockierung sind zusätzlich kontrollierte Funktionstests erforderlich.

9. Geoblocking und unerwünschte Zugriffe

Wenn eine Webanwendung nur für eine bestimmte geografische Region vorgesehen ist, kann BunkerWeb Zugriffe auf ausgewählte Länder begrenzen.

Beispiel für eine Beschränkung auf Deutschland:

WHITELIST_COUNTRY=DE
SECURITY_MODE=block

Die Entscheidung basiert auf der erkannten Quell-IP-Adresse. Bei vorgeschalteten Proxies oder CDN-Diensten muss deshalb sichergestellt werden, dass BunkerWeb die tatsächliche Client-IP vertrauenswürdig ermittelt.

Auch Sicherheitsprüfungen, externe Monitoring-Systeme oder Zertifikatsvalidierungen können von geografischen Einschränkungen betroffen sein.

Insbesondere bei Let's Encrypt HTTP-01 muss der ACME-Challenge-Pfad von den Validierungsservern erreichbar sein. Der hierfür erforderliche Zugriff muss bei der Konfiguration von Länderfiltern berücksichtigt werden.

10. Let's Encrypt für HTTPS aktivieren

BunkerWeb unterstützt die automatische Ausstellung und Erneuerung von TLS-Zertifikaten über Let's Encrypt.

AUTO_LETS_ENCRYPT=yes
USE_LETS_ENCRYPT_STAGING=no

Für die HTTP-01-Validierung muss die Domain öffentlich auf die richtige WAF-Instanz verweisen. Außerdem muss die erforderliche HTTP-Erreichbarkeit gewährleistet sein.

Nach der Einrichtung sollten Zertifikatsausstellung und automatische Verlängerung anhand der Scheduler-Protokolle kontrolliert werden.

11. Sicherheitsregeln mit Nextcloud testen

Nach der Aktivierung der WAF sollten nicht nur die BunkerWeb-Protokolle kontrolliert werden. Entscheidend ist, ob die Nextcloud weiterhin fehlerfrei funktioniert.

Anmeldung im Browser und mit aktivierter Mehrfaktor-Authentifizierung
Upload und Download kleiner und großer Dateien
Synchronisierung über Nextcloud Desktop
Mobile Zugriffe über iOS und Android
WebDAV mit verschiedenen HTTP-Methoden
Kalender- und Kontakte-Synchronisierung
Aktivierte Erweiterungen und Office-Integrationen
Automatische Zertifikatserneuerung
Nachweis tatsächlicher WAF-Blockierungen bei kontrollierten Tests

Falls legitime Anfragen blockiert werden, sollten zunächst die Request-Methode, der betroffene Pfad und die auslösende OWASP-Regel ermittelt werden.

Gezielte Ausnahmen sind einer globalen Deaktivierung ganzer Sicherheitsregelgruppen vorzuziehen.

12. Sicherheitsbetrieb und Wartung

Die Einrichtung einer WAF ist keine einmalige Maßnahme. BunkerWeb, CrowdSec, das OWASP-Regelwerk und Nextcloud müssen regelmäßig aktualisiert werden.

Zusätzlich empfiehlt es sich, blockierte Anfragen und sicherheitsrelevante Ereignisse zu überwachen, Zugriffsrechte zu überprüfen und die Wiederherstellbarkeit der betroffenen Systeme sicherzustellen.

Für geschäftskritische Anwendungen sollte jede größere Änderung der Sicherheitsregeln zunächst in einer Testumgebung validiert werden.

Fazit zur Nextcloud-Absicherung

Durch die Kombination aus BunkerWeb, OWASP CRS, dem offiziellen Nextcloud-Ausnahme-Plugin und CrowdSec lässt sich eine zusätzliche Sicherheitsebene für selbst gehostete Nextcloud-Umgebungen schaffen.

Wichtig ist die sorgfältige Abstimmung der Sicherheitsregeln. Ein hoher Schutzgrad ist nur dann sinnvoll, wenn gleichzeitig die regulären Funktionen der Webanwendung zuverlässig verfügbar bleiben.

Systemhaus Schulz unterstützt Unternehmen bei der Planung, Implementierung und laufenden Betreuung solcher Sicherheitslösungen.

BunkerWeb: Open-Source Web Application Firewall für Unternehmen