我做过一个挺“刺激”的实验给客户站点套上CDN之后我没有主动告诉客户源站IP让客户那边一位刚入职的安全工程师去“找”它。结果那位同学用了不到三个小时通过一条几年前的DNS解析记录把源站IP翻了出来然后直接在浏览器里访问顺利打开了源站页面。这个实验让我印象特别深——源站IP的隐藏根本不是“套上CDN就完事”这么简单它是一条完整的信息链管理问题。在明网也就是普通用户通过常规浏览器、常规搜索引擎能够直接访问的公开互联网上部署业务源站IP是最核心的资产信息之一。从技术分类上讲源站隐藏属于信息隐藏技术的一种具体应用我们要做的不是让服务器“不存在”而是让它在海量的公网资产里不可定位、不可区分。这篇报告我会把自己这些年做源站IP隐藏的排查思路、架构设计、细节操作和踩坑记录完整梳理一遍。无论你是刚开始建站还是正在给公司业务做安全加固这套方法都可以直接照着落地并且能反复用于自查。1. 源站IP暴露的本质一个信息链问题而非单点配置问题1.1 为什么攻击者非要拿到源站IP源站IP这个东西说白了一个字直。域名可以换CDN可以加WAF可以堆但只要攻击者手里握着源站IP他就可以绕过你放在前面的所有安全设备直接打你家服务器。打个比方你在商业街开店门口雇了保安CDN装了一堆摄像头WAF结果仓库后门地址写在快递单DNS历史记录、证书日志等上被有心人捡去了。人家根本不需要走正门直接从后门进去搬东西。Web业务的安全模型天然是分层防御的。边缘层CDN/WAF/高防负责流量清洗和规则拦截但真正的数据和应用都在源站。一旦源站IP暴露边缘层的防护就只剩“看戏”的份。尤其是DDoS攻击场景下攻击者发现目标有CDN防护后第一反应永远是绕过CDN打源站只要把流量直接打到源站IP上CDN的清洗能力就完全失效这就是典型的“绕过防护打源站”。源站隐藏技术之所以在明网安全里这么受重视就是因为它是这个绕过行为的“开关”。开关没合上前面堆再多防护都是给别人看的开关合上了攻击者只能在边缘层跟你缠斗而够不到你的心脏。1.2 我踩过和见过的几条典型泄露通路我把这些年实际遇到过、以及帮朋友排查过的泄露路径整理成一张表大家可以对照着自己查一遍泄露通道典型暴露形态危险等级历史DNS解析记录早期A记录快照、换CDN前的源站IP极高子域名解析记录老后台、测试站点直接A记录到源站高证书透明日志源站证书绑定了内部域名或直接含IP高邮件头Received字段暴露出口IP或同段邮件服务器IP中高错误页/默认站点直接IP访问命中业务内容中移动端App/服务端回调代码里硬编码IP、回调地址裸奔中代码仓库/文档nginx.conf、.env、部署文档泄露地址中高这里我要特别说明一下上面这些通道在自查场景下全都是“对自己资产做排查”的方法目的是发现风险而不是教人去攻击别人。做运维和安全的同学都应该养成这种“攻击者视角”的习惯但前提是只针对自己有权管理的系统。后面介绍的查询手段也一样请务必用在合法授权的资产上。2. 动手自查把自己想象成攻击者从五个方向锁定源站2.1 查DNS解析现状域名到底是CNAME还是A记录裸奔第一步永远是最基础的先看当前解析状态。dig yourdomain.com A dig yourdomain.com CNAME如果是用CDN且配置正确主域名通常是一条CNAME记录指向CDN分配的别名例如yourdomain.com.cdn.example.com或者A记录直接解析到CDN服务商的IP段。这里有个判断技巧拿A记录返回的IP去查归属whois或IP138等工具如果IP归属是“Cloudflare”“阿里云CDN”“腾讯云CDN”这类服务商说明域名已经套了CDN如果IP归属是“某某数据中心”“某某云服务器”并且和你服务器购买记录一致那基本就是裸奔状态第一步就被击穿了。自查这个环节应当把主域名、www、api、旧站、测试站全部查一遍只查一个主域名没有意义因为泄露往往发生在你没想到的子域上。2.2 翻查历史DNS记录最容易被翻出底牌的环节当前解析干净不等于历史干净。我自己排查时一定会去下面这些地方看历史快照SecurityTrails输入域名后点“History”可以查看历史A/AAAA/CNAME记录。ViewDNS.info同样提供DNS历史查询功能。威胁情报平台微步在线、奇安信情报中心等也能查到历史解析和情报关联。特别是运营了三五年以上的老站点很可能中间换过CDN、换过服务器甚至某段时间直接用IP访问这些都会在历史记录里留下痕迹。查到任何一条非CDN的A记录都要把对应IP记下来进入下一步确认。这里要说一个残酷的事实历史DNS记录是“删不掉”的。即使你现在把DNS全部改成CNAME第三方平台上的历史快照依然存在攻击者依然能查到。所以历史记录裸露的源站IP最彻底的处理方式是更换源站IP或调整源站部署位置而不是只改解析。2.3 证书透明日志源站证书的“公开账本”这个环节很多人会漏掉。SSL/TLS证书签发后会被提交到公共的Certificate Transparency日志任何人都能查询最常用的入口是crt.sh。curl -s https://crt.sh/?qyourdomain.comoutputjson | jq .返回结果里能看到历史所有证书的颁发时间、域名列表以及证书关联的IP信息。更有用的场景是如果你源站上曾经为某个内部域名比如origin.internal.example.com、server.old-domain.com签过证书攻击者就能顺着这些域名去关联源站IP。自查时重点看有没有“不该在日志里出现的内部域名、测试域名、老域名”。为什么证书日志能关联到IP因为CA签发证书时会记录申请者信息而很多服务器软件在申请证书时会把服务器IP作为验证信息之一同时crt.sh本身也会关联同一证书IP上的其他域名即“IP反查域名”。用它来排查经常能发现你想象不到的陈旧暴露点。2.4 子域名爆破把“漏网”的解析记录都揪出来主域名套了CDN、CNAME干干净净不代表子域名都干净。用子域名收集工具对自己域名做一轮枚举是必备动作。subfinder -d yourdomain.com -all -silent或者用Amass也可以。做这个操作的核心逻辑是很多站点的源站真实IP其实藏在api.、test.、old.、dev.、git.、crm.、admin2.这种子域名里。因为运维图省事给内部系统直接绑了A记录到源站IP或者干脆没有套CDN就暴露在公网上。这里要提醒一下不建议用过于激进的暴力字典去扫大量不存在的子域一方面容易触发云厂商的告警封禁另一方面也会给DNS服务器带来压力。更稳的做法是把公司CMDB里的资产表、历史域名清单、常用命名字典合并起来做一轮轻量级枚举然后逐条核对解析记录。2.5 邮件头发送测试很多站点的源站IP是它自己“寄”出去的如果这台服务器还承担邮件发送或接收功能那源站IP泄露几乎是必然的。找一个外部邮箱给这个域名随便发一封邮件然后查看邮件原文在Received字段里会看到发件服务器的IP和主机名。如果是自己网站通过SMTP发信去翻自己邮箱里收到的验证邮件原文同样能看出服务器出口IP。通过邮件头自查的时候有一个判断重点邮件服务器IP和Web源站IP到底是不是同一个或者是不是同一个C段。如果发现邮件服务和Web服务共用同一个IP或同段IP最好尽快把邮件服务拆到独立资源上或者使用第三方邮件服务。否则Web这边藏得再好邮件头也会把底牌亮出去攻击者顺着同一个C段继续扫端口很容易发现其他暴露服务。3. 三层隐藏架构落地解析层、接入层、源站层各管一件事完成自查后如果发现源站有泄露点下面这套“三层隐藏”架构是我目前认为最稳的落地方案。它不是某一项单独技术而是三个环节互相配合解析层负责“不让源站出现在DNS结果里”接入层负责“不让源站响应未知请求”源站层负责“即使IP暴露也打不进来”。3.1 解析层只允许CNAME不允许源站A记录出现在公网DNS第一层是域名解析层面的“言出必行”。标准做法是所有对外提供业务的域名、子域名统一解析到CDN或高防分配的CNAME地址。源站“回源域名”CDN回源时访问的域名可以是一个不对外解析的域名甚至可以不在公网DNS里配置只在CDN回源配置和源站本地hosts里使用。严禁在公网DNS上给源站创建指向真实IP的A记录尤其是不能把origin.、source.、web.这类名字的A记录暴露出去。关于回源方式我推荐使用“独立源站域名Host头校验”的模式而不是直接把源站IP填进CDN回源配置。原因很简单CDN回源配置里的IP一旦被填进去它就会出现在CDN控制台、API返回值、配置导出文件里成为新的泄露面。使用一个仅内网可解析的源站域名配合CDN的回源HOST攻击者从外部DNS层面很难关联到源站。3.2 接入层源站默认站点对所有未知请求一律“装死”接入层是指Nginx、Apache这类Web服务本身的处理逻辑。这里最容易犯的错是源站IP上部署了网站之后只配置了业务域名对应的server_name却没有配置默认站点导致用IP访问源站时请求直接命中了第一个server块返回了完整业务页面——这不就等于告诉扫描器“我就是源站”。正确做法是配置一个默认站点对所有没有带正确Host头的请求直接断掉连接或返回空响应。Nginx里我一般这么配server { listen 80 default_server; listen 443 ssl default_server; server_name _; # 返回444表示直接断开连接不返回任何内容 return 444; }关于为什么用444而不是403403会告诉扫描器“这个IP上有Web服务只是拒绝你”反而暴露了服务存在444直接断开连接扫描器看到的结果是“端口开着但不响应”更像一个被防火墙丢弃的普通主机。如果用的不是Nginx而是Apache原理一样配置default虚拟主机返回空状态即可。3.3 源站层防火墙只放行CDN回源IP段其他一律drop第三层也是最容易被忽略的一层源站主机防火墙和安全组。很多朋友套了CDN但源站的安全组规则依然对0.0.0.0/0放行80/443这等于CDN形同虚设。攻击者一旦拿到IP直接访问80端口照样能打开站点。合理的配置思路是80/443端口只对CDN回源IP段放行。各家CDN都有公开的回源IP段列表比如Cloudflare、阿里云CDN、腾讯云CDN的官方文档或API都会定期更新直接拉取后配置到云安全组或主机防火墙里。22等管理端口只对办公网或堡垒机IP放行绝对不对公网开放。如果必须在公网访问管理端用SSH密钥堡垒机双因子认证。数据库、Redis、消息队列等服务端口一律只监听内网IP或UNIX socket不绑定0.0.0.0。这里有个运维顺序的坑必须提醒先在CDN控制台完成域名接入、确认回源正常再收紧源站防火墙。因为如果先收紧防火墙CDN节点还没拿到IP段或配置还没生效回源会直接失败用户端看到502/504到时候排查起来会手忙脚乱。4. 指纹清理与主动探测对抗让源站在公网扫描中“泯然众人”有了三层结构攻击者已经很难从DNS侧找到源站了。但还有一类风险来自“主动测绘”——以Shodan、Censys、FOFA等为代表的互联网空间测绘系统会周期性扫描全网IP把响应特定指纹的资产全部标记出来。如果你源站的特征太明显就算藏在CDN后面扫描器扫到那个IP时依然能一眼认出它。4.1 识别指纹为什么那么关键互联网空间测绘的原理其实很朴素它扫描全网的IP和端口把返回的banner、响应头、HTML标题、证书信息记录下来建立索引。举个例子我用IP直接访问源站即使默认站点返回空白但如果响应头里带着Server: nginx/1.24.0并且SSL证书的Common Name写着业务域名测绘平台就足够把这条资产和你的业务关联起来。所以指纹清理要做的不是让服务器不响应而是让响应不带任何可以被关联的特征。具体包括隐藏或替换Server头、X-Powered-By等版本信息。所有错误页面404、403、500使用统一的自定义页面不带框架名称、版本号、路径信息。关闭目录浏览避免源站目录结构暴露。不让源站对外提供与业务无关的端口服务比如phpMyAdmin、Jenkins、Grafana等运维面板一律走内网。源站SSL证书的Common Name里不要出现业务主域名回源证书可以用自签证书或单独的内部证书只要CDN回源时能完成校验即可。Nginx里清理响应头的常见写法server_tokens off; add_header X-Frame-Options SAMEORIGIN;如果是OpenResty或者安装了ngx_headers_more模块的Nginx可以用more_clear_headers把上游返回的Server、X-Powered-By等字段彻底清掉社区版Nginx可以用proxy_hide_header在上游响应里逐字段隐藏。4.2 从访问控制层面杜绝“顺手牵羊”除了指纹还有一种泄露是“主动验证型”的。攻击者拿到疑似源站IP后会在浏览器里直接用https://IP访问或者在请求里带上业务域名Host头去访问IP。如果你的源站不校验Host头直接返回了业务内容那等于主动承认“我就是源站”。所以源站Nginx里的server_name匹配一定要严格。建议只允许回源配置里指定的那个源站域名或Host头访问业务server块其他一律落到default_server。还可以通过map变量做Host头校验map $host $is_valid_host { default 0; origin.internal.example.com 1; } server { listen 80; listen 443 ssl; if ($is_valid_host 0) { return 444; } # 正常业务配置... }这里要注意Nginx里if指令在location中是“邪恶的”所以上面这种判断最好放在server块或者通过map变量间接使用避免出现意料之外的行为。4.3 端口收敛减少暴露面等于减少指纹来源再提醒一次端口和服务面收敛。很多源站IP泄露并不是通过80/443被发现的而是通过22端口SSH、3306端口MySQL、6379端口Redis。这些端口即使做了访问控制只要对公网开放扫描器就能看到“端口开放状态”从而给这个IP打上“活跃服务器”的标签配合其他信息就能关联到业务。我的建议很简单所有非Web服务端口要么用防火墙白名单限制只能从内网或办公网访问要么直接不监听公网地址。特别是云服务器安全组入方向只保留80/443且只对CDN回源段放行以及必要的管理源IP其余全部drop。同时定期用FOFA、Shodan、Censys这类测绘平台查一下自己的IP段看看有没有意外暴露的服务端口算是反向自查的一个补充手段。5. 隐藏做不到100%边界、误区与纵深防御的正确看法到了这一节我想说几句大实话。源站IP隐藏虽然是明网安全里非常重要的一环但它不是银弹有它做不到的边界。理解这些边界反而能帮你设计出更务实的方案。5.1 哪些场景下源站IP必然暴露业务需要用户直连源站的长连接、WebSocket、非HTTP端口服务比如游戏服务器、音视频流媒体信令服务这类场景CDN覆盖不完全源站IP无可避免要暴露。存在“同IP旁站”的情况你的源站IP上还跑着其他业务或者同一台母机上有别的用户部署了服务测绘平台通过旁站关联一样能推理出来。内部威胁与供应链泄露CDN服务商内部人员、云厂商工单记录、合作开发人员手里的配置文件这些环节任意一个出问题源站IP都有可能流出去。全互联网的被动流量分析每个请求最终都会到达源站所在的IDC或云机房如果攻击者有能力在上游链路做流量透视单纯靠隐藏IP是藏不住的。不过这种级别的威胁已经不是大多数Web业务需要考虑的对抗对象了。正因为存在这些边界我在设计安全方案时从不把“隐藏源站IP”当成唯一防线。它更像是第一道低成本防线目标是挡住脚本小子、批量扫描器和大多数初级攻击者把攻击成本抬高到“不值得打”的程度。5.2 四个最常见的源站隐藏误区结合实际踩坑经验我总结了四个典型误区基本覆盖了我接手过的绝大多数问题案例误区一套了CDN就万事大吉源站安全组仍然对0.0.0.0/0放行80/443。这是最典型的问题正确做法是回源IP段白名单。误区二只给主域名套CDN子域名和老域名裸奔。很多公司主站防护得严严实实结果老站、测试站、营销落地页直接A记录到同一台源站服务器攻击者顺藤摸瓜就到了主机。误区三源站上同时运行Web服务和高风险运维服务比如Redis、Docker API、Kibana端口还对公网开放。这类服务一旦被直接访问轻则信息泄露重则被拿下整个服务器。误区四源站IP换过、域名改过之后不做历史清理。旧证书、旧DNS记录、旧CDN配置里的源站信息都会成为长久存在的泄露点。5.3 纵深防御的搭配思路当源站隐藏做到位之后再往下的安全投入应该放在这些方面流量层面继续用CDN加WAF做异常请求过滤监控是否有针对源站IP的高频探测和异常流量主机层面做基线加固、补丁管理、主机入侵检测、日志集中审计业务层面对API做鉴权、限流、参数校验对管理后台做双因子认证和操作审计。这里最实际的一个建议是建立一套“资产指纹台账”。把主域名、子域名、源站IP、回源域名、证书序列号、CDN厂商、防火墙策略全部登记成一张表每季度按本文第2章的方法跑一遍自查对比台账看有没有新增暴露面。很多泄露其实不是被什么高深攻击打出来的就是资产太多、时间太久没人记得哪个子域还连着源站。最后分享一个我的个人习惯安全自查我固定安排在季度末流程很简单——先查DNS现状和历史记录再拉一遍crt.sh的证书日志然后用subfinder轻量级枚举一遍子域最后给域名发一封测试邮件看邮件头有需要的话再用测绘平台查一遍自己的IP段。整个过程大概半天成本很低但每次都能发现一些“意外”。做源站IP隐藏这件事本质上就是一个持续管理信息暴露面的过程你没法让攻击者完全不存在但可以让你的资产在明网的嘈杂噪声里变得不那么显眼不那么容易被打中。有一次我甚至通过crt.sh发现公司一个三年前停用的测试域名证书里还带着源站IP而且这个IP上竟然还在跑生产数据库。如果不是那次例行检查及时发现后果真的不堪设想。希望这篇报告能帮你在面对CDN、源站、解析记录这些日常配置时多一分“攻击者视角”的警觉。毕竟安全这件事很多时候拼的不是谁的盾更厚而是谁的底牌藏得更深。