Redis absichern: Warum offene Datenbanken KMU zum Verhängnis werden

Vor Kurzem meldete ein Sicherheitsforscher mehrere zuvor unbekannte Schwachstellen in der weitverbreiteten Datenbank Redis – gefunden mithilfe eines KI-gestützten Analyse-Tools. Das ist kein Einzelfall: Redis-Instanzen gehören seit Jahren zu den am häufigsten kompromittierten Diensten im Internet, weil sie in vielen Unternehmen ohne Passwort und direkt erreichbar im Netz stehen. Für KMU, die Redis als Cache oder Session-Speicher hinter Webanwendungen betreiben, ist das ein Risiko, das oft unbemerkt bleibt – bis der Server plötzlich leer oder verschlüsselt ist.

Warum Redis so oft zum Problem wird

Redis wurde ursprünglich als schneller, interner Cache konzipiert – nicht als Dienst, der öffentlich erreichbar sein soll. Aus diesem Grund läuft Redis in der Standardkonfiguration ohne Authentifizierung und bindet sich auf allen Netzwerkschnittstellen (0.0.0.0). Wird ein Redis-Server bei der Einrichtung eines Webshops, einer Automatisierungsplattform wie n8n oder einer selbstgebauten Anwendung unbedacht in einer Docker-Umgebung oder Cloud-VM gestartet, landet er ungewollt im offenen Internet.

Angreifer scannen das Internet permanent nach offenen Redis-Ports (Standard: 6379). Ist keine Authentifizierung aktiv, können sie:

• alle gespeicherten Daten auslesen, verändern oder löschen
• über den Befehl CONFIG SET das Arbeitsverzeichnis von Redis manipulieren
• eine SSH-Public-Key-Datei in authorized_keys schreiben und sich so direkten Serverzugriff verschaffen
• die Datenbank als Ausgangspunkt nutzen, um Ransomware auf dem gesamten Server zu platzieren

Diese Kette – offener Port, keine Authentifizierung, Schreibzugriff auf das Dateisystem – ist seit Jahren dokumentiert und wird trotzdem regelmäßig ausgenutzt, weil viele Unternehmen Redis “mal eben schnell” aufsetzen und die Absicherung auf später verschieben.

Zero-Day-Lücken kommen obendrauf

Selbst korrekt konfigurierte, passwortgeschützte Redis-Server sind nicht automatisch sicher. Die aktuell gemeldeten Schwachstellen zeigen, dass auch im Kernprogramm selbst Fehler stecken können, die unter bestimmten Bedingungen zur Ausführung von Schadcode führen. Wer Redis produktiv einsetzt, muss deshalb zwei Dinge gleichzeitig im Blick behalten: die Grundkonfiguration und den Patch-Stand der Software.

Praxisteil: Redis in 6 Schritten absichern

1. Niemals ungeschützt ins Netz

Redis sollte grundsätzlich nur auf 127.0.0.1 oder in einem internen, per Firewall abgeschotteten Netzwerksegment lauschen. In der redis.conf:

bind 127.0.0.1 -::1
protected-mode yes

Ein Zugriff von außen erfolgt ausschließlich über die Anwendung, die Redis nutzt – niemals direkt über das Internet.

2. Authentifizierung aktivieren

Ab Redis 6 gibt es ein vollwertiges ACL-System (Access Control Lists), mit dem sich einzelne Nutzer mit eingeschränkten Rechten anlegen lassen – statt eines einzigen globalen Passworts:

requirepass <starkes-zufalls-passwort>
user app-user on >app-passwort ~cache:* +get +set -@dangerous

So kann eine kompromittierte Anwendung nicht automatisch die gesamte Datenbank manipulieren.

3. Gefährliche Befehle deaktivieren oder umbenennen

Befehle wie CONFIG, FLUSHALL, FLUSHDB, DEBUG oder SHUTDOWN sollten produktiv nicht ohne Weiteres verfügbar sein:

rename-command CONFIG ""
rename-command FLUSHALL ""

4. Netzwerksegmentierung nutzen

Redis gehört nicht in dasselbe Netzsegment wie öffentlich erreichbare Webserver. Mit einer OPNsense-Firewall lässt sich der Zugriff auf Redis-Ports gezielt auf die Anwendungsserver beschränken, die ihn tatsächlich benötigen – ein Grundprinzip, das für ostdeutsche KMU mit gewachsenen Serverlandschaften besonders wichtig ist, weil hier historisch oft alles im selben Netz hängt.

5. Patch-Management konsequent umsetzen

Redis-Versionen veralten schnell, und Sicherheitslücken werden regelmäßig nachgemeldet. Ein fester Prozess für Updates – idealerweise automatisiert getestet und ausgerollt – verhindert, dass bekannte Lücken monatelang offenstehen.

6. Monitoring einrichten

Ungewöhnliche Befehlsmuster, plötzliche CONFIG-Aufrufe oder unerwartete Verbindungen aus fremden IP-Bereichen lassen sich mit einem zentralen Log-Monitoring frühzeitig erkennen, bevor aus einem Versuch ein erfolgreicher Angriff wird.

Für Dresden und Sachsen besonders relevant

Viele Startups und KMU in Dresden und Sachsen setzen auf schlanke, selbst gehostete Infrastruktur – Redis ist dabei oft Teil des Stacks hinter Webshops, internen Tools oder Automatisierungsplattformen. Genau diese pragmatische Server-Kultur macht die Stadt zu einem Ort, an dem Redis-Instanzen häufig schnell aufgesetzt und selten nachträglich gehärtet werden. Ein einmaliger Blick in die eigene Serverlandschaft lohnt sich: Ein offener Redis-Port ist in wenigen Minuten gefunden – und in wenigen Minuten auch abgesichert.

Sie betreiben Redis, Datenbanken oder andere interne Dienste und sind unsicher, ob diese korrekt abgeschottet sind? Rexoma prüft als IT-Dienstleister aus Dresden die Serverlandschaft ostdeutscher KMU auf offene Ports, fehlende Authentifizierung und veraltete Softwarestände – und setzt die Härtung direkt um.

FAQ

Woran erkenne ich, ob mein Redis-Server offen im Internet erreichbar ist? Ein einfacher Portscan von außen (z. B. mit nmap -p 6379 <server-ip>) zeigt, ob Port 6379 von außen erreichbar ist. Ist das der Fall und lässt sich ohne Passwort mit redis-cli verbinden, besteht akuter Handlungsbedarf.

Reicht ein Passwort allein aus? Nein. Ein Passwort verhindert unautorisierten Zugriff, schützt aber nicht vor Schwachstellen im Redis-Kernprogramm selbst. Bind-Adresse, Firewall-Regeln und aktuelle Patches gehören ebenso zur Absicherung.

Muss Redis überhaupt aus dem Internet erreichbar sein? In den allermeisten Fällen nein. Redis kommuniziert mit der eigenen Anwendung, die üblicherweise auf demselben Server oder im selben internen Netz läuft. Ein direkter Zugriff aus dem Internet ist praktisch nie notwendig.

Was tun, wenn ein Redis-Server bereits kompromittiert wurde? Server vom Netz trennen, Passwörter und Zugangsschlüssel rotieren, authorized_keys-Dateien auf unbekannte Einträge prüfen und die Datenbank aus einem sauberen Backup wiederherstellen. Anschließend die Ursache – meist eine offene Bind-Adresse ohne Authentifizierung – beheben.

Gilt das auch für andere Datenbanken wie MongoDB oder Elasticsearch? Ja, das gleiche Grundmuster – Standardkonfiguration ohne Authentifizierung, offen im Netz erreichbar – betrifft auch andere NoSQL-Datenbanken. Die hier beschriebenen Prinzipien (Bind-Adresse, Authentifizierung, Netzwerksegmentierung, Patch-Management) lassen sich direkt übertragen.