Redis Server Unprotected by Password Authentication (Nessus plugin 100634) means a scanner reached a Redis service, usually on TCP 6379, and could run commands without credentials. Fix it by setting requirepass or an ACL password for the default user, keeping protected-mode on, binding Redis to trusted interfaces, firewalling port 6379 and giving every client the new password.
What the scanner is actually detecting
The finding comes from Tenable Nessus plugin 100634, titled Redis Server Unprotected by Password Authentication. It is a remote, unauthenticated network check. Tenable’s description says the Redis server on the remote host is not protected by password authentication, and its solution is to enable the requirepass directive in redis.conf.
| Field | Value on the Tenable plugin page |
|---|---|
| Plugin name | Redis Server Unprotected by Password Authentication |
| Plugin ID | 100634 (redis_password_protection_disabled.nasl) |
| Severity | Critical |
| Type and family | Remote, Misc. |
| Dependency | redis_detect.nbin (Redis service detection) |
Because the plugin depends on Tenable’s Redis service detection, check the port in the plugin output: it is not always 6379. The important detail is where the scan came from. With the default configuration, Redis protected mode refuses clients on non-loopback addresses when the default user has no password. If a remote scanner got in without a password, then protected mode was off, or (on Redis before 7.0) an explicit bind line had switched it off, or the instance runs from the official Docker image, which disables protected mode by default.
Real-world risk
Redis is designed for trusted clients on trusted networks, and it has no authentication unless you configure it. Anyone who can reach an unprotected instance can:
- Read and change all data. Session stores, cached tokens, job queues and rate-limit counters are all exposed.
- Delete everything. The Redis security documentation points out that a single FLUSHALL wipes the whole data set.
- Write files on the server. The same page explains that CONFIG can change the working directory and dump file name, which lets a client write RDB files to arbitrary paths and can lead to code execution as the Redis user. Redis 7.0 and later make sensitive configs such as dir and dbfilename immutable by default and block DEBUG and MODULE, which narrows this path. The data exposure remains.
Urgency depends on reachability. A Redis port reachable from the Internet should be fixed today, and it is worth reviewing your external attack surface management scope to find out how it got there. An instance reachable only from its own application servers is lower risk, but one compromised host on that segment gets full access.
How to confirm it on the host
From another machine, ideally the scanner’s segment:
redis-cli -h <host> -p 6379 ping
# PONG = no authentication, finding is valid
# (error) NOAUTH Authentication required. = a password is set
# (error) DENIED Redis is running in protected mode ... = protected mode is blocking you
nmap -p 6379 --script redis-info <host>On the Redis host (loopback connections are allowed even in protected mode):
ss -tlnp 'sport = :6379'
redis-cli INFO server | grep -E 'redis_version|config_file|tcp_port'
redis-cli CONFIG GET requirepass
redis-cli CONFIG GET protected-mode
redis-cli CONFIG GET bind
redis-cli ACL LIST # Redis 6+: "user default on nopass ..." means no passwordThe config_file line tells you which file to edit. For containers, run docker ps –format ‘{{.Names}} {{.Ports}}’ | grep 6379 to see whether the port is published on the host.
How to fix it
Generate a long random password
Clients store the password, so nobody has to remember it. Redis recommends long passwords because Redis answers queries very fast and a short one can be brute forced.
openssl rand -hex 32
redis-cli ACL GENPASS # Redis 6+, 256 bits from the system CSPRNGOption 1: requirepass (all versions)
Back up the file first (cp -p /etc/redis/redis.conf /etc/redis/redis.conf.bak), then set these directives:
requirepass <long-random-value>
protected-mode yes
bind 127.0.0.1 -::1 10.0.5.20Replace 10.0.5.20 with the private address that application servers use, or drop it if every client is local. Since Redis 6, requirepass simply sets the password of the default user, so clients keep using AUTH <password>. The password is stored in cleartext, so make sure only root and the Redis service account can read the file. Restart the service:
sudo systemctl restart redis-server # Debian, Ubuntu (/etc/redis/redis.conf)
sudo systemctl restart redis # RHEL 9 family (/etc/redis/redis.conf)To set the password without a restart, do it in one interactive session and persist it:
redis-cli
127.0.0.1:6379> CONFIG SET requirepass "<long-random-value>"
127.0.0.1:6379> AUTH "<long-random-value>"
127.0.0.1:6379> CONFIG REWRITENote that redis.conf states requirepass is ignored when an aclfile is configured.
Option 2: ACL users (Redis 6 and later)
ACLs are the method Redis now recommends. Give each application its own user and turn off the default user. Add aclfile /etc/redis/users.acl to redis.conf (do not also define users inside redis.conf, or Redis refuses to start), then create the file:
user default off resetpass -@all
user app on ><app-password> ~* &* +@all -@admin -flushall -flushdb -swapdb
user admin on ><admin-password> ~* &* +@allresetpass removes the nopass flag, and off means new connections start unauthenticated. The app user loses administrative commands such as CONFIG, DEBUG and REPLICAOF plus the flush commands. Restart Redis, then clients authenticate with AUTH app <password> or a URI such as redis://app:<password>@host:6379/0. After cutover, run ACL LOG to see any command your application still needs.
Redis 5 and earlier: disable dangerous commands
Without ACLs, the older rename-command directive can remove commands. Redis marks it deprecated in favour of ACLs, and redis.conf warns that renaming commands logged to the AOF or sent to replicas may cause problems.
rename-command CONFIG ""
rename-command FLUSHALL ""
rename-command DEBUG ""Replicas, Sentinel and Cluster
- Replicas: set masterauth <password>, and masteruser <username> when the primary uses ACL users.
- Sentinel: add sentinel auth-pass <master-name> <password> (and sentinel auth-user for ACL users) to sentinel.conf. Sentinel has its own requirepass if port 26379 is also flagged.
- Cluster: configure both requirepass and masterauth on every node, since any replica can be promoted.
Docker containers
The official Redis image turns protected mode off so other containers can connect, and its documentation warns that a port published with -p is then open without a password. Supply a config file with requirepass and bind * -::* (the stock 127.0.0.1 bind would block other containers), and publish the port only on loopback, or not at all:
docker run -d --name redis -p 127.0.0.1:6379:6379
-v /srv/redis/conf:/usr/local/etc/redis
redis redis-server /usr/local/etc/redis/redis.confFirewall TCP 6379
Allow the port only from application servers. With firewalld, which ships a redis service definition:
firewall-cmd --permanent --remove-service=redis
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.5.0/24" service name="redis" accept'
firewall-cmd --reloadWith ufw, add the allow rule before the deny:
ufw allow from 10.0.5.0/24 to any port 6379 proto tcp
ufw deny 6379/tcpDocker’s documentation notes that published container ports bypass ufw, so for containers rely on the port binding above.
How to verify the fix and rescan
- From a remote machine, redis-cli -h <host> ping should return (error) NOAUTH Authentication required., or time out if the firewall blocks that source.
- With credentials it should return PONG: redis-cli -h <host> –askpass ping (add –user app for ACL users). Avoid -a, which puts the password in shell history and the process list.
- On the host, ACL LIST must not show an enabled default user with nopass.
- Check application, worker and replica logs for NOAUTH or WRONGPASS errors.
- Rescan with the same Nessus policy and scanner. Plugin 100634 should no longer be reported. If the firewall now blocks the scanner entirely, that proves only one path; the password is what protects the others.
What can break and how to roll back
- Clients without the password fail with NOAUTH: applications, background workers, cron jobs, monitoring exporters and backup scripts.
- Order of changes: on Redis 6 and later, a client that sends AUTH <password> before the server has one gets an error (“AUTH <password> called without any password configured for the default user”). Change the server and clients in the same window.
- Replication and failover stop working until masterauth and sentinel auth-pass are set.
- ACL restrictions can block commands a library calls on connect. ACL LOG shows what was denied.
- Disabling the default user breaks tools that cannot send a username.
To roll back, restore redis.conf.bak (and remove the aclfile line if you added one), then restart Redis. Keep protected mode and the firewall rules in place while you fix the clients, and treat the rollback as temporary.
Common false positive reasons
- A different instance answered. A second Redis on another port, a Sentinel, or a NAT rule that forwards 6379 to another host. Match the port and address in the plugin output.
- The service loads a different file. You edited one redis.conf, but config_file in INFO server points to another, or Redis was never restarted.
- requirepass is ignored. An aclfile is configured, so the default user stays on nopass. This is a real finding, not a false positive.
- The asset came back. A container recreated from the stock image, or a test instance nobody tracks. These unknown unknown assets are a common source of repeat findings.
FAQ
Is protected mode enough to close this finding?
No. Protected mode only applies while the default user has no password, is disabled in the official Docker image, and on Redis before 7.0 any explicit bind directive switched it off. A password is what the plugin checks for.
Should I use requirepass or ACLs?
Either closes the finding. requirepass is quickest and works on every version. ACLs (Redis 6 and later) give each client its own user and least privilege, and Redis recommends them.
How do I rotate the password without downtime?
On Redis 6 and later, a user can hold several passwords. Add the new one with ACL SETUSER default ><new>, update the clients, remove the old one with ACL SETUSER default <<old>, then update the config or ACL file so the change survives a restart.
Does the password protect traffic on the wire?
No. AUTH is sent unencrypted like every other command. Use Redis TLS support (Redis 6 and later) if clients cross untrusted networks.
Tracking this finding across many hosts
Unprotected Redis tends to come back as containers are recreated and new test instances appear. A platform such as SITEY can import Nessus results (as an uploaded .nessus export) alongside other scanners, draft a host-specific configuration change that its Linux agent deploys only after human approval, and re-test each Nessus finding to confirm plugin 100634 has closed.