从防御者视角看SSRF攻击Redis：手把手教你用WAF规则和Redis配置堵住这个高危组合

构建企业级SSRF与Redis联合防御体系的实战指南当SSRF漏洞遇上未授权访问的Redis服务就像给攻击者打开了通往企业核心数据的大门。这种高危组合可能导致从敏感信息泄露到服务器完全沦陷的严重后果。本文将系统性地从防御视角出发提供一套覆盖应用层、网络层和服务层的立体化防护方案。1. 理解威胁SSRF与Redis的组合攻击原理SSRF服务器端请求伪造允许攻击者通过受控服务器发起任意网络请求而Redis的未授权访问漏洞则让攻击者能够直接操作数据库服务。当两者结合时攻击者可以通过dict://或gopher://协议直接与内网Redis服务交互利用Redis的持久化功能写入SSH公钥获取服务器权限向Web目录植入webshell控制网站服务器通过计划任务实现持久化后门典型攻击链示例攻击者发现存在SSRF漏洞的Web接口如/api/fetch?urlhttp://example.com构造特殊URL探测内网Redis服务dict://192.168.1.100:6379/info确认Redis存在未授权访问后发送精心构造的Gopher协议Payload通过Redis的config set命令修改存储路径并写入恶意内容关键点这种攻击完全通过正常业务接口实现传统边界防御设备往往难以识别2. 应用层防御从源头阻断SSRF漏洞应用层是防御的第一道防线重点在于限制服务器发起的网络请求能力。2.1 输入验证与过滤策略建立严格的白名单验证机制// 安全的URL验证函数示例 function isValidUrl($url) { $parsed parse_url($url); if (!isset($parsed[scheme]) || !in_array($parsed[scheme], [http,https])) { return false; } if (isset($parsed[host]) isInternalIp($parsed[host])) { return false; } return filter_var($url, FILTER_VALIDATE_URL) ! false; } function isInternalIp($host) { $ip gethostbyname($host); $privateRanges [ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, fc00::/7 ]; foreach ($privateRanges as $range) { if (ipInRange($ip, $range)) { return true; } } return false; }2.2 安全CURL配置对于必须使用CURL的场景严格限制协议和访问范围$ch curl_init(); curl_setopt($ch, CURLOPT_URL, $validatedUrl); curl_setopt($ch, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS); // 仅允许HTTP/HTTPS curl_setopt($ch, CURLOPT_REDIR_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS); curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4); // 避免DNS重绑定攻击 curl_setopt($ch, CURLOPT_TIMEOUT, 5); // 设置合理超时2.3 编程语言特定防护不同语言需要针对性防护语言关键防护措施PHP禁用allow_url_fopen, 严格校验parse_url结果Java使用SecurityManager限制网络访问Python配置urllib的allowed_schemesNode.js使用dns.lookup而非dns.resolve避免DNS重绑定3. Redis服务加固消除未授权访问风险3.1 基础安全配置修改redis.conf关键参数# 绑定特定IP生产环境必须 bind 192.168.1.100 # 启用认证 requirepass YourStrongPassword123! # 禁用高危命令 rename-command FLUSHDB rename-command CONFIG rename-command EVAL # 限制内存使用 maxmemory 2gb maxmemory-policy volatile-lru # 启用保护模式 protected-mode yes3.2 网络层隔离策略实施最小权限网络访问控制# iptables示例规则 iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP # 或使用更精细的应用账号授权 sudo -u redis-user redis-server /etc/redis.conf3.3 企业级Redis安全架构对于大型企业建议代理层部署Twemproxy或Redis Cluster代理TLS加密配置SSL/TLS传输加密审计日志启用slowlog和AOF持久化权限分离使用不同账号运行Redis和应用程序4. 网络层纵深防御体系4.1 WAF规则示例ModSecurity针对SSRF攻击的特征检测规则SecRule REQUEST_URI rx \b(gopher|dict|file):// \ id:10001,\ phase:2,\ deny,\ status:403,\ msg:SSRF attack attempt detected,\ tag:OWASP_TOP10/A1 SecRule ARGS rx ^(?:[0-9]{1,3}\.){3}[0-9]{1,3} \ id:10002,\ phase:2,\ chain,\ t:none SecRule REMOTE_ADDR validateByteRange 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 \ ctl:ruleRemoveById100024.2 网络分段与微隔离建议的网络架构区域访问控制策略互联网区仅开放80/443端口部署WAFDMZ区限制出站连接到特定IP和端口内网应用区应用服务器只能访问所需数据库端口数据存储区仅允许来自应用区的Redis连接4.3 入侵检测规则Suricata示例检测异常的Redis协议流量alert tcp any any - $HOME_NET 6379 (msg:ET EXPLOIT Possible Redis Unauthorized Access Attempt; flow:to_server,established; content:|2a 31 0d 0a 24 34 0d 0a 69 6e 66 6f 0d 0a|; depth:14; classtype:attempted-admin; sid:20231337; rev:1;)5. 持续监控与应急响应5.1 关键监控指标建立Redis专项监控看板异常认证失败次数非授权IP连接尝试CONFIG命令使用情况内存使用突变告警持久化文件异常变更5.2 应急响应流程当检测到可疑活动时立即隔离通过防火墙阻断可疑IP取证分析检查Redis日志/var/log/redis/redis.log分析AOF文件变更检查~/.ssh/authorized_keys完整性恢复措施重置Redis密码回滚到安全快照轮换所有可能泄露的凭证5.3 加固检查清单定期执行的安全检查[ ] Redis绑定IP检查[ ] 认证密码强度验证[ ] 高危命令禁用确认[ ] 网络ACL规则审计[ ] 日志监控配置检查[ ] 备份恢复测试在一次实际事件响应中我们发现攻击者通过SSRF漏洞尝试连接内网Redis服务。由于我们已实施网络微隔离和命令重命名攻击者虽然触发了告警但未能成功执行任何危险操作。这凸显了纵深防御的价值——没有单一防护层是完美的但多层防护可以极大提高攻击成本。