Redis 生产环境安全基线配置指南：从风险分析到实操加固

在分布式系统架构中，Redis 凭借高性能、高可用的特性成为主流缓存与数据存储组件。然而，Redis 默认配置以开发调试为目标，直接用于生产环境将面临严重安全威胁。

一、警惕！Redis 默认配置的生产环境风险

Redis 设计初衷聚焦高性能缓存能力，其默认配置未考虑生产环境的安全需求，存在五大高危隐患，极易成为攻击者突破系统的跳板：

• 无密码认证：任何用户可直接连接 Redis 服务，无需身份校验
• 监听所有 IP：默认绑定 0.0.0.0，暴露在所有网络接口，外部可通过端口扫描发现
• 高权限运行：默认以 root 用户启动，一旦被攻破，攻击者将获得系统级控制权
• 无操作日志：不记录任何操作行为，安全事件发生后无法追溯根源
• 高危命令未限制：KEYS、FLUSHALL 等危险命令可随意执行，可能导致数据泄露或清空

典型攻击链示例：

攻击者通过端口扫描发现开放的 6379 端口 → 利用无密码配置直接连接 Redis → 写入恶意 SSH 公钥至 ~/.ssh/authorized_keys → 通过 SSH 登录服务器 → 横向渗透整个内网。

要阻断此类攻击，必须完成以下 7 项核心安全基线配置。

二、7 项 Redis 安全基线配置实操方案（适用于 CentOS/RHEL/Ubuntu）

假设 Redis 已通过包管理器或源码部署，以下配置覆盖访问控制、权限管理、日志审计等核心维度，每项均包含文件路径、操作命令、参数说明及生效方式。

1. 设置客户端空闲超时时间：避免资源浪费与恶意连接

长期闲置的客户端连接会占用 Redis 资源，可能导致服务性能下降甚至拒绝服务。

修改文件：/etc/redis/redis.conf（多实例需对应 redis-6379.conf 等自定义路径）

定位并修改参数：
将默认 timeout 0（永不超时）改为 timeout 600（10 分钟，可按需调整）

生效方式：

• 临时生效：redis-cli CONFIG SET timeout 600
• 持久生效：修改配置文件后重启服务（systemctl restart redis）

2. 启用系统日志审计：满足等保 2.0 追溯要求

缺乏操作日志会导致安全事件无法追溯，违反等保 2.0 对日志留存的基本要求。

修改文件：/etc/redis/redis.conf

添加 / 修改三项参数：

syslog-enabled yes    # 启用系统日志输出
syslog-ident redis    # 日志标识为redis，便于过滤
syslog-facility local0 # 使用local0设备，避免与其他服务冲突

验证方法：
启动服务后执行 tail -f /var/log/messages | grep redis，应看到类似日志：

May 15 10:23:45 server redis[1234]: Server started

3. 配置强密码认证：阻断未授权访问

无密码的 Redis 等同于 “裸奔”，必须设置符合复杂度要求的密码。

修改文件：/etc/redis/redis.conf

定位并修改参数：

requirepass HnY@app2025（实际环境需替换为企业合规密码）

密码复杂度要求：
长度≥8 位，包含大写字母、小写字母、数字、特殊字符，禁止使用 foobared、123456 等弱密码

注意事项：

• 修改后需同步更新所有客户端连接配置（如应用代码、脚本）
• 验证密码加载：redis-cli CONFIG GET requirepass
• 测试认证流程：连接后执行 ping，需先通过 AUTH 密码 认证

4. 使用普通用户运行：避免权限滥用

以 root 用户运行 Redis 是严重安全隐患，一旦被攻破，攻击者将获得系统控制权，需创建专用普通用户运行服务。

步骤 1：创建专用运行用户

useradd -r -s /sbin/nologin redis
# -r：创建系统用户（无家目录）；-s /sbin/nologin：禁止登录shell，降低风险

步骤 2：修改文件 / 目录归属

# 配置文件归属
chown redis:redis /etc/redis/redis.conf
# 数据目录归属（由配置文件dir指令指定，默认/var/lib/redis）
chown -R redis:redis /var/lib/redis
# 日志目录归属（如自定义路径）
chown -R redis:redis /var/log/redis
# PID文件目录归属
chown redis:redis /var/run/

步骤 3：调整 systemd 服务启动方式（推荐）
编辑服务文件：/usr/lib/systemd/system/redis.service
在 [Service] 段添加：

User=redis
Group=redis

生效并重启：

systemctl daemon-reexec
systemctl restart redis

验证命令

ps -ef | grep redis
# 预期结果：进程所属用户为redis，而非root

5. 严格控制文件 / 目录权限：防止配置篡改与数据泄露

文件权限过宽可能导致敏感信息泄露（如密码）或配置被恶意修改，需按最小权限原则设置。

类型	路径	权限设置命令	权限说明
配置文件	/etc/redis/redis.conf	chmod 600 $路径 chown redis:redis $路径	600：仅属主可读写，防止非授权查看密码
数据目录	/var/lib/redis	chmod 700 $路径 chown -R redis:redis $路径	700：仅属主可进入 / 读写，保护 RDB/AOF 文件
独立日志目录	/var/log/redis	mkdir -p $路径 touch $路径/redis-server.log chown -R redis:redis $路径 chmod 700 $路径	700：仅属主可操作日志，避免日志被篡改

6. 绑定受信任 IP：缩小攻击面

默认监听 0.0.0.0 会使 Redis 暴露在所有网络接口，需仅绑定本地回环地址和应用服务器 IP。

修改文件：/etc/redis/redis.conf

定位并修改参数：

bind 127.0.0.1 192.*.*.1（多个 IP 用空格分隔，仅保留受信任地址）

禁止操作：严禁保留 bind 0.0.0.0 或注释 bind 行

防火墙加固（可选但推荐）：
以 CentOS/RHEL 的 firewalld 为例：

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='134.175.*.*' port protocol='tcp' port='6379' accept"
firewall-cmd --reload

7. 重命名 / 禁用高危命令：避免误操作与恶意利用

部分 Redis 命令在生产环境中极少使用，但风险极高，需禁用或重命名为无意义字符串。

修改文件：/etc/redis/redis.conf

添加重命名规则：

rename-command KEYS ""        # 禁用KEYS（易引发性能问题+数据探测）
rename-command FLUSHALL ""    # 禁用FLUSHALL（清空所有数据）
rename-command FLUSHDB ""     # 禁用FLUSHDB（清空当前数据库）
rename-command CONFIG ""      # 禁用CONFIG（防止动态修改配置）

替代方案（需临时使用时）：
可重命名为复杂字符串，如 rename-command FLUSHALL abcdefg_9527，仅运维人员知晓真实命令。

三、加固后验证 Checklist：确保配置生效

完成上述配置后，需通过以下命令验证效果，避免遗漏或配置失效：

检查项	操作命令	预期结果
超时设置	redis-cli config get timeout	返回 600（或自定义超时时间）
密码认证	redis-cli ping	返回 (error) NOAUTH Authentication required.
运行用户	`ps -ef	grep redis`
配置文件权限	ls -l /etc/redis/redis.conf	权限为 -rw-------（即 600）
数据目录权限	ls -ld /var/lib/redis	权限为 drwx------（即 700）
监听地址	`netstat -tlnp	grep :6379`
高危命令禁用	redis-cli flushall（需先认证）	返回 ERR unknown command 'flushall'

四、Redis 安全基线核心框架总结

类别	关键控制点	核心目标
访问控制	bind限定 IP、timeout设置空闲超时	缩小攻击面，阻断闲置恶意连接
身份认证	requirepass设置强密码	防止未授权访问
权限最小化	普通用户（redis）运行、文件权限≤600	降低权限滥用风险，保护敏感文件
日志审计	启用 syslog 日志输出	满足等保要求，便于安全事件追溯
命令安全	重命名 / 禁用FLUSHALL、CONFIG等高危命令	避免数据丢失或配置篡改
网络收敛	不监听0.0.0.0、配合防火墙策略	限制网络访问范围，减少外部攻击可能