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 toresetchannelsif the app doesn't use pub/sub.- Trim the command list to what the app actually uses. If it needs hashes, add
+hget +hsetand so on. - Hash the passwords with
echo -n 'pw' | sha256sum, so no plaintext is stored in the file. - Keep
adminfor operators only, and prefer reaching it over localhost or SSH. SCANisn't filtered by key pattern, so give the app+scanonly if it needs it. It will see key names, but not values outsidecache:*.
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
- Apply the firewall (Step 1). The app keeps working.
- 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 - Deploy the app with the new credentials, and with TLS if it's enabled.
- Restart Redis with the final config. The restart requires a maintenance window, because
bind,tls-portandprotected-modecan't all be changed on a live instance. - Confirm from outside the allowed IP that the port is closed:
nmap -p 6379 <vps_ip>.
Step 5: Ongoing
- Set
slowlogandlatency-monitorand ship the logs somewhere. Alert onNOPERMandWRONGPASSspikes (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.1or 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_writerexample uses~*with+@all -@dangerous, which isn't limited tocache:*.
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.
できること
Redis, Inc. が推奨する本番 Redis の守り方をモデルに伝えます。必ず認証し TLS と併用すること、アプリごとに専用の ACL ユーザーを用意すること、サーバーをインターネットに直接公開しないことです。
仕組み
- 認証と TLS:
requirepass、より望ましい ACL ユーザー、tls-portと証明書の設定、Python と Java のクライアント例。 - ACL:キャッシュ読み取り専用ユーザー、危険なコマンドを禁止した書き込みユーザー、管理者の例と、
@read、@write、@dangerous、@adminなどのカテゴリ。 - ネットワーク:
bindで特定のインターフェースに限定しprotected-mode yesを維持、アプリのサブネットだけを許可するファイアウォール、必要に応じて破壊的コマンドの無効化。
向いている場面
Redis を本番投入する前の強化、アプリ用 ACL ユーザーの設計、スキャナーの「Redis がインターネットに公開されている」という指摘への対応。
制限
短い内容です(約 7 KB)。クラウド事業者側の設定、Redis Cluster、監査ツールは扱いません。
低リスク:Redis 公式リポジトリ(MIT ライセンス)の指示ファイルのみで、スクリプトなし、通信なし、自身によるファイル書き込みなし、アカウントやキーも不要です。ただし、助言の内容は本番サーバーの公開方法(bind アドレス、ファイアウォール、ACL、無効化するコマンド)を変えるものです。あなたやエージェントがそのまま適用すると、設定を誤って自分が締め出されたりアプリが止まったりする恐れがあります。まずステージング環境で試し、ファイアウォールや ACL を変更する間は別のセッションを開いたままにし、元に戻す手段を用意してください。