Skip to main content

Security and Best Practices

Redis is a powerful in-memory data store, but like any component in your architecture, it must be secured and managed with best practices. This lesson covers the essential security features of Redis, how to properly configure them, and practical advice to protect your data and infrastructure. You'll also learn common pitfalls and how to avoid them, ensuring your Redis deployment is robust and safe.

Why Security Matters in Redis​

Redis prioritizes performance, often running as an open TCP service on the network. By default, it is not secure against malicious actors. Exposing an unsecured Redis instance can lead to data leaks, corruption, and even remote code execution. With ever-increasing threats, adopting security best practices is not optional—it's essential.

Redis Security Features and Concepts​

1. Binding to Interfaces​

By default, Redis listens on all network interfaces. Limit binding to trusted interfaces to prevent unauthorized access.

Example (redis.conf):

bind 127.0.0.1

This restricts Redis to accept connections only from localhost.

Use Case:
For a single-server deployment or when using a reverse proxy, always bind to 127.0.0.1 or your internal IP address.

2. Require Authentication​

Redis supports password-based authentication. Without a password, anyone can connect and issue commands.

Set a Password (redis.conf):

requirepass S3cureP@ssw0rd

Connect with Password (CLI):

redis-cli -a S3cureP@ssw0rd

Python Example (redis-py):

import redis
r = redis.Redis(password='S3cureP@ssw0rd')
r.ping()

Credential Rotation:
Change passwords regularly and never hardcode them in source code repositories.

3. Access Control Lists (ACLs)​

Redis 6.0+ introduces fine-grained access control via ACLs. You can define multiple users, restrict commands, and control key patterns.

Example (redis.conf):

user readonly on >readonlypass ~* +@read
user admin on >adminpass allcommands allkeys
  • readonly user can only run read commands on all keys.
  • admin user has full access.

Using ACLs (CLI):

redis-cli --user readonly -a readonlypass

Best Practice:
Grant the least privilege necessary for each user or application.

4. Protecting Sensitive Commands​

Some commands (FLUSHALL, CONFIG, SHUTDOWN, etc.) are dangerous if misused. Use ACLs to restrict these commands.

Deny Dangerous Commands (redis.conf):

user appuser on >apppass ~* +@all -FLUSHALL -CONFIG -SHUTDOWN

Explanation:
This user can do everything except execute FLUSHALL, CONFIG, and SHUTDOWN.

5. Renaming or Disabling Dangerous Commands​

For extra security, you can rename or disable risky commands.

Example (redis.conf):

rename-command FLUSHALL ""
rename-command CONFIG "CONFIGDISABLED"
  • Disables FLUSHALL entirely.
  • Renames CONFIG to CONFIGDISABLED.

Use Case:
This makes it harder for attackers and accidental scripts to run sensitive commands.

6. Network Security: Firewalls and TLS​

Firewalls​

Always use firewalls (iptables, cloud security groups, etc.) to restrict which IPs can connect to Redis.

Example (Linux iptables):

iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

TLS/SSL Encryption​

Redis supports TLS for encrypted client-server communication.

Enabling TLS (redis.conf):

tls-port 6379
port 0
tls-cert-file /etc/ssl/certs/redis.crt
tls-key-file /etc/ssl/private/redis.key
tls-ca-cert-file /etc/ssl/certs/ca.crt

Connect with TLS (CLI):

redis-cli --tls --cert redis.crt --key redis.key --cacert ca.crt

Best Practice:
Never expose plaintext Redis traffic over public or untrusted networks.

7. Securing Redis in Containers and Cloud​

  • Isolate Redis containers: Use Docker networks or Kubernetes namespaces.
  • Use managed Redis services: e.g., AWS ElastiCache, Azure Cache for Redis, which handle many security aspects.
  • Keep Redis updated: Always run the latest stable version to patch vulnerabilities.

Common Mistakes and Pitfalls​

  1. Exposing Redis to the Internet
    • Many breaches occur when port 6379 is open to the world. Always restrict access.
  2. Using Default or Weak Passwords
    • Attackers scan for common passwords. Use strong, unique secrets.
  3. Relying Solely on Application-Level Security
    • Secure Redis itself, not just your application.
  4. Ignoring Updates
    • Outdated Redis versions may contain unpatched vulnerabilities.
  5. Neglecting Command Restrictions
    • Even trusted users can make mistakes. Use ACLs and command renaming.

Summary​

Redis security is multi-layered: protect the network, require authentication, use ACLs for least-privilege access, disable/rename risky commands, and encrypt traffic. Always combine Redis's built-in features with external protections like firewalls and proper deployment practices. Security is not a one-time task—review and update your security posture regularly.

Quiz​

  1. What Redis configuration prevents the server from accepting connections from all network interfaces?

    • a) port 0
    • b) bind 127.0.0.1
    • c) requirepass
    • d) renaming commands

    Answer: b) bind 127.0.0.1

  2. Which feature allows you to restrict which commands and keys a user can access in Redis 6.0+?

    • a) Firewall rules
    • b) Lua scripting
    • c) Access Control Lists (ACLs)
    • d) Modules

    Answer: c) Access Control Lists (ACLs)

  3. What is the effect of rename-command FLUSHALL "" in redis.conf?

    • a) Renames FLUSHALL to an empty command
    • b) Disables the FLUSHALL command entirely
    • c) Restricts FLUSHALL to admin users only
    • d) No effect

    Answer: b) Disables the FLUSHALL command entirely

  4. True or False:
    Using a strong password and enabling TLS are sufficient to expose Redis safely to the public Internet.

    Answer: False

  5. What is a common pitfall that leads to Redis data breaches?

    • a) Using Lua scripts
    • b) Exposing Redis on an open/public network without authentication
    • c) Disabling persistence
    • d) Using hashes instead of strings

    Answer: b) Exposing Redis on an open/public network without authentication