Redis Security in Production: ACL Users, TLS, and Protected Mode Configuration
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Redis is the most widely deployed in-memory data store, and it is consistently one of the most misconfigured. Unauthenticated Redis instances have been used for unauthorized cryptocurrency mining via cron-injected SSH keys, data exfiltration of session tokens and cached API responses, and lateral movement using Redis as a persistent command-and-control channel. The attack surface is well understood: unauthenticated server, bound to a public interface, with CONFIG command available for file write attacks. This guide covers the complete Redis security configuration: ACL user model replacing requirepass, TLS setup with the tls-port directive, bind restriction to private interfaces, dangerous command renaming, protected-mode enforcement, and Sentinel and Cluster authentication.
Restrict Network Binding and Enable Protected Mode
Network binding is the first Redis security control to configure. Redis should never listen on a public network interface in production, regardless of authentication configuration.
Set bind to loopback and private interface only
In redis.conf, set `bind 127.0.0.1 10.0.1.5` replacing the private IP with your server's actual internal interface address. This prevents Redis from accepting connections on any public-facing interface. The default Redis config in many Linux distributions ships with `bind 127.0.0.1` already, but cloud deployments via configuration management tools sometimes reset this to `bind 0.0.0.0`. Verify after any config change: `redis-cli CONFIG GET bind` should return only loopback and private addresses.
Verify protected-mode is on
Confirm protected-mode is active: `redis-cli CONFIG GET protected-mode` should return `yes`. Do not change this. Protected-mode is a safety net that blocks external connections when no authentication is configured -- it catches misconfiguration before it becomes exploitation. If a deployment requires `protected-mode no` for any reason, that reason is almost certainly a misconfigured bind or missing ACL, not a legitimate requirement.
Apply OS-level firewall rules as defense in depth
Add iptables or cloud security group rules allowing port 6379 (or your configured Redis port) only from known application server CIDR ranges: `iptables -A INPUT -p tcp --dport 6379 -s <app-cidr> -j ACCEPT; iptables -A INPUT -p tcp --dport 6379 -j DROP`. For Redis Sentinel, also restrict port 26379. For Redis Cluster, restrict 6379 (client) and 16379 (cluster bus). Firewall rules are defense in depth alongside bind restrictions -- if a misconfiguration sets bind to 0.0.0.0, the firewall catches the exposure.
Configure ACL Users for Least-Privilege Access
The Redis ACL system replaces the single requirepass password with per-user command, key, and channel restrictions. Configure ACL users for every application service that connects to Redis.
Disable the default user and create named ACL users
Redis creates a default user with full access (equivalent to requirepass). Disable it: `ACL SETUSER default off nopass nocommands nokeys`. Then create named users for each application service: `ACL SETUSER cache_svc on ><password> ~cache:* +get +set +del +expire +ttl +exists`. The `~cache:*` restricts key access to the cache: prefix. The `+` commands grant specific commands only -- the user starts with no permissions and each `+<cmd>` adds one. Save to the ACL file: `ACL SAVE`.
Use ACL categories for broader command grants
Instead of listing individual commands, use ACL category grants: `+@read` grants all read commands, `+@write` grants all write commands, `+@string` grants all string commands. For a full read-write caching user: `ACL SETUSER cache_svc on ><password> ~app:* +@read +@write +@string +@hash -@admin -@dangerous`. The `-@admin` and `-@dangerous` explicit denials block config, debug, shutdown, and slowlog commands even if they would otherwise be included in the granted categories. Verify the effective ACL for a user: `ACL GETUSER cache_svc`.
Rename dangerous commands before creating ACL users
Before configuring ACL users, rename dangerous commands in redis.conf so that even misconfigured ACL grants cannot expose them: `RENAME-COMMAND CONFIG b7f3e2a1d4c9 RENAME-COMMAND FLUSHALL '' RENAME-COMMAND FLUSHDB '' RENAME-COMMAND DEBUG '' RENAME-COMMAND SHUTDOWN b8e4f1a2c5d7`. Empty string disables the command entirely. A non-empty rename makes the command available only to callers who know the renamed string. Document the renamed strings in a secrets manager, not in redis.conf comments.
Configure ACL logging to detect unauthorized command attempts
Enable ACL logging to capture denied command attempts: `ACL LOG RESET` clears the log, `CONFIG SET acllog-max-len 256` sets the log buffer size. When an ACL user attempts a command they are not permitted, Redis logs the event: `ACL LOG COUNT` returns the number of denied operations since last reset, `ACL LOG` returns the recent denial events with user, command, key, and timestamp. Forward ACL log entries to your SIEM by tailing the Redis log file and parsing entries containing `ACL_DENIED`.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Enable TLS for Encrypted Connections
TLS prevents credential interception and data exposure on the network. Redis TLS requires certificates and is configured via the tls-port and tls-* directives.
Obtain or generate TLS certificates for Redis
Generate a CA and server certificate for Redis using openssl or your PKI: `openssl genrsa -out redis-ca.key 4096; openssl req -x509 -new -nodes -key redis-ca.key -sha256 -days 1825 -out redis-ca.crt -subj '/CN=Redis-CA'`. Issue a server certificate: `openssl genrsa -out redis-server.key 2048; openssl req -new -key redis-server.key -out redis-server.csr -subj '/CN=<redis-hostname>'; openssl x509 -req -in redis-server.csr -CA redis-ca.crt -CAkey redis-ca.key -CAcreateserial -out redis-server.crt -days 365 -sha256`. Distribute `redis-ca.crt` to all application servers as the trusted CA.
Configure redis.conf for TLS-only operation
In redis.conf: set `port 0` to disable the plaintext port, `tls-port 6380` to enable TLS on port 6380, `tls-cert-file /etc/ssl/redis/redis-server.crt`, `tls-key-file /etc/ssl/redis/redis-server.key`, `tls-ca-cert-file /etc/ssl/redis/redis-ca.crt`, `tls-auth-clients no` (no client certs required -- SCRAM via ACL handles auth). Set `tls-min-version TLSv1.2` to reject TLS 1.0 and 1.1 connections. Restart Redis and verify: `redis-cli -p 6380 --tls --cacert /etc/ssl/redis/redis-ca.crt PING` should return PONG.
Configure TLS for Redis Cluster and Sentinel
For Redis Cluster, enable TLS on the cluster bus port: `tls-cluster yes` in redis.conf. This encrypts node-to-node cluster communication in addition to client connections. For Redis Sentinel, configure TLS in sentinel.conf: `tls-port 26380`, `port 0`, and the same cert/key/ca directives. Update Sentinel `sentinel monitor` and `sentinel auth-pass` configurations to use the TLS port. Test Sentinel TLS: `redis-cli -p 26380 --tls --cacert /etc/ssl/redis/redis-ca.crt SENTINEL masters`.
The bottom line
Redis security hardening centers on three mandatory controls: bind to private interfaces only, require authentication via ACL users with per-service command and key restrictions, and disable CONFIG and FLUSHALL via RENAME-COMMAND before any production data is stored. TLS adds a fourth layer that prevents credential interception. The ACL system introduced in Redis 6.0 is a significant improvement over requirepass -- use it. Any Redis deployment running requirepass only, without ACL users, without RENAME-COMMAND for dangerous commands, or bound to 0.0.0.0, should be treated as an open security finding regardless of firewall rules.
Frequently asked questions
What is the difference between requirepass and the Redis ACL system?
requirepass sets a single shared password for the entire Redis server. Any client that authenticates with this password has access to all commands and all keys -- there is no per-user granularity, no key namespace isolation, and no command restriction. The ACL system (Redis 6.0+) creates named users, each with their own password, a set of permitted commands (e.g., +get +set -config -debug), a key pattern restriction (e.g., only keys matching the pattern `session:*`), and optionally a channels restriction for pub/sub. ACL users enable least-privilege Redis access: a caching service gets only GET/SET/DEL on its key prefix, while a separate session service gets HGET/HSET on its own prefix.
How do you configure TLS in Redis?
Redis TLS requires building Redis with TLS support (included in Redis 6.0+ official packages) and configuring the tls-port directive. In redis.conf: `tls-port 6380` (or keep port 6379 disabled by setting `port 0` for TLS-only), `tls-cert-file /etc/ssl/redis.crt`, `tls-key-file /etc/ssl/redis.key`, `tls-ca-cert-file /etc/ssl/ca.crt`. For mutual TLS (requiring client certificates): `tls-auth-clients yes`. For clients connecting with redis-cli: `redis-cli -h 127.0.0.1 -p 6380 --tls --cert /etc/ssl/client.crt --key /etc/ssl/client.key --cacert /etc/ssl/ca.crt`.
What Redis commands should be renamed or disabled in production?
The highest-risk Redis commands to rename or disable: CONFIG (allows reading and writing the Redis config file, used for file write attacks), DEBUG (internal testing command with attack potential), SLAVEOF/REPLICAOF (can redirect replication to an attacker-controlled host), FLUSHALL/FLUSHDB (instant data deletion for ransomware), KEYS (blocks the event loop on large keyspaces), SHUTDOWN (denial of service). Rename to a random string: `RENAME-COMMAND CONFIG 7f4e2b1a8c3d9f0e`. To disable entirely: `RENAME-COMMAND DEBUG ''`. Applications that legitimately need CONFIG (for Redis cluster management) can use the renamed command string.
What is Redis protected-mode and when does it trigger?
Protected-mode is a security feature enabled by default in Redis. When protected-mode is on and Redis is NOT bound to 127.0.0.1 only AND no password (requirepass or ACL) is configured, Redis refuses all external connections with an error explaining that the server is not configured securely. This protects newly deployed Redis instances from accidental internet exposure before credentials are configured. Protected-mode does not provide security once credentials are set -- it is a last-resort safeguard, not a replacement for proper bind and ACL configuration. Never set `protected-mode no` unless you have explicit bind restrictions and authentication configured.
How do you secure Redis Sentinel deployments?
Redis Sentinel requires authentication on both the Redis instances it monitors and on the Sentinel communication channel itself. Configure a Sentinel password in sentinel.conf: `requirepass <sentinel-password>`. Configure Sentinel to authenticate when connecting to Redis instances: `sentinel auth-pass <master-name> <redis-password>`. Bind Sentinel to private interfaces: `bind 127.0.0.1 <private-ip>`. If using ACL-based Redis auth (Redis 6.0+), also configure: `sentinel auth-user <master-name> <acl-user>`. Without Sentinel authentication, any client that can reach the Sentinel port can issue SENTINEL FAILOVER commands, triggering unplanned Redis failovers.
How does Redis persistence affect security?
Redis persistence (RDB snapshots and AOF logging) creates disk files that contain all Redis data, including any secrets, tokens, or PII stored in Redis. Secure these files: set the RDB dump file directory (`dir`) to a path accessible only by the redis OS user, set file permissions to 600 (`rdbchecksum yes` is default and validates integrity). The classic Redis attack using `CONFIG SET dir /root/.ssh; CONFIG SET dbfilename authorized_keys; BGSAVE` writes an RDB file to the SSH authorized_keys directory -- RENAME-COMMAND CONFIG '' blocks this. Encrypt the disk volume containing Redis persistence files at rest using dm-crypt or cloud disk encryption.
How do you implement ACL users for a multi-service Redis deployment?
Create per-service ACL users in redis.conf or via the ACL SETUSER command. For a session store service: `ACL SETUSER session_svc on >session_pass_here ~session:* +get +set +del +expire +ttl`. This user can only access keys matching `session:*` and can only execute the listed commands -- no KEYS, no CONFIG, no FLUSHDB. For a pub/sub service: `ACL SETUSER pubsub_svc on >pubsub_pass ~* +subscribe +publish +psubscribe &events:*`. The `&events:*` restricts pub/sub to channels matching the pattern. Persist ACL config with `ACL SAVE` to write current ACL rules to the aclfile specified in redis.conf.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.