Security

Redis AUTH

Redis allows you to require a password to access the server. This is the first layer of security.

How it Works:

A password is defined in redis.conf:

requirepass myStrongPassword

When enabled, all clients must authenticate before running commands.

Connecting with AUTH:

redis-cli
127.0.0.1:6379> AUTH myStrongPassword
OK
127.0.0.1:6379> SET user:1 "Masum"
OK

If you try to run a command without AUTH, Redis responds:

(error) NOAUTH Authentication required.

Redis ACLs (Access Control Lists)

Introduced in Redis 6.0, ACLs allow fine-grained role-based access control.

• You can define multiple users with different permissions.
• Permissions can restrict:
  • Commands (GET, SET, DEL, FLUSHALL, etc.)
  • Keys or key patterns (user:*, session:*, etc.)
• Provides better security than a single global password.

ACL Configuration

In redis.conf or dynamically using ACL commands:

Example: Create a user

ACL SETUSER alice on >AlicePass ~user:* +GET +SET

• alice → username
• on → enable the user
• >AlicePass → set password
• ~user:* → can access keys matching user:*
• +GET +SET → allowed commands

Example: Connect as Alice

redis-cli -u redis://alice@127.0.0.1:6379

• Alice can now only run GET and SET on keys starting with user:
• Any other command or key is forbidden.

View Users

ACL LIST

Delete or Disable User

ACL DELUSER alice
ACL SETUSER alice off

Network-level Security

Network-level security protects Redis from unauthorized access over the network. Even if your Redis server is running with proper authentication and ACLs, if the network is exposed, attackers can still try to connect.

Network-level security involves controlling access to Redis via networking configurations and secure communication protocols.

Key Network-Level Security Measures in Redis

1. Bind Address

   • Redis binds to a specific network interface. By default:

     bind 127.0.0.1

   • 127.0.0.1 → only accessible locally.

   • To allow external access:

     bind 0.0.0.0

     Warning: Exposing Redis to the public without security is very dangerous.

2. Protected Mode

   Enabled by default in Redis >= 3.2:

   protected-mode yes

   • Redis refuses connections from external hosts if no password is set.
   • Provides an extra layer for safeguarding default installations.

3. Firewall Rules

   Use firewalls to allow only trusted IPs to connect.

   Example: UFW on Linux

   # Allow Redis port 6379 only from 192.168.1.10
   sudo ufw allow from 192.168.1.10 to any port 6379

   Example: iptables

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

4. TLS/SSL Encryption

   • Redis >= 6 supports TLS for encrypted network traffic.
   • Protects data in transit and prevents man-in-the-middle attacks.

   Example: Enabling TLS

   In redis.conf:

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

   • port 0 disables non-TLS connections.
   • Clients must connect using TLS:

   redis-cli -h redis.example.com -p 6379 --tls

5. Network Segmentation

   • Place Redis in a private network or VPC.
   • Only application servers that need Redis can access it.
   • Avoid exposing Redis directly to the internet.

6. Disable Dangerous Commands

   While not strictly “network-level,” disabling commands like FLUSHALL or CONFIG can prevent attackers from damaging your system if they somehow gain network access.

   rename-command FLUSHALL ""
   rename-command CONFIG ""

Summary of Measures

Security Layer	Purpose	Example
Bind Address	Limit network interfaces	bind 127.0.0.1
Protected Mode	Prevent unauthorized remote access	protected-mode yes
Firewall / IP Whitelisting	Restrict access to trusted IPs	ufw allow from 10.0.0.5 to any port 6379
TLS/SSL Encryption	Encrypt traffic in transit	tls-port 6379
Network Segmentation	Isolate Redis in private network	VPC / Private Subnet
Disable Dangerous Commands	Mitigate risk if network is compromised	rename-command FLUSHALL ""

Private Network

Private Networks / VPCs

• Place Redis inside a private subnet in a Virtual Private Cloud (VPC).
• Only application servers or trusted IP addresses inside the VPC can communicate with Redis.
• Redis is not exposed to the public internet.

Example (Cloud Setup)

• AWS VPC with two subnets:
  • Public subnet → Web servers
  • Private subnet → Redis servers
• Web servers access Redis via internal IP (e.g., 10.0.1.10)

Firewall Rules

• Control which IPs or subnets can access Redis.
• On Linux, use ufw or iptables.
• In the cloud, use security groups or network ACLs.

Example: Linux Firewall (UFW)

# Allow only application server (10.0.1.5) to connect
sudo ufw allow from 10.0.1.5 to any port 6379

# Deny all other connections
sudo ufw deny 6379

Example: AWS Security Group

• Inbound rule: TCP 6379 → Source: 10.0.1.0/24 (private subnet)
• Outbound rule: allow Redis responses back to the app servers

Bind Redis to Private IP

In redis.conf, set:

bind 10.0.1.10          # Redis private IP
protected-mode yes       # Extra safeguard

Do not use 0.0.0.0 unless combined with strict firewall rules.

Optional: Combine with TLS

If you must allow access across a less-trusted network, enable TLS:

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

Encrypts traffic between client and Redis even on private networks.