CDN绕过与信息搜集-CSDN博客

本文链接：https://blog.csdn.net/2201_75854013/article/details/147666902

声明：本教程仅为科普网络安全，切勿用于非法攻击，非法攻击产生的一切后果自行承担，维护网络安全

在学习cdn绕过与信息搜集之前必须来了解cnd是什么以及工作原理

CDN介绍相关知识

什么是 CDN（内容分发网络）

CDN（Content Delivery Network） 是一种通过分布式网络架构，将内容（如图片、视频、网页文件等）缓存到离用户更近的边缘服务器，从而加速内容传输、提升用户访问体验的技术体系。其核心原理是利用遍布全球的节点服务器，将用户请求导向地理位置最近、负载最低的节点，减少数据传输距离和延迟，同时分担源站压力

CDN 的核心技术与工作流程

分布式架构
- 由源站（存储原始内容）、分布式节点服务器（边缘节点，缓存内容副本）和 智能调度系统（DNS 或 HTTP 重定向，判断用户位置并分配最优节点）组成。
- 节点覆盖全球或特定区域，通过高速网络互联，实时同步内容。
缓存机制
- 静态内容（HTML、CSS、JS、图片、视频等）提前缓存到边缘节点，用户请求直接由最近节点响应，无需回源站。
- 动态内容（如用户个性化页面）通过边缘节点与源站的高效交互，减少延迟（如动态内容加速技术）。
智能调度技术
- 基于用户 IP 地址、网络运营商、节点负载等信息，通过 DNS 解析或 HTTP 302 重定向，将请求路由到最优节点。

CDN 的典型应用措施

1. 网站加速与性能优化

静态资源托管：将 CSS、JS、图片等静态文件部署到 CDN 节点，减少源站带宽消耗，提升网页加载速度（如谷歌、百度均使用 CDN 加速官网）。
全站加速：结合动态内容路由技术（如边缘节点与源站建立长连接、压缩传输），加速动态页面（如电商商品详情页、用户登录界面）。

2. 视频与直播场景

实时流媒体传输：在直播、在线教育、短视频平台中，CDN 节点缓存视频分片（如 HLS、DASH 协议），支持高并发访问，减少卡顿和延迟。
视频点播（VOD）：将长视频文件分布式存储，用户就近获取分片，降低源站压力（如 Netflix、YouTube 依赖全球 CDN 节点）。

3. 大文件下载加速

软件更新、固件下载：通过 CDN 节点分片传输大文件（如操作系统安装包、游戏补丁），利用多节点并行下载提升速度（如微软 Windows 更新、Steam 游戏下载）。
P2P 与 CDN 结合：部分场景中，CDN 节点作为种子节点，辅助 P2P 网络提升下载效率。

4. 电商与高并发场景

促销活动抗峰值：双 11、黑色星期五等流量高峰时，CDN 分担源站压力，避免因瞬时流量过大导致服务器崩溃（如阿里巴巴、亚马逊的核心保障技术）。
地域化内容适配：根据用户所在地区推送本地化内容（如语言、价格、库存信息），提升转化率。

5. 安全增强与防御

DDoS 攻击防护：CDN 节点作为流量入口，过滤恶意请求，分散攻击流量，保护源站 IP 不被暴露（如 Cloudflare、阿里云 CDN 的安全模块）。
HTTPS 加速：边缘节点支持 SSL/TLS 加密加速，减少源站 SSL 证书负载，同时提升传输安全性（当前 HTTPS 已成为 CDN 标配）。

6. 边缘计算与新兴场景

边缘逻辑处理：结合边缘计算（如 Cloudflare Workers、阿里云函数计算边缘版），在 CDN 节点上运行轻量化代码（如 A/B 测试、请求过滤），降低源站处理压力。
5G 与 IoT 支持：为 5G 终端、智能家居等低延迟场景提供就近内容服务，满足实时交互需求（如 AR/VR 内容分发）

总结

CDN 是互联网内容分发的基础设施，通过 “分布式缓存 + 智能调度” 解决了用户与源站之间的物理距离和网络瓶颈问题，广泛应用于几乎所有需要快速、稳定内容传输的场景。随着 5G、边缘计算等技术的发展，CDN 的角色将从 “加速工具” 升级为 “边缘服务平台”，支撑更多低延迟、高并发的新兴业务。

一句话概括：CDN 是分布式加速内容传输的网络系统。类似于中间商

CDN特征

CDN最大特征：

只开启80.443端口

其他特征:

短 TTL（如 300 秒内）：常见于 CDN 服务，用于快速节点切换，减少缓存影响。

长 TTL（如 3600 秒以上）：可能为源站服务器或未接入 CDN 的子域名（企业通常对内部服务设置长 TTL 以减少解析压力）。

小知识：TTL 是什么？

定义：DNS 记录的 TTL 是一个时间值（单位为秒），指示递归 DNS 服务器、客户端等对该记录的缓存时长。
例：若某域名 A 记录的 TTL 为 300 秒（5 分钟），则客户端在 5 分钟内会直接使用缓存的 IP，而非重新解析 DNS。

ping的过程中会记录ttl的值

CDN绕过之获取web网站源iIP

在现在大部分的web网站中，往往会采取严格的安全措施，即所有流量只经过CDN节点，再由CDN节点通向源ip，这样做的措施往往让网站的安全得到更多的保障，一方面，不法分子通过ddos攻击web网站时CDN达到了一个负载均衡和流量清洗，保障了web网站的稳定，但是在信息搜集以及渗透测试时，CDN往往成了负担，所以，必须要学会CDN的绕过

我们开始从易到难学习，方法都是在上一个方法的基础上更进

方法1：超级ping筛选

我们知道ping是用来测试连通性，而超级ping则是网络上的一种词汇（多地甚至是全国，全球的主机一同ping同一地址）以测试web网站在全球的节点延迟，以更好地分布cdn，或者判断网站基本信息

现在很多浏览器都有很多在线超级ping网站

例如：

https://www.itdog.cn/ping

我们超级ping下www.baidu.com(百度)

我们可以看到百度在全国的延迟信息，包括大量的CDN以及占比

我们怎末分辨cdn和源ip的区别呢？

小技巧：直接取超级ping解析ip占比最小的，就例如上图的0.84%节点ip，但是大型厂商不太管用，只针对小站效果较好，而且大型网站一般web网站只开启CDN，而超级ping往往更多作为基础信息搜集，例如延迟大小是否合理可以判断web网站负载带宽情况，以及cdn的分布

接下来上肝货

方法2：TTL值分辨源IP

讲到TTL，又不得不补充知识了

小知识：TTL是什莫

CDN 中 TTL 的作用

负载均衡与节点切换
CDN 提供商通常会将 TTL 设置为较短值（如 300 秒、60 秒），以便快速切换节点（如节点故障、流量调度），确保用户始终连接到最优 CDN 节点。若 TTL 过长（如数小时），客户端会长期缓存旧节点 IP，可能导致故障节点仍被访问。
隐藏源站 IP 的辅助手段
源站域名的 A 记录若直接指向 CDN 节点 IP，且 TTL 较短，可减少用户直接获取源站真实 IP 的概率（因缓存时间短，难以通过历史解析记录长期留存真实 IP）

好了，接下来我们切回正题，TTL分辨源IP的技巧

TTL的分辨有涉及windows系统和Linux系统，因为两个系统架构不一，所以TTL也会完全不一样，我们接下来针对两种操作系统分别讲下，通过 操作系统默认 TTL 值 和 网络路径跳数 的结合分析，可辅助判断目标服务器是否为 CDN 节点或源站

Windows 系统的 TTL 特征与 CDN / 源站判断

默认 TTL 值与路由跳数

初始 TTL：

Windows Server / 桌面系统：默认 128（部分版本或配置可能显示为 127）。

示例：

跨国访问（如中国到美国）经过 30 跳：128 - 30 = 98（显示 TTL=98）。

本地到目标服务器经过 10 跳路由：128 - 10 = 118（显示 TTL=118）。

特殊场景：

若目标服务器为 Windows 但 TTL 显示为 50~60，可能是：

CDN 节点：CDN 厂商可能使用 Windows 系统（虽罕见但存在）。

路径跳数极多：例如从中国访问南美节点，经 70 跳后 128 - 70 = 58

CDN 节点与源站的 TTL 差异

CDN 节点（Windows 系统）：

TTL 特征：与源站 Windows 服务器的 TTL 无本质区别（均为 128 初始值）。

验证方法：

DNS TTL 分析：若域名解析的 TTL 较短（如 300 秒），且响应 IP 属于 CDN 厂商（如阿里云的 101.37.x.x 段7），则为 CDN 节点。

HTTP 响应头：访问目标 IP 的 80/443 端口，若返回 CF-Connecting-IP（Cloudflare）或 X-Cache（阿里云）等字段，直接确认是 CDN 节点12

源站服务器（Windows 系统）：

TTL 特征：初始 TTL 为 128，路径跳数较少时显示为 110~120。

验证方法：

DNS TTL 较长：例如 A 记录的 TTL 为 3600 秒（1 小时）。

IP 归属：通过 ipinfo.io 或 站长工具 查询，IP 归属显示为目标企业（如 example.com 的服务器

操作案例

场景：扫描到某 IP 的 TTL 为 118，疑似 Windows 服务器

步骤：查询 DNS TTL

nslookup example.com  # Windows 命令行

若返回 TTL=300，且 CNAME 指向 cdn.cloudflare.com，则为 CDN 节点。

验证 IP 归属：

curl ipinfo.io/104.26.0.1  # Cloudflare 节点示例

若显示 org: "Cloudflare, Inc."，则确认是 CDN 节点

CDN与源站区别，能看到明显 org:不同

Linux 系统的 TTL 特征与 CDN / 源站判断

默认 TTL 值与路由跳数

初始 TTL：

Linux 服务器 / 路由器：默认 64（部分发行版或配置可能调整为 56、60 等）

示例：

本地到目标服务器经过 10 跳：64 - 10 = 54（显示 TTL=54）

跨国访问经过 20 跳：64 - 20 = 44（显示 TTL=44)

特殊场景：

若目标服务器为 Linux 但 TTL 显示为 110~120，可能是：

路径跳数极少：例如本地直连服务器，跳数为 0，TTL=64。

CDN 节点：CDN 厂商自定义 TTL（如设置为 128）。

CDN 节点与源站的 TTL 差异

CDN 节点（Linux 系统）：

TTL 特征：与源站 Linux 服务器的 TTL 无本质区别（均为 64 初始值）。

验证方法：

DNS TTL 较短：例如 CNAME 记录的 TTL 为 600 秒（10 分钟）。

IP 归属：查询 IP 属于 CDN 厂商（如 Cloudflare 的 104.26.x.x 段8）

源站服务器（Linux 系统）：

TTL 特征：初始 TTL 为 64，路径跳数较少时显示为 50~60。

验证方法：

DNS TTL 较长：例如 A 记录的 TTL 为 3600 秒。

响应头分析：访问目标 IP，若返回 Server: Apache 或 nginx，且无 CDN 标识，则可能为源站。

操作案例

场景：扫描到某 IP 的 TTL 为 54，疑似 Linux 服务器

步骤：

查询 DNS TTL：

dig example.com +short  # Linux 命令行

若返回 TTL=600，且 IP 为 101.37.0.1（阿里云 CDN 段7），则为 CDN 节点

验证响应头：

curl -I http://101.37.0.1

若返回 X-Cache: HIT from aliyun-cdn，则确认是 CDN 节点

跨系统验证的核心方法

1. TTL 与 DNS 记录结合

CDN 节点：

DNS TTL 短（300~600 秒），且响应 IP 属于 CDN 厂商。

源站：

DNS TTL 长（3600 秒 +），且 IP 归属为目标企业。

2. 路径追踪与 IP 归属交叉验证

工具：

Linux：traceroute example.com

Windows：tracert example.com

关键观察点：

若最后一跳 IP 属于 CDN 厂商（如 Cloudflare 的 104.26.x.x），则为 CDN 节点。

若最后一跳 IP 归属为目标企业，则可能为源站

注意事项与补充技巧

TTL 修改的可能性：

部分企业可能通过命令行修改操作系统的默认 TTL（如 Windows 可通过 netsh 命令设置4），导致 TTL 特征失效。

混合架构场景：

主站使用 CDN（Linux 节点），但子域名（如 api.example.com）可能未启用 CDN（Windows 源站），需分别分析。

法律与道德风险：

绕过 CDN 获取他人源站 IP 可能违反《网络安全法》或目标网站的使用条款，需确保操作在合法授权范围内。

场景	操作系统	TTL 特征	验证方法
CDN 节点（Windows）	Windows	初始 128，跳数后 110~120	DNS TTL 短、IP 属 CDN 厂商、响应头含 CDN 标识
CDN 节点（Linux）	Linux	初始 64，跳数后 50~60	DNS TTL 短、IP 属 CDN 厂商、响应头含 CDN 标识
源站（Windows）	Windows	初始 128，跳数后 110~120	DNS TTL 长、IP 属目标企业、响应头无 CDN 标识
源站（Linux）	Linux	初始 64，跳数后 50~60	DNS TTL 长、IP 属目标企业、响应头无 CDN 标识

通过 TTL 值、DNS 记录、IP 归属、响应头 的多维度分析，可有效区分 CDN 节点和源站服务器。实际操作中需综合多种方法，避免单一指标误判

方法3：HTTP 响应头的 CDN 标识

常见标识：

CDN 厂商	响应头字段	示例值
Cloudflare	`CF-RAY`	`5e3d2a8b-1234`
阿里云 CDN	`X-Cache`	`HIT from aliyun-cdn`
Akamai	`X-Akamai-Transformed`	`1`

可通过抓包查看，结合方法1，2，这里不过多讲解

方法4：子域名扫描结合超级ping以及DNS的TTL特征(结合，推荐)

结合子域名扫描、超级 ping（分布式 ping）以及 DNS 的 TTL 特征来分辨 CDN 和源 IP，是一种高效且常用的方法

核心原理与工具组合

子域名扫描

作用：主域名可能使用 CDN，但子域名（尤其是内部系统、测试域名、旧域名）可能未启用 CDN，直接指向源服务器。

工具：Subfinder、Sublist3r、Assetfinder、DNSdumpster等，结合爆破（如Dirbuster）或被动扫描（如 Shodan、Censys）获取完整子域名列表。

关键：优先关注业务相关子域名（如api.xxx.com、admin.xxx.com），这类子域名常暴露真实服务器

超级 ping（分布式 ping）

原理：通过多个不同地理位置（如国内 / 国外、不同运营商）的节点发送 ping 请求，获取目标 IP 和 TTL 值。CDN 节点通常分布广泛，响应 IP 多样；而源 IP 在不同节点下可能返回相同 IP（或少数几个 IP）。

工具：

在线工具：站长工具（超级 ping）、Cloudflare Radar、阿里测。

自建脚本：利用多个 VPS（如 AWS、阿里云、腾讯云不同地域实例）执行ping -c 3 domain.com，记录 IP 和 TTL

DNS TTL 特征分析

TTL 含义：DNS 记录的缓存时间，CDN 为快速更新节点信息，TTL 通常较短（如 300 秒、60 秒）；源服务器的 TTL 可能较长（如 86400 秒）或保留系统默认值。

核心逻辑：对比子域名与主域名的 TTL 差异，结合操作系统默认 TTL 值判断真实服务器

具体分辨步骤

步骤 1：子域名扫描，扩大检测范围

批量获取子域名：

#常见工具
# Subfinder快速扫描
subfinder -d target.com -o subs.txt  
# 结合爆破（需字典）
assetfinder --subs-only target.com | tee -a subs.txt  
cat subs.txt | sort -u > unique_subs.txt  # 去重

筛选可疑子域名：

排除 CDN 明确标记的子域名（如cdn.xxx.com、edge.xxx.com）。

保留可能直接指向服务器的子域名（如mail.xxx.com、auth.xxx.com）

步骤 2：超级 ping 检测 IP 和 TTL

多节点 ping 测试：

对每个子域名执行 ping，记录返回的 IP 和 TTL（Windows 用ping domain.com，Linux 用ping -c 3 domain.com）。

示例输出（Linux）：

64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=20ms  
64 bytes from 1.1.1.2: icmp_seq=2 ttl=58 time=21ms

TTL 值为58（接近 Linux 默认 64，可能被 CDN 节点微调）

关键特征判断：

CDN 节点特征

不同节点返回的 IP 不同（如国内节点返回 A 记录，国外节点返回 CName 解析的 IP）

TTL 较短（通常≤300 秒），且不同节点 TTL 可能不一致（CDN 厂商动态调整）

源 IP 特征：

多个节点（尤其是同区域）返回相同 IP

TTL 接近操作系统默认值（见下文），且稳定不变（如长期 TTL=64 或 128）

步骤 3：结合 TTL 与操作系统默认值

Windows 系统默认 TTL：

默认值：128（Win7/10/Server），可能因版本略有差异（如 WinXP 为 64，但现代服务器极少使用）。

真实 Windows 服务器：ping 返回 TTL 通常为 128，或因路由跳转减少（如 126、124，每经过一个路由器减 1-2）。

示例：TTL=126 → 可能为 Windows 服务器，经过 2 次路由跳转。

Linux/Unix 系统默认 TTL：

默认值：64（Ubuntu、CentOS、FreeBSD 等），部分系统（如 OpenBSD）为 255，但服务器常用 64。

真实 Linux 服务器：ping 返回 TTL 通常为 64，或调整为相近值（如 60、58，CDN 节点可能故意接近此值伪装）。

示例：TTL=58 → 可能为 Linux 服务器，经过 6 次路由跳转（64-6=58）。

关键对比：

若某子域名在多个节点返回 TTL=64/128，且 IP 相同 → 高度疑似源 IP。

若主域名 TTL=300，某子域名 TTL=86400 → 子域名可能未使用 CDN，指向源服务器。

大小厂商 CDN 的 TTL 差异

大型 CDN 厂商（如 Cloudflare、阿里云 CDN、腾讯云 CDN）：

TTL 特征：

主域名 TTL 通常较短（300 秒内），强制用户配置短 TTL 以保证节点更新。

节点 TTL 可能被统一设置，不同地区节点 TTL 一致（如均为 60 秒）。

绕过点：

使用dig +short domain.com查看 DNS 解析链，若最终指向xxx.cloudflare.com等域名 → 确认 CDN。

子域名可能未接入 CDN（如内部管理系统），TTL 保留默认值（64/128）

小型 CDN 厂商或自建 CDN：

TTL 特征：

TTL 设置不规范（可能长至数小时），或直接继承源服务器 TTL

节点 IP 归属地混乱，TTL 可能随机变化（如时而 58，时而 60）

绕过点：直接 ping 子域名，若 TTL=64 且 IP 归属地为目标公司所在地区 → 可能为源 IP

通过 ASN 查询（如whois -h whois.radb.net -- -i origin ASXXX IP）判断 IP 是否属于 CDN 厂商

实战案例与注意事项

案例：某电商主域名 vs 子域名

主域名（www.xxx.com）：

超级 ping 返回 10 + 不同 IP，TTL=300，DNS 解析为 CName 到cdn.xxx.com → CDN 节点。

子域名（pay.xxx.com）：

所有节点返回 IP=192.168.1.1，TTL=64，ASN 归属为目标公司 → 源 IP（Linux 服务器）

注意事项

CDN 伪装 TTL：部分 CDN 节点故意将 TTL 设置为 64/128 以模仿源服务器，需结合 IP 归属地、DNS 解析链（是否有 CName 跳转）判断

源服务器 TTL 修改：管理员可能手动修改源服务器 TTL（如 Windows 设为 64），需结合多子域名一致性判断（若多个子域名 TTL=64 且 IP 相同，可信度高）

HTTPS 站点限制：部分 CDN 仅代理 HTTP，HTTPS 可能直接连接源服务器，可尝试curl -I https://domain.com查看响应头中的X-Forwarded-For或Server字段辅助判断

推荐工具链

子域名扫描：Subfinder+Assetfinder+Amass（被动扫描）

超级 ping：自建 Python 脚本（利用requests调用多个地区 API）或站长工具 API

TTL 与 DNS 分析：dig domain.com +noall +answer +ttl（查看 DNS 记录 TTL）、ping -c 3 domain.com | grep ttl（提取 TTL 值）

OK,以上就是关于CDN节点的绕过，希望我的经验对你有所帮助

CDN的信息搜集可结合前篇信息搜集