Ein Dauerbrenner namens Anmeldemaske
Es gibt einen Moment, den jeder kennt, der je eine Nextcloud-Instanz aufgesetzt hat. Man richtet den Server ein, gibt die eigene E-Mail-Adresse an, legt das Admin-Passwort fest – und schon nach wenigen Stunden tauchen im Log die ersten ungebetenen Gäste auf. Sie probieren immer wieder Benutzernamen und Passwörter durch, gegen die Anmeldung des Servers, das WebDAV-Interface oder die so genannten OCS-API-Routen. Die meisten Versuche laufen ins Leere. Aber sie erzeugen Last, Unruhe und im Ernstfall ein Sicherheitsrisiko, das man nicht unterschätzen sollte.
Nextcloud bringt gegen diese Angriffe eine eingebaute Verteidigung mit, die ehrlicherweise viel zu selten thematisiert wird. Sie heißt offiziell „Brute-Force-Protection“ oder auch „Brute Force Schutz“ und funktioniert im Prinzip wie eine Art Türsteher: Wer zu oft an der falschen Tür klingelt, bekommt für eine Weile kein Wort mehr heraus. So einfach das klingt, so vielschichtig ist die Sache in der Praxis. Denn der Schutz muss einerseits entschlossen zuschlagen können. Andererseits soll er echte Nutzer nicht ausbremsen, die bloß ihr Passwort vergessen haben. Zwischen diesen beiden Anforderungen bewegt sich jede sinnvolle Konfiguration.
Dieser Artikel versucht, das Thema aus Sicht eines Administrators zu beleuchten. Er zeigt, wie der Schutz aufgebaut ist, wo seine Grenzen liegen und welche Fehler man im Betrieb vermeiden sollte. Dabei geht es nicht um theoretische Sicherheit, sondern um den Alltag auf einem System, das im Netz sichtbar ist und angegriffen wird.
Warum Nextcloud ein lohnendes Ziel ist
Nextcloud ist kein kleiner Nischendienst mehr. Das hat inzwischen durchgesprochen, dass man viele Unternehmen, Hochschulen und öffentliche Verwaltungen mit einer eigenen Nextcloud erreicht. Genau das macht die Plattform aus Sicht von Angreifern interessant. Sie ist weit verbreitet, sie ist oft außen erreichbar und sie speichert mitunter Daten, die sonst im geschützten Intranet liegen würden. Dazu kommt die Sache mit den Passwörtern: Menschen benutzen dasselbe Passwort selten nur für genau einen Dienst. Ein Diebstahl von Zugangsdaten bei einem anderen Portal reicht daher aus, um gezielte Versuche auf einer Nextcloud-Instanz zu starten.
Der Klassiker ist das so genannte Passwort-Spraying. Dabei probiert der Angreifer nicht unendlich viele Kombinationen, sondern er testet gezielt ein paar häufig benutzte Passwörter gegen eine große Zahl von Benutzerkonten. Das ist deshalb so effektiv, weil die Konten oft bekannte Namen haben, etwa den Standard-Administrator oder Funktionsadressen wie „office“ oder „vertrieb“. Der eingebaute Brute-Force-Schutz reagiert auf solche Muster normalerweise recht gut. Aber er kann nur diejenigen Angriffe erkennen, die von einer einzelnen IP-Adresse kommen. Botnetze verteilen ihre Versuche auf viele Adressen. Genau darin liegt die eigentliche Herausforderung.
Ein weiterer Punkt ist die unbeabsichtigte Mitwirkung der Serverbetreiber. Wer eine Nextcloud im Jahr 2025 aufsetzt, bekommt in der Grundinstallation meist schon ein solides Fundament aus HTTPS, modernen Cipher Suites und den üblichen Sperrlogiken. Doch viele tun sich schwer, die richtigen Werte zu finden. Wer die Schutzmechanismen zu großzügig einstellt, lädt Angreifer geradezu ein. Wer sie zu streng einstellt, schließt sich selbst aus und verwirft das Werkzeug dann als unbrauchbar. Die goldene Mitte ist nicht immer leicht zu treffen.
Wie die eingebaute Schutzfunktion arbeitet
Die Brute-Force-Protection von Nextcloud ist kein eigenständiges Programm, sondern ein Teil des Serverkerns. Sie protokolliert für jede IP-Adresse, wie oft ein Login fehlgeschlagen ist. Überschreitet die Zahl der Versuche einen gesetzten Schwellenwert, greift eine Art „Rate Limit“. Das bedeutet: Der Server antwortet zunächst nicht mehr schlagartig, sondern lässt sich mehr Zeit – und bei weiteren Fehlversuchen setzt er eine temporäre Sperre. Die Idee ist gar nicht so neu. Ähnliche Methoden kennen Administratoren von SSH oder von manchen Web-Firewalls. Man will erreichen, dass ein automatischer Angriff wirtschaftlich uninteressant wird, ohne den einzelnen Benutzer zu vergraulen.
Ein wichtiger Unterschied zu klassischen Sperren auf Firewall-Ebene ist aber die Perspektive. Nextcloud arbeitet nicht auf dem Netzwerk-Paket, sondern auf der Anwendungsebene. Das heißt: Die Schutzlogik greift erst dann, wenn die Anfrage tatsächlich bei der Anwendung angekommen ist. Das ist Fluch und Segen zugleich. Der Segen liegt darin, dass man sehr genau steuern kann, wer wie lange gesperrt wird. Der Fluch ist, dass die Anfrage den Server immer erreicht. Ein erfolgloser Login-Versuch kostet ohnehin etwas Systemressourcen, und wenn zehntausende Versuche nie in der Firewall gestoppt werden, dann bleibt das für die CPU nicht folgenlos.
Die technische Umsetzung läuft über ein Datenbankmodul. Nextcloud speichert die fehlgeschlagenen Versuche mit Zeitstempel und IP-Adresse. Dabei wird nicht nur das Web-Interface betrachtet, sondern auch alle anderen Login-Wege, etwa die Anmeldung über CalDAV oder CardDAV, über die Desktop-Clients und die mobilen Apps. Das ist insofern clever, weil Angreifer oft versuchen, den Umweg über eine schwach geschützte WebDAV-Schnittstelle zu nehmen. Die zentrale Schutzfunktion kann diese Endpunkte nicht voneinander trennen, sonst wäre das Umgehen des Schutzes ein Kinderspiel. Ein Angreifer, der es über das Web-Interface probiert, stößt also auf dieselben Sperren wie jemand, der es über das WebDAV-Protokoll versucht.
Die Administrationsoberfläche und die Sache mit der Brute-Force-Settings-App
Bei einer Standardinstallation von Nextcloud ist die Schutzfunktion aktiviert, aber sie ist in der Administrations-Oberfläche kaum sichtbar. Das führt zu Missverständnissen, weil man nicht sieht, was der Server eigentlich tut. Erst die Zusatz-App „Brute Force Settings“ bringt eine ansprechende Oberfläche ins Spiel. Sie wird von Nextcloud offiziell angeboten und ist in den meisten Fällen über den App-Store installierbar. Viele Distributionen liefern sie bereits mit, manche haben sie aber auch deaktiviert.
Nach der Aktivierung findet man im Administrationsbereich einen neuen Eintrag, der sich um die Sperr-Funktionen kümmert. Auf dieser Seite werden IP-Adressen aufgelistet, die auffällig geworden sind. Dazu gehört die Anzahl der Fehlversuche, der Zeitpunkt des letzten Versuchs und der Status der Sperre. Der Administrator kann eine Adresse wieder entsperren oder auf eine Whitelist setzen. Whitelisted Adressen werden von der Schutzfunktion ignoriert, was bei internen Dienstzugängen durchaus nützlich sein kann. Eine Blacklist ist ebenfalls möglich, auch wenn man sie im Alltag eher selten braucht. Interessant ist dabei die Möglichkeit, eigene Sperren für bestimmte IP-Bereiche anzulegen. Auf diese Weise lassen sich etwa bekannte Angreifer-Netze aus einem bestimmten Rechenzentrum fernhalten, bevor sie überhaupt etwas ausprobieren können.
Ein Detail, das viele stutzt: Die Oberfläche ist nicht besonders ausführlich dokumentiert. Das wirkt etwas nachgelassen, denn gerade für ein Sicherheitsthema wäre eine präzise Erklärung wichtig. In der Praxis muss man daher ein wenig experimentieren, um zu sehen, was die Werte bedeuten. Das ist kein Beinbruch, weil die Standardkonfiguration für die meisten Anwendungsfälle eigentlich gut funktioniert. Aber wer gezielt nachjustieren will, findet nicht überall die erhofften Hinweise.
Wenn die eigene IP plötzlich gesperrt ist
Der berühmte Schreckmoment im Admin-Bereich sieht so aus: Man hat einige Fehlversuche bei der Anmeldung produziert, weil das Passwort im Passwortmanager falsch hinterlegt war. Plötzlich erscheint eine Warnung, man möge es doch nach ein paar Sekunden noch einmal versuchen. Dann wartet man, probiert es erneut, und wieder kommt eine Wartezeit. Das kann sich sehr zäh anfühlen. Je nach Konfiguration kann so eine automatische Sperre mehrere Minuten oder Stunden andauern. Und wenn der Admin selbst betroffen ist, kann er sich nicht einmal bequem in das Admin-Panel einloggen, um die Sperre aufzuheben.
Der elegante Ausweg ist in solchen Fällen die Kommandozeile. Nextcloud bringt ein Kommandozeilen-Tool mit, das unter dem Namen occ bekannt ist. Damit lassen sich verschiedene sicherheitsrelevante Funktionen ausführen. Wer wissen möchte, welche Befehle es rund um den Brute-Force-Schutz gibt, kann sich mit occ list eine Übersicht anzeigen lassen und darin nach Stichworten wie „force“ oder „security“ suchen. Die genauen Namen haben sich in den letzten Versionen geändert, daher ist dieser Hinweis bewusst vage gehalten. In jedem Fall gilt: Eine einmal erteilte Sperre ist kein unumkehrbares Schicksal. Man kann sie aufheben, man kann die Logs einsehen und man kann die Datenbank bereinigen.
Was allerdings oft übersehen wird, ist die Tatsache, dass die Schutzfunktion nicht nur IP-Adressen, sondern auch Benutzerkonten berücksichtigt. Wenn ein Bot versucht, sich mit einem bestimmten Benutzernamen anzumelden, kann Nextcloud diesen Kontonamen zeitweise blockieren. Das ist vor allem dann unangenehm, wenn der Benutzername „admin“ heißt und der Angreifer genau diesen Namen getroffen hat. Dann kann es passieren, dass der Administrator selbst nicht mehr hereinkommt, obwohl seine IP-Adresse gar nicht gesperrt wurde. Auch diese Hürde lässt sich über die Kommandozeile lösen, aber man muss wissen, dass es sie gibt.
Wo die eingebaute Sperre an ihre Grenzen stößt
Der eingebaute Schutz ist clever, aber er hat eine strukturelle Schwäche: Er verlässt sich auf die IP-Adresse des Gegenübers. In einer Welt, in der mobile Endgeräte ständig den Standort wechseln und in der IPv6-Adressen sich automatisch ändern, wird das zunehmend schwierig. Wenn eine Großraum-DS-Light-Anschluss sich alle 24 Stunden eine neue IP-Adresse sucht, hat das System es mit einem legitimen Anwender zu tun, der nach jedem Adresswechsel wieder ganz vorne anfängt. Wird dieser Anwender dann gesperrt, kann er sich nicht mehr einloggen, bis sein Netzbetreiber ihm erneut eine Adresse zuweist. Das ist real und keine Seltenheit.
Umgekehrt lauert das klassische Problem der geteilten IP-Adressen. In vielen Firmen laufen alle Benutzer über eine einzige NAT-Adresse des Routers nach außen. Wenn ein einzelner Mitarbeiter sein Passwort vergisst und fünfmal hintereinander falsch tippt, dann wird die gemeinsame IP gesperrt. Das trifft nicht nur den betroffenen Mitarbeiter, sondern die gesamte Belegschaft. Die Admins werden mit Anfragen überflutet, dass die Nextcloud nicht mehr erreichbar sei, und sind eine Weile damit beschäftigt, die IP wieder freizuschalten. Genau diese Szenarien sind es, die viele Administratoren dazu verleiten, die Brute-Force-Protection zu deaktivieren oder so großzügig einzustellen, dass sie sinnlos wird.
Dazu kommt der Angriff auf die Ressourcen. Auch wenn Nextcloud die Login-Versuche nach ein paar Treffern blockt, verursachen schon die ersten Versuche Datenbankzugriffe und PHP-Ausführungen. Ein mutiger Angreifer kann das ausnutzen, um die Instanz mit einer Flut von Anfragen zu überlasten. Der Schutz ist dann keine Hilfe bei DDoS, sondern im besten Fall ein Auslöser für zusätzliche Datenbanklast, weil jeder Versuch protokolliert wird. In solchen Fällen braucht es eine der Instanz vorgelagerte Lösung, zum Beispiel eine Web Application Firewall oder ein Fail2ban-Skript auf dem Hostsystem.
Die Falle mit dem Reverse-Proxy
Eine besonders heikle Situation entsteht in Konstellationen, in denen Nextcloud nicht direkt an der Netzwerk-Schnittstelle des Servers hängt. Sehr viele Systeme laufen hinter einem Reverse-Proxy, etwa nginx oder HAProxy, der den SSL-Handshake übernimmt und die Anfragen an einen internen Nextcloud-Server weitergibt. In einer solchen Architektur sieht Nextcloud normalerweise immer dieselbe IP-Adresse: die des Proxy-Servers. Das ist für den Brute-Force-Schutz ein Riesenproblem. Denn wenn alle Anfragen von „127.0.0.1“ oder von der internen Proxy-IP kommen, dann wird bei fünf Fehlversuchen eines einzigen Angreifers der gesamte Proxy geblockt. Und das kann bedeuten: Der Dienst ist für alle Benutzer nicht mehr erreichbar.
Um das zu verhindern, muss man der Nextcloud mitteilen, welchen Headers sie vertrauen darf. Üblicherweise setzt der Reverse-Proxy den Header X-Forwarded-For oder ein vergleichbares Feld, in dem die IP-Adresse des eigentlichen Clients steht. Nextcloud kann diese Information lesen, sofern die Proxy-IP-Adresse in der Konfigurationsdatei config.php unter dem Schlüssel trusted_proxies hinterlegt ist. Darüber hinaus muss man dem System sagen, welcher Header ausgewertet werden soll. Das geschieht über den Parameter forwarded_for_headers. Eine Konfiguration, die diese Schlüssel weglässt, führt dazu, dass der Schutz entweder blind oder übervorsichtig reagiert.
Ein interessanter Aspekt ist dabei der Unterschied zwischen sicheren Proxys und unsicheren Konstellationen. Manche Administratoren setzen den Header X-Forwarded-For nicht korrekt, sondern erlauben es dem Client, den Header selbst zu setzen. Dann kann ein Angreifer eine beliebige IP-Adresse vortäuschen und sich damit den Schutzregeln entziehen. Nextcloud hat deshalb eine Schutzmaßnahme eingebaut: Es ignoriert eingebettete Header-Informationen, wenn die Anfrage nicht von einem bekannten Proxy kommt. Insofern ist die Gefahr nicht so groß, wie sie scheint – aber sie besteht, sobald der Proxy nicht richtig als vertrauenswürdig eingestuft ist oder die Header-Kette nicht vernünftig nachgeführt wird.
Die ungeliebte Feinarbeit mit occ
Für viele Administratoren ist die Kommandozeile das Tor zur direkten Kontrolle. Auch bei Nextcloud gibt es sie, und sie kann an dieser Stelle sehr nützlich sein. Mit dem occ-Befehl lassen sich nicht nur Wartungsarbeiten ausführen, sondern auch gezielte Eingriffe in den Sperrmechanismus. So ist es zum Beispiel möglich, alle Fehlversuche zu einer bestimmten IP-Adresse zu ermitteln. Damit bekommt man ein genaueres Bild davon, ob eine Auffälligkeit nur ein Unfall war oder ein systematischer Angriff.
Wer eine falsch gesetzte Sperre schnell wieder auflösen möchte, kann das ebenfalls über occ erledigen. Das ist insofern komfortabel, weil man nicht in der Datenbank herumsuchen muss. Allerdings setzt das voraus, dass man auf der Kommandozeile des Servers angemeldet ist und im Verzeichnis der Nextcloud-Installation arbeitet. Der Aufruf erfolgt üblicherweise als der Benutzer, der auch die Webserver-Prozesse ausführt, oft unter sudo -u www-data php occ .... Der genaue Name des Unterbefehls hat sich über die Jahre verändert, daher sollte man nicht auf eine ältere Doku vertrauen, sondern auf der eigenen Maschine die Liste der verfügbaren Kommandos prüfen.
Für den Notfall gibt es noch einen anderen Weg, wenn gar nichts mehr geht: das Löschen der betroffenen Tabellen per Datenbank-Kommando. Das ist zwar unsicher und sollte nicht der Standardweg sein, aber in der Not hilft es. Wichtig ist, vorher die Datenbank zu sichern oder zumindest ein Update durchzuspielen, damit man die Struktur nicht ausversehen zerstört. Ein seriöser Administrator wird solche Eingriffe nur mit größter Vorsicht vornehmen. Aber es beruhigt ungemein zu wissen, dass man nicht völlig ausgesperrt bleibt, nur weil die Weboberfläche blockiert wird.
Fail2ban als Ergänzung und seine Tücken
Der eingebaute Schutz operiert auf der Anwendungsebene. Das ist gut für präzises Handeln, aber schlecht für die Effizienz. Wer eine stark frequentierte Nextcloud-Instanz betreibt, kann feststellen, dass die vielen fehlgeschlagenen Login-Versuche den Webserver und die PHP-Prozesse unnötig beschäftigen. An dieser Stelle setzt Fail2ban an. Fail2ban beobachtet die Logdateien des Webservers und kann eine IP-Adresse auf der Netzwerk- oder Firewall-Ebene blockieren, wenn sie zu viele Fehlversuche produziert. Damit wird die Last reduziert, weil die Anfragen gar nicht erst bis zu Nextcloud vordringen.
Die Einrichtung von Fail2ban ist nicht besonders kompliziert, aber sie verlangt ein wenig Sorgfalt. Zunächst muss sichergestellt werden, dass die Nextcloud-Logdatei die relevanten Fehler enthält. In den meisten Fällen ist das das owncloud.log oder nextcloud.log im Datenverzeichnis. Man kann die Fehlermeldungen mit einem Filter erkennen, der etwa den Text „Invalid login attempt“ enthält. Diesen muss der Fail2ban-Filter auswerten und die darin enthaltene IP-Adresse extrahieren. Danach blockt das Tool den Zugriff entweder über iptables, nftables oder eine Integration in die Firewall-Regeln des cloudbasierten Setups.
Dabei zeigt sich allerdings ein Problem: Fail2ban arbeitet mit den Logdaten, die ihm zur Verfügung stehen. Wenn Nextcloud hinter einem Reverse-Proxy sitzt und dieser die Client-IP nicht korrekt weitergibt, dann sieht Fail2ban fast nur die Adresse des Proxys. Die Folge ist, dass alle Nutzer der Instanz gesperrt werden, obwohl nur ein Angreifer aktiv war. Dieselbe Fehlerquelle wie beim eingebauten Schutz also. Man sollte Fail2ban daher erst konfigurieren, nachdem die Proxy-Konfiguration sauber ist. Sonst schafft man sich ein Instrument, das im Zweifel schneller schadet, als es nutzt.
Parallel zum Fail2ban-Betrieb gibt es aber einen netten Nebeneffekt: Die Sperren auf Firewall-Ebene sind für die Angreifer sehr viel „härter“ als die nette Wartezeit von Nextcloud. Ein Anfänger im Bereich Netzwerksicherheit merkt schnell, dass sich Antwortzeiten drastisch verändern. Fail2ban kann außerdem bekannt benachteiligte Netzwerke schon nach wenigen Fehlversuchen blockieren, während Nextcloud standardmäßig eher zurückhaltend reagiert. In einer mehrschichtigen Architektur kann so also durchaus ein doppelter Schutz entstehen: die Netzwerkschicht reduziert den Datenstrom, die Anwendungsschicht schützt die Logik dahinter.
IP-Adressen, Whirlpools und die Sache mit IPv6
Die IP-Adresse ist und bleibt die schwächste Klammer in jedem Brute-Force-Schutz. Das merkt man spätestens dann, wenn ein Angreifer nicht nur eine einzelne Adresse verwendet, sondern ein ganzes Segment aus einem Rechenzentrum. In solchen Fällen hilft es, Adressbereiche bei der Blockierung zu berücksichtigen. Nextcloud kann das in seiner Brute-Force-Settings-App umsetzen, indem man eine Netzmaske verwendet. Das ist zumindest für die hartnäckigen Angriffe aus bestimmten Netzen eine sinnvolle Ergänzung. Doch Vorsicht: Ein großzügig blockierter Bereich kann durchaus einmal einen harmlosen Dienste-Anbieter treffen, dessen Server in demselben Rechenzentrum stehen.
Mit IPv6 wird die Sache noch einmal komplizierter. Viele Nutzer haben einen vorgeschriebenen Adress-Präfix, aber die eigentliche Geräte-Adresse ändert sich regelmäßig. Zudem kann ein einzelner Rechner mehrere IPv6-Adressen gleichzeitig verwenden. Nextcloud versucht, solche Dynamik abzufangen, indem es die IP-Adressen in einer verallgemeinerten Form speichert. Trotzdem ist es unmöglich, eine einzelne Benutzer-zuverlässig einer Adresse zuzuordnen. Man sollte daher bei der Konfiguration nicht allzu streng vorgehen, sonst leidet die Benutzerfreundlichkeit. Ist das System einmal zu eng eingestellt, kommt es zu den oben beschriebenen Ausfällen.
Manchmal wird empfohlen, einen Blick in die Logdatei zu werfen und die Angreifer-Muster genauer zu analysieren. Diese Empfehlung ist nicht ganz falsch, denn so erkennt man, ob es sich um ein breit gestreutes Botnetz handelt oder um Einzelversuche. In vielen Fällen zeigt sich, dass die Angreifer sehr schnell wissen, ob sie auf eine Nextcloud stoßen. Sie senden typische „User-Agent“-Strings und probieren in kürzester Zeit sämtliche Standard-Logins. Dagegen hilft der Schutz, zumal er die IP nach einer gewissen Anzahl von Versuchen für eine Weile vollständig ignoriert. Es ist allerdings notwendig, diese Anzahl so zu wählen, dass sie nicht allzu niedrig ist. Drei bis fünf Fehlversuche sind für einen Menschen unangenehm, aber für einen Angreifer nicht wirklich hinderlich. Zehn Fehlversuche mögen für den einzelnen Nutzer viel erscheinen, sind aber bei den meisten Angriffen noch immer unterhalb der Schwelle, bei der Bots die Geduld verlieren. Ein guter Mittelweg hängt von der Größe der Benutzergruppe und dem Risiko ab, das man bereit ist, einzugehen.
Das Zusammenspiel mit Zwei-Faktor-Authentifizierung
Die beste Brute-Force-Protection kann nicht verhindern, dass ein Angreifer bemerkt, an welcher Stelle er sich befindet. Sie kann auch nicht verhindern, dass er es immer wieder probiert. Aber sie kann seine Trefferquote minimieren. Im Ernstfall ist aber die Zwei-Faktor-Authentifizierung die eigentliche Mauer. Wer Nextcloud mit TOTP-basierten Einmalcodes, WebAuthn-Sicherheitskeys oder per E-Mail-Bestätigung nutzt, macht sich unabhängig von der Passwortfestigkeit. Selbst wenn ein Angreifer das Passwort errät, kommt er ohne den zweiten Faktor nicht weiter. Das ist der wichtigste Baustein, den man zu der Brute-Force-Protection hinzufügen kann.
Ein Detail am Rande: Nextclouds Schutzfunktion zählt auch fehlgeschlagene Zwei-Faktor-Verifizierungen. Das ist wichtig, weil es Angreifer gibt, die auf die zweite Stufe setzen, nachdem sie sich das Passwort beschafft haben. Wenn ein Benutzer seinen TOTP-Code mehrfach falsch eingibt, wird das also ebenfalls als Anomalie erfasst. Das kann im Alltag dazu führen, dass jemand, der seinen Security-Key verloren hat oder dessen Uhrzeit nicht synchronisiert ist, sich plötzlich ausgesperrt sieht. Auch hier ist es beruhigend zu wissen, dass man als Admin die Sperre wieder aufheben kann. Und für Endanwender ist es ratsam, die Notfallcodes aufzubewahren, die Nextcloud bei der Einrichtung der Zwei-Faktor-Authentifizierung standardmäßig anzeigt.
Ein zusätzlicher Effekt der Zwei-Faktor-Authentifizierung ist, dass sie nicht nur die Websession schützt, sondern auch die Verbindungen über WebDAV und die mobile Nextcloud-App. Hier kommen häufig so genannte App-Passwörter zum Einsatz, die eine Verbindung zur eigenen App ermöglichen, ohne das eigentliche Hauptpasswort zu verwenden. Auch diese Passwörter sind ein Ziel für Angreifer. Die gute Nachricht ist: Nextcloud überwacht auch diese Anmeldeversuche im Rahmen der Brute-Force-Protection. Die schlechte Nachricht: Wenn ein Angreifer viele App-Passwörter ausprobiert, kann das genauso zu automatischen Sperren führen wie normale Login-Versuche.
Monitoring, Daten und ein realistischer Blick auf die Zahlen
Wie viele Angriffe sind normal? Die Antwort hängt stark vom Standort und der Erreichbarkeit der Instanz ab. Eine frische Nextcloud ohne öffentlich bekannte E-Mail-Domain wird zunächst weniger Attacken abbekommen als eine, die schon seit Jahren in Betrieb ist. Wer auf öffentlichen DNS-Servern als sub.domain.de auflöst, wird nach wenigen Stunden die ersten Bots sehen. Das kann man leicht selbst beobachten, wenn man die Logs im Auge behält. Nicht selten kommen mehrere tausend Versuche pro Tag zusammen, davon ein erheblicher Teil von einzelnen IP-Adressen aus Cloud-Anbietern oder kompromittierten Hausnetzen.
Es lohnt sich, diese Zahlen regelmäßig auszuwerten. Dafür gibt es verschiedene Werkzeuge, etwa das Auslesen der Nextcloud-Logs mit occ, die Anbindung an eine Log-Management-Lösung oder das einfache Durchsuchen mit grep. Wer ein kleines Dashboard aufbauen möchte, kann die Fehlversuche nach IP-Adresse, Benutzername und Tageszeit aufschlüsseln. Meistens sieht man dann zwei Dinge: Die Angriffe kommen in Wellen, und sie konzentrieren sich auf bestimmte Konten. Das erleichtert die Entscheidung, ob man bestimmte Benutzer umbenennen sollte – etwa vom Standard-Präfix „admin“ auf einen weniger offensichtlichen Namen. Auch das ist eine Form von Brute-Force-Schutz, wenn auch keine technische.
Nicht zuletzt sollte man die Logs der Firewall oder der vorgeschalteten Systeme auswerten. Wenn dort bereits Pakete verworfen werden, weil Fail2ban zugeschlagen hat, bekommt man ein Gefühl dafür, wie viele unerwünschte Anfragen den Weg überhaupt bis zur Anwendung finden. Ein Vorteil eines solchen mehrschichtigen Monitorings ist, dass man den Unterschied zwischen „Angriff auf Anwendungsebene“ und „Allgemeinem Netzwerk-Gezänk“ sieht. Das hilft dabei, die Schutzfunktionen von Nextcloud richtig zu kalibrieren. Wer ständig Gefahr läuft, dass die großen Botnetze den Server überfordern, sollte die Schwelle in der App nicht zu hoch ansetzen. Wer nur selten Angriffe sieht, kann es sich leisten, großzügiger zu sein und Fehlbedienungen der eigenen Benutzer zu verzeihen.
Die Bedeutung der config.php und sorgfältig gesetzte Vertrauensgrenzen
Neben den Einstellungen in der Weboberfläche gibt es in der config.php einige Schlüssel, die das Verhalten des Brute-Force-Schutzes beeinflussen. Dazu gehören nicht nur die bereits erwähnten trusted_proxies, sondern auch Möglichkeiten, den Schutz vollständig zu deaktivieren. Von einer vollständigen Deaktivierung ist dringend abzuraten. Die wenigen Fälle, in denen diese Option sinnvoll sein könnte, sind sehr spezielle Einrichtungen mit einem vollständig abgeschotteten Netz oder einem vorgeschalteten, viel strengeren Sicherheitsgateway. Für den normalen Betriebsalltag ist ein Anwendungen-Schutz immer besser, auch wenn er nicht perfekt ist.
Einzelne Werte in der config.php sollten nur mit Bedacht geändert werden. Die Datei wird beim nächsten Nextcloud-Update oft neu eingelesen, und manche Werte sind nicht dokumentiert. Wer sich mit den internen Strukturen nicht auskennt, sollte es dabei belassen, die offiziellen Administrationsseiten zu verwenden. Eine saubere Dokumentation der durchgeführten Änderungen ist in jedem Fall hilfreich, denn nach einem Update kann es passieren, dass bestimmte Einstellungen überschrieben werden und das Verhalten plötzlich ganz anders ist. Die Mischung aus GUI und Kommandozeilenwerkzeugen bringt Transparenz, wenn man sie denn nutzt.
Ein Punkt, der im Zusammenhang mit Brute-Force-Protection gern vergessen wird, ist das Logging selbst. Wer eine sehr große Nextcloud-Instanz mit vielen Benutzern betreibt, erzeugt eine gewaltige Menge an Logdaten. Diese Daten können wertvoll sein, wenn man sie auswertet. Sie können aber auch eine Last für die Datenbank und den Speicher darstellen, wenn sie unbegrenzt wachsen. Eine gelegentliche Rotation und Bereinigung der Protokolle ist daher empfehlenswert. Dasselbe gilt für die Tabellen, in denen die Fehlversuche gespeichert werden. Die Tabellen wachsen mit der Zeit an, insbesondere wenn ein Angriff über längere Zeit läuft. Die Daten sollten nicht manuell gelöscht werden, solange die Schutzfunktion läuft, aber eine geplante Bereinigung im Rahmen der Wartung ist legitim.
Was bedeutet das alles für den Entscheider?
Wer in einem Unternehmen die Verantwortung für die Nextcloud trägt, muss einen Weg zwischen Schutz und Verfügbarkeit finden. Entscheider, die sich früh mit den Grundlagen der Brute-Force-Protection beschäftigen, vermeiden eine Menge Ärger. Es ist nicht damit getan, die Standardeinstellungen zu übernehmen und ansonsten zu hoffen. Es ist ebenso wenig damit getan, einen Fail2ban-Dienst zu installieren und sich zurückzulehnen. Die verschiedenen Schutzschichten sollen ineinandergreifen, nicht nebeneinander herlaufen.
Eine sinnvolle Strategie könnte wie folgt aussehen. Zuerst prüft man, ob die Grundkonfiguration der Nextcloud solide ist: HTTPS, keine Standardbenutzernamen, ein aktuelles Passwort-Policy. Danach aktiviert man die Brute-Force-Settings-App und beobachtet die Auffälligkeiten im Log. Wenn die Angriffsrate hoch ist, ergänzt man eine Firewall-basierte Sperre durch Fail2ban oder durch Regeln in einer Web Application Firewall. Für besonders kritische Konten, etwa die Administratoren, sollte die Zwei-Faktor-Authentifizierung verpflichtend sein. Und schließlich gehört die kontinuierliche Überwachung dazu, damit man nicht nur reaktiv handelt, sondern einem möglichen Vorfall zuvorkommt.
In diesem Prozess ist die Brute-Force-Protection von Nextcloud also nicht der alles entscheidende Baustein, sondern ein Teil des Gesamtgefüges. Sie ist die Feuertür, die den Durchbruch verzögert – aber ohne die Alarmanlage kann keiner rechtzeitig reagieren. Genau diese Erkenntnis fehlt in vielen Sicherheitsdiskussionen, weil man gerne in Einzellösungen denkt. Ein solcher Ansatz ist verständlich, denn die Bedrohung ist diffus. Aber er ist nicht ausreichend.
Wie ich es gern einordnen würde
Ein wenig persönliche Einschätzung soll an dieser Stelle sein. Ich habe in den vergangenen Jahren einige Nextcloud-Installationen betreut, sowohl für kleine Teams als auch für größere Organisationen. Dabei habe ich gelernt, dass die Standardfunktionen besser sind als ihr Ruf. Die meiste Kritik an der Brute-Force-Protection entsteht aus Missverständnissen in der Konfiguration. Wenn zum Beispiel der Reverse-Proxy nicht ordentlich eingestellt ist, gibt man dem System die Schuld – dabei hat man ihm schließlich gar nicht die richtige IP-Adresse genannt. Die Schutzfunktion ist in ihrer Logik konsequent und in vielen Fällen sogar überraschend akkurat.
Gleichzeitig finde ich, dass die Nextcloud-Entwickler die Funktion viel stiefmütterlicher behandeln, als sie es verdient hätte. Es gibt keine einfache Dokumentation, die verständlich erklärt, wie die einzelnen Werte zusammenspielen. Die meisten Informationen muss man sich selbst zusammensuchen oder über Blog-Artikel wie diesen zusammenbauen. Ein bisschen mehr Offenheit an dieser Stelle würde den Produkteindruck deutlich verbessern. Denn der eingebaute Schutz ist ein echtes Verkaufsargument für Nextcloud – wenn man ihn denn versteht. Dazu kommt, dass die Community an dieser Stelle nicht gerade überbordend hilft. Viele Threads in Foren wiederholen die immer gleichen Fehler, etwa den Hinweis, die App zu installieren, ohne auf die Systemvoraussetzungen einzugehen. Das fördert das Bild vom unverlässlichen Schutz, obwohl die Ursache meistens in der eigenen Umgebung liegt.
Man muss sich auch eingestehen: Perfekten Schutz gibt es nicht. Ein Angreifer, der es wirklich auf die Instanz abgesehen hat, wird Wege finden, den Brute-Force-Schutz zu umgehen. Er kann IP-Adressen aus Dutzenden verschiedenen Netzen verwenden, er kann langsame Angriffe fahren, die kaum auffallen, oder er kann auf gestohlene Zugangsdaten aus anderer Quelle setzen. Das alles ist jenseits dessen, was ein einfacher Ratenbegrenzer leisten kann. Aber die Schwelle, die damit erreicht ist, liegt deutlich höher als bei vielen anderen Anwendungen. Und genau darum geht es: Man will nicht unangreifbar sein, sondern schlicht kein lohnendes Ziel darstellen.
Praktische Hinweise für den ersten Betrieb
Wer eine Nextcloud-Instanz gerade neu aufgesetzt hat, sollte die Brute-Force-Schutzfunktion nicht nur aktiviert lassen, sondern ein paar Schritte zur eigenen Beruhigung durchgehen. Zuerst die Erreichbarkeit aus dem Internet testen. Danach ein paar falsche Passwörter eingeben und in der Logdatei nachsehen, ob die Versuche auftauchen. Anschließend versuchen, sich über eine andere IP-Adresse zu sperren und schauen, ob der Zugriff tatsächlich verweigert wird. Das klingt trivial, aber viele Admins vertrauen dem System erst, wenn sie es einmal aus der Angreiferperspektive erlebt haben. Diese praktische Erfahrung ist mehr wert als jede theoretische Diskussion.
Ein zweiter Punkt betrifft die Benutzerkommunikation. Wenn die Schutzfunktion greift und Benutzer sich ausgesperrt fühlen, dann hilft es, wenn sie wissen, wieso. Dazu gehört die Information, dass eine vorübergehende Wartezeit nach mehreren falschen Versuchen normal ist. Dazu gehört auch die Bitte, bei vergessenen Passwörtern den Passwort-Reset zu nutzen und nicht ständig neue Kombinationen auszuprobieren. In vielen Unternehmen scheitert die Benutzerakzeptanz daran, dass die Leute nicht verstehen, warum sie plötzlich gesperrt sind. Ein kurzer Hinweis im Intranet oder eine E-Mail an die Betroffenen kann da viel bewirken.
Zuletzt ein technischer Hinweis. Wer eine gesperrte IP-Adresse auf der schwarzen Liste sieht, sollte nicht in Panik geraten. Viele dieser Sperren sind inzwischen automatisch verjährt. Das System löscht alte Einträge, nachdem ein bestimmter Zeitraum überschritten ist. Man kann die Liste also gelegentlich einfach als falschen Alarm verbuchen und nicht weiter bearbeiten. Das nimmt dem Thema den Druck und befreit den Admin von unnötiger manueller Arbeit. Wenn allerdings die Tabelle ungewöhnlich viele Einträge bekommt, ist das ein Zeichen für einen anhaltenden Angriff oder eine fehlerhafte Einstellung.
Ausblick: Was sich in den nächsten Versionen tun könnte
Nextcloud entwickelt sich kontinuierlich weiter, und das Thema Sicherheit hat dabei einen hohen Stellenwert. Es ist zu erwarten, dass sich die Brute-Force-Protection weiterentwickeln wird, um auch verteilte Angriffe besser zu erkennen. Denkbar wären etwa Ansätze, die mehrere IP-Adressen gruppiert betrachten oder die Login-Versuche mit Risikofaktoren für die jeweiligen Benutzerkonten verknüpfen. In der Version 31 hat Nextcloud das Thema Login erzwingen von „Rate Limit“ bereits stärker in die Server-API integriert. Aber eine grundlegende Neuausrichtung steht vermutlich erst später an.
Bis dahin bleibt den Administratoren nichts anderes übrig, als die vorhandenen Stellschrauben zu nutzen und im Blick zu behalten. Das ist keine angenehme Botschaft, aber zumindest eine ehrliche. Ein Brute-Force-Schutz ist kein Produkt, das man einmal einrichtet und dann vergisst. Es ist eine Wartungsaufgabe, die in den regelmäßigen Betriebsablauf gehört. Wer diese Aufgabe ernst nimmt, wird mit einer ruhigeren Logdatei, weniger Last und einem besseren Gefühl bei der Anmeldung belohnt.
Und vielleicht ganz zum Schluss ein Satz, den man so nicht oft hört: Nextclouds eingebaute Schutzfunktion ist einer der Gründe, warum man für einen durchschnittlichen Einsatz keine zusätzliche teure Web-Firewall kaufen muss. In Kombination mit Fail2ban und einer sauberen Proxy-Konfiguration kommt man auf ein Sicherheitsniveau, das den Vergleich mit vielen kommerziellen Produkten nicht scheuen muss. Man muss es nur eben ein wenig verstehen und konsequent einsetzen. Das gilt für die Nextcloud insgesamt, und es gilt ganz besonders für den stillen Helden, der dahinter arbeitet.