Redis ACL and Security Hardening Prompt

You are a senior security-focused SRE who has hardened Redis against real-world compromises.

I will provide:
- My Redis version and deployment (standalone, replica, Cluster, managed)
- Who/what connects and what they need to do
- My current redis.conf / ACL setup

Your job:

1. **Lock down network exposure first**: `bind` to specific interfaces (not 0.0.0.0 on a public NIC), keep `protected-mode yes`, never expose 6379 to the internet, put it behind a private network/security group.
2. **Replace the default user**: the `default` user historically allows full access with no password. Either set a strong password (`requirepass`/ACL) or disable it (`ACL SETUSER default off`) and create scoped users.
3. **Design least-privilege ACL users**: `ACL SETUSER <name> on >password ~keyprefix:* +@read +@string -@dangerous`. Explain categories (@read, @write, @admin, @dangerous, @keyspace) and key patterns (~pattern), channel patterns (&pattern) for pub/sub.
4. **Restrict dangerous commands**: remove or rename FLUSHALL, FLUSHDB, CONFIG, KEYS, DEBUG, SHUTDOWN via ACL (-@dangerous / -flushall) or `rename-command` to an unguessable string (or "" to disable).
5. **Persist ACLs**: use an external `aclfile` and `ACL SAVE`, or CONFIG REWRITE; avoid keeping secrets only in memory.
6. **Audit**: `ACL LIST`, `ACL WHOAMI`, `ACL GETUSER`, `ACL CAT`, and log auth failures.
7. **Secrets hygiene**: no plaintext passwords in shell history or committed config; use secret stores; rotate.
8. **Layer with TLS** (separate concern) and disable Lua/DEBUG for untrusted clients.

Mark DESTRUCTIVE: `ACL DELUSER` of an in-use account (locks out apps), `rename-command`/CONFIG REWRITE (breaks tooling expecting original names), `CONFIG SET requirepass` without updating clients, FLUSHALL.

---

Version/deployment: [DESCRIBE]
Who connects and needs what: [DESCRIBE]
Current config/ACL: [PASTE]

Why this prompt works

Most Redis breaches come from the same handful of defaults: bound to the world, no password, default user with full access, dangerous commands wide open. This prompt drives a defense-in-depth pass — network, identity, least-privilege ACLs, command restriction, and persistence — while flagging the exact changes that can lock out live applications.

How to use it

1. State version and whether it is internet-adjacent — network first.
2. Enumerate every client and the minimal commands/keys it needs.
3. Paste your current ACL/config so gaps are concrete.
4. Roll out ACL changes with a new user before disabling the old one.

Useful commands

# Inspect current security posture
redis-cli ACL LIST
redis-cli ACL WHOAMI
redis-cli ACL GETUSER default
redis-cli ACL CAT                       # list command categories
redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode

# Create a least-privilege app user (read/write only its prefix)
redis-cli ACL SETUSER app_orders on '>S3cret!' '~orders:*' '+@read' '+@write' '-@dangerous'

# Neuter the default user
redis-cli ACL SETUSER default off

# Persist ACLs
redis-cli ACL SAVE                      # requires aclfile configured

Example config

# redis.conf hardening
bind 127.0.0.1 10.0.1.5                  # private interfaces only
protected-mode yes
port 6379

# Externalized ACLs (preferred over inline user directives)
aclfile /etc/redis/users.acl

# Disable/rename the most dangerous commands
rename-command FLUSHALL ""               # disable entirely
rename-command FLUSHDB  ""
rename-command KEYS     ""               # forces SCAN instead
rename-command DEBUG    ""
rename-command CONFIG   "CONFIG_9f2a71"  # keep for ops, unguessable name

# /etc/redis/users.acl
#   user default off
#   user app_orders on #<sha256-pw> ~orders:* +@read +@write -@dangerous
#   user admin on #<sha256-pw> ~* +@all

Common findings this catches

• World-bound + no auth → open, compromised instance.
• Live default user → unauthenticated full access.
• Over-broad ACLs → app can FLUSHALL or read all keys.
• KEYS/DEBUG exposed → DoS and info-leak vectors.
• Ephemeral ACLs → security config lost on restart.
• Secrets in history → leaked credentials.
• No auth-failure logging → brute force unnoticed.

When to escalate

• Any internet-exposed instance — immediate network remediation with security.
• Suspected compromise — incident response, rotate all secrets, audit persistence files.
• Command renaming that breaks managed tooling — coordinate with platform team.