Nicht der Hacker war das Problem, sondern der offene Datenbank-Port

Kurz gesagt: Anfang Juli wurde bekannt, dass bei der Nextcloud GmbH rund 367.000 interne Datensätze offen im Netz standen — Rechnungen, Verträge, interne Mails, sogar Kundenskripte mit Datenbank-Passwörtern im Klartext. Keine Malware, kein Zero-Day. Nur eine Datenbank ohne Passwort, erreichbar aus dem Internet. Das ist kein Nextcloud-Problem. Das ist das häufigste Datenleck-Muster überhaupt — und es trifft jedes DMS, das falsch aufgesetzt wird.

Was passiert ist

Sicherheitsforscher von Cybernews fanden am 18. Mai einen Elasticsearch-Cluster der Nextcloud GmbH↗, der ohne jede Authentifizierung aus dem offenen Internet erreichbar war. Rund acht Gigabyte, 367.000 Datensätze.

Drin lagen Rechnungen, Verträge, interne E-Mails mit Absendern und Zeitstempeln, Mitarbeiter- und Kundendaten. Und — der unangenehmste Teil — kundenspezifische Shell- und Python-Skripte, in denen Datenbank-Zugangsdaten im Klartext standen.

Nextcloud hat sauber reagiert: Zugang binnen zwei Tagen geschlossen, den Vorfall an die Landesdatenschutzbehörde gemeldet↗. Betroffen war ausdrücklich nicht die Nextcloud-Software oder eine Kundeninstanz, sondern die eigene Firmen- und Hosting-Infrastruktur.

Ich schreibe das ohne Häme. Nextcloud ist ein Unternehmen, das ich respektiere — Open Source, Server in Deutschland, das Gegenteil einer Datenkrake. Genau das macht den Fall lehrreich. Wenn es die trifft, trifft es jeden.

Das Muster ist älter als die Cloud

Die häufigste Ursache für ein Datenleck ist nicht der geniale Angreifer. Es ist eine Datenbank, die jemand „nur mal kurz" nach außen geöffnet und dann vergessen hat.

Gartner sagt das seit Jahren: Bis 2026 gehen 99 Prozent der Cloud-Sicherheitsvorfälle auf das Konto des Kunden, nicht des Anbieters — fast immer durch Fehlkonfiguration↗. Der Anbieter sichert die Cloud, der Kunde alles, was er hineinstellt.

Auf Shodan↗, der Suchmaschine für offen erreichbare Systeme, sehen Sie das live: über 190.000 ungeschützte MongoDB-Instanzen, dazu tausende offene Elasticsearch-Cluster. Das sind keine Bastelserver. Da hängen Produktivdaten dran.

Warum das ständig passiert

Datenbanken wie Elasticsearch oder MongoDB hören in der Standard-Installation nur auf localhost. Sicher. Sobald aber ein zweiter Server dazukommt — der Suchindex hier, die Anwendung dort — muss man die Datenbank im Netz erreichbar machen. Man setzt network.host auf die interne IP, startet neu, es läuft.

Und dann fehlt der eine Schritt: die Firewall-Regel, die den Port 9200 auf das interne Netz begrenzt. Ohne sie lauscht die Datenbank plötzlich auf allen Interfaces — auch dem öffentlichen. Ohne Passwort, weil „ist ja nur intern". Shodan indexiert das binnen Stunden.

Kein exotischer Fehler. Der Klassiker.

Was das mit Ihrem DMS zu tun hat

Ein Dokumentenmanagement-System ist im Kern zwei Dinge: eine Datenbank mit Metadaten und ein Volltext-Suchindex über den Inhalt jedes Dokuments. Bei uns sind das MongoDB und Typesense, bei anderen Postgres und Elasticsearch. Das Prinzip ist immer gleich.

Der Punkt, den viele unterschätzen: Der Login Ihres DMS schützt nichts, wenn die Datenbank dahinter direkt erreichbar ist. Die Weboberfläche mit Benutzername und Passwort ist eine Tür. Steht daneben ein offenes Fenster zur Datenbank, nimmt der Angreifer das Fenster.

Und im Suchindex eines DMS liegt der OCR-Volltext — der lesbare Inhalt jeder Rechnung, jedes Arztbriefs, jedes Arbeitsvertrags. Für eine Arztpraxis oder eine Steuerkanzlei ist ein offener Suchindex kein „IT-Vorfall", sondern ein glasklarer Verstoß gegen § 203 StGB und Artikel 32 DSGVO.

Bei einem Interessenten aus der Immobilienverwaltung habe ich genau das im Frühjahr live gesehen. Das alte DMS lief seit Jahren, die Weboberfläche war ordentlich passwortgeschützt — aber der Solr-Suchindex dahinter hing offen am Internet, weil ein Dienstleister ihn 2019 „zum Testen" geöffnet und die Firewall-Regel nie zurückgesetzt hatte. Fünf Jahre lang stand jeder Mietvertrag im Klartext im Netz. Nachgesehen hatte in der Zeit niemand.

Das Thema hatte ich hier schon von der anderen Seite beleuchtet: ein DMS ersetzt kein Backup. Verfügbarkeit und Vertraulichkeit sind zwei Baustellen. Beide muss man aktiv absichern, keine erledigt sich von selbst.

Was ich jedem rate, der ein DMS selbst betreibt

Wer sein DMS selbst hostet, übernimmt die Sicherheit „in der Cloud" komplett selbst. Machbar — aber es sind ein paar Handgriffe, die niemand überspringen darf:

1. Datenbank und Suchindex nie ans öffentliche Netz. Binden Sie sie an localhost oder ein privates Netz (bei Hetzner das Cloud-Network oder den vSwitch), nie an 0.0.0.0.
2. Firewall als zweite Schicht. Verlassen Sie sich nicht allein auf die Bind-Adresse. Eine Regel, die die Ports 27017, 9200 und 8108 von außen dichtmacht, ist die Rückversicherung.
3. Authentifizierung auch intern. „Ist ja nur das interne Netz" ist genau die Annahme, die bei Nextcloud gebrochen wurde. Passwort auf die Datenbank, immer.
4. Keine Zugangsdaten in Skripten. Passwörter gehören in einen Secret-Manager oder eng berechtigte Umgebungsvariablen — nicht in eine deploy.sh, die dann selbst mit im Leak liegt.
5. Regelmäßig gegen Shodan prüfen. Suchen Sie Ihre eigene Server-IP auf shodan.io. Was Sie dort sehen, sieht ein Angreifer auch.
6. Backups getrennt und verschlüsselt. Ein offener Datenbank-Port und ein offener Backup-Speicher sind derselbe Fehler an zwei Orten.
7. Einmal im Jahr jemanden draufschauen lassen, der das System nicht selbst gebaut hat. Betriebsblindheit ist real.

Wer dafür kein eigenes Team hat, sollte genau prüfen, was der Betrieb beim Managed Hosting abdeckt — und was nicht. Diesen Teil nehmen wir unseren Kunden bewusst ab; er gehört bei uns zur Infrastruktur, nicht auf die Checkliste des Kunden.

Souveränität schützt vor US-Zugriff, nicht vor sich selbst

Vor drei Wochen rief mich der IT-Verantwortliche eines Sportverbands aus Kassel an. Sie hatten ihr altes System aus einer US-Cloud zu einem deutschen Anbieter geholt — richtig so. Seine Frage: „Sind wir jetzt sicher?" Meine Antwort gefiel ihm nicht. Der Serverstandort löst das Compliance-Problem, nicht das Konfigurationsproblem.

„Made in Germany" auf dem Server sagt nichts über die Firewall davor. Open Source sagt nichts über das Passwort auf der Datenbank. Das eine ist digitale Souveränität — wichtig, aber eine andere Baustelle. Das andere ist Handwerk.

Der Nextcloud-Fall ist deshalb keine Blamage einer einzelnen Firma. Er ist die Erinnerung, dass die teuerste Lücke fast nie im Produkt steckt, sondern im Betrieb. Der BSI-Lagebericht↗ beziffert den Gesamtschaden für die deutsche Wirtschaft auf über 200 Milliarden Euro — ein guter Teil davon geht nicht auf raffinierte Angriffe zurück, sondern auf offene Türen.

Wenn Sie nicht genau wissen, wie Ihr DMS aufgesetzt ist — Datenbank, Suchindex, Backups — dann reden Sie mit jemandem, der die richtigen Fragen stellt. Wir machen das im Erstgespräch ohne Verkaufsdruck: zum Kontakt. Lieber wir schauen einmal drauf als Shodan zuerst.