Redis漏洞利用与安全加固：零基础从配置到实战
为什么你的Redis容易被攻击
Redis默认配置存在多个安全短板，比如未开启密码、监听所有IP、保留危险命令等。
攻击者利用这些漏洞可以未授权访问、窃取数据、执行系统命令甚至控制服务器。
在动手加固之前，先了解几个最常见的攻击入口：
- 未授权访问：Redis默认无密码，如果绑定在公网IP，任何人都可以远程连接。
- 弱口令：使用
123456、redis等简单密码，等于直接开门。 - 危险命令：
FLUSHALL、CONFIG、EVAL等命令可被用于修改配置或执行脚本。 - 默认端口6379：没有改端口或防火墙限制，直接暴露。
加固前需要准备什么
操作前请确认以下条件均已满足：
- 一台安装了Redis的服务器（版本建议5.0或以上）。
- 拥有服务器的root权限或sudo权限。
- 能通过SSH或服务器面板（如宝塔）登录。
- 备份当前Redis数据和配置文件（路径通常在
/etc/redis/redis.conf或/usr/local/etc/redis.conf）。 - 准备一个强密码（建议32位随机字符，含大小写、数字和符号）。
三步完成核心安全配置
第一步：禁止公网监听，只允许内网访问
编辑Redis配置文件：
vim /etc/redis/redis.conf找到bind这一行，默认可能是bind 127.0.0.1 ::1或空。
修改为只监听内网IP：
bind 127.0.0.1 你的内网IP（如192.168.1.100）如果只需要本机访问，直接保留127.0.0.1。切勿设为0.0.0.0。
第二步：设置强密码并开启认证
在配置文件中搜索requirepass，取消注释并设置密码：
requirepass Mj43!kP#9xZw@Q2f保存后重启Redis服务：
systemctl restart redis # 或 service redis restart重启后，客户端连接必须提供密码：
redis-cli -h 127.0.0.1 -a Mj43!kP#9xZw@Q2f第三步：禁用危险命令，缩小攻击面
在配置文件中添加rename-command指令，把高危险命令重命名为空字符串或自定义名字：
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command EVAL ""
rename-command SCRIPT ""如果想保留功能但隐蔽使用，可以改成其他名字，例如：
rename-command FLUSHALL "FLUSHALL_MTq9"配置后同样要重启Redis生效。
常见踩坑与避坑指南
- 改了bind忘记重启：配置不重启不会生效，且重启前请确认配置文件语法正确。可以用
redis-server /etc/redis/redis.conf测试启动，没问题再重启服务。 - 密码包含特殊字符导致连接失败：密码中的
$、!、#等可能会被Shell解释，建议用单引号括起来。在redis-cli中使用-a参数时，用双引号或直接放在redis.conf里。 - 危险命令被禁用后影响业务：部分应用依赖
CONFIG、EVAL等命令，禁用前务必确认业务需求。如果必须保留，应缩小命名替换范围。 - 防火墙未同步：即使配置了bind，如果iptables/ufw放行了6379端口，外网依然能绕过限制。建议同时添加防火墙规则：
ufw deny 6379
# 或者只允许特定IP
ufw allow from 192.168.1.0/24 to any port 6379验证加固是否生效
1. 检查绑定地址
执行命令查看监听状态：
ss -tnlp | grep 6379正常情况下应只显示127.0.0.1:6379或你的内网IP，不能有0.0.0.0:6379或*:6379。
2. 测试未授权访问
在不配置密码的情况下尝试连接：
redis-cli -h 你的服务器IP -p 6379如果提示NOAUTH Authentication required.，说明认证生效；
如果能直接执行PING并返回PONG，说明未授权访问仍存在，请检查requirepass是否已配置并重启。
3. 验证危险命令是否被禁用
连接Redis后执行：
FLUSHALL应返回-ERR unknown command 'FLUSHALL'或类似错误，表示命令已被禁用。
4. 使用安全扫描工具外部测试
推荐使用nmap的redis-info脚本或者在线Redis安全检测工具（如redis-security-checker），从外部视角检查目标服务器的Redis暴露面和弱口令风险。
如果你正在处理Redis漏洞利用与安全加固，建议按上述步骤完整执行一遍，再根据业务场景微调。
遇到异常时优先回头检查配置文件语法和重启状态，大多数问题都能在这些环节中找到原因。
