Redis Security Hardening for Production

1. The starting point: Redis is insecure by default

Redis was originally designed for use in trusted, isolated networks, and that design decision still shapes the default configuration today. Without explicit hardening, a fresh Redis installation listens on all network interfaces, requires no password, and grants every connected client the full command palette, including commands that can wipe the entire database in seconds. In a Magento environment where Redis holds sessions, object cache and sometimes sensitive configuration data, this default configuration is simply not acceptable for production.

The consequences of an unhardened Redis instance are well documented in practice: automated scanners continuously search the open internet for reachable Redis ports, and unprotected instances are regularly abused for ransomware attacks, data theft, or as part of botnets. The attack path is often surprisingly simple: an open connection without a password is enough to read data, manipulate it, or even execute code on the host through manipulated configuration values.

This article covers hardening systematically across five levels: authentication, fine-grained rights management via ACLs, network isolation, restriction of dangerous commands, and encryption of transport. Each of these levels addresses a different attack surface, and only the combination of all five results in production ready Redis hardening.

2. requirepass: the minimum authentication

The simplest and simultaneously most important hardening step is enabling a password via the requirepass directive. Without this password, Redis accepts every incoming connection without any check. The password should be long, randomly generated and never reused, ideally generated and distributed via a password manager or a secrets management system like Vault, instead of being typed manually into configuration files.

An important, often overlooked point: requirepass alone does not protect against brute force attacks if Redis remains reachable from outside, because the command is processed extremely fast and no built-in rate limiting exists. An attacker could theoretically try hundreds of thousands of passwords per second. requirepass should therefore be understood as one of several defense layers, not as a standalone solution.

; /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)

Since Redis 6, requirepass is technically an alias for assigning a password to the default user in the new ACL system, but it still works as usual for simple setups. For production Magento environments with multiple applications accessing the same Redis instance, however, switching directly to full ACLs, covered in the next section, is worthwhile.

3. ACLs: differentiated rights instead of one password for all

Redis 6 introduced a full access control list system that goes far beyond a single shared password. ACLs allow creating multiple users with different rights: a user for the Magento application with read and write rights on specific key patterns, a separate user for monitoring tools with read-only rights, and an administrator user with full access used only for manual maintenance.

The decisive security gain from ACLs in a Magento environment with multiple logical Redis instances for cache, session and full page cache is the ability to restrict every user to their respective key pattern. A compromised monitoring account can then never manipulate session data, even if it operates on the same physical Redis instance. This isolation significantly reduces the blast radius of a single compromised credential.

# 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

The -@dangerous directive automatically excludes an entire category of risky commands, including FLUSHALL, FLUSHDB, CONFIG, SHUTDOWN and DEBUG, without having to list each one individually. The ACL file should be maintained outside of version control in a secrets manager, and access to the generated passwords should be restricted to the deployment system and a small circle of authorized administrators.

4. Network binding: only internal interfaces allowed

Even with a strong password and ACLs, a Redis instance listening on all network interfaces remains unnecessarily exposed. The bind directive in redis.conf should be explicitly restricted to the server's internal IP address or a private network segment, never to 0.0.0.0, which includes all interfaces, including potentially publicly reachable ones.

In addition to the bind directive, protected-mode yes should remain active, a security feature that Redis has enabled by default since version 3.2 and that rejects connections from non-local addresses as long as no password is set. This feature is an additional safety net in case the bind configuration is accidentally wrong, but it does not replace correct firewall and bind configuration.

; /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

At the infrastructure level, a firewall rule should additionally open the Redis port only for the IP addresses of the Magento application servers, never for the entire internal network or even the internet. In cloud environments, Security Groups take on this function, in classic setups iptables or nftables. This network isolation is the most effective single measure against automated scanners, because it makes Redis completely invisible to unauthorized sources, regardless of whether authentication is correctly configured.

5. Disabling or renaming dangerous commands

Even with correct authentication and network isolation, certain Redis commands remain a risk, because they can have catastrophic consequences in a failure scenario, through compromised application credentials, or through accidental misuse. FLUSHALL and FLUSHDB delete the entire dataset immediately and irrevocably. CONFIG allows changing the runtime configuration, including the storage location for RDB files, which historically has been abused in combination with SET for remote code execution. SHUTDOWN terminates the process immediately.

The standard solution is to either fully disable these commands or give them a cryptically long, random name, so they are only known if you explicitly look at the configuration. This measure complements ACLs, because it also applies when a user was accidentally granted overly broad rights, or a legacy client still uses the old, simple password model without ACL restriction.

; /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)

An empty string as the target name disables the command completely, so it can no longer be called under any name. This is the safest option for commands like FLUSHALL, which are never needed in normal Magento operation anyway, except through a deliberate administrative command outside the application. KEYS should also be disabled in production environments, both for security and performance reasons, since SCAN serves the same purpose without a blocking risk.

6. Setting up TLS encryption from Redis 6

Since version 6, Redis supports native TLS encryption for communication between client and server, as well as for replication between instances. Without TLS, data, including session contents and passwords during authentication, is transmitted in plaintext. In purely internal, isolated network segments this may be tolerable, but in cloud environments with shared network infrastructure or under compliance requirements like PCI-DSS, TLS is mandatory.

Setup requires certificates for the server and optionally for client authentication via mutual TLS. For internal infrastructure, a self-operated certificate authority is usually sufficient, whose root certificate is deposited as trusted on all involved servers. The performance overhead of TLS is low on modern CPUs with AES-NI support and negligible in the vast majority of cases compared to the security gain.

; /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"

After enabling TLS, the client, in this case Magento via the PHP Redis extension or Credis, must be configured with the matching certificate paths. A common mistake is enabling TLS on the server side but not actually disabling the plaintext port via port 0, which leaves both connection paths open in parallel and makes the TLS measure ineffective as long as the unencrypted port remains reachable.

7. Connecting hardened Redis to Magento

After hardening, Magento's env.php must be adapted to the new configuration: password, TLS parameters and, if applicable, certificate paths for client authentication. These changes affect all three Redis roles equally, cache, session and full page cache, even when they run on separate instances.

// 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,
            ],
        ],
    ],
],

Passwords never belong directly in plaintext in env.php, especially when this file is versioned. Using environment variables via getenv(), combined with a secrets manager that sets these variables at runtime, keeps credentials out of the version control system and allows central rotation without triggering code deployments.

8. Continuous verification: audit and monitoring

Hardening is not a one-time state, but an ongoing process. After the initial configuration, it should be checked regularly whether the hardening measures are still active, especially after updates, Redis version changes, or infrastructure migrations, where configuration files can accidentally get reset. An automated check that is part of the CI/CD pipeline or a regular cron job catches such regressions early.

It is also worth checking ACL LOG, which logs failed authentication attempts and permission violations. Repeated failed attempts from an unknown IP address are a clear signal of an active scanning or brute force attempt and should feed into a central monitoring and alerting system.

# 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. Hardening checklist overview

The following table summarizes the five hardening levels with their respective priority and concrete configuration goal, as a quick reference for audits and new deployments.

Authentication and network binding are non-negotiable and should be active from day one in every production Redis instance. ACLs and command restriction follow shortly after as a second line of defense. TLS is situationally mandatory, but even in purely internal networks a worthwhile investment that already anticipates future compliance requirements.

10. Summary

Production ready Redis hardening for Magento environments rests on five pillars: strong authentication via passwords or ACLs, consistent network isolation via bind configuration and firewall rules, fine-grained rights assignment per application role, disabling catastrophic commands like FLUSHALL and CONFIG, and TLS encryption for transport. None of these measures alone is sufficient, but together they form a robust defense against the most common attack vectors on Redis instances.

Hardening is not a one-time project, but must be embedded into deployment pipelines, infrastructure code and regular audits, so configuration drift does not silently reopen security gaps. Whoever consistently implements and regularly reviews these five levels operates Redis in Magento environments with a security posture that withstands automated scanners and most targeted attacks.

11. FAQ: Redis Security Hardening for Magento