Home / Skills / Developer Productivity / Redis Security
Developer Productivity

Redis Security

Redis, Inc.MITSkill language: English
License verifiedNo scripts
DemoReal run · claude-sonnet-5-5 · October 2026
Our production Redis runs on a VPS with 'bind 0.0.0.0', protected-mode no and no password. The app only needs to read and write keys starting with cache:. Give me a hardening plan with the config.
Skill: redis-security

Redis hardening plan for a cache:-only app

Right now anyone who can reach port 6379 has full control. That includes CONFIG SET dir and SLAVEOF, which attackers commonly use to get code execution or to write SSH keys. Check for compromise before you harden.

Step 0: Check whether it's already compromised

redis-cli CONFIG GET dir; redis-cli CONFIG GET dbfilename
redis-cli CLIENT LIST; redis-cli INFO replication
redis-cli --scan | grep -v '^cache:' | head      # unexpected keys
ls -la ~/.ssh/authorized_keys /etc/cron.d /var/spool/cron   # unexpected entries

If anything looks wrong, treat the host as breached and rebuild it. Rotate any secrets that were stored in Redis.

Step 1: Firewall first (immediate, no app change)

Allow only the app host's IP. This example uses ufw; use the iptables equivalent if you prefer.

ufw default deny incoming
ufw allow from <APP_SERVER_IP> to any port 6379 proto tcp
ufw allow 22/tcp   # ideally restricted to your IP too
ufw enable

If the VPS provider has a cloud firewall or security group, set the same rule there too. Docker bypasses ufw through its own iptables rules, so if Redis runs in Docker, publish the port as 127.0.0.1:6379:6379 or use the DOCKER-USER chain.

Step 2: Create ACL users

Don't use a single requirepass. Disable the default user and give the app a user scoped to cache:*. Generate the passwords with openssl rand -hex 32.

/etc/redis/users.acl:

user default off
user app on #<sha256 of app password> ~cache:* &* -@all +get +set +mget +mset +del +unlink +exists +expire +pexpire +ttl +pttl +incr +decr +scan +ping +hello +auth
user admin on #<sha256 of admin password> ~* &* +@all
  • &* can be changed to resetchannels if the app doesn't use pub/sub.
  • Trim the command list to what the app actually uses. If it needs hashes, add +hget +hset and so on.
  • Hash the passwords with echo -n 'pw' | sha256sum, so no plaintext is stored in the file.
  • Keep admin for operators only, and prefer reaching it over localhost or SSH.
  • SCAN isn't filtered by key pattern, so give the app +scan only if it needs it. It will see key names, but not values outside cache:*.

Step 3: redis.conf

# Network
bind 127.0.0.1 <PRIVATE_OR_PUBLIC_IFACE_IP>   # not 0.0.0.0
port 0                                        # disable plaintext if using TLS below
protected-mode yes

# Auth
aclfile /etc/redis/users.acl

# TLS (needed if traffic crosses the public internet)
tls-port 6379
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
tls-auth-clients optional     # use "yes" for mutual TLS
tls-protocols "TLSv1.2 TLSv1.3"

# Dangerous commands (ACLs already block them for `app`; this is defence in depth)
rename-command DEBUG ""
rename-command SHUTDOWN ""
# Prefer ACLs over renaming CONFIG/FLUSHALL, since rename-command is deprecated and breaks tooling.

# Cache behaviour
maxmemory 1gb
maxmemory-policy allkeys-lru
save ""                      # drop persistence if it's purely a cache
appendonly no

Also run as an unprivileged redis user. With systemd, add NoNewPrivileges=yes, ProtectSystem=full and ProtectHome=yes. Keep /etc/redis at mode 640, owned by root:redis.

Step 4: Roll out without an outage

  1. Apply the firewall (Step 1). The app keeps working.
  2. Add the ACL users while Redis is live, and test them from the app host:
    redis-cli --tls --user app --askpass SET cache:x 1     # OK
    redis-cli --tls --user app --askpass SET other:x 1     # NOPERM
    redis-cli --tls --user app --askpass FLUSHALL          # NOPERM
    
  3. Deploy the app with the new credentials, and with TLS if it's enabled.
  4. Restart Redis with the final config. The restart requires a maintenance window, because bind, tls-port and protected-mode can't all be changed on a live instance.
  5. Confirm from outside the allowed IP that the port is closed: nmap -p 6379 <vps_ip>.

Step 5: Ongoing

  • Set slowlog and latency-monitor and ship the logs somewhere. Alert on NOPERM and WRONGPASS spikes (ACL LOG).
  • Keep Redis patched, and keep the OS up to date.
  • Rotate the app password on a schedule. ACL users allow multiple passwords at once, so rotation needs no downtime.
  • If the app and Redis are on the same host, skip the network entirely. Use bind 127.0.0.1 or a unix socket (unixsocket /run/redis/redis.sock, unixsocketperm 770).

Notes

  • If the app is on the same private network, TLS is optional but still recommended. Across the public internet it is mandatory.
  • I tightened the example ACLs from the reference material. Its app_writer example uses ~* with +@all -@dangerous, which isn't limited to cache:*.

I can also write the config files out or review your current redis.conf if you'd like.

Pure-instruction skill, so the trial gave the model only the Skill and Read tools: no shell and no Redis server, and none of the commands were run. The answer goes beyond the skill text (for example ACL password hashes and Docker firewall notes); treat those parts as the model's own additions and test every setting on a staging copy first.

What it does
Tells the model how Redis, Inc. recommends locking down a production Redis: always authenticate, pair it with TLS, give each application its own ACL user, and keep the server off the open internet.

How it works

  1. Authentication and TLS: requirepass or, better, ACL users, with tls-port and certificate settings and client examples in Python and Java.
  2. ACLs: example users for a cache-only reader, a writer without dangerous commands, and an admin, plus the @read, @write, @dangerous and @admin categories.
  3. Network: bind to specific interfaces, keep protected-mode yes, firewall rules that allow only application subnets, and optionally disabling destructive commands.

Good for
Preparing a Redis deployment for production, defining ACL users for an app, or answering a scanner finding such as "Redis exposed to the internet".

Limits
Short (about 7 KB). It does not cover cloud-provider settings, Redis Cluster or auditing tools.

Notes & risks

Low risk: pure instruction files from the official Redis repository (MIT). No scripts, no network access, no file writes of its own, no account or key needed. But the advice changes how a production server is exposed (bind address, firewall rules, ACLs, disabled commands). If you or your agent apply it, a wrong rule can lock you out or break the application: try it on a staging copy first, keep a second session open while changing firewall or ACL settings, and have a way back.

SKILL.md original5 files in this package