Redis 为什么常被拿来做入口
Redis 早期版本默认不设认证，很多安装方式还默认监听全部地址，扫描器很容易发现并直接连上。拿到未授权的 Redis 之后，攻击者可以写文件——把 SSH 公钥写进账号的授权文件、把计划任务写进 spool 目录，或者直接改配置加载模块，从而把「缓存服务」变成拿到主机 shell 的跳板。所以处置顺序是先封边界，再补认证与降权。
基本信息
| 加固项 | 缓存服务安全 |
|---|---|
| 适用平台 | Linux（Redis 6 及以上，旧版本部分参数行为不同） |
| 风险等级 | 高 |
| 基线 | 不暴露公网、启用认证、非 root 运行 |
| 端口 | 6379（默认） |
典型使用场景
- 暴露面整改：发现 6379 对全网开放时按高危优先处置
- 新服务上线：部署前确认监听地址、认证与运行账号三项
- 安全事件排查：被判为挖矿或写公钥的机器常先查 Redis
- 跨环境核查：缓存常被放在内网，需确认内网也做了来源收敛
- 版本升级评估：老版本缺少 ACL 能力，需要用其他手段补足
核查命令
核查命令
ss -tlnp | grep ':6379'
redis-cli -h 127.0.0.1 config get bind 2>/dev/null
redis-cli -h 127.0.0.1 config get protected-mode 2>/dev/null
redis-cli -h 127.0.0.1 config get requirepass 2>/dev/null
grep -E '^(bind|protected-mode|requirepass|user)' /etc/redis/redis.conf 2>/dev/null加固要点（redis.conf）
加固要点（redis.conf）
bind 127.0.0.1 -::1 # 只监听回环，需要跨机访问时改为内网地址
protected-mode yes # 兜底保护，不能替代认证
requirepass <强口令> # 或使用 ACL 统一管理用户与权限
rename-command CONFIG "" # 禁用高风险管理命令（确认无运维脚本依赖）
rename-command FLUSHALL ""
# systemd 单元中 User=redis，禁止以 root 运行，并确认数据目录属主正确关键配置读法
| 配置项 | 作用 | 注意事项 |
|---|---|---|
| bind | 限定监听地址 | 写成全部地址等于允许任何可达来源连接 |
| protected-mode | 无绑定且无口令时的兜底保护 | 配置了 bind 后不再起保护作用，不能当认证用 |
| requirepass | 设置访问口令 | 口令要纳入密钥管理，不要写进代码仓库 |
| rename-command | 禁用或改名高风险命令 | 改名后需同步调整所有运维脚本 |
| ACL 用户 | 按用户划分权限与键空间 | 与 requirepass 混用会改变认证语义，建议二选一 |
历史事件中攻击者通过未授权访问写入授权文件直接获得 shell，也有写入计划任务维持访问的做法。因此在确认主机曾暴露过 6379 时，除了收紧 Redis，还要检查账号的授权文件与计划任务是否被篡改，两者要一起看。
protected-mode 只在既没有绑定地址也没有设置口令时才生效，一旦显式配置了 bind 它就退到后台，因此不能替代认证。新版本推荐用 ACL 管理用户、角色与键空间权限，比单一口令更细粒度；ACL 与 requirepass 同时使用时认证行为会变化，迁移前先在测试环境验证。
处置顺序
建议固定四步：先封边界（安全组与本机防火墙），再确认本机监听地址收敛到回环或内网，然后开启认证并禁用高风险命令，最后确认服务以专用账号而非 root 运行。已暴露过的机器还要追加一轮排查：授权文件、计划任务、异常模块与配置文件改动时间，判断是否已被利用。