Redis

Tested on: Ubuntu 24.04 LTS, Redis 7.2.x (from the official redis apt repository at packages.redis.io). Configuration paths use /etc/redis/redis.conf — RHEL-family installs use /etc/redis/redis.conf as well, so the file paths below are portable. Why this matters Almost every newsworthy Redis incident reduces to one of three failures: The server was bound to 0.0.0.0 “for testing” and reachable from the internet. There was no password (or the password was the example one from a tutorial). FLUSHALL, CONFIG, or DEBUG were left available, so a connected client could wipe data, exfiltrate keys, or write arbitrary files through CONFIG SET dir / BGSAVE. Redis is fast, in-memory, and trusts its clients by default. That trust is appropriate inside a private subnet with disciplined access controls. It is catastrophic everywhere else. This guide closes those three holes and adds the obvious next layer (TLS, resource limits, persistence safety). ...

What this script does redis-check is a read-only Bash + redis-cli script that reports on each recommendation from the Redis hardening guide: Network exposure (bind, protected-mode) Authentication (default user state, any ACL user with nopass) Dangerous-command accessibility (FLUSHALL, FLUSHDB, DEBUG, CONFIG, SHUTDOWN) TLS (tls-port vs cleartext port) Resource limits (maxmemory, maxmemory-policy, timeout) Persistence (appendonly) It uses only PING, INFO, CONFIG GET, ACL LIST, and COMMAND DOCS — no writes. If CONFIG has been renamed or disabled (recommended in the guide), the affected checks are skipped with a WARN rather than failing the whole run. ...