CDN防护的薄弱环节：实战中寻找真实IP的多种思路

1. CDN防护的基本原理与常见误区

CDN（内容分发网络）是现代网站加速和安全防护的标配技术，但很多安全测试人员对它存在误解。我见过不少新手一发现目标用了CDN就直接放弃，其实CDN防护并非铁板一块。CDN本质上是个"中间商"，用户请求先到CDN节点，再由节点回源到真实服务器。这个设计本身就埋下了隐患——如果攻击者能找到不经过CDN的路径，就能直连真实服务器。

最常见的误区是认为所有域名都套了CDN。实际上很多网站只给主域名配置CDN，像www.example.com有防护，但example.com或m.example.com可能还是裸奔状态。去年我测试某电商平台时，就是通过直接访问不带www的域名找到了真实IP。另一个误区是认为CDN配置全球一致，其实很多企业为省钱，只给海外节点配置CDN，国内访问反而暴露真实IP。

提示：用dig +short example.com和dig +short www.example.com对比解析结果，差异可能就是突破口。

2. 从DNS记录中挖掘真实IP

2.1 历史DNS快照分析

网站上线初期往往还没配置CDN，这些"黑历史"都藏在DNS历史记录里。我常用SecurityTrails的DNS历史查询功能，输入域名后能看到从2010年至今的所有A记录变更。有次渗透测试中，我发现目标公司三年前用的IP至今仍在运行，只是没在公开DNS记录里显示。

# 使用SecurityTrails API查询历史DNS记录 curl -X GET "https://api.securitytrails.com/v1/history/example.com/dns/a" \ -H "APIKEY: your_api_key"

2.2 子域名爆破与解析

CDN通常只保护主要业务域名，像dev.example.com、test.example.com这类子域名经常被忽略。用subfinder工具跑一下子域名，经常能发现漏网之鱼：

subfinder -d example.com -silent | while read sub; do dig +short $sub | grep -v cdn; done

上个月测试某金融平台时，我就通过old.example.com这个被遗忘的测试环境域名拿到了生产服务器的IP。

3. 利用互联网档案与遗留文件

3.1 Wayback Machine宝藏

Internet Archive的Wayback Machine保存着网站的历史快照，包括早期的robots.txt、sitemap.xml等文件。这些文件里可能包含直接调用IP的接口地址。有次我在2015年的快照中发现了http://203.0.113.45/admin的引用，这个IP至今仍是他们的管理后台入口。

3.2 敏感文件泄露

网站根目录下的phpinfo.php、test.php这类调试脚本会暴露服务器环境信息。用ffuf快速扫描常见路径：

ffuf -w wordlist.txt -u https://example.com/FUZZ -mc 200

特别要关注/package.json、/composer.json这类开发配置文件，里面引用的私有仓库地址可能指向真实服务器。

4. 网络空间测绘技术实战

4.1 SSL证书指纹追踪

CDN可以隐藏IP，但SSL证书指纹是唯一的。先用openssl获取证书哈希：

openssl s_client -connect example.com:443 2>&1 | openssl x509 -noout -fingerprint -sha256

然后把指纹值去掉冒号，放到FOFA搜索：

cert="a1b2c3d4e5f6..."

这个方法帮我找到了某云服务商的真实IP池，他们的CDN节点和源站使用相同证书。

4.2 特定文件哈希匹配

网站favicon.ico、logo.png等静态文件的哈希值是独特的。先计算目标网站图标哈希：

curl -s https://example.com/favicon.ico | md5sum

然后在Shodan搜索：

http.favicon.hash:1234567890

去年用这招定位到了某政府网站的源站，他们的CDN配置漏掉了/static/目录下的图标文件。

5. 特殊场景下的真实IP发现

5.1 邮件服务器溯源

企业邮件系统很少套CDN，给目标发个邮件然后查看原始邮件头，X-Originating-IP字段经常泄露真实IP。有个取巧的方法：注册目标域名的拼写错误邮箱（如admin@exmaple.com），当对方邮件系统自动回复时，退回邮件里往往包含内部服务器IP。

5.2 第三方服务引用

很多网站引用的Google Analytics、Hotjar等第三方JS脚本会直接连接源站。在浏览器开发者工具中搜索/analytics.js的请求，查看网络瀑布图中是否有非常规IP出现。最近一次测试中，我发现目标网站的客服系统JS文件直连了他们的内网IP。

6. 验证真实IP的实用技巧

找到可疑IP后，最怕遇到"李鬼"服务器。我习惯用四重验证法：

1. TTL值比对：直连IP的TTL通常比CDN节点小，比如源站TTL=60，Cloudflare节点TTL=14400
2. HTTP头特征：对比Server、X-Powered-By等头信息
3. 内容相似度：用difff工具比较CDN页面和直连页面的HTML相似度
4. 端口服务扫描：CDN节点通常只开放80/443，而真实服务器可能暴露SSH、RDP等端口

# 简单的页面相似度比对脚本 from difflib import SequenceMatcher import requests def compare(url1, url2): r1 = requests.get(url1).text r2 = requests.get(url2).text return SequenceMatcher(None, r1, r2).ratio() print(compare("http://1.2.3.4", "https://example.com")) # >0.9则为同一站点

7. 防御视角下的对抗策略

作为防守方，我建议采用以下措施防止真实IP泄露：

• 为源站配置独立的证书，与CDN证书区分开
• 严格限制源站IP的对外暴露，只允许CDN厂商IP段回源
• 定期检查子域名解析情况，关闭不必要的DNS记录
• 监控互联网空间测绘平台的查询记录，发现异常及时处置

有次客户遭遇CC攻击，我们通过分析攻击流量中的TCP Timestamp选项，反向追踪到了攻击者伪造的源IP段，及时更新了防火墙规则。这种攻防对抗就像下棋，关键是要比对手多看三步。