Nextcloud absichern über den Sicherheitscheck hinaus: Härtung, Dateiintegrität, Ransomware-Alarm

Der eingebaute Scan prüft deinen Server von außen. Sentinel deckt das Innere ab: Anmeldungen nur mit Passwort, alte App-Passwörter, eine von dir bestätigte Datei-Baseline, ein Selbsttest auf offen liegende Dateien und ransomware-ähnliche Änderungen.

Warum die Prüfung von außen nicht reicht

Wenn du Nextcloud betreibst, kennst du vermutlich den offiziellen Sicherheitscheck, der deine Instanz aus dem Internet betrachtet und meldet, was ein Fremder sehen kann: Header, TLS, offengelegte Version. Auch die Admin-Übersicht leistet ihren Teil. Nextcloud kümmert sich bereits um Throttling, Passwort-Hashing, Header, Zwei-Faktor, Integritätssignaturen und so weiter, und das gut.

Was beide nicht sehen, ist der Zustand, der sich im laufenden Betrieb aufbaut. Das Konto, das sich weiterhin allein mit einem Passwort anmelden kann. Das App-Passwort eines Sync-Clients, den du vor Monaten ausgemustert hast und das heute noch funktionieren würde. Die Datei in der Installation, die sich geändert hat, obwohl niemand etwas geändert hat. Die Konfigurationsdatei, die dein Webserver jedem aushändigt, der danach fragt. Genau diese Lücke füllt Sentinel: eine fortlaufende Sicherheitsüberwachung, die in deiner Nextcloud lebt und dir meldet, wenn sich daran etwas ändert.

Dieses Tutorial führt durch eine praktische Härtungssitzung mit Sentinel, von der ersten Baseline bis zum wöchentlichen Cron-Eintrag.

Voraussetzungen

  • Nextcloud 34 und PHP 8.4 oder neuer. Absichtlich nichts Älteres.
  • Laufende Nextcloud-Hintergrundjobs (Cron), für die Watcher und die tägliche Zusammenfassung.
  • Konfigurierte Mail-Einstellungen in Nextcloud, wenn du E-Mail-Warnungen willst.
  • Optional: der EDR-Daemon (Linux 4.20+, Python 3.9+, root und systemd) und optional ClamAV über dessen clamd-Socket.

Die Installation selbst ist kurz. Lade das Archiv aus deinem MediaLab-Works-Konto unter Licenses herunter, entpacke es nach apps/ (oder custom_apps/) mit dem Webserver-Benutzer als Eigentümer, aktiviere es und füge deinen Lizenzschlüssel unter Administration settings → Sentinel → License ein. Die vollständigen Schritte stehen im Leitfaden.

Schritt 1: Baseline nehmen, bevor du etwas änderst

Mach das, sobald du sicher bist, dass die Installation in dem Zustand ist, in dem sie sein soll:

sudo -u www-data php occ sentinel:baseline take

Die Baseline erfasst den Code der Installation — lib, core, apps, 3rdparty, config, themes — in diesem Moment. Die Dateien der Nutzer sind nie enthalten. Ab dann werden nur Änderungen seit diesem Moment gemeldet.

Nach jedem Nextcloud- oder App-Update bestätigst du die geänderten Dateien einmal, mit einer Notiz, die du später verstehst:

sudo -u www-data php occ sentinel:baseline accept --all --note "Nextcloud 34.0.4"

Ein bewusster Patch bekommt dieselbe Behandlung. Was danach übrig bleibt, ist nur die unerklärte Änderung — und genau die willst du dir ansehen. Unter The files kannst du einstellen, welche Teile der Installation die Baseline abdeckt, die Dateitypen, Ausschlüsse, die Größenbeschränkung und den Hash.

Schritt 2: Die Statusseite lesen, das Schlimmste zuerst

Die Statusseite listet Befunde auf, jeweils mit Grund und Lösung daneben. In der Praxis siehst du etwa:

  • Konten, die sich allein mit einem Passwort anmelden können;
  • veraltete App-Passwörter;
  • inaktive Sitzungen;
  • ruhende Administratoren;
  • ablaufende Zertifikate;
  • ob überhaupt etwas protokolliert wird.

Arbeite die Liste von oben nach unten ab. Jeder Befund sagt, was er bedeutet und was passiert, wenn du ihn ignorierst, und hat die Aktion (ablaufen lassen, widerrufen, entfernen) direkt daneben. Die Schwellen für „zu alt“ legst du selbst fest unter What counts as too old: veraltete App-Passwörter, inaktive Sitzungen, ruhende Administratoren und Links ohne Ablauf.

Schritt 3: Prüfen, was dein Webserver tatsächlich ausliefert

Der Selbsttest fragt deinen eigenen Webserver als anonymer Besucher nach Dateien, die niemals ausgeliefert werden dürfen: die Konfiguration, das Log, .git-Verzeichnisse. Was zurückkommt, wird gemeldet.

Du kannst ihn auch im Terminal ausführen:

sudo -u www-data php occ sentinel:check --probe

Unter Asking the server what it serves schaltest du die Prüfung ein oder aus, ergänzt zusätzliche Pfade, die dir wichtig sind, und legst fest, wie viele Tage Warnung du vor dem Ablauf des Zertifikats willst.

Schritt 4: Die Zugänge im Blick behalten

Das Inventar listet jeden Weg in deine Instanz auf: öffentliche Links, Sitzungen, App-Passwörter, Gruppenmitgliedschaften — jeweils mit Ablaufen, Widerrufen oder Entfernen daneben. Kombiniere es mit den Watchern, die dich warnen, wenn sich etwas ändert: ein Konto wird Administrator, Zwei-Faktor wird abgeschaltet, ein neues Konto entsteht, eine Adresse arbeitet über mehrere Konten, ein Administrator meldet sich aus einem neuen Netz an, Apps werden aktiviert oder deaktiviert, vertrauenswürdige Domains oder Proxies ändern sich, oder ein Link wird von einer Menge geöffnet, an die er nie geschickt wurde.

Anmeldungen werden über das Netz gemerkt, das ein Konto nutzt, nicht über die exakte Adresse, und vertrauenswürdige Domains und Proxies werden nur als Fingerabdrücke gespeichert. Unter Where people sign in from entscheidest du, ob Netze überhaupt gemerkt werden, ob neue dich warnen, wie genau ein Netz ist und welche Konten ignoriert werden. Unter Public links stellst du die Überwachung der Linknutzung ein: wie groß eine Menge sein muss, um erwähnt zu werden, wie weit über dem eigenen Eintrag des Links, und wie viele abgelehnte Passwortversuche als Raten zählen.

Schritt 5: Ransomware-ähnliche Änderungen erkennen

Sentinel urteilt nicht allein nach der Rate. Es erkennt Ransomware auf einem synchronisierten Laptop an Dateien, die nicht mehr das sind, was ihre Namen behaupten, an Erpressernotizen und an massenhaften Umbenennungen. Die Stellschrauben liegen unter Files changing very fast: das Zeitfenster, die Zahl der Neuschreibungen, Löschungen oder Umbenennungen auf eine Endung, und ob nur gewarnt oder das Konto deaktiviert und seine Sitzungen beendet werden sollen.

Letzteres ist standardmäßig aus, und ich würde es so lassen, bis du den Schwellen auf deinen eigenen Daten vertraust. Sentinel ändert von sich aus nichts, außer du bittest es darum.

Schritt 6: Sicherstellen, dass Warnungen einen Menschen erreichen

Unter Being told wählst du, ab welcher Schweregradstufe Glocke und E-Mail genutzt werden, fügst eine zusätzliche Adresse hinzu — idealerweise eine, die ein Handy erreicht —, stellst die Stunde der täglichen Zusammenfassung ein und drückst Send a test message. Dann lies die Übersicht: in welchem Zustand der Server ist, was überwacht wird und was nicht, und ob Warnungen überhaupt jemanden erreichen würden.

Schritt 7: Einen wöchentlichen Check in Cron einbauen

occ sentinel:check gibt den Bericht aus und beendet sich mit einem Fehlercode, wenn etwas Aufmerksamkeit braucht. Damit ist ein wöchentlicher Cron-Eintrag, der nur bei Fehlschlag mailt, eine einzige Zeile:

sudo -u www-data php occ sentinel:check --quiet-when-clean

Er akzeptiert außerdem --inventory und --json, wenn du die Ausgabe woanders einspeisen willst.

Optional: EDR-Daemon und ClamAV

Wenn du wissen willst, welches Programm in das Datenverzeichnis schreibt, läuft der mitgelieferte EDR-Daemon in apps/sentinel/edr/ als root außerhalb von Nextcloud und kann den betroffenen Prozess anhalten:

cd /var/www/nextcloud/apps/sentinel/edr
sudo sh install.sh
sudoedit /etc/sentinel-edr/config.ini    # at minimum data_dir
sudo sh install.sh                       # again, to grant the paths it needs
sudo systemctl enable --now sentinel-edr

Unter Which program is writing sagst du Sentinel, ob der Daemon erwartet wird und wo er seine Berichte hinterlässt. Separat kannst du mit A scanner to ask auf ClamAV zeigen: den Socket und wie viel einer Datei gesendet wird. ClamAV scannt Dateien, die bereits falsch aussehen.

Tipps und Fehlerbehebung

  • Der Integritätsbereich listet direkt nach der Installation viele geänderte Dateien auf. Es wurde noch keine Baseline genommen, oder ein Update wurde nicht bestätigt. Nimm die Baseline, oder führe nach der Prüfung occ sentinel:baseline accept --all --note "..." aus.
  • Nichts wird überwacht, obwohl die App aktiviert ist. Hintergrundjobs müssen laufen (Cron). Nach einem Deaktivieren und erneuten Aktivieren öffne die Sentinel-Seite einmal: Die Jobs werden wieder eingerichtet, und der Einrichtungscheck meldet es.
  • E-Mail-Warnungen kommen nicht an. Prüfe die Mailserver-Einstellungen von Nextcloud und nutze Send a test message. Administratoren ohne E-Mail-Adresse bekommen nur die Glocke.
  • Du hast sie mit occ app:remove entfernt und Tabellen sind geblieben. Entferne sie stattdessen aus der App heraus oder mit occ sentinel:remove. Von Sentinel deaktivierte Konten bleiben deaktiviert, bis sie freigegeben werden (--release-accounts), und der EDR-Daemon läuft weiter, bis du ihn mit systemctl disable --now sentinel-edr stoppst.
  • Pausieren versus Entfernen. Du kannst die Überwachung pausieren, die App abschalten und alles behalten (occ app:disable sentinel) oder sie mit jedem von ihr geschriebenen Datensatz entfernen (occ sentinel:remove).
  • Datenschutz. Es gibt keine Telemetrie und kein Cloud-Konto. Die einzige ausgehende Verbindung ist die tägliche Lizenzprüfung an medialab.works, die den Abonnementschlüssel, die Instanz-ID, einen gehashten Hardware-Fingerabdruck, die App-Version und eine Prüfsumme der eigenen Dateien der App sendet — nichts über deine Nutzer, ihre Dateien, Anmeldungen oder Ereignisse. Alles wird in vier Tabellen gespeichert: Baseline, Ereignisse, bekannte Netze und tägliche Linknutzung.

Zum Abschluss

Nimm die Baseline, lies die Statusseite, prüfe, was dein Server ausliefert, und lass dir von den Watchern und der täglichen Zusammenfassung sagen, wenn sich etwas bewegt. Das ist die innere Hälfte der Nextcloud-Härtung, und es ist die Hälfte, die ein entfernter Scan nie sehen kann. Wenn du nicht weiterkommst, hat der Leitfaden die vollständige Referenz, das Changelog verfolgt die Änderungen, und die Wissensdatenbank und FAQ decken den Rest ab.

Dieser Beitrag wurde mit KI-Unterstützung auf Grundlage unserer Produktdokumentation oder der aufgeführten Quellen verfasst und vor der Veröffentlichung automatisch geprüft.

Als Nächstes lesen

Günstiges Webhosting in der EU mit Node.js, Python und PHP 8.5

Ein praktischer Rundgang durch unser Hosting in Rumänien: ein rootless Podman-Container pro Website, Apache oder nginx pro Site, Node.js 22/24 und Python 3.12 ab Standard, automatisches Cloudflare-DNS und die ehrlichen Grenzen, die du kennen solltest.

Du betreibst Emby, Jellyfin oder Nextcloud?

Unsere Plugins und Apps bringen Live-TV, Untertitel, Registrierung und Sicherheit auf deinen eigenen Server, mit kostenlosem Testzeitraum.