redis防御加固与安全基线

攻击 = 允许被网络访问 + 允许执行危险操作 + 操作落在危险位置。那防御就是三件事：

1. 先看现状：现在的 Redis 有多裸？

任何加固的第一步是盘点现状。管理员先自查：

# 1) 谁在监听、监听在哪张网卡
ss -tlnp | grep 6379        # 看是否 0.0.0.0 / *（公网）在听
# 或
netstat -an | grep 6379
​
# 2) 关键配置现状
redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode
redis-cli CONFIG GET requirepass
redis-cli CONFIG GET dir
redis-cli INFO server | grep redis_version
​
# 3) 当前用户/权限
ps -ef | grep redis-server | grep -v grep   # redis 以什么用户跑？

我怎么知道 Redis 是否暴露在公网？

上面 ss 看监听地址：0.0.0.0:6379 或 *:6379 = 所有网卡都在听（含公网）。也可以从另一台机器 telnet 公网IP 6379 试连通性。安全工具如 shodan/fofa 能直接搜到全网暴露的 6379——那些基本都是被攻击重灾区。

2. 网络层加固：让攻击者"连不上"

2.1 bind：只监听需要的网卡

# redis.conf 里
# 只允许本机访问（最安全，开发/单机推荐）
bind 127.0.0.1
​
# 只允许内网特定 IP 访问（生产常用，按需改）
bind 127.0.0.1 10.10.10.5
​
# 千万别这样（监听所有网卡，等于暴露公网）
# bind 0.0.0.0
# 或注释掉 bind

不写 bind 0.0.0.0 时，老版本默认可能监听所有网卡——所以显式写明 bind 是好习惯。

2.2 protected-mode：兜底开关，务必保持 yes

protected-mode yes

protected-mode 只在"没设密码 + 非本机连接"时才拦。它是兜底不是万能。正确姿势：bind 收紧 + 设密码 + protected-mode yes 三者一起上，别只靠一个。

2.3 防火墙 / 安全组

即使 bind 失误，网络层还有最后一道闸：

# 只允许信任网段访问 6379
iptables -A INPUT -p tcp –dport 6379 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp –dport 6379 -j DROP
# 云上：安全组入方向不向 0.0.0.0/0 放行 6379

3. 认证与授权：连上了也要拦

3.1 requirepass：设置访问密码（最基础）

Redis 6 之前只有这一种认证方式，所有客户端共用一个密码。

# redis.conf
requirepass 一个足够强、且不重复使用的密码

验证：

redis-cli -p 6379 ping
# (error) NOAUTH Authentication required.   ← 没密码进不去，攻击断一条腿
redis-cli -p 6379 -a 密码 ping
# PONG

设了 requirepass 之后，主从/哨兵之间也要配密码（masterauth），否则从库连不上主库——这属于运维细节，但漏配会导致复制失败告警。

3.2 ACL：细粒度控制"谁能执行哪些命令"（Redis 6+，强烈推荐）

requirepass 是"一刀切"，ACL 才是现代 Redis 的正解：可以建多个用户，每个用户指定能访问哪些 key、执行哪些命令。

ACL 基本模型：

ACL SETUSER 用户名 规则…

常用规则：

创建一个只能读 cached:*、只能执行少量命令的只读用户（演示，真实按业务改）：

# 建用户：demo，密码 s3cretPwd，只能访问 cached:*，只允许 ping/get/set
redis-cli -p 6379 ACL SETUSER demo on '>s3cretPwd' '~cached:*' '+ping' '+get' '+set'
# 查看所有用户
redis-cli -p 6379 ACL LIST
# 输出示例：
# user default on nopass sanitize-payload ~* &* +@all         ← 默认超级用户
# user demo on sanitize-payload #hash… ~cached:* resetchannels -@all +get +set +ping

用 demo 用户连：

redis-cli -p 6379 –user demo -a s3cretPwd
# 能 get cached:xxx、set cached:yyy、ping
# 但不能 KEYS、不能 FLUSHALL、不能 CONFIG → 会被 (error) NOPERM 拒绝

ACL 和 requirepass 能同时用吗？

能。requirepass 本质是给 default 用户设密码。Redis 6+ 更推荐直接用 ACL 管理用户，可以保留 default 强密码，另建只读/最小权限用户给不同业务方。

 为什么 ACL 能防住攻击？

前面所有 getshell，最后都依赖 CONFIG / BGSAVE / REPLICAOF / MODULE / EVAL 这类高危命令。用 ACL 把业务账号限制成只读 + 只碰业务 key，攻击者拿到这个账号也调不动任何危险命令。

3.3 禁用/改名高危命令（无 ACL 的版本也能用）

老版本没有 ACL，用 rename-command 把危险命令改名或直接禁用（只能写在 redis.conf 里，重启生效，CONFIG SET 改不了）：

# redis.conf
# 把危险命令禁掉（改名成空字符串 = 禁用）
rename-command CONFIG ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command EVAL ""
rename-command SCRIPT ""
rename-command SHUTDOWN ""
​
# 或改成只有你知道的暗名（如果业务确实要用）
rename-command CONFIG "r3dis_c0nfig_9527"

改名命令的坑：

4. 系统层：就算命令执行了，也"写不了 / 干不了活"

4.1 用低权限用户跑 Redis

这是最容易被忽略、也最有效的一条。 Redis 若以 root 跑，写 crontab / SSH 公钥 / WebShell 全都有权限；用普通用户跑，那些系统目录根本写不进去。

# 建一个无登录、最小权限的 redis 用户
useradd -r -s /sbin/nologin redis
mkdir -p /var/lib/redis /var/log/redis /etc/redis
chown redis:redis /var/lib/redis /var/log/redis /etc/redis
​
# redis.conf 里指定
user redis
​
# 或 systemd 单元里 User=redis

为什么有些未授权 Redis 打不出 getshell？

很多时候不是命令被禁，而是 Redis 跑在 redis 用户下，/root/.ssh、/var/spool/cron、web 目录它都没权限写——这正是低权限运行的防御价值。

4.2 数据目录与落盘位置最小化

• 给 Redis 一个独立且无执行权限的数据目录（如 /var/lib/redis），不要把 dir 指到 web 根目录。

• 即使攻击者改了 dir，目录权限 + SELinux/AppArmor 也能二次拦截。

• 定期检查 dir 里有没有异常文件（攻击者落盘的 shell.php 之类）。

4.3 日志与监控

• 开 Redis 日志（logfile），记录连接和命令。

• 监控 6379 的连接来源、异常 KEYS * / CONFIG SET / FLUSHALL / REPLICAOF 命令。

• 对外部发起的长时间连接、异常大流量保持警惕。

5. 云上/容器部署的额外注意

□ Docker：端口映射别裸开 6379（-p 6379:6379 且无密码 = 灾难）；用 –network 内网或仅本机
□ k8s：Redis 服务不要暴露成 NodePort/LoadBalancer 到公网
□ 云托管 Redis（如云厂商）：用安全组/VPC 隔离 + 开密码 + 开审计
□ 公网示例默认账号/端口：第一时间改端口或至少加密码，别用默认 6379 裸奔

6. 最小加固清单

按顺序做，前三条性价比最高：

# ===== redis.conf 最小安全配置 =====
bind 127.0.0.1                       # 1. 不对外监听（或用内网IP）
protected-mode yes                   # 2. 保护模式兜底
requirepass 换成超强随机密码         # 3. 无密码 = 未授权访问（高危）
​
# 4. 若有 ACL，给业务用最小权限用户（可选但推荐）
# 5. 禁用/改名危险命令（老版本）
rename-command CONFIG ""
rename-command FLUSHALL ""
​
# 6. 系统层
#   用非 root 用户跑 redis
#   数据目录独立且不可写危险位置
# 7. 网络层
#   防火墙/安全组只放行信任来源

即使只做 1+2+3，之前的四条 getshell 全都会断在第 1 步（连不上/要密码）。再做 5，连"拿到密码但想用危险命令"也被断。这就是分层防御：每一层都独立地挡住一种攻击路径。

7. 攻防对照表

8. 失陷后的排查要点

如果怀疑 Redis 失陷，冷静按下面查（配合应急响应流程）：

处置时优先"保留现场取证"，别急着 flushall（会把攻击痕迹也清了）。

9. 小结

防御的本质不是背命令，而是分层：

网络层（连不上） → 认证层（连上也要密码） → 授权层（危险命令被禁）
→ 系统层（命令执行了也写不了危险位置） → 监控审计（打进来能发现）

攻防其实是同一张地图，攻方从外往内一层层找"允许"，守方从内往外一层层设"不允许"。

全系列自测