备份泄露常常不是网络攻击,而是文件权限:RDB 和 AOF 里就是你的全部数据。Redis 自己创建这些文件时用什么权限?要怎么收紧?这篇用两种 umask 各启动一个实例,把每个文件的实际权限列出来。
文件 umask 022 umask 077
数据目录 0755 0755
redis.conf(CONFIG REWRITE 之后) 0644 0600
dump.rdb 0644 0600
BGSAVE 进行中的 temp-*.rdb 0644 0600
appendonlydir/ 0755 0700
appendonlydir/appendonly.aof.N.base.rdb 0644 0600
appendonlydir/appendonly.aof.N.incr.aof 0644 0600
appendonlydir/appendonly.aof.manifest 0644 0600
users.acl(ACL SAVE) 0644 0600
nodes.conf 0644 0600
redis.log 0644 0600
r.sock 0755 0700表里左边是 umask 022,右边是 umask 077。同一套配置:集群模式、AOF 打开、aclfile、Unix 套接字、CONFIG REWRITE、BGSAVE(用 rdb-key-save-delay 放慢以便抓到临时文件)。所有由 Redis 创建的文件都随进程 umask 走,没有单独的「收紧」。
未设 unixsocketperm: 0755 设 unixsocketperm 700: 0700
unixsocketperm 显式指定套接字文件的权限。
redis.conf 含明文的 masterauth 密码: True users.acl 只有哈希、没有明文: True 一个明文的 requirepass 行读起来是: ['masterauth "Conf-Plain-Pw"'] users.acl 内容: ['user default on nopass sanitize-payload ~* &* +@all', 'user svc on sanitize-payload #f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7 ~* resetchannels -@all +get']
redis.conf 里的 masterauth(以及 requirepass)是明文;ACL 文件里只有 SHA-256 哈希(第 122 篇)。
aclfile(空)+ requirepass:不带密码 PING → PONG ACL LIST → ['user default on nopass sanitize-payload ~* &* +@all'] 日志里的相关行: [] 把 requirepass 写在 aclfile 前面:不带密码 PING → PONG
这是本文实验里意外看到的。仅限这里测过的情形:aclfile 存在但里面没有 default 用户行。文件里写了 default 用户的密码时是否正常(应当由 aclfile 决定)本文没有验证。
umask 077 启动 Redis 进程(用哪种方式设置取决于你的启动方式:shell、启动脚本或服务管理器,本文只在命令行下用 preexec_fn 设置过 umask)。chmod 700。redis.conf、users.acl 设 600,并限定属主。unixsocketperm 显式指定。