Redis 未授权访问是什么
Redis 的设计假设是运行在可信内网，早期版本默认没有认证与访问控制，只要网络可达就能读写全部键。风险因此不完全在数据本身：攻击者可以读取业务缓存里的会话与业务数据，也可以清空或篡改键造成业务异常，还可以通过 CONFIG 修改持久化目录、再触发落盘，把可控内容写进系统文件。默认端口 6379 一旦暴露到公网，通常在数小时内就会被自动扫描命中。
基本信息
| 默认端口 | 6379（Sentinel 26379，集群总线 16379） |
|---|---|
| 默认认证 | 无密码，requirepass 为空即允许任意客户端操作 |
| 常见暴露原因 | bind 配成 0.0.0.0、云安全组放行、容器端口映射到宿主机 |
| 直接危害 | 读取、篡改、删除键；读取会话与业务缓存数据 |
| 扩大危害 | 改写持久化配置并落盘，可影响主机文件与计划任务 |
| 主要加固手段 | 认证加 ACL、绑定内网地址、安全组收敛、危险命令重命名或禁用 |
典型暴露场景
- 云主机把 6379 加入安全组放行，本意是方便本地调试
- 容器编排里把容器端口直接映射到宿主机并绑定全网卡
- 多机部署时把 bind 改成 0.0.0.0，认证仍留空
- 测试环境沿用生产配置，测试机暴露后成为跳板
- 自建集群把总线端口与业务端口一起对外放行
- 运维用公网地址远程连接，弱口令与空口令长期并存
暴露核查（对本方资产）
暴露核查（对本方资产）
redis-cli -h <目标IP> -p 6379 ping # 返回 PONG 表示可达且未触发认证
redis-cli -h <目标IP> -p 6379 ping # 若有认证应返回 NOAUTH 或权限错误
redis-cli -h <目标IP> info server | head -5 # 有认证时该命令会被拒绝
# 核查要点：确认监听地址、认证开关、危险命令是否被禁用
# 单向判断：能连通不等于已授权，先确认资产归属与授权范围再操作redis.conf 加固项
redis.conf 加固项
bind 127.0.0.1 10.0.0.5 # 只监听本机与内网业务地址，不要写 0.0.0.0
protected-mode yes # 无绑定地址且无认证时拒绝外部连接
requirepass <强随机口令> # 基础认证；Redis 6 起建议用 ACL 细分权限
rename-command CONFIG "" # 禁用或重命名高危命令，需确认业务未依赖
rename-command FLUSHALL ""
appendonly yes # 按业务需要评估持久化策略
# 改完先 redis-cli -h 内网地址 ping 验证业务连通，再收敛安全组规则风险面与加固对照
| 暴露点 | 风险 | 加固动作 |
|---|---|---|
| 网络可达 | 任意客户端直连操作数据 | 安全组只放行业务网段，关闭公网映射 |
| 无认证 | 无需凭据即读写 | requirepass 或 ACL 用户加最小权限 |
| 危险命令可用 | 可改写持久化路径与清库 | 重命名 CONFIG、FLUSHALL、KEYS 等命令 |
| 弱口令 | 可被字典命中 | 长随机口令，禁止跨环境复用 |
| 日志缺失 | 失陷后无法追溯 | 开启慢日志与访问日志，接入集中日志平台 |
对外网或非受信网段开放的 6379 应视为高优先级问题；处置前先评估业务依赖再分级收敛，避免直接关停导致业务中断。
Redis 6.0 起提供 ACL：可以按用户限定可访问的键前缀与命令集合，比单一 requirepass 更适合多业务共用实例的场景。收敛前先确认客户端版本，老客户端可能不支持用户名认证语法。