问题思考：
- 为什么需要获取CDN后面的真实IP？
- 有哪些安全漏洞的验证会受到影响？
- 如何获得CDN后面的真实IP？
CDN（内容分发网络）会将网站内容缓存到全球各地的服务器，隐藏原始服务器的真实IP。在安全测试中，测试的对象是CDN还是真实IP，会影响到漏洞验证的结果。
有哪些场景/漏洞会受到影响？
对纯前端逻辑漏洞（如业务逻辑错误、某些XSS）可能没有影响，但对于依赖服务器响应、网络拓扑、后端交互的漏洞（SSRF、某些RCE、缓存投毒等）会影响到漏洞利用成功与否。
| 场景 | 使用CDN域名测试 | 使用真实源站IP测试 | 影响程度 |
|---|---|---|---|
| 端口与服务探测 | 只能看到CDN的端口 | 可发现全端口（数据库、SSH等） | 高 |
| Web漏洞利用 (如SSRF) | 请求可能被CDN闭环，测试失败 | 可直接触达内部/后端服务 | 高 |
| 绕过WAF规则 | 所有流量被过滤和监控 | 可能直接面对无防护的源站 | 高 |
| 访问非常规路径 | 可能被CDN规则阻挡 | 可能直接暴露管理后台等 | 中 |
| 遗留的"废弃"资产 | 不会被发现 | 可能发现未维护的旧系统 | 中 |
为什么需要获取真实IP？
- 对端口服务的探测影响：使用nmap对CDN的IP扫描时，大概率只能看到CDN提供商开放的少数端口（如80, 443）， 而无法发现源站服务器上可能暴露的数据库端口（3306, 6379）、管理后台（8080）、SSH（22）、或老旧易受攻击的服务。 对真实IP的端口扫描可以扩大潜在攻击面；
- **绕过集成在CDN中的WAF/安全策略：**许多公司将Web应用防火墙集成在CDN中，找到真实IP可能暴露未受保护的服务。例如，源站IP的8080端口可能运行着Jenkins、Weblogic等管理界面，这些界面没有经过CDN，因此也绕过了WAF；
- **特定Web漏洞的测试受CDN的影响：**例如应用存在SSRF漏洞时，如果让服务器去请求它的"公网域名"，这个请求很可能被CDN解析到CDN节点，形成回环，无法触达内网系统；
- 查找"非标准"接口目录：CDN配置通常是"按需缓存"，并非所有路径和内容都会被CDN代理。通过域名 访问一些非常规使用的接口目录（例如/admin/, /backup/）可能会被CDN拒绝或返回错误，但通过真实IP访问可以直接打开；
- 查找过程中有机会发现"废弃"的遗留机器：企业的网络架构会发生变化，可能曾经有aaa.example.com直接解析到IP地址A，后来才接入CDN，将解析改为CDN的CNAME记录，但是旧的IP地址A可能还在互联网上，指向一台"废弃"的遗留机器。在查找真实IP的过程中，通过历史记录找到的IP，有可能指向这样的一台机器，可以作为测试的切入点。
如何寻找真实IP？
- **查找历史DNS记录：**查看DNS历史记录，可能保存了CDN部署前的A记录；
- 查找未接入CDN的子域名： 主站用了CDN，但
dev.example2.com、mail.example2.com、test.example2.com等子域名可能没有使用CDN，仍然指向真实IP； - 利用 SSL/TLS 证书寻找关联 IP **：**查找同一组织签发的其他SSL证书，其关联的域名可能指向真实IP；
- **第三方内容引用：**网站的JavaScript文件、图片等可能从非CDN的地址加载；
- 其他DNS记录类型：查询其他记录类型，如MX、TXT、NS等，也有可能指向真实IP。
如何判断IP是否属于CDN?
- 检查 IP 是否属于已知 CDN 的 IP 段；
- 查看CNAME记录： 如果子域名 CNAME 指向 xxx.cloudfront.net、xxx.fastly.net等，则明显使用了 CDN；
- 观察HTTP响应头：检查响应头中的server、X-Cache、Via等字段中是否有CDN标识（cloudflare, akamai）；
- C段排除法：网络空间引擎中，如果是CDN的话，C端大概会包含大量杂乱资产（查询语法示例：ip="xxx.xxx.xxx.xxx/24"）
拓展阅读
https://blog.csdn.net/weixin_45802999/article/details/145185998（有实例参考）