写在前面：合法学习边界
本文只讲原理和防御。Redis 未授权访问属于高风险问题，未经授权读取、写入、修改、配置或控制 Redis 服务都可能造成安全事故。
一、为什么 Redis 容易出问题
Redis 常用于缓存、队列和会话存储。如果配置不当，可能直接暴露到公网，造成严重风险。
常见错误配置：
1
2
3
4
| bind 0.0.0.0
无 requirepass
未启用 ACL
公网端口暴露
|
二、风险链路
如果 Redis 未授权且公网可访问，攻击者可能：
1
2
3
4
5
| 读取敏感缓存
写入恶意配置
写计划任务
写 SSH 公钥
篡改业务数据
|
因此 Redis 不应默认暴露在公网。
三、常见表现
1
2
3
4
| 6379/tcp open
Redis 服务无认证
CONFIG 命令可用
SET/GET 命令可访问
|
在授权测试中，可以验证：
1
2
3
| 是否存在认证要求
是否能读取敏感 key
是否能写文件
|
但只能在授权环境中进行。
影响与危害
Redis 未授权访问能造成：
1
2
3
4
| 数据泄露与篡改
写入 crontab/SSH key 实现服务器接管（配合写入）
内网横向
勒索/清空数据
|
风险等级：高到严重。
四、防御建议
1. 绑定内网地址
2. 启用密码
3. 使用 ACL
限制命令和 key 访问范围。
4. 网络隔离
不要把 Redis 直接暴露公网。
5. 开启审计日志
记录配置变更、敏感命令和异常访问。
6. 最小权限
应用只给需要的读写能力。
修复
1
2
3
4
5
| 开启 requirepass 设置强密码
bind 限制监听地址，禁止 0.0.0.0
禁用危险命令（CONFIG/SLAVEOF/DEBUG 等改名或禁用）
用防火墙/安全组限制 6379 暴露
修复后复测：无密码无法访问、危险命令被拒
|
验证操作步骤
1
2
3
4
| 第 1 步：端口扫描确认 6379 开放
第 2 步：redis-cli/nc 连接，执行 ping 或 CONFIG GET dir
第 3 步：无需认证即确认未授权
第 4 步：进一步验证写入能力（授权内）
|
五、报告中的正确写法
示例：
1
2
3
| 发现：6379/tcp 端口开放，Redis 服务未配置认证。
风险：可能导致敏感数据泄露、配置篡改、计划任务写入或服务器控制。
建议：限制监听地址；启用 requirepass；使用 ACL；隔离网络；补充审计日志。
|
六、小结
Redis 最大的问题通常不是软件本身，而是网络暴露和认证缺失。安全重点是“不要公网裸奔”。