1. 从一次授权测试说起Cloudflare 到底“烦”在哪做渗透测试的朋友都懂那种感觉目标系统明明就在眼前nmap 扫了半天结果全是 Cloudflare 的节点 IP访问目标域名返回的证书是 *.cloudflare.com想直接连源站打点却连入口都找不到。这就是 Cloudflare 这类 CDN 防护带来的典型困境——它把源站 IP 藏得严严实实所有流量都先过它那一层过滤你连真实的“门牌号”都摸不到后面的渗透动作自然无从谈起。我早期接触这类项目时也踩过不少坑后来接了几个带 Cloudflare 防护的授权测试项目才慢慢摸出一套行之有效的思路。这篇文章就围绕“渗透测试里如何应对 Cloudflare 防护”这个主题把我实操中证明有效的方法、失败过的尝试、以及踩过的坑整理成一份可以直接参考的路线图。需要提前声明所有方法仅适用于获得书面授权的渗透测试、漏洞评估或防御加固场景请勿用于任何未授权目标。需要说明的是所谓的“绕过”不是要突破 Cloudflare 的 WAF 规则那是另一套攻防对抗而是要绕过“Cloudflare 挡住你发现源站 IP”这一层。一旦拿到源站 IP测试者可以绕过 CDN 直接访问源站判断是否存在防护盲区。从防御方视角看这篇文章同样有价值——你知道攻击者是怎么想的才知道源站 IP 该怎么藏。2. 为什么 Cloudflare 能“锁死”你的探测路径2.1 流量代理模型所有请求先过 CDNCloudflare 的防护本质是一个反向代理。当目标域名接入 Cloudflare 后DNS 解析结果会变成 Cloudflare 的任一节点 IP通常是 104.x.x.x、172.x.x.x 等段源站 IP 在公共 DNS 里彻底消失。用户请求到达 Cloudflare 节点后由节点缓存响应或转发给源站源站只与 Cloudflare 节点通信。这样一来外部扫描者看到的所有资产都归属于 Cloudflare目标真实的服务器被完全遮蔽。这里的关键点在于源站 IP 并不是“不存在”而是被隐藏了。只要源站还存在对外通信的行为就一定有办法把它“揪”出来。理解这一模型后整个测试思路就清晰了——我们要找的不是直接攻击 Cloudflare 节点而是寻找任何可能“泄露”源站 IP 的旁路信息。2.2 安全过滤层WAF 和防护规则除了隐藏 IPCloudflare 还提供 WAF 功能会拦截常见的 SQL 注入、XSS、路径遍历等攻击载荷。即使你找到了源站 IP直接拿扫描器去打源站也会遇到 Cloudflare 的规则过滤如果源站仍处于 Cloudflare 保护下比如通过 CNAME 接入。所以在测试中要区分的两个概念是找到源站 IP 不等于绕过防护还要考虑源站是否直接暴露在公网、是否信任来自 CDN 的请求头等。2.3 动态 IP 与 DNS 代理的坑Cloudflare 的另一个特点是 IP 段非常庞大且动态。即使你通过某种手段拿到了一个源站 IP它可能是一个 CDN 节点而不是真正的源站也可能是 Cloudflare 的 Spectrum 功能代理的任意端口。这就要求测试者要有“验证”的意识任何疑似源站 IP 都要通过 Host 头访问来确认而不能只看 IP 归属。3. 找源站 IP那些实测有效的技术路线3.1 历史 DNS 记录最直接的突破口很多运维人员在接入 Cloudflare 之前域名曾经直接解析到源站 IP。这些历史 A 记录会被各类 DNS 查询服务商存档成为后期查询的宝贵线索。常用的途径包括在线历史 DNS 查询平台如 viewdns、dnsdumpster 等提供的历史记录功能使用命令行工具如dig配合特定历史接口部分威胁情报平台会留存长期 DNS 数据实操中的经验是查询时不能只看眼前的记录要往前翻三到五年的记录。我遇到过不少目标现网全走 Cloudflare但两年前的阿里云 IP 就这么挂在历史记录里顺着那个 IP 直接访问果然是源站。不过要注意历史 IP 可能已经换掉了也可能已经被 Cloudflare 接管需要结合其他线索一起判断。3.2 子域名枚举寻找未接入防护的旁站这是最值得投入时间的一步。很多企业只把主域名和几个核心业务域名接入了 Cloudflare其他子域名、测试环境、老项目可能完全裸奔在外。这些旁站如果和主站部署在同一台服务器或同一网段就能帮你推断出源站 IP。推荐的执行流程是通过证书透明度日志如 crt.sh拉取目标域名下的所有子域名列表用子域名爆破工具补充一批未出现在证书里的子域名将收集到的子域名逐一解析筛选出 IP 不属于 Cloudflare 段的那部分对这些非 Cloudflare IP 进行端口扫描和 Web 指纹识别判断是否属于目标资产需要注意的细节是解析出的非 Cloudflare IP 不一定是源站可能是其他第三方服务如邮件服务器、对象存储、SaaS 应用。需要通过 SSL 证书主题、页面标题、响应头 Server 字段等做关联验证。我一般在验证时用curl -k https://IP -H Host: 目标域名来观察返回内容如果页面是目标站的内容或者出现证书不匹配但应用特征吻合那基本可以确认。3.3 证书透明度日志泄露真实 IP 的利器证书透明度Certificate Transparency是一个公开的证书日志系统所有公开信任的 SSL/TLS 证书都会被记录在里面。攻击者可以通过查询某个域名下的证书历史发现那些时间段内的 IP 地址。因为证书签发时包含的 IP 信息是可以被查询的尤其是早期证书很多包含 IP 字段。常用的查询方式在 crt.sh 上搜索%目标域名%获取所有子域名证书列表分析证书中的 SAN 字段找到额外域名对证书中出现过的 IP 进行筛选配合其他手段确认源站有个小技巧不少企业在迁移到 Cloudflare 前内部测试环境也申请了证书这些证书可能包含了旧 IP。我就在一个项目里通过 crt.sh 找到一条五年前的证书记录里面直接显示了当时的 IP 和域名那个 IP 现在仍然开放了 80/443 端口并指向旧版后台系统。这类信息价值极高因为证书日志没法被删除时间久了很容易被忽略。3.4 邮件头溯源从业务入口抄后路如果目标站点有注册功能、忘记密码功能、联系表单等这些功能往往需要发送邮件。邮件头的 Received 链会记录发件服务器的 IP 路径虽然多数邮件服务商会在域名的 SPF 记录里指定邮件服务器地址但有时候邮件是直接由源站所在服务器的邮件服务发出的这时候邮件头里就会暴露出源站 IP。实操步骤找一个需要邮件通知的功能如注册、密码找回接收邮件后展开原始邮件头查看Received字段找到非 Cloudflare 段的 IP核对该 IP 的开放端口和 Web 服务特征这个方法的效果取决于目标的邮件架构。对于自建邮件服务器且与 Web 服务同机部署的目标几乎是直接命中如果目标用了企业邮箱托管邮件头只会显示托管商的 IP价值有限。所以邮件头要靠但不能押宝在这一个方向上。3.5 主动探测让源站自己“开口说话”除了被动收集主动探测也是一条路。核心思路是让源站产生出站连接或者让 Cloudflare 转发一个不存在的请求给源站通过观察响应差异来判断源站。几个实测有效的手段寻找网站中的 SSRF 类功能比如 URL 预览、图片抓取、文件导入让服务器主动访问自己可控的服务器从访问日志中查看来访 IP利用 Cloudflare 的缓存行为如果源站对某个路径返回了自定义报错信息这个报错可能会暴露内部服务器信息伪造X-Forwarded-For头观察响应差异判断源站是否信任该头并基于它做判断利用 DNS 解析差异Cloudflare 在不同网络下的解析结果可能不同尝试使用不同地区的 DNS 查询工具对比这里要提一个印象深刻的案例某授权测试中目标站点有一个“分享链接生成”功能会去抓取用户提交的 URL 并生成缩略图。我向该功能提交了一个指向自己服务器的 URL很快在服务器日志里就看到了目标源站的真实 IP。这类 SSRF 入口本身就是高危漏洞用到这里反而成了“绕过 Cloudflare”的跳板。当然做这种测试要在授权范围内避免对目标造成实际损害。3.6 第三方测绘平台利用历史扫描数据互联网上有许多持续进行全球扫描的测绘平台如 Shodan、FOFA、Quake 等它们会不断记录公开设备的 IP、端口、服务指纹。由于这些平台扫描的覆盖面极广很可能在目标接入 Cloudflare 之前就已经记录下了源站信息。使用方法很简单在测绘平台搜索目标域名的 SSL 证书指纹通常是 SHA256 指纹搜索目标的 HTML 标题、关键词、favicon 哈希搜索目标开放的非标准端口特征Shodan 搜索时可以用ssl.cert.subject.cn:目标域名来查找证书中包含目标域名的所有 IP。FOFA 则支持cert目标域名这类语法。如果源站还开放了 SSH、Redis、数据库等端口测绘平台的端口指纹也能帮助你定位。需要提示的是测绘平台的数据源是持续变化的有些 IP 可能已经失效所以拿到的结果仍然要逐一验证。但作为信息收集的补充渠道它的价值非常高。4. 验证源站 IP别把 CDN 节点误当源站很多新手找到一堆疑似 IP 后就急着去打结果打的全是 Cloudflare 节点既浪费了时间又可能触发风控。这里我有一套固定的验证流程供你参考检验项方法和标准IP 归属查询通过 IP 归属库或平台查询排除知名云 CDN 段如 Cloudflare 104.16.0.0/13 等SSL 证书直接访问https://IP查看返回的证书是目标域名的证书还是 Cloudflare 的证书响应头对比curl -I直接访问 IP 与访问域名的响应头差异源站通常不会带cf-ray头Host 头验证curl -k https://IP -H Host: 目标域名若返回目标站内容且无 Cloudflare 标识则基本确认端口开放情况源站通常开放 22、3306、6379 等管理端口而 Cloudflare 代理只会开放 80/443 等常用端口时延对比直连 IP 的响应时间与通过 Cloudflare 访问的响应时间存在明显差异源站直连通常更快最可靠的是组合验证如果某个 IP 的证书是目标域名且不包含 Cloudflare 标识端口扫描又发现非 Web 服务同时带 Host 头能访问到目标页面那基本可以肯定是源站了。我见过不少把 CDN 节点误导认为源站的情况就是因为只看了 IP 归属和页面返回忽略了证书核验这一步。5. 拿到源站 IP 之后如何继续推进测试5.1 直接访问与指纹识别确认源站 IP 后下一步就是用扫描器对源站进行全端口扫描和服务识别。此时你面对的是没有 CDN 过滤的原始服务MySQL、Redis、SSH、RDP 等管理端口暴露在公网的话就打开了新的攻击面。注意扫描时要控制速率避免触发源站的防护软件或安全组策略。5.2 路径发现与敏感文件探测源站与 CDN 在目录结构上往往存在差异。Cloudflare 可能会缓存部分静态资源但源站上可能有完整的备份文件如.git、.svn、备份压缩包、配置文件泄露。用目录爆破工具配合常见敏感路径字典可以快速发现这些文件。遇到过几次源站直接暴露.git目录的情况拉下来源码后整个测试瞬间简单了很多。5.3 绕过 WAF 直接攻击源站如果源站解析到 IP 后仍然能通过 Host 访问那 WAF 层面的规则大概率就不生效了或部分生效。测试时可以把攻击载荷直接发到源站 IP观察响应与通过 Cloudflare 的差异。这里要注意有些防护部署在源站服务器本身如 nginx 规则、云安全组这种情况下绕过 CDN 并不能完全绕过安全防护需要具体问题具体分析。5.4 利用 CDN 与源站的缓存差异Cloudflare 与源站之间经常存在缓存不一致的问题。比如源站更新了 robots.txt 或安全策略而 CDN 上仍是旧版本或者源站删除的页面在 CDN 缓存中仍然可访问。利用这些差异可以发现一些有趣的信息比如历史版本的内容、临时开放的接口、测试用的凭证等。测试时可以用curl -H Cache-Control: no-cache或强制刷新来观察差异。6. 常见的“死胡同”与对应的排查思路6.1 所有子域名都走 Cloudflare怎么办这时候优先考虑证书透明度日志和历史 DNS然后是第三方测绘平台。多数情况下至少有一个旁站的证书或历史记录会泄露底层 IP。如果所有路都走不通还可以尝试从移动端 App 入手App 的 API 地址可能直连源站或使用独立的域名和 IP。对 App 做一次反编译翻一下里面的硬编码域名和 IP往往有意外收获。6.2 找到的 IP 是一个 CDN 节点不是源站这种误判在腾讯云、阿里云这类同时提供 CDN 和云主机的环境中尤其常见。解决方案是观察该 IP 是否开放非标准端口、验证证书是否包含目标域名、查看该 IP 的历史解析记录。如果是 CDN 节点一般不会开放非标准端口证书也通常与该节点关联的其他域名相关。6.3 源站拒绝直接 IP 访问怎么办不少服务器配置了默认站点设置直接使用 IP 或非绑定域名访问时会返回空响应或默认页面。此时需要带正确的 Host 头访问即curl -k https://IP -H Host: www.target.com。如果源站有多个域名绑定在同一 IP 上Host 头指向正确的站点就能拿到目标页面。这个方法也是验证源站 IP 是否有效的黄金标准。6.4 Cloudflare 的“始终在线”功能造成误判Cloudflare 有一个“Always Online”功能当源站不可用时Cloudflare 会展示缓存的旧页面。如果攻击者扫描时发现目标页面仍然可访问但源站实际已经挂了就会误判源站 IP。遇到这种情况可以提交一个不存在的路径看返回的是 Cloudflare 的 404 页还是源站自定义 404 页通过错误页特征来区分。7. 防御视角源站 IP 泄露之后如何加固7.1 网络层限制源站访问范围最直接有效的措施是在源站服务器和云安全组中仅允许 Cloudflare 官方 IP 段访问 80/443 端口。这样即使源站 IP 泄露外部扫描者也无法直接访问 Web 服务。Cloudflare 官方会发布当前的 IP 段列表运维人员可以用脚本定期同步安全组规则。7.2 不要在同一台服务器上托管 Web 与邮件邮件头泄露源站 IP 这个攻击路径根源在于 Web 和邮件共用服务器。将邮件服务迁到独立服务器或托管邮箱后邮件头只会暴露邮件服务商的 IP源站信息就保住了。同理FTP、SSH 等管理服务也尽量与 Web 服务拆分或迁移到独立管理网段。7.3 使用独立源站域名并保持私密部分架构会用direct.target.com这类域名作为源站回源地址。这个域名如果被爆破出来配合 DNS 解析就能拿到源站 IP。正确做法是回源域名不要使用可预测的名称不要将其写入公开的证书里使用内部 CA 或泛域名但不公开同时通过访问控制限制回源域名的解析范围。7.4 定期检查泄露面我建议防御方每季度做一次“源站 IP 泄露自查”方法就是本文提到的那些用 crt.sh 查看证书、用测绘平台搜 IP、翻历史 DNS。知道攻击者会怎么看才知道自己哪里没藏好。这套思路对所有使用 Cloudflare 的团队都适用相当于给自己做一次免费的安全体检。8. 实操心得与最后提示在我参与过的多个带 Cloudflare 的授权测试项目里效率最高的组合不是某个单一技巧而是“证书透明度 子域名枚举 测绘平台”这三板斧。它们都利用了同一个弱点企业的数字资产是持续扩展的不可能所有资产都永远躲在 CDN 后面只要有个别漏网之鱼就能顺藤摸瓜摸到源站。有一个容易被忽略但很实用的心得拿到疑似源站 IP 后先不急着丢进扫描器用浏览器访问一下 IP 或带 Host 头访问看看页面是否和域名的登录页一致。很多时候源站和 CDN 的登录页会有细微差异比如没有 Cloudflare 的 JS 挑战、没有安全 Cookie、favicon 路径不同这些差异反而能帮你快速确认归属。另外提醒一点测试过程中对源站的操作务必谨慎。源站直接暴露公网往往意味着它的安全防护比 CDN 薄弱误操作可能导致目标服务不可用在授权测试里这是底线问题。所有高危操作如 SQL 注入验证、目录删除、命令执行尽量先评估影响范围至少选在业务低峰期执行。最后从防御方角度多说一句接入了 Cloudflare 并不等于万事大吉源站 IP 泄露在现实里太常见了。如果你维护的站点已经接入了 CDN不妨今天就按照上面提的方式自查一轮找到泄露面之后及时封堵别等测试者来帮你发现。