这事儿发生在去年，北京的某家互联网企业，研发部那帮人正忙着冲刺新版本上线，结果半夜收到安全团队的警报：服务器被攻了，Redis 数据全被拖走。好家伙，查了才发现，竟然是因为 Redis 端口直接暴露在公网，还没设密码，黑客进门就像逛自家后花园一样自在。这可不是什么玄学，这是实打实的“未授权访问”漏洞导致的经典案例。
很多人觉得“Redis 只是缓存，丢了就丢了”，但这次泄露的是用户核心数据，直接导致公司面临巨额罚款和声誉崩塌。那问题来了：到底谁该背锅？是运维没配置好安全组？是开发没加认证？还是老板没批预算买安全服务？
别急，咱们一步一步扒开这个案例，顺便把排查和加固的干货给你讲透。看完这篇，你不仅知道责任在谁，还能立刻动手保护你自己的系统。
一、责任归属：谁该为这次泄露买单？
首先，咱得明确一点：安全不是某个人的事，是团队的事。但这次事故，有几个关键角色没能守住底线。
1. 运维团队：首要责任人
运维同学，你们是不是觉得“Redis 配完能跑就行”？太天真了！这次事故的根源，是 Redis 服务绑定了 0.0.0.0，并且通过防火墙规则开放了 6379 端口到公网。运维没检查安全组策略，没做端口监听检查，没设置 requirepass，这是明显的失职。
责任点：
- 未限制 Redis 监听地址（应为
127.0.0.1或内网 IP） - 未配置防火墙规则屏蔽公网访问
- 未启用密码认证（
requirepass为空） - 未关闭危险命令（如
CONFIG、FLUSHALL）
2. 开发团队：连带责任
开发同学，你们是不是觉得“安全是运维的事”？错！如果你们的业务代码里硬编码了 Redis 连接信息，且没有使用环境变量或密钥管理服务，那你们也有责任。另外，如果开发过程中没有进行安全测试（比如用 redis-cli 测试未授权访问），那这也是疏漏。
责任点：
- 代码中硬编码敏感配置
- 未进行安全测试
- 未遵循最小权限原则（比如用 root 用户运行 Redis）
3. 安全团队：监督失职
安全团队呢？是不是平时只忙着扫描漏洞，没关注配置层面的风险？Redis 未授权访问是个老生常谈的问题，安全团队应该早就推动运维加固，而不是等出事了才事后诸葛亮。
责任点：
- 未定期进行配置审计
- 未推动安全基线落地
- 应急响应不及时
4. 管理层：最终责任
最后，老板和管理层，你们是不是觉得“买个 WAF 就万事大吉”？安全投入不够，安全策略执行不力，最终买单的还是公司。这次事故导致的罚款、赔偿、声誉损失，都是管理层决策失误的代价。
责任点：
- 安全预算不足
- 安全文化缺失
- 未建立责任追溯机制
二、漏洞排查：怎么发现你的 Redis 也裸奔？
别等黑客上门，自己先查查。下面这些步骤，能帮你快速定位 Redis 未授权访问漏洞。
1. 检查 Redis 监听地址
登录到 Redis 服务器，执行以下命令：
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET bind
正常应该返回 127.0.0.1 或内网 IP。如果返回 0.0.0.0，说明监听在所有接口，公网可达，危险！
2. 检查密码认证
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET requirepass
如果返回空字符串，说明没设密码。赶紧设一个复杂的密码！
3. 检查防火墙规则
sudo iptables -L -n | grep 6379
看看有没有允许公网访问 6379 端口的规则。如果有，立即删除！
4. 检查危险命令
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET rename-command
看看有没有禁用危险命令。如果没有，执行以下命令禁用：
redis-cli -h 127.0.0.1 -p 6379 CONFIG SET rename-command FLUSHALL ""
redis-cli -h 127.0.0.1 -p 6379 CONFIG SET rename-command FLUSHDB ""
redis-cli -h 127.0.0.1 -p 6379 CONFIG SET rename-command CONFIG ""
redis-cli -h 127.0.0.1 -p 6379 CONFIG SET rename-command KEYS ""
5. 使用工具扫描
可以用 nmap 扫描端口开放情况：
nmap -p 6379 <目标IP>
或者用专门的 Redis 漏洞扫描工具，比如 redis-rogue。
三、权限加固：一步到位，让黑客无门可入
排查完漏洞，接下来就是加固。下面这些措施，能大幅提升 Redis 的安全性。
1. 限制监听地址
编辑 Redis 配置文件 redis.conf：
bind 127.0.0.1
或者只绑定内网 IP：
bind 192.168.1.100
重启 Redis 生效：
sudo systemctl restart redis
2. 设置复杂密码
同样在 redis.conf 中：
requirepass YourStrongPassword123!
重启 Redis 生效。之后连接 Redis 必须带上密码：
redis-cli -h 127.0.0.1 -p 6379 -a YourStrongPassword123!
3. 配置防火墙规则
使用 iptables 或 firewalld 限制访问来源。比如只允许内网网段访问：
sudo iptables -A INPUT -p tcp -s 192.168.0.0/16 --dport 6379 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 6379 -j DROP
或者用 firewalld：
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/16" port port="6379" protocol="tcp" accept'
sudo firewall-cmd --reload
4. 禁用危险命令
在 redis.conf 中：
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command KEYS ""
rename-command DEBUG ""
重启 Redis 生效。
5. 启用 TLS 加密
如果 Redis 需要跨网络传输，建议启用 TLS 加密。在 redis.conf 中：
tls-port 6380
tls-cert-file /path/to/cert.pem
tls-key-file /path/to/key.pem
tls-ca-cert-file /path/to/ca.pem
连接时使用：
redis-cli -h <IP> -p 6380 --tls
6. 使用 VPN 或跳板机
最安全的做法是：Redis 只在内网访问，通过 VPN 或跳板机连接。这样即使 Redis 暴露端口，黑客也无法直接访问。
四、应急响应：出事了怎么办？
如果发现自己也中招了，别慌，按以下步骤处理：
1. 隔离受影响系统
立即断开 Redis 与外网的连接，防止数据继续泄露。
2. 保存证据
备份日志文件、快照文件，不要删除任何数据。这些是后续调查的关键。
3. 重置密码和权限
按照上面的加固步骤，立即重置密码、限制访问、禁用危险命令。
4. 评估泄露范围
检查 Redis 中存储的数据类型，判断泄露数据的敏感程度。如果是用户数据，可能需要通知监管部门和用户。
5. 修复漏洞并复盘
找出漏洞根源，修复配置，同时复盘整个安全流程，避免再次发生。
五、给小朋友的通俗解释
想象一下，你家有一把金钥匙，放在门口地垫下面，还敞开大门。结果隔壁的小偷轻松进来，把你的宝贝全偷走了。这时候，你要怪谁？怪你自己没锁门，怪邻居没提醒，怪物业没保安。
Redis 就像你家的大门，密码就像金钥匙。你没锁门（没设密码），还敞开大门（绑定 0.0.0.0），小偷自然轻松进来。所以，一定要锁好门，藏好钥匙，别让坏人有机可乘。
六、总结
这次北京企业的事故，给所有互联网从业者敲响了警钟。Redis 未授权访问不是新漏洞，但每年都有人因此翻车。责任不在某一个人，而在整个团队。运维要配置好安全组，开发要写好安全代码，安全要审好配置，管理层要投好预算。
排查漏洞，从检查监听地址、密码、防火墙规则开始。加固权限，从限制访问、设置密码、禁用危险命令入手。出事了，别慌，隔离、取证、修复、复盘，一步步来。
最后，送大家一句话：安全无小事，预防胜于救灾。别等被黑了才后悔，现在就动手，检查一下你的 Redis 吧！