ZooKeeper 未授权访问漏洞：你做的 ACL 加固可能只是“假动作”-编程实验室

在日常安全加固中，经常会收到基础架构或安全部门的反馈：ZooKeeper 存在未授权访问漏洞。很多同学拿到需求后的第一反应是“加个 ACL 就好了”，于是动手操作一轮：添加超级用户、给某个节点设置 IP 白名单、然后觉得超级用户碍事把它删掉，顺便禁掉四字命令。这一套“组合拳”打下来，是不是就算修复完成了？

答案是：远没有。本文将以一个实际的操作过程为例，拆解其中的误区，并给出真正有效的修复方案。

一、常见的“加固”操作回顾

假设我们接到了漏洞修复任务，顺手完成了以下步骤：

添加超级用户
在zoo.cfg中配置superDigest，让super用户获得最高权限：
```
-Dzookeeper.DigestAuthenticationProvider.superDigest=super:cY+9eK20soteVC3fQ83SXDvwlP0=
```
重启节点后，可以用addauth digest super:cloudera登录。
为特定 znode 设置 IP 白名单 ACL
```
create /znode1 setAcl /znode1 ip:192.168.0.74,192.168.0.75:cdrwa
```
意思是只有192.168.0.74和192.168.0.75能读写/znode1。
验证权限
- 用.75访问/znode1成功；
- 用.76访问/znode1被拒绝（Authentication is not valid）。
  感觉“ACL 生效了”。
删除超级用户配置
去掉superDigest行，重启节点，让超级用户失效。

禁用危险的四字命令
限制白名单：

4lw.commands.whitelist=conf,cons,crst,dirs,dump,gtmk,ruok,stmk,srst,srvr,stat,wchs,mntr,isro

看上去有认证、有 ACL、有指令限制，但为什么漏洞报告依然存在？

二、问题究竟出在哪里？

1. ACL 没有递归性，根节点及其他节点仍然“裸奔”

ZooKeeper 的 ACL 模型不是树状继承的。你对/znode1设置了ip限制，但对根节点/、/zookeeper以及无数其他业务节点，并没有做任何限制。这些节点的 ACL 仍然停留在默认值：

world:anyone:cdrwa

这意味着任何一个能访问 ZooKeeper 2181 端口的客户端，都可以：

ls /列出所有节点；
get /敏感数据直接读取；
create /evil创建非法节点；
delete /关键路径进行破坏。

“只保护一个节点”在安全层面上等同于没保护。

2. IP 白名单的认证强度不足

ip模式的 ACL 完全依赖客户端来源 IP。它的缺点很明显：

同一网段的任何机器只要 IP 被列入白名单，就拥有完整权限，无法区分“谁来操作”；
IP 可能被伪造，或者作为跳板机被攻陷后滥用；
缺乏账号体系，无法审计、无法精准回收权限。

所以用 IP ACL 来兜底未授权访问，安全部门通常是不接受的，他们会要求采用digest 或 SASL 认证。

3. 删除了超级用户，阻塞了最后的应急通道

Super 用户是一种特殊的 digest 认证，可以无视所有 ACL 进行操作。它的设计初衷正是防止误配 ACL 把自己完全锁在外面，提供一条“超级后门”用于恢复。

你在没有建立完善的全局认证机制之前就把 super 用户删掉，一旦将来某个节点 ACL 配错导致所有业务账号都无法访问，集群将陷入不可管理的状态。安全加固不允许这种“玉石俱焚”的做法。

4. 四字命令限制是独立漏洞，不能替代访问控制

禁用危险的四字命令（如wchc、wchp、dump等）确实能阻止信息泄露和部分 DoS 攻击，但这是另一个漏洞。正常的 ZooKeeper 客户端 API 根本不需要四字命令就能读写数据，因此数据节点的未授权访问漏洞依然原封不动。

三、真正的修复方案

要彻底关闭“ZooKeeper 未授权访问漏洞”，必须做到：任何未经认证的客户端连ls /都执行不了。具体步骤如下：

1. 启用 Digest 或 SASL 认证

推荐使用digest认证，并让所有业务客户端在连接时主动提供账号密码。在zoo.cfg中添加：

authProvider.1=org.apache.zookeeper.server.auth.DigestAuthenticationProvider

如果你有 Kerberos 环境，也可以切换到 SASL，这里不展开。

2. 移除根节点的 world 可访问权限

选择一个或几个管理员账号，用digest模式对根节点/重新设置 ACL，并移除默认的world:anyone。例如：

# 先登录管理员账号addauth digest admin:secure_password# 设置根节点仅允许 admin 操作setAcl / auth:admin:cdrwa

执行后，未认证的客户端再连接进来执行ls /时，会直接返回Authentication is not valid。新创建的子节点也会默认继承 ACL（注意是“创建时指定 ACL 或连接会话的默认 ACL”，所以还需在客户端侧设置好默认 ACL）。

更好的做法是：创建节点时显式指定 ACL，或在连接上通过setAuthInfo让所有新建节点都使用认证用户的 ACL。

3. 保留超级用户作为应急入口

在zoo.cfg中保留一条superDigest配置，密码强度要足够，并且只有核心管理员掌握。

-Dzookeeper.DigestAuthenticationProvider.superDigest=super:<加密后密码>

不要删除它，这是你最后的救命稻草。

4. 结合网络访问控制与四字命令限制

在防火墙或安全组层面，将 ZooKeeper 的 2181 端口仅对受信 IP 段（如本集群机器）开放，杜绝外网探测；
继续使用四字命令白名单，只保留运维必须的少量指令。

5. 验证效果

使用一个未认证的客户端尝试连接：

zookeeper-client-server<ip>:2181ls/# 预期结果：Authentication is not valid

而正常业务客户端配置了相同的digest凭据后，应该能正常读写。

四、总结

你认为的修复	实际情况
为测试节点加 ip ACL	根路径、其他节点仍然`world:anyone`，漏洞依然存在
删除超级用户	失去紧急管理通道，加固反而降低了可用性
禁用部分四字命令	修复的是另一个漏洞，未授权数据访问依然不受限

ZooKeeper 的未授权访问漏洞，核心在于默认的world:anyone:cdrwa权限。除非你显式地将根节点 ACL 改为仅认证用户可访问，并以全局视角要求所有连接必须提供凭据，否则漏洞就等于没有修。