P-12 — Security: ACLs, TLS, and Network Hardening

Who this module is for: You have a Redis instance in production but its security posture is "it's on a private network, nobody can reach it." That is not enough. Redis has had critical vulnerabilities exploited via misconfigured network access. This module covers the full security model: ACLs, TLS, bind configuration, and the most common Redis security mistakes that lead to data breaches and server compromise.

The Security Threat Model

Redis was designed to be deployed on trusted networks — not exposed to the internet. Its original security model was simple: strong network perimeter, single shared password. As Redis has moved into cloud environments and microservices architectures, the threat model has evolved:

1. Unauthenticated access — Redis exposed publicly or on a poorly segmented internal network
2. Overprivileged clients — a compromised microservice can run FLUSHALL or CONFIG SET dir
3. In-transit data exposure — traffic between app and Redis is unencrypted and interceptable
4. Lateral movement — a compromised Redis instance can be used to write files to disk (via CONFIG SET dir + CONFIG SET dbfilename + BGSAVE), achieving code execution on the server

A correctly secured Redis deployment mitigates all four.

Network Hardening

Bind to Specific Addresses

By default in Redis 3.2+, Redis binds to 127.0.0.1 only — not publicly accessible. Explicitly configure the bind addresses:

Protected Mode

With protected-mode yes, if Redis is not bound to a specific address and has no authentication configured, it rejects all connections from non-loopback addresses. This is a safety net against accidentally exposing an unauthenticated Redis to the network.

Firewall Rules

At the infrastructure level, restrict Redis port (6379) to only your application servers:

On cloud providers, use security groups (AWS), firewall rules (GCP), or network security groups (Azure) to achieve the same.

Rename or Disable Dangerous Commands

Commands like FLUSHALL, FLUSHDB, CONFIG, DEBUG, SHUTDOWN, and SLAVEOF can cause catastrophic damage if abused. You can rename them to unpredictable strings or disable them entirely:

Limitation: rename-command applies to all clients. With ACLs (below), you can restrict commands per user more granularly.

Authentication: requirepass

Or at runtime:

With requirepass set, clients must authenticate before issuing commands:

In ioredis:

Limitations of requirepass:

• It is a single shared password for all clients
• There is no per-user access control
• A compromised password gives full access to all commands
• Use ACLs for multi-user or fine-grained access control

ACLs: Access Control Lists

Introduced in Redis 6.0, ACLs let you define per-user command and key restrictions. Each user has a username, password, a set of allowed commands, and a set of allowed key patterns.

Viewing the Default User

The default user has full access (all commands, all keys) when requirepass is not set. With ACLs, you should disable or restrict the default user.

ACL Rule Syntax

Command Categories

Common categories: read, write, string, hash, list, set, sortedset, generic, server, admin, dangerous.

Practical ACL Examples

Read-only cache user (application only reads from Redis):

This user can:

• Authenticate with password cache-reader-pass
• Access only keys matching cache:*
• Run read commands (GET, HGET, LRANGE, etc.)
• Cannot run admin commands (CONFIG, FLUSHALL, DEBUG, etc.)

Cache writer (application reads and writes cache):

Queue worker (only accesses queue keys):

Admin user (for operations, full access):

Disable the default user:

This forces all clients to use named users with passwords. Any client not providing a username will be rejected.

ACL in redis.conf

users.acl file format (each line is one user rule):

ACL in ioredis

ACL Logging

When a client attempts a denied command, the attempt is logged:

TLS Encryption

Redis 6.0+ supports TLS for in-transit encryption. Without TLS, all data (including passwords, session tokens, cached values) travels in plaintext over the network.

Generating Certificates

For production, use certificates from a trusted CA (Let's Encrypt, your PKI). For testing:

Redis TLS Configuration

TLS in ioredis

Common Redis Security Misconfigurations

1. Redis Bound to 0.0.0.0 Without Authentication

The most common breach vector. An unprotected Redis instance on 0.0.0.0 is globally accessible. Shodan reports tens of thousands of such instances at any given time.

Fix: bind 127.0.0.1 <private-ip> + firewall rules + requirepass or ACLs.

2. CONFIG SET dir + CONFIG SET dbfilename = Remote Code Execution

A client with access to CONFIG can change the RDB save directory and filename, then trigger BGSAVE to write arbitrary content to arbitrary paths on the server's filesystem. This has been used to write SSH keys to ~/.ssh/authorized_keys, achieving server access.

Fix: Disable CONFIG via ACL (-@admin) for all non-admin users, or via rename-command CONFIG "".

3. Default User with Full Access

Leaving the default user enabled with nopass (the default before Redis 6.0 required passwords) means any client can connect without authentication.

Fix: Set requirepass or use ACLs to disable/restrict the default user.

4. Sensitive Data in Plain-Text Redis Values

Session tokens, API keys, passwords, and PII stored in Redis without encryption. If Redis is compromised, all cached data is exposed.

Fix: Encrypt sensitive values before storing in Redis. Use TLS for in-transit encryption. Apply principle of minimal data — do not cache data that does not need to be cached.

Summary

• Bind to specific IPs — never 0.0.0.0 in production; use private IP + firewall rules
• Protected mode (yes by default) prevents unauthenticated access from non-loopback addresses
• ACLs (Redis 6.0+) — per-user command and key restrictions; disable or restrict the default user; use least-privilege users per application role
• TLS (Redis 6.0+) — encrypt in-transit data; use mutual TLS for additional client authentication
• Disable dangerous commands — CONFIG, DEBUG, FLUSHALL, SHUTDOWN via ACL -@admin or rename-command
• Monitor ACL violations with ACL LOG — unauthorized command attempts are audit signals
• The CONFIG SET dir + dbfilename + BGSAVE attack achieves arbitrary file write — restrict CONFIG access

Next: P-13 — Redis's Single-Threaded Event Loop: Speed, Limits, and Multithreading — how the event loop handles 100K+ RPS, what Redis 6+ multithreading parallelises, and the one failure mode that brings a Redis instance to its knees.