1. The Historic Vulnerability of Default Redis Deployments
Redis was originally designed for trusted internal environments, lacking default authentication and binding to 0.0.0.0. Exposing Redis to public internet interfaces has led to widespread automated exploitation, where attackers write SSH keys or crontabs to host filesystems using the CONFIG SET and SAVE commands, seizing full root server compromise.
2. Binding and Network Isolation
Never expose port 6379 to external interfaces. In redis.conf, strictly bind the daemon to localhost (127.0.0.1) or a private VPC subnet IP. Ensure protected-mode yes is active, preventing Redis from answering queries from external network interfaces when no password is set.
3. Enforcing Native TLS (Redis 6.0+)
Beginning with Redis 6.0, native TLS encryption is supported without requiring stunnel proxies. Encrypt all client-to-server traffic and replication streams between primary and replica nodes by configuring valid TLS certificates in redis.conf: tls-port 6379, port 0, tls-cert-file /etc/redis/redis.crt, tls-key-file /etc/redis/redis.key, tls-auth-clients yes.
4. Access Control Lists (ACLs) and Command Renaming
Redis 6 introduced granular Access Control Lists (ACLs), replacing the single global requirepass with role-based user accounts. Furthermore, dangerous administrative commands should be completely disabled or renamed to cryptographically random strings: rename-command FLUSHALL "", rename-command CONFIG "CONFIG_x9823fha8s7d", preventing unauthorized data wiping.
