How to Secure Redis Installations: Essential Configuration Tips

Redis is fast, simple, and often trusted by application code with session data, queues, counters, and cached records. That makes Redis security important: one exposed instance can let an attacker read data, delete keys with FLUSHALL, or abuse administrative commands.

Your goal is to make Redis reachable only from the systems that need it, require authentication, reduce dangerous command access, and protect the files that hold configuration and persisted data.

---

1. Network Configuration: Limiting Exposure

The most immediate security measure is controlling which network interfaces Redis listens on. Many packaged Redis installations bind to localhost by default, but container images, custom config files, and older deployments may differ. Always check your active redis.conf instead of assuming the default is safe.

Binding to Specific Interfaces (bind)

You must configure Redis to only listen on necessary interfaces. In most production environments, this means binding only to the loopback address or a specific private IP address used by application servers.

Internal or Local Access Only

If your application server resides on the same host as Redis, bind exclusively to the loopback address.

# redis.conf configuration snippet
bind 127.0.0.1

Networked Private Access

If your application servers are on a private network segment and need network access, bind to that specific private IP address. Do not bind Redis to a public internet-facing IP. If you need remote access, put it on a private network and restrict traffic with firewall rules or security groups.

# List the specific internal IP addresses that should access Redis
bind 192.168.1.100 10.0.0.5

Understanding Protected Mode

Since Redis 3.2, protected mode is enabled by default in standard Redis builds. It helps block external access when Redis is not explicitly configured for remote clients. Treat it as a safety net, not your main control. Use binding restrictions, authentication, and firewall rules.

If you must disable it for a specific configuration, you can use:

protected-mode no

Warning: Only disable protected-mode when you have correctly configured bind, authentication, and network filtering.

2. Authentication and Access Control

Once network access is restricted, the next layer of defense is authentication. Clients should only be able to interact with Redis if they provide a valid password or, preferably, use the modern Access Control List (ACL) system.

Implementing Password Protection (requirepass)

Use the requirepass directive in your redis.conf file to enforce client authentication. This acts as a global shared secret for basic security.

# Set a strong, unique password
requirepass T4h!S_Is_V3ry_S3cure_P@ss

To connect using a password, clients must use the AUTH command:

# Example using redis-cli
$ redis-cli
127.0.0.1:6379> AUTH T4h!S_Is_V3ry_S3cure_P@ss
OK
127.0.0.1:6379> PING
PONG

Advanced Security: Redis Access Control Lists (ACLs)

For production environments running Redis 6.0 and later, ACLs are the preferred authentication method. ACLs allow you to define multiple users with specific passwords and granular permissions (e.g., User A can only read, User B can write to specific keyspaces).

ACL configuration typically involves defining users and their rules in redis.conf or a separate ACL file:

# Example ACL user definitions in redis.conf or an aclfile
user default off
user app_reader on >app_read_P@ss ~cache:* +get +scan
user app_writer on >app_write_P@ss ~data:* +set +del

Renaming or Disabling Dangerous Commands

Certain administrative commands (like FLUSHALL, CONFIG, KEYS, and SHUTDOWN) can cause operational disruptions or expose sensitive configuration details if misused. It is a best practice to either rename these commands to obscure names or disable them entirely.

To rename a command, use rename-command:

# Rename CONFIG command to prevent unauthorized changes
rename-command CONFIG HIDE_MY_CONFIG

# Disable FLUSHALL entirely
rename-command FLUSHALL ""

3. Operational Security Best Practices

Beyond internal Redis configuration, applying robust external operational security measures is crucial for a complete security posture.

Enforce Strict Firewall Rules

Regardless of the bind directive setting, always enforce network filtering using cloud security groups, iptables, or similar firewall solutions. The Redis default port (6379) should only be open to the specific IP addresses or IP ranges of your trusted application servers.

Example Firewall Rule (Linux/iptables)

Allow incoming traffic on port 6379 only from a known application server IP (192.168.1.50):

# Allow specific application server
iptables -A INPUT -p tcp -s 192.168.1.50 --dport 6379 -j ACCEPT

# Deny other incoming Redis traffic
iptables -A INPUT -p tcp --dport 6379 -j DROP

Running with Least Privilege

Never run the Redis server process as the root user. If an attacker compromises the Redis process, running it as root grants them full control over the entire operating system.

Create a dedicated, non-privileged system user such as redis, then configure your service manager to run the Redis process as that user. With systemd, this is normally handled in the unit file with directives such as User=redis and Group=redis, or by the packaged service that your distribution provides.

Securing Configuration Files and Persistence

The redis.conf file contains sensitive information like the requirepass password and network settings. Ensure this file, along with persistence files (RDB snapshots and AOF logs), is protected by restrictive file permissions, preventing unauthorized reading or modification by other system users.

# Example recommended permissions
# Only the 'redis' user and root should read/write
chown redis:redis /etc/redis/redis.conf
chmod 600 /etc/redis/redis.conf

Implement SSL/TLS Encryption

For environments where Redis traffic traverses an untrusted network segment (even internally), implement SSL/TLS encryption. While Redis historically lacked native TLS support, modern versions (starting with Redis 6) fully support it. Configuring TLS requires generating certificates and setting relevant directives in redis.conf:

# Enable TLS listener
tls-port 6379
port 0
tls-auth-clients yes
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt

port 0 disables the plaintext listener. Keep a plaintext port only when every client using it is on a trusted local path and you have a clear reason.

Summary of Essential Security Steps

Securing a Redis installation is a layered job. Start with exposure, then authentication, then operational controls:

1. Restrict Network Access: Use bind 127.0.0.1 or specific private IPs.
2. Enforce Authentication: Use requirepass (basic) or ACLs (advanced).
3. Harden Commands: Disable or rename dangerous administrative commands (FLUSHALL, CONFIG).
4. Use Firewalls: Only permit traffic on port 6379 from trusted application servers.
5. Least Privilege: Run the Redis process as a non-root, dedicated user.
6. Encrypt Traffic: Enable SSL/TLS for networked connections where appropriate.