Redis-Security-Haertung fuer den Produktivbetrieb

1. Die Ausgangslage: Redis ist unsicher per Default

Redis wurde urspruenglich fuer den Einsatz in vertrauenswuerdigen, isolierten Netzwerken entworfen, und diese Designentscheidung praegt bis heute die Standardkonfiguration. Ohne explizite Haertung lauscht eine frische Redis-Installation auf allen Netzwerk-Interfaces, verlangt kein Passwort, und erlaubt jedem verbundenen Client die vollstaendige Kommandopalette, inklusive Befehlen, die die komplette Datenbank in Sekunden loeschen koennen. In einer Magento-Umgebung, in der Redis Sessions, Objektcache und mitunter sensible Konfigurationsdaten haelt, ist diese Standardkonfiguration fuer den Produktivbetrieb schlicht nicht akzeptabel.

Die Konsequenzen einer ungehaerteten Redis-Instanz sind in der Praxis dokumentiert: automatisierte Scanner durchsuchen das offene Internet kontinuierlich nach erreichbaren Redis-Ports, und ungeschuetzte Instanzen werden regelmaessig fuer Ransomware-Angriffe, Datendiebstahl oder als Teil von Botnetzen missbraucht. Der Angriffsweg ist dabei oft ueberraschend simpel: eine offene Verbindung ohne Passwort reicht aus, um Daten auszulesen, zu manipulieren oder ueber manipulierte Konfigurationswerte sogar Code auf dem Host auszufuehren.

Dieser Artikel behandelt die Haertung systematisch entlang von fuenf Ebenen: Authentifizierung, feingranulare Rechteverwaltung ueber ACLs, Netzwerk-Isolation, Einschraenkung gefaehrlicher Befehle und Verschluesselung der Uebertragung. Jede dieser Ebenen adressiert eine unterschiedliche Angriffsflaeche, und erst die Kombination aller fuenf ergibt eine produktionstaugliche Redis-Haertung.

2. requirepass: die minimale Authentifizierung

Der einfachste und zugleich wichtigste Haertungsschritt ist die Aktivierung eines Passworts ueber die requirepass-Direktive. Ohne dieses Passwort akzeptiert Redis jede eingehende Verbindung ohne jegliche Pruefung. Das Passwort sollte lang, zufaellig generiert und nicht wiederverwendet sein, idealerweise ueber einen Passwort-Manager oder ein Secrets-Management-System wie Vault erzeugt und verteilt, statt manuell in Konfigurationsdateien getippt zu werden.

Ein wichtiger, oft uebersehener Punkt: requirepass allein schuetzt nicht vor Brute-Force-Angriffen, wenn Redis trotzdem von aussen erreichbar bleibt, weil das Kommando extrem schnell verarbeitet wird und keine eingebaute Rate-Begrenzung existiert. Ein Angreifer kann theoretisch hunderttausende Passwoerter pro Sekunde durchprobieren. requirepass ist daher als eine von mehreren Verteidigungsebenen zu verstehen, nicht als alleinstehende Loesung.

; /etc/redis/redis.conf: minimum authentication baseline
requirepass "aK9#mP2$vN8xQ4wZ7yT1uR6sL3jH0gF5c"

; Also require the password for internal replication traffic
masterauth "aK9#mP2$vN8xQ4wZ7yT1uR6sL3jH0gF5c"

; Do not log the password itself in slow query logs
; (Redis automatically redacts AUTH command arguments since 6.0)

Ab Redis 6 ist requirepass technisch ein Alias fuer die Vergabe eines Passworts an den Default-User im neuen ACL-System, funktioniert aber weiterhin wie gewohnt fuer einfache Setups. Fuer produktive Magento-Umgebungen mit mehreren Anwendungen, die auf dieselbe Redis-Instanz zugreifen, lohnt sich jedoch der direkte Umstieg auf vollstaendige ACLs, die im naechsten Abschnitt behandelt werden.

3. ACLs: differenzierte Rechte statt eines Passworts fuer alle

Mit Redis 6 wurde ein vollstaendiges Access-Control-List-System eingefuehrt, das weit ueber ein einzelnes gemeinsames Passwort hinausgeht. ACLs erlauben es, mehrere Benutzer mit unterschiedlichen Rechten anzulegen: ein Nutzer fuer die Magento-Anwendung mit Lese- und Schreibrechten auf bestimmte Key-Patterns, ein separater Nutzer fuer Monitoring-Tools mit ausschliesslich Leserechten, und ein Administrator-Nutzer mit vollem Zugriff, der nur fuer manuelle Wartung genutzt wird.

Der entscheidende Sicherheitsgewinn von ACLs in einer Magento-Umgebung mit mehreren logischen Redis-Instanzen fuer Cache, Session und Full-Page-Cache ist die Moeglichkeit, jeden Nutzer auf sein jeweiliges Key-Pattern zu beschraenken. Ein kompromittierter Monitoring-Account kann so niemals Session-Daten manipulieren, selbst wenn er auf derselben physischen Redis-Instanz operiert. Diese Isolation reduziert den Blast Radius eines einzelnen kompromittierten Credentials erheblich.

# Create a dedicated user for the Magento application with scoped access
redis-cli ACL SETUSER magento-app on \
  >aK9#mP2$vN8xQ4wZ7yT1uR6sL3jH0gF5c \
  ~cache:* ~session:* \
  +@read +@write +@keyspace \
  -@dangerous \
  -flushall -flushdb -config -shutdown

# Read-only user for monitoring dashboards
redis-cli ACL SETUSER monitoring on \
  >mR4#kL8$wX2vB6zY9tQ1eS7uJ0hG3fD5c \
  ~* \
  +@read +info +ping \
  -@write -@dangerous

# Persist ACL configuration so it survives a restart
redis-cli ACL SAVE

# Verify configured users and their scopes
redis-cli ACL LIST

Die Direktive -@dangerous schliesst automatisch eine ganze Kategorie riskanter Befehle aus, darunter FLUSHALL, FLUSHDB, CONFIG, SHUTDOWN und DEBUG, ohne jeden einzeln auflisten zu muessen. Die ACL-Datei sollte ausserhalb der Versionskontrolle in einem Secrets-Manager gepflegt werden, und der Zugriff auf die generierten Passwoerter sollte auf das Deployment-System und einen kleinen Kreis autorisierter Administratoren beschraenkt bleiben.

4. Netzwerk-Bindung: nur interne Interfaces erlauben

Selbst mit starkem Passwort und ACLs bleibt eine Redis-Instanz, die auf allen Netzwerk-Interfaces lauscht, unnoetig exponiert. Die bind-Direktive in der redis.conf sollte explizit auf die interne IP-Adresse des Servers oder auf ein privates Netzwerksegment beschraenkt werden, niemals auf 0.0.0.0, das alle Interfaces einschliesst, inklusive potenziell oeffentlich erreichbarer.

Zusaetzlich zur bind-Direktive sollte protected-mode yes aktiv bleiben, eine Sicherheitsfunktion, die Redis seit Version 3.2 standardmaessig aktiviert und die Verbindungen von nicht-lokalen Adressen ablehnt, solange kein Passwort gesetzt ist. Diese Funktion ist ein zusaetzliches Sicherheitsnetz, falls die bind-Konfiguration versehentlich fehlerhaft ist, ersetzt aber keine korrekte Firewall- und Bind-Konfiguration.

; /etc/redis/redis.conf: bind only to the internal application subnet
bind 10.0.1.30 127.0.0.1
protected-mode yes
port 6380

; Explicitly disable the default port if running on a non-standard one
; to reduce automated scanner hits

Auf Infrastrukturebene sollte zusaetzlich eine Firewall-Regel den Redis-Port nur fuer die IP-Adressen der Magento-Application-Server oeffnen, keinesfalls fuer das gesamte interne Netzwerk oder gar das Internet. In Cloud-Umgebungen uebernehmen Security Groups diese Funktion, in klassischen Setups iptables oder nftables. Diese Netzwerk-Isolation ist die wirksamste Einzelmassnahme gegen automatisierte Scanner, weil sie Redis fuer nicht autorisierte Quellen komplett unsichtbar macht, unabhaengig davon, ob Authentifizierung korrekt konfiguriert ist.

5. Gefaehrliche Befehle deaktivieren oder umbenennen

Selbst mit korrekter Authentifizierung und Netzwerk-Isolation bleiben bestimmte Redis-Befehle ein Risiko, weil sie im Fehlerfall, durch kompromittierte Anwendungs-Credentials oder durch versehentliche Fehlbedienung katastrophale Folgen haben koennen. FLUSHALL und FLUSHDB loeschen den kompletten Datenbestand sofort und unwiderruflich. CONFIG erlaubt es, die Laufzeitkonfiguration zu aendern, inklusive des Speicherorts fuer RDB-Dateien, was in Kombination mit SET historisch fuer Remote-Code-Execution missbraucht wurde. SHUTDOWN beendet den Prozess sofort.

Die Standardloesung ist, diese Befehle entweder komplett zu deaktivieren oder mit einem kryptisch langen, zufaelligen Namen zu versehen, sodass sie nur bekannt sind, wenn man die Konfiguration explizit einsieht. Diese Massnahme ergaenzt ACLs, weil sie auch dann greift, wenn ein Nutzer versehentlich mit zu weitreichenden Rechten ausgestattet wurde oder ein Legacy-Client noch das alte, einfache Passwort-Modell ohne ACL-Beschraenkung nutzt.

; /etc/redis/redis.conf: disable or rename catastrophic commands
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command SHUTDOWN "SHUTDOWN_a8f3e9c2b1"
rename-command CONFIG "CONFIG_7d2a4f8e91"
rename-command DEBUG ""
rename-command KEYS ""

; Keep SCAN available as the safe alternative to KEYS
; (SCAN is not affected by this rename)

Ein leerer String als Zielname deaktiviert den Befehl vollstaendig, sodass er unter keinem Namen mehr aufrufbar ist. Das ist die sicherste Option fuer Befehle wie FLUSHALL, die im normalen Magento-Betrieb ohnehin nie noetig sind, es sei denn ueber ein bewusstes administratives Kommando ausserhalb der Anwendung. KEYS sollte in produktiven Umgebungen ebenfalls deaktiviert werden, sowohl aus Sicherheits- als auch aus Performance-Gruenden, da SCAN denselben Zweck ohne Blockierungsrisiko erfuellt.

6. TLS-Verschluesselung ab Redis 6 einrichten

Seit Version 6 unterstuetzt Redis native TLS-Verschluesselung fuer die Kommunikation zwischen Client und Server sowie fuer Replikation zwischen Instanzen. Ohne TLS werden Daten, inklusive Session-Inhalte und Passwoerter bei der Authentifizierung, im Klartext uebertragen. In rein internen, isolierten Netzwerksegmenten mag das tolerierbar sein, in Cloud-Umgebungen mit geteilter Netzwerk-Infrastruktur oder bei Compliance-Anforderungen wie PCI-DSS ist TLS jedoch verpflichtend.

Die Einrichtung erfordert Zertifikate fuer Server und optional fuer Client-Authentifizierung per Mutual-TLS. Fuer interne Infrastruktur reicht meist eine selbst betriebene Certificate Authority, deren Root-Zertifikat auf allen beteiligten Servern als vertrauenswuerdig hinterlegt wird. Der Performance-Overhead von TLS ist bei modernen CPUs mit AES-NI-Unterstuetzung gering und in den allermeisten Faellen vernachlaessigbar gegenueber dem Sicherheitsgewinn.

; /etc/redis/redis.conf: enable TLS and disable the plaintext port
port 0
tls-port 6380
tls-cert-file /etc/redis/tls/redis-server.crt
tls-key-file /etc/redis/tls/redis-server.key
tls-ca-cert-file /etc/redis/tls/ca.crt

; Require client certificates for mutual TLS authentication
tls-auth-clients yes

; Enforce TLS for replication traffic as well
tls-replication yes

; Restrict to strong cipher suites only
tls-ciphers "ECDHE-RSA-AES256-GCM-SHA384"
tls-protocols "TLSv1.2 TLSv1.3"

Nach der Aktivierung von TLS muss der Client, in diesem Fall Magento ueber das PHP-Redis-Extension oder Credis, mit den passenden Zertifikatspfaden konfiguriert werden. Ein haeufiger Fehler ist, TLS auf Serverseite zu aktivieren, aber den Klartext-Port ueber port 0 nicht wirklich zu deaktivieren, wodurch beide Verbindungswege parallel offenbleiben und die TLS-Massnahme wirkungslos wird, solange der unverschluesselte Port erreichbar bleibt.

7. Gehaertetes Redis in Magento einbinden

Nach der Haertung muss die env.php von Magento an die neue Konfiguration angepasst werden: Passwort, TLS-Parameter und gegebenenfalls Zertifikatspfade fuer Client-Authentifizierung. Diese Aenderungen betreffen alle drei Redis-Rollen gleichermassen, Cache, Session und Full-Page-Cache, auch wenn sie auf getrennten Instanzen laufen.

// app/etc/env.php: connecting Magento to a hardened, TLS-enabled Redis instance
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => 'tls://10.0.1.30',
        'port' => '6380',
        'password' => getenv('REDIS_SESSION_PASSWORD'),
        'timeout' => '2.5',
    ],
],
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => 'tls://10.0.1.10',
                'port' => '6380',
                'password' => getenv('REDIS_CACHE_PASSWORD'),
                'persistent' => 1,
            ],
        ],
    ],
],

Passwoerter gehoeren niemals direkt im Klartext in die env.php, insbesondere wenn diese Datei versioniert wird. Die Nutzung von Umgebungsvariablen ueber getenv(), kombiniert mit einem Secrets-Manager, der diese Variablen zur Laufzeit setzt, haelt Zugangsdaten aus dem Versionskontrollsystem heraus und erlaubt eine zentrale Rotation, ohne Code-Deployments auszuloesen.

8. Kontinuierliche Ueberpruefung: Audit und Monitoring

Haertung ist kein einmaliger Zustand, sondern ein fortlaufender Prozess. Nach der initialen Konfiguration sollte regelmaessig geprueft werden, ob die Haertungsmassnahmen noch aktiv sind, insbesondere nach Updates, Redis-Versionswechseln oder Infrastruktur-Migrationen, bei denen Konfigurationsdateien versehentlich zurueckgesetzt werden koennen. Ein automatisierter Check, der Teil der CI/CD-Pipeline oder eines regelmaessigen Cronjobs ist, faengt solche Regressionen fruehzeitig ab.

Zusaetzlich lohnt sich ein Blick in ACL LOG, das fehlgeschlagene Authentifizierungsversuche und Berechtigungsverletzungen protokolliert. Wiederholte fehlgeschlagene Versuche von einer unbekannten IP-Adresse sind ein klares Signal fuer einen aktiven Scan- oder Brute-Force-Versuch und sollten in ein zentrales Monitoring- und Alerting-System einfliessen.

# Automated hardening verification, run periodically or in CI
echo "Checking bind address..."
grep -E "^bind" /etc/redis/redis.conf

echo "Checking protected-mode..."
grep -E "^protected-mode" /etc/redis/redis.conf

echo "Checking for disabled dangerous commands..."
grep -E "^rename-command (FLUSHALL|FLUSHDB|CONFIG|SHUTDOWN)" /etc/redis/redis.conf

echo "Checking recent ACL violations..."
redis-cli -a "$REDIS_ADMIN_PASSWORD" --no-auth-warning ACL LOG 10

echo "Verifying TLS is enforced..."
redis-cli -a "$REDIS_ADMIN_PASSWORD" --no-auth-warning CONFIG GET port

9. Haertungs-Checkliste im Ueberblick

Die folgende Tabelle fasst die fuenf Haertungsebenen mit ihrer jeweiligen Prioritaet und dem konkreten Konfigurationsziel zusammen, als schnelle Referenz fuer Audits und neue Deployments.

Authentifizierung und Netzwerk-Bindung sind nicht verhandelbar und sollten in jeder produktiven Redis-Instanz vom ersten Tag an aktiv sein. ACLs und Befehls-Restriktion folgen kurz danach als zweite Verteidigungsebene. TLS ist situationsabhaengig Pflicht, aber selbst in rein internen Netzwerken eine sinnvolle Investition, die zukuenftige Compliance-Anforderungen bereits vorwegnimmt.

10. Zusammenfassung

Eine produktionstaugliche Redis-Haertung fuer Magento-Umgebungen ruht auf fuenf Saeulen: starke Authentifizierung ueber Passwoerter oder ACLs, konsequente Netzwerk-Isolation ueber Bind-Konfiguration und Firewall-Regeln, feingranulare Rechtevergabe pro Anwendungsrolle, Deaktivierung katastrophaler Befehle wie FLUSHALL und CONFIG, sowie TLS-Verschluesselung fuer die Uebertragung. Keine dieser Massnahmen allein reicht aus, aber gemeinsam bilden sie eine robuste Verteidigung gegen die haeufigsten Angriffsvektoren auf Redis-Instanzen.

Haertung ist dabei kein einmaliges Projekt, sondern muss in Deployment-Pipelines, Infrastruktur-Code und regelmaessige Audits eingebettet werden, damit Konfigurationsdrift nicht unbemerkt Sicherheitsluecken wieder oeffnet. Wer diese fuenf Ebenen konsequent umsetzt und regelmaessig ueberprueft, betreibt Redis in Magento-Umgebungen mit einem Sicherheitsniveau, das automatisierten Scannern und den meisten gezielten Angriffen standhaelt.

11. FAQ: Redis-Security-Haertung fuer Magento