给站点上完 CDN 之后大部分人心里都会冒出一个问题我这套 CDN 到底有没有把源站藏住真实的源站 IP 会不会被人顺手摸出来说白了查询 CDN 真实 IP这件事本身是中性的技术动作站在运维视角它是上线前必须做的一次自查站在安全视角它是资产暴露面梳理里的固定一环。我自己在不同项目里把这件事做过很多遍有几次是真的在自查中发现源站裸奔——CDN 挂在那儿真正的源站 443 端口直接开在公网上任何人绑个 Host 头就能直连。这篇就把这套东西完整拆一遍边缘节点 IP、回源 IP、源站 IP 到底差在哪信息从哪些缝隙里漏出去一套从低成本线索到高成本验证的漏斗怎么搭每一步具体敲什么命令、看什么结果、怎么判断你找到的 IP 是不是真源站最后再反过来讲防护侧该怎么做。内容适合有一定 Linux 和 DNS 基础的运维、安全、后端同学也适合刚接手一个站点、想搞清楚自己资产状况的朋友。所有操作请只在自己的资产或已获得书面授权的目标上执行这一点没有商量余地。1. 先把概念掰清楚CDN 真实 IP 到底指什么1.1 三个容易混的 IP边缘节点 IP、回源 IP、源站 IP很多人一上手就搞混把 ping 出来的 IP 当成CDN 的 IP把另一些 IP 当成真实 IP结果判断全错。先把三个东西分开名称是谁的地址谁在用它能不能公开边缘节点 IPCDN 厂商在全国各地机房的服务节点终端用户访问时解析到的就是这个本来就是公开的无所谓回源 IPCDN 节点回源站取内容时使用的出口地址CDN 节点到源站之间厂商通常公布网段用于源站白名单源站 IP你自己那台服务器 / 负载均衡 / 对象存储的公网地址只有 CDN 回源时才应该访问它必须藏死这是本次讨论的主角日常说的查 CDN 真实 IP严格讲就是找源站 IP。用户dig出来的那个地址是边缘节点你拿它去做任何事都没意义而 CDN 厂商公布的回源 IP 段是给源站做安全组白名单用的也不是秘密。真正需要关心的是有没有人能绕过 CDN直接怼到你的源站上。这里有个特别常见的误解有人觉得源站 IP 泄露了也没事我源站又不对外开放。但事实是CDN 要能回源源站就必然对公网可达至少对 CDN 的回源网段可达。而现实中大量源站图省事安全组直接开0.0.0.0/0等于门户大开只靠别人不知道我 IP这一层薄薄的屏障在撑着。这就是为什么源站 IP 一旦泄露风险会瞬间放大。还有一个细节值得说源站不一定是一台机器。负载均衡SLB、WAF、对象存储、容器网关都可能成为 CDN 回源的落点。你找到的那个 IP 到底是 SLB 的 VIP 还是真实 ECS 的公网 IP决定了后续判断的难度。先确认架构再谈 IP这个顺序不能反。1.2 为什么源站 IP 会露出来CDN 接入的三种典型姿势与泄露面源站 IP 泄露不是因为 CDN 本身有漏洞绝大多数情况下是接入姿势不干净。我见过的情况大致归三类。第一类是部分接入。主域名www走了 CDN但邮箱服务、测试环境、旧版接口、管理后台、静态资源独立域名全都没接。攻击面从来不是从主站破的是从那个被遗忘的test.xxx.com破的。这是最高频的泄露源没有之一。第二类是被动泄露。站本身接得挺干净但应用层往外吐信息错误页把服务器 IP 打出来、X-Forwarded-For没清理、邮件通知头里带着发信服务器地址、JS 里硬编码了接口 IP、公开仓库里提交过含 IP 的配置文件、SSL 证书在多台机器上复用。这些都不是配置没做完而是细节没擦干净。第三类是架构性泄露。比如源站同时承担其他对外服务、源站 IP 与其他业务共用、CDN 回源走的是明文 HTTP 能被中间环节看到、多级 CDN 嵌套导致某一级回源暴露。这类最难发现因为它不体现在某一条配置上而是体现在整体拓扑里。理解了这三类后面的排查思路就顺了先找没接入 CDN 的入口再找应用层吐出来的痕迹最后验证架构层面的连通性。这个顺序是从便宜到贵、从高概率到低概率效率最高。2. 整体排查思路从低成本线索到高成本验证的四层漏斗2.1 分层漏斗的设计逻辑我不建议一上来就扫全网 IP 段那样既慢又容易触发各种风控而且大概率扫不出东西。合理的做法是搭一个四层漏斗每一层都把候选集缩小第一层被动信息收集。不动目标一根手指头只看已经公开的信息DNS 解析链、历史解析记录、证书透明度日志、公开的代码仓库、搜索引擎缓存。这一层成本最低、风险为零能解决 60% 以上的场景。第二层半被动探测。在正常访问范围内做轻度探测枚举子域名、看 HTTP 响应头、看邮件头、看页面源码里的硬编码地址。这一层会对目标产生少量请求但都是普通 HTTP 请求和正常用户没区别。第三层主动验证。拿到候选 IP 列表后逐个做 Host 绑定、证书比对、端口探测确认它是不是真的在提供这个站点的内容。这一步会明确打到候选 IP 上必须确保在授权范围内。第四层交叉确认。用两个以上独立维度验证同一个 IP比如证书指纹 页面特征 特定路径响应排除共享 IP、负载均衡 VIP、已下线 IP 造成的误判。这个漏斗的核心逻辑是用信息换成本越靠前的层信息获取越便宜但覆盖面越窄越靠后的层结论越确定但代价越高。绝大多数项目在第一层和第二层就能得出结论第三层只是用来确认。2.2 单点验证与交叉确认的判据找到候选 IP 之后怎么判断它真的是源站而不是别的什么我一般看四个判据满足三个以上才敢下结论内容一致性用Host头绑定访问该 IP返回的页面内容和通过 CDN 访问的一致包括特定路径的响应、静态资源的 ETag、甚至 404 页面的样式。证书一致性该 IP 的 443 端口出示的证书其指纹或序列号与 CDN 上的一致同一张证书被复用到源站是极常见的现象。端口特征源站常常会多开一些 CDN 不需要的端口比如 SSH、数据库、管理后台、健康检查端口。这些端口在边缘节点上是不会开放的。响应头差异直连源站时通常看不到 CDN 注入的头部如缓存状态、节点标识反而可能看到源站自己的Server、X-Powered-By。反过来有几个典型的误判陷阱要提前避开多级 CDN 场景下你找到的可能是上一级 CDN 的回源节点云厂商共享 IP 场景下同一个 IP 上跑着别人的站负载均衡 VIP 后面挂了一堆后端你看到的页面可能是默认站点历史 IP 已经解绑早就不通。这些坑我在第 5 章会专门拆。3. 实操环节一DNS 与证书维度的信息收集3.1 解析链与历史解析记录怎么读先从最基础的解析看起。一个站接没接 CDN看 CNAME 链就八九不离十dig short www.example.com A dig short www.example.com CNAME dig noall answer www.example.com如果返回的 CNAME 指向某个 CDN 厂商的域名后缀那基本确认走了 CDN。更稳妥的是用trace看完整解析路径能看清是哪一级在做调度dig trace www.example.com | tail -n 30注意一个细节A 记录返回多个 IP 不代表没接 CDN。很多 CDN 会一次返回多个边缘节点地址用于负载。判断依据永远是是否解析到第三方节点域名而不是 IP 数量。真正有价值的是历史解析记录。很多站点是先裸奔、后上 CDN早期直接解析到源站 IP 的记录会留在历史数据库里。这类数据在若干公开的 DNS 历史查询平台、威胁情报平台、域名信息站点上都能查到输入主域名就能看时间线。这里的关键是看变更时间点如果某条 A 记录在上 CDN 前后突然消失那这个 IP 大概率就是当时的源站。这类平台通常有免费额度和付费额度之分。我的经验是免费额度足够做初步判断但数据延迟可能有几天到几周如果急需确认某个时间点的记录付费查询能拿到更完整的时间线。另外别只查主域名mail、ftp、api、admin、m这些前缀的历史记录往往更有料。提示历史记录里的 IP 一定要当成候选而不是结论。IP 会被回收、重新分配几年前解析到某 IP不代表现在还是它。所有候选都必须经过第三层验证。3.2 子域名是最大的泄露入口枚举与筛选我做过的大部分自查里源站都是从子域名漏出去的。原因很简单主站上线前会走流程、会做检查但一个三个月前临时开的测试域名、一个给第三方对接用的回调域名往往没人管。枚举方式上我会同时跑几条线证书透明度日志免费、覆盖广、几乎无遗漏、搜索引擎语法、公开的子域名字典爆破、以及从页面 JS 里提取出来的域名。用开源工具跑一遍基础枚举subfinder -d example.com -all -silent -o subs.txt cat subs.txt | sort -u | wc -l拿到列表之后关键是批量解析 过滤。把所有子域名解析结果拉出来然后把落在 CDN 厂商公布网段里的剔除掉剩下的就是疑似没接 CDN的while read -r d; do ip$(dig short $d A | tail -n 1) [ -n $ip ] echo $d $ip done subs.txt resolved.txt sort -k2 resolved.txt | uniq -f1 -c | sort -rn | head -20最后一行命令很有用按 IP 聚合统计看看哪些子域名落在同一个 IP 上。如果三五个子域名都指向同一个 IP而这个 IP 又不在 CDN 网段内那这个 IP 是源站的概率就非常高了。另一个高价值动作是查 MX 记录和 TXT 记录dig short example.com MX dig short example.com TXT邮件服务器通常不接 CDNMX 记录指向的 IP 可能就是同一台机器或同一个网段。SPF 记录里偶尔也会带出服务器 IP 段。3.3 证书透明度日志与证书指纹匹配证书透明度Certificate Transparency日志是公开的、不可篡改的、几乎不可能绕过的一类数据源。任何公开签发的证书都会被记录进去包括签发时间、域名列表SAN。它的价值有两层第一层找子域名。CT 日志里会记录证书包含的所有域名很多在别处查不到的域名就藏在这里curl -s https://crt.sh/?q%25.example.comoutputjson \ | jq -r .[].name_value \ | tr \n \n | sed s/\*\.//g | sort -u ct_subs.txt第二层做证书指纹匹配。这是我认为最靠谱的验证手段之一。逻辑很朴素如果源站和 CDN 用的是同一张证书大量项目为了省事就是这样那么找到持有相同证书指纹的 IP基本就等于找到了源站。先从 CDN 侧拿证书指纹echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2/dev/null \ | openssl x509 -noout -fingerprint -sha256 -serial -subject记下 SHA256 指纹和序列号然后对每个候选 IP 做同样的操作echo | openssl s_client -connect 203.0.113.10:443 -servername www.example.com 2/dev/null \ | openssl x509 -noout -fingerprint -sha256指纹一致那这个 IP 上跑的就是同一套证书。要注意证书是公开的别人也可能复用了同一个证书模板所以还不能单独下结论得配合内容一致性再确认一次。但在缩小范围这件事上它极其高效。4. 实操环节二协议与应用层的蛛丝马迹4.1 HTTP 响应头里不该出现的东西响应头是被动信息里最容易被忽略、又最容易出问题的地方。每次上线前我都会跑一遍这个检查curl -sI https://www.example.com | grep -iE server|via|x-cache|x-powered|x-forwarded|x-real-ip|cf-ray|x-ttl这里面要重点看几类Via和X-Cache出现说明确实经过了一层代理正常。但如果源站自己也带Via说明它上游还有代理拓扑比想象的复杂。X-Forwarded-For里如果出现了一个不是用户 IP 的地址那可能是源站上游的地址被透传出来了。有些配置不干净的站点这个头里能直接看到内网 IP 甚至公网源站 IP。X-Powered-By、Server暴露具体版本虽然不直接泄 IP但会告诉别人你的技术栈属于顺手擦干净的范畴。还有一种很隐蔽的情况错误页泄露。故意请求一个不存在的路径、一个超长参数、一个非法方法看返回的错误页有没有带出服务器地址、内网路径、框架版本。老牌的调试页面比如某些框架默认开启的调试入口、某些中间件的状态页更是重灾区直接就能看到服务器环境变量和网络配置。curl -s -o /dev/null -w %{http_code}\n https://www.example.com/__nonexistent_path_12345 curl -s -X OPTIONS https://www.example.com/ -i | head -20这里我要强调一句这些检查都是对自己站点的常规安全配置检查和正常的运维巡检没有区别不涉及任何越权动作。4.2 邮件相关记录与第三方服务回连这个思路知道的人不多但在实际自查里命中率不低。逻辑是站点的邮件服务通常和 Web 服务在同一套基础设施上而邮件的协议头是必须携带真实发信服务器信息的。注册一个账号、触发一封通知邮件、或者让系统发一封找回密码的邮件然后看邮件原始头里的Received字段。如果发信服务器就是源站那台机器那么Received里会带着它的地址。同样值得查的还有站点的 RSS、API 回调、Webhook 配置页——有些系统会把回连地址显示出来。第三方服务的对接配置——比如对象存储的回源地址、短信服务的回调地址、支付平台的异步通知地址。站点自己的robots.txt、sitemap.xml——偶尔会暴露没接入 CDN 的路径或子域。curl -s https://www.example.com/robots.txt curl -s https://www.example.com/sitemap.xml | head -40还有一类是客户端资源泄露。爬一遍页面上的 JS 文件搜一下里面有没有硬编码的 IP 或内部域名curl -s https://www.example.com/ | grep -oE src[^]\.js | head -20 # 逐个下载后搜索 grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} app.js | sort -u这一条在自查时经常有意外收获——前端为了绕过跨域往往把某个接口地址写死成 IP 或内部域名而这些地址通常没走 CDN。4.3 内容指纹匹配favicon hash 与页面特征当候选 IP 数量变多比如你怀疑源站在某个云厂商的某个网段里逐个手工验证不现实这时候需要内容指纹。最经典的是 favicon 的 hash 值——同一个站点的图标在源站和 CDN 上是同一个文件算出来的 hash 也一样。import base64, mmh3, requests def favicon_hash(url): r requests.get(url, timeout10, verifyFalse) # mmh3 的经典算法需要对 base64 结果按 76 字符换行处理 b64 base64.encodebytes(r.content) return mmh3.hash(b64) print(favicon_hash(https://www.example.com/favicon.ico))拿到这个 hash 之后就可以在各类空间测绘平台上按图标 hash 检索相同特征的资产把候选 IP 范围缩小到个位数。这个思路的原理是测绘平台对整个公网做过规模化扫描并且记录了每个 IP 的图标特征你用同样的算法算一遍就能反查回去。除了 favicon还可以用这些特征做指纹页面title的精确内容、某个静态资源的 MD5、某个特定接口的响应体结构、甚至 404 页面的字节长度。特征越独特误报越少。注意favicon hash 会被同一套模板部署的多个站点干扰也会被图标 CDN干扰。用它做初筛可以做定论不行一定要配合清单里的其他判据。5. 实操环节三验证与确认避开假源站5.1 用 Host 绑定与证书比对做确认拿到候选 IP 之后标准验证动作是绑定 Host 头访问模拟 CDN 回源的请求形态curl -k -I https://203.0.113.10/ -H Host: www.example.com curl -k -s https://203.0.113.10/ -H Host: www.example.com | head -20看什么看返回的状态码、看页面内容是否与正式访问一致、看响应头里有没有源站自己的特征。如果返回 200 且内容是正确页面这个 IP 基本确认在直接服务这个站点。再配合证书比对echo | openssl s_client -connect 203.0.113.10:443 -servername www.example.com 2/dev/null \ | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256-servername这个参数很关键它触发 SNI让服务器返回对应域名的证书。不加的话多站点服务器可能返回默认证书导致误判。最后做一次端口层面的观察nmap -Pn -p 22,80,443,3306,6379,8080,8443,9000 --open 203.0.113.10源站常常会多开一些 CDN 不需要的端口。这里我只列了常见端口的探测用途是评估暴露面——发现自己的源站把数据库端口开在公网上这本身就是一条必须立刻修掉的高危项。扫到之后不要尝试连接登录评估暴露面到此为止。5.2 端口与指纹的交叉验证脚本思路候选 IP 多的时候我会写个小脚本把上面几步串起来输出一张表一眼看出哪个最像源站import subprocess, json, ssl, socket def get_cert_fp(ip, sni, port443): ctx ssl.create_default_context() ctx.check_hostname False ctx.verify_mode ssl.CERT_NONE try: with socket.create_connection((ip, port), timeout5) as s: with ctx.wrap_socket(s, server_hostnamesni) as ss: der ss.getpeercert(binary_formTrue) import hashlib return hashlib.sha256(der).hexdigest() except Exception as e: return fERR:{type(e).__name__} def check_host(ip, domain): try: out subprocess.run( [curl, -k, -s, -o, /dev/null, -w, %{http_code}, fhttps://{ip}/, -H, fHost: {domain}, --max-time, 8], capture_outputTrue, textTrue, timeout10) return out.stdout.strip() except Exception: return ERR candidates [203.0.113.10, 203.0.113.11, 198.51.100.20] for ip in candidates: print(ip, check_host(ip, www.example.com), get_cert_fp(ip, www.example.com)[:16])输出结果里HTTP 200 证书指纹与 CDN 侧一致的那一行就是最可疑也最可能的答案。如果出现 200 但指纹不同那可能是同 IP 上的另一个站共享 IP需要用页面内容再确认。我一直觉得这套交叉验证比单看任何一个指标都靠谱。单看 IP 归属地会说这是某云厂商的地址但云厂商地址多了去了单看端口开放会说这个 IP 开了 443但公网上一半的 IP 都开 443。只有把内容、证书、端口三个维度叠在一起结论才立得住。6. 反过来看防护把源站藏住的六件事6.1 网络层只放行 CDN 回源地址讲完怎么查必须讲怎么防——因为这套排查的真正用途就是自查。防护的第一原则是默认拒绝源站的安全组、防火墙、ACL只放行 CDN 厂商公布的回源 IP 段其余全部拒绝。# 以 iptables 为例思路是先把默认策略收紧再放行回源网段 iptables -P INPUT DROP iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT for net in 198.51.100.0/24 203.0.113.0/24; do iptables -A INPUT -s $net -p tcp -m multiport --dports 80,443 -j ACCEPT done实际生产中更推荐用云平台的安全组来做因为 CDN 厂商的回源网段会更新用安全组配合定期同步脚本维护成本更低。这里有个关键细节回源网段一定要从厂商的官方渠道获取并且定期核对更新。网段变了没同步轻则回源失败站点挂掉重则为了恢复把安全组改成全放开前功尽弃。同时把不必要暴露的端口全关掉SSH 改成只允许跳板机访问、数据库只允许内网、管理后台加 IP 白名单或走独立通道。源站 IP 就算泄露了只要攻击面足够小风险也可控——这是纵深防御的意义所在。6.2 应用层回源鉴权与头部过滤网络层之外应用层还要再包一层。最实用的做法是回源鉴权CDN 回源时带一个约定的密钥头源站校验不通过的直接 403。这样即使有人知道 IP 并绑定了 Host没有密钥也拿不到内容。# 源站 Nginx 侧示例校验回源密钥 server { listen 443 ssl http2; server_name www.example.com; if ($http_x_origin_auth ! 这里放你的回源密钥) { return 403; } # 其余配置略 }几个配套动作一起做清理转发头。源站不要盲目信任X-Forwarded-For只信任来自 CDN 回源网段的请求同时确保源站自己往外返回的响应头里不包含任何内部地址。关闭调试与状态页。框架的 debug 模式、中间件的状态页、server-status、phpinfo之类生产环境一律关掉。统一错误页。自定义 404、500 页面不要用框架默认的详细报错。证书策略。如果条件允许源站用一张和 CDN 不同的证书或者用私有 CA这样证书指纹匹配这条路就走不通了攻击者的验证成本会上升。独立源站域名。给源站配一个不对外的内部域名CDN 回源走这个域名源站只响应这个 Host对外的域名在源站上直接返回 403。6.3 上线检查清单我把上面这些整理成一张清单每次新站点上线前过一遍十分钟能省掉后面一堆麻烦检查项合格标准常见错误子域名覆盖所有对外域名均已接入 CDN 或有独立防护测试、旧版、接口域名漏接源站安全组仅放行 CDN 回源网段图省事写0.0.0.0/0源站端口仅开 80/443其余关闭或白名单SSH、数据库端口对公网开放回源鉴权携带密钥头源站强校验只靠 Host 头判断响应头清理不泄露内部地址、版本信息X-Forwarded-For原样透传错误页自定义无堆栈与路径框架默认调试页证书策略源站与 CDN 证书不同或私有全站复用同一张证书历史解析老 IP 已解绑、旧记录不可用换 IP 后旧记录仍可解析这张表我贴在自己的文档里每次上线照着打勾。说实话绝大多数源站泄露事件出问题的都在这几行里。7. 常见问题与排查技巧实录7.1 常见问题速查表实际操作里踩过的坑不少整理成速查表遇到对不上的情况可以照着排现象可能原因排查动作找到的 IP 打开是别的站共享 IP / 默认站点加Host头再访问对比页面内容证书指纹一致但内容不对同证书模板复用于多个站点用页面特征、特定路径响应再确认历史解析记录里 IP 全部不通IP 被回收或已解绑拉长时间线看最近一次变更找到的 IP 是另一家 CDN 的节点多级 CDN 嵌套看 CNAME 链有几层逐层往回追子域名解析到内网地址内部 DNS 记录外泄检查 DNS 记录是否误配公网邮件头里的 IP 访问不到站点邮件服务独立部署单独评估该 IP 的暴露面扫描发现端口开放但无法访问有 WAF / ACL 前置检查是否有独立防护设备favicon hash 命中大量 IP用了公共模板或公共图标换成更独特的页面特征7.2 几个踩过的坑坑一把负载均衡 VIP 当成源站。有一次自查所有判据都指向一个 IP我差点就在报告里写了源站暴露。后来多看了一眼响应头发现后端返回的机器名一直在变才反应过来那是 SLB 的 VIP后面挂了多台机器。VIP 暴露和真实机器暴露风险等级不一样处理方式也不一样——VIP 至少还有一层转发真实机器可是直连。看响应头里有没有负载均衡的特征标识这个习惯我从此保留了下来。坑二忽略已经下线的候选。早期做这件事的时候我只看能不能连上连不上的直接排除。后来发现有些站点做了地域封禁或按时间限流某段时间连不上不代表它就不是源站。现在我的做法是多时点、多路径验证换不同的时间段、不同的请求方式HTTP 与 HTTPS、HEAD 与 GET、不同源端口把连不上的原因先排除掉再下不是源站的结论。坑三只查主域名不查资产。这个坑最贵。有个项目的源站防护做得非常好主域名层层加固结果在一个三年前注册、忘了删的旧域名上A 记录直指源站。所以现在我的自查清单第一条就是先把资产盘清楚所有域名、所有解析记录、所有证书、所有对外服务。资产不清楚后面所有加固都是在自己想象的范围里打转。坑四忘了 CDN 回源端口本身就是线索。很多站点为了图方便把 CDN 回源端口配成非标准的 8080、8443然后在源站上把这个端口开着。这个端口在边缘节点上是完全看不到的一旦有人扫到源站的这个端口等于直接确认。回源端口要么用标准端口加鉴权要么把非标端口也纳入白名单管理别让它成为独特指纹。坑五把多点 ping 结果不一致当成没接 CDN。有些 CDN 的调度策略比较保守同城多个节点返回同一个 IP看起来就像单点。判断接没接 CDN永远看 CNAME 和响应头里的代理特征别只看 ping。这一点在排查到底接没接的时候特别容易翻车。最后分享一个小习惯每次做完这类自查我会把所有验证过的候选 IP、验证时间、判据、结论记成一张表附在运维文档里。下次再查的时候第一件事就是拿新结果和上次对比——一旦某个 IP 重新出现在候选列表里说明某条防护链路松了这比从头查一遍快得多也更容易发现问题是在哪次变更之后出现的。