企业官网建设流程全解析

我做过一个挺“刺激”的实验：给客户站点套上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 我踩过和见过的几条典型泄露通路

我把这些年实际遇到过、以及帮朋友排查过的泄露路径整理成一张表，大家可以对照着自己查一遍：

这里我要特别说明一下：上面这些通道，在自查场景下全都是“对自己资产做排查”的方法，目的是发现风险，而不是教人去攻击别人。做运维和安全的同学都应该养成这种“攻击者视角”的习惯，但前提是只针对自己有权管理的系统。后面介绍的查询手段也一样，请务必用在合法授权的资产上。

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/?q=yourdomain.com&output=json" | 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而不是403：403会告诉扫描器“这个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、源站、解析记录这些日常配置时，多一分“攻击者视角”的警觉。毕竟，安全这件事，很多时候拼的不是谁的盾更厚，而是谁的底牌藏得更深。