Redis Security

By default, Redis binds to all network interfaces and requires no password. This is fine on a laptop during development but dangerous on any server exposed to a network. A Redis instance left open on the internet can be accessed, drained, and used to execute commands by anyone. These steps close those gaps.

The Bank Vault Analogy

A bank vault with no lock, no guard, and an open door is not a vault — it is a storage room. Redis security is about adding the lock, the guard, and the door. Each layer makes unauthorized access harder.

Unsecured Redis (dangerous):
  ┌───────────────────────────────────────┐
  │  Redis Server                         │
  │  Listening on: 0.0.0.0:6379           │
  │  No password                          │
  │  No command restrictions              │
  │                                       │
  │  ← Anyone on the internet can connect │
  └───────────────────────────────────────┘

Secured Redis (safe):
  ┌───────────────────────────────────────┐
  │  Redis Server                         │
  │  Listening on: 127.0.0.1:6379         │ ← only local connections
  │  Protected by TLS                     │ ← encrypted traffic
  │  Requires password (AUTH)             │ ← authentication
  │  Dangerous commands renamed or off    │ ← reduced attack surface
  └───────────────────────────────────────┘

Step 1 – Bind to a Specific Interface

Tell Redis to listen only on the local loopback address. This makes the server unreachable from the outside network.

In redis.conf:
  bind 127.0.0.1

Or for a server that also serves your app on the same machine:
  bind 127.0.0.1 192.168.1.10
  (loopback + your private internal IP only)

Never use:
  bind 0.0.0.0   ← listens on all interfaces, including the internet

Step 2 – Enable Protected Mode

In redis.conf:
  protected-mode yes

With protected mode on and no password set, Redis rejects
connections from any address other than the loopback address.
This is a safety net in case you forget to bind correctly.

Step 3 – Set a Password with requirepass

In redis.conf:
  requirepass YourStrongPassphraseHere2024!

Any client must now authenticate before running commands:
  127.0.0.1:6379> AUTH YourStrongPassphraseHere2024!
  OK

Without AUTH, every command returns:
  (error) NOAUTH Authentication required.

Choose a long, random password. Redis processes hundreds of
thousands of requests per second, so brute-force attacks
run very fast without rate limiting.

Step 4 – Use Access Control Lists (ACL) for Fine-Grained Users

ACLs (introduced in Redis 6) let you create multiple users, each with their own password, allowed commands, and allowed keys. This replaces the single requirepass approach.

Create a read-only user for your reporting dashboard:
  ACL SETUSER reporter on >report_pass ~* &* +@read

  on         → user is enabled
  >report_pass → password
  ~*         → can access all keys
  +@read     → can run only read commands (GET, HGET, LRANGE, etc.)

Create an app user allowed only to work with specific keys:
  ACL SETUSER appuser on >appSecret123 ~user:* ~session:* +@all

  ~user:* ~session:* → can only access keys starting with user: or session:
  +@all              → can run all commands on those keys

List all users:
  ACL LIST

Verify current user:
  ACL WHOAMI

Step 5 – Rename or Disable Dangerous Commands

Commands like FLUSHALL, CONFIG, and DEBUG can wipe your data or expose server internals. Rename them to a secret string or disable them entirely.

In redis.conf:
  rename-command FLUSHALL ""          ← disabled (empty string = off)
  rename-command CONFIG   "cfg_9x7k2" ← renamed to a secret name
  rename-command DEBUG    ""          ← disabled
  rename-command KEYS     ""          ← disabled (use SCAN instead)

After this, running FLUSHALL returns:
  (error) ERR unknown command 'flushall'

Only someone who knows "cfg_9x7k2" can run CONFIG.

Step 6 – Enable TLS for Encrypted Connections

Without TLS, all data travels as plain text over the network. Anyone with network access between your app and Redis can read every command and response.

In redis.conf (Redis 6+):
  tls-port 6380
  tls-cert-file /etc/redis/tls/redis.crt
  tls-key-file  /etc/redis/tls/redis.key
  tls-ca-cert-file /etc/redis/tls/ca.crt

Connect with TLS:
  redis-cli --tls --cert /etc/redis/tls/redis.crt \
            --key /etc/redis/tls/redis.key \
            --cacert /etc/redis/tls/ca.crt -p 6380

Step 7 – Use a Firewall

Allow connections to port 6379 only from your app server's IP.
Block everything else at the OS firewall level (ufw, iptables, etc.):

  ufw allow from 192.168.1.20 to any port 6379
  ufw deny 6379

Even if bind and requirepass are misconfigured, the firewall
stops external connections before they reach Redis.

Security Checklist

┌────────────────────────────────────────────────────┬──────────┐
│  Measure                                           │  Status  │
├────────────────────────────────────────────────────┼──────────┤
│  bind to 127.0.0.1 or specific internal IP         │  □       │
│  protected-mode yes                                │  □       │
│  requirepass or ACL users configured               │  □       │
│  FLUSHALL, CONFIG, DEBUG disabled or renamed       │  □       │
│  TLS enabled for any network (non-loopback) path   │  □       │
│  Firewall blocks port 6379 from external IPs       │  □       │
│  Redis does not run as root user on the OS         │  □       │
└────────────────────────────────────────────────────┴──────────┘

Key Points

  • Bind Redis to a specific IP (127.0.0.1 or a private IP) — never 0.0.0.0 on a production server.
  • Set a long, random password with requirepass, or use ACL users for per-user access control.
  • Rename or disable FLUSHALL, CONFIG, and DEBUG to prevent accidental or malicious misuse.
  • Enable TLS when your app and Redis communicate over any non-loopback network.
  • Add a firewall rule to allow port 6379 only from trusted IP addresses as a final layer of protection.
Previous lessons
Back to courses
Next lessons

Leave a Comment