Defaults.Exposed › 修复 › CDN / WAF 与主机

如何修复 CDN / WAF 与主机

对你网站背后管线的两次解读：你是否坐落在一面防护盾后面（一个带 Web 应用防火墙的 CDN，如 Cloudflare），它过滤攻击、吸收流量高峰；以及一张地图，说明到底是谁在运行你的 DNS、网站和邮箱。两者在我们的评分中都属于提示性——它们不动你的评分——但它们描述了你的源站服务器对攻击和宕机有多暴露，以及你的提供商有多盘根错节。前面有一面盾、再加上一组合理拆分的提供商，正是有韧性的企业该有的样子。

对您业务的关键影响： 一个前面没有防护盾的网站，会把每一次攻击、每一次流量高峰直接接在源站服务器上——所以一次机器人洪流、一次上线日激增，或单单一次自动化攻击，就能让你下线好几个小时，而恢复全靠你自己。在前面放一个 CDN/WAF（有免费档）能过滤掉绝大多数自动化攻击、吸收激增，并让网站在全球更快——对你的 IT 人员来说通常是一下午的活，且无许可费用。另外，如果你的 DNS、网站和邮箱全都在一家提供商那里，那里的一次宕机或攻破就会把你整个在线存在一次带下线；在一起事件中，知道你的提供商地图是你首先需要的东西。这两项检查都不改变你的评分——但两者都描述了对停机、销售损失和缓慢痛苦恢复的真实暴露。

这会让您付出什么代价

• 一场大促销的早晨，一阵机器人流量或一次小型 DDoS 打中你没有防护的服务器——网站变得爬行或直接倒下，客户在结账处看到错误，你在主机手忙脚乱时损失了一整天的销售。前面有一个 CDN/WAF 本会吸收掉它。
• 你的 DNS、网站和邮箱全都经过一家提供商；那家提供商宕机，于是你的网站、你的预订系统和你的邮箱在同一刻一起变黑——你甚至发不出我们已知悉问题，因为邮箱也宕了。
• 一次自动化攻击整夜探测你的网站——SQL 注入和登录爆破脚本直接捶打你的源站，因为没有防火墙层去过滤它们——而你直到有东西坏了才知道。一个 WAF 会在那些噪声到达你的代码之前就挡掉其中大部分。
• 一起事件来袭，却没人能回答一个基本问题：我们到底该打给谁？网站和邮箱在同一台主机上吗？谁运行 DNS？光是把管线理出来就耗掉好几个小时，而网站还在宕着。
• 潜在客户的 IT 团队在签约前扫描你，看到一台没有 CDN/WAF 的裸源站，外加一个泄露信息的服务器版本响应头，明明白白地宣告你跑的是什么软件（和版本）——在最糟糕的时刻给出一个这些人连基础都没加固的小信号。

为什么它重要。 本页两项检查在我们的方法学里都属于提示性——它们登记为零分，永远不改变你的评分——因为它们描述的是你的基础设施，而非测试一个通过/失败的安全控制。我们把它们呈现出来，是因为它们映射真实的业务暴露。一个没有 CDN/WAF 的网站，把每一次攻击和流量高峰直接接在源站上，没有过滤、没有激增吸收；加上一个（Cloudflare 的免费档是常规路子）是一家小企业能做的杠杆最高、成本最低的韧性升级之一。而一张清晰的提供商地图——知道你的 DNS、网站和邮箱是拆分还是堆叠在一家提供商上——是出了状况时你首先需要的东西，也是一起被控制住的事件和一次彻底停摆之间的区别。

一句话说清这是什么

每个网站都跑在某处的一台服务器上。本页回答的问题是：在开放的互联网和那台服务器之间站着什么——以及到底是谁在运行你在线存在的各个部件？

有两个部分：

1. **CDN / WAF——前面的盾。**CDN（内容分发网络）是一个坐落在你网站前面的全球网络，把你的内容快速送给任何地方的访客，并吸收流量激增。WAF（Web 应用防火墙）是一个过滤器，检查进入的请求，在它们到达你服务器之前挡掉恶意的。流行的服务（Cloudflare、AWS CloudFront、Fastly、Akamai、Sucuri 等）把这些捆在一起。我们查看你网站的响应，报告能否看到前面有一面盾——并且也记下你跑的是什么 Web 服务器。

2. 主机 / 提供商地图——谁在运行你的管线。我们读取那些说明谁处理你 DNS（把你的域名变成地址的目录）、谁处理你邮箱的公开记录。由此我们能判断你的 DNS、网站和邮箱是拆分在多个提供商上（有韧性），还是堆叠在一家上（便利，但是一个单点故障）。

**最重要的一点要先说清：**在我们的评分中，**这两项都属于提示性。**它们不影响你的评分。我们把它们呈现出来，是因为它们描述了你的业务对停机和攻击有多暴露——这是一个不同于评分、且非常实际的问题。

这会让你付出什么代价

这些不是抽象的风险——它们是一个没有防护、盘根错节的配置把小问题变成糟糕一天的日常方式。

• **在最要紧的那天被打下线。**你的网站坐落在源站服务器上，前面什么都没有。在一次上线或促销的早晨，流量激增——或一阵不大的机器人洪流来袭——服务器应付不来。页面超时，结账出错，你在主机救火时损失了一整天的营收。一个 CDN 吸收激增、一个 WAF 过滤垃圾流量；两者合起来，就是忙碌的一天和宕了一上午之间的区别。

• **一切同时变黑。**你的 DNS、网站和邮箱全都经过一家提供商。那家提供商宕机（所有提供商最终都会遇到），于是你的网站、你的预订系统和你的邮箱同时消失。你既处理不了订单，也连给客户发封我们已知悉的邮件都做不到——因为邮箱也宕了。拆分提供商意味着一次故障是被控制住的，而非彻底的。

• **你的代码直接挨每一次攻击。**没有 WAF，每一次自动化探测——注入尝试、登录爆破、已知漏洞扫描器——都不经过滤地打中你的应用代码。你是在赌你的软件永远完美无瑕、补丁齐全。一个 WAF 会在那些自动化噪声到达你之前挡掉其中绝大多数，把持续的背景攻击变成大体被过滤。

• **因为没人有那张地图而缓慢、惊慌的事件处置。**有东西坏了，而第一个小时浪费在等等，谁运行我们的 DNS？邮箱和网站在同一台主机上吗？该打给谁？上。当你的提供商地图不清楚时，每一起事件都从零开始。事先知道这张地图，就把一场慌乱变成一通电话。

• **给谨慎买家的糟糕第一印象。**潜在客户的 IT 团队在签约前扫描你，看到一台没有 CDN/WAF 的裸源站——外加一个公然宣告你确切软件和版本的服务器响应头。这是一个小信号，但它在恰好错误的时刻把你放进了连基础都没加固那一栏。

它实际上是什么

CDN / WAF——那一层防护

当一位访客（或一名攻击者）请求你的网站时，请求要么直接去你的源站服务器，要么先经过一个 CDN/WAF。如果前面有一面盾，那面盾可以：

• **过滤恶意请求（WAF 那部分）：**在注入尝试、机器人攻击和已知漏洞利用模式到达你代码之前挡掉它们。
• **吸收流量（CDN 那部分）：**从离每位访客近的服务器提供缓存内容，并吸收激增，使一次高峰——无论正当还是敌意——都不压垮你的源站。
• **让网站更快：**从邻近的边缘服务器送达的内容，对全球访客加载更快。

我们通过查看这些服务在你网站响应头里留下的指纹来检测一面盾——例如 cf-ray 响应头（Cloudflare）、x-amz-cf-id（Amazon CloudFront）、x-served-by（Fastly）、x-akamai-transformed（Akamai）或 x-sucuri-id（Sucuri）。我们也读取 Server 响应头来识别你底层的 Web 服务器（nginx、Apache、IIS、LiteSpeed、Caddy 等），并标记任何过度分享的 X-Powered-By 响应头。

良好的状态长什么样：在你源站前面检测到一个 CDN/WAF，并且一个不宣告具体版本号的 Server 响应头。

主机 / 提供商地图——你的基础设施依赖

你的域名悄悄指向好几个不同的服务：

• DNS——把 yourbusiness.com 变成实际服务器地址的目录。我们读取你的域名服务器（NS）记录，并识别常见提供商（Cloudflare、AWS Route 53、Azure DNS、GoDaddy、Namecheap、DigitalOcean、Hetzner、Linode，以及各地区注册商等）。
• 邮箱——你的邮件在哪里处理。我们读取你的 MX 记录，并识别常见提供商（Google Workspace、Microsoft 365、Proofpoint、Mimecast、Barracuda、Zoho 等）。

由此我们能看出这些职责是拆分在多个提供商上（一处故障不会拖垮其他），还是堆叠在单一提供商上（便利，但一次宕机或攻破就带走一切）。

**良好的状态长什么样：**至少，DNS 由一个专门、可靠的提供商持有，而不是和其余一切捆在同一个账户里——这样你域名的目录就不和你的网站及收件箱同命运。

如何修复（免费，约一下午）

**把这交给你的 IT 人员或网页开发人员——修复是免费的。**在常见的免费档上，把一个 CDN/WAF 放到你网站前面不花一分钱，而隐藏你的服务器版本是一行设置。没有许可要买。（这里的付费选项只有监控、组合追踪和审计——绝不是修复本身。）业主唯一的决定是：对，在网站前面放一面盾。

因为两项检查都是提示性的，这里没有一样是计分的——但一个 CDN/WAF 是一家小企业能做的最有价值的韧性升级之一，所以值得做。

1. 在你网站前面放一个 CDN/WAF

最常见、免费的路子是 Cloudflare：

1. 创建一个免费的 Cloudflare 账户并添加你的域名。
2. Cloudflare 读取你现有的 DNS 记录；检查它们是否正确导入。
3. 把你域名的域名服务器（在你的注册商处）改成 Cloudflare 给你的那两个。这就是把流量路由经过 Cloudflare 的开关。
4. 把 SSL/TLS 模式设为 Full（strict），使加密在访客 → Cloudflare → 你的源站之间保持端到端。（避免 Flexible，它让最后一段不加密。）
5. CDN 和一个基线 WAF 现在已激活。你之后可以调整 WAF 规则，但默认值已经过滤了不少。

其他路子，取决于你的技术栈：

• AWS CloudFront——创建一个指向你源站的分发；搭配 AWS WAF 做过滤。如果你已经在 AWS 上，这最合适。
• Sucuri WAF——基于 DNS，无需在你服务器上做任何改动；如果你不能动源站，它不错。
• Fastly / Akamai——企业级的 CDN/WAF，通常用于较大或较高流量的网站。

切换后，测试网站，确认 HTTPS 处处可用，并观察一天。不要过度缓存那些必须保持个性化或实时的页面（已登录区域、购物篮、结账）。

2. 停止宣告你的服务器版本

无论你加不加 CDN，都把你服务器宣告的版本隐藏起来——那是你白白递给攻击者的信息。

Nginx：

server_tokens off;

Apache（在主配置里）：

ServerTokens Prod
ServerSignature Off

移除一个过度分享的 X-Powered-By 响应头（例如来自 PHP 或某个应用框架），在服务器或 CDN 层面——在 Cloudflare 上你可以用一条响应头转换规则把它剥掉。

3. 核对一下你的提供商地图（可选，约 10 分钟）

看看你的 DNS、网站和邮箱实际活在哪里：

• 如果三者都在一个提供商账户里，考虑至少把 DNS 迁到一个专门的提供商（Cloudflare DNS 免费且快）。单单这一处拆分，就意味着你域名的目录能在一次主机宕机中存活下来。
• 把地图写下来——DNS 提供商、Web 主机、邮箱提供商、注册商，以及每一个的登录/支持联系人。这一页纸，是一起事件中你面前最有用的东西。

平台说明

• Google Workspace / Microsoft 365：这些是你的邮箱提供商，不是你的网站。在网站前面放一个 CDN/WAF 不触碰邮箱，反之亦然——它们是各自独立的决定。（邮箱在 Google/Microsoft、网站在 Cloudflare 后面，是一个完全不错、刻意拆分的配置。）
• **托管建站平台（Wix、Squarespace、Shopify）：**这些把自己的 CDN 和一定程度的 WAF 防护作为平台的一部分，所以即便我们的响应头检查没点出一个提供商，你也可能已经被防护。你通常不能在前面加自己的 Cloudflare；那也没关系——平台替你处理了。
• **自有主机上的 WordPress：**前面加一层免费 Cloudflare 的理想候选。把它和一个安全插件的防火墙结合，做应用层规则。

常见错误

• **因为网站小就跑一台裸源站。**小网站和大网站一样会挨同样的自动化攻击和机器人洪流——机器人不会先查你的营收。免费的 CDN/WAF 档正是为小网站而存在的；不用它就是把一个简单的胜果留在桌上。
• **用 Cloudflare 的 Flexible SSL。**它显示一把小锁，却让 Cloudflare 和你源站之间的连接不加密。永远用 Full（strict），使它端到端加密。
• **缓存错误的东西。**过度缓存已登录页面、购物篮或结账，可能把一个客户的内容或过时价格显示给另一个客户。缓存静态内容；让个性化和交易页面不缓存。
• **没意识到就把一切堆叠在一家提供商上。**便利没问题，前提是它是一个自觉的选择——但许多企业是在那次把三者一起带下线的宕机中，才发现 DNS、网站和邮箱共用一个账户。让它成为一个决定，而非一个发现。
• **把服务器版本留在显眼处。**这是一个免费、一行、容易被忘的加固步骤。把它关掉。

关于评分的说明

把话说得彻底明白：**这两项检查都不影响你的评分。**它们在我们的方法学里登记为提示性、零分，我们绝不会因为一个没防护的源站或一个单一提供商配置而罚你。我们报告它们，是因为它们描述了对停机、攻击和缓慢事件恢复的真实暴露——也因为加一个免费的 CDN/WAF 是一家小企业能做的最有价值的升级之一。如果你在这里什么都不做，你的评分不变。如果你在网站前面放一面盾、并把 DNS 拆分出去，你就免费让业务变得明显更有韧性。这才是看待本页的正确方式：不是一个要去守的数字，而是一次值得拿下的韧性升级。

常见问题