6-6 防火墙之后的缓冲地带 · 波仔的云计算课

📄 一句话概括

有些服务必须对外公开（网站、邮件网关），把它们放进内网等于把门开在客厅里。于是有了第三个位置——DMZ（非军事区）：一个夹在两墙之间的缓冲地带，专放必须对外的服务。而 DMZ 真正的功夫不在【放什么进去】，在 【DMZ 到内网那一格怎么开】 ——那一格开得越松，DMZ 就等于白设。

📝 本节和前面几节的关系

上一节讲的是【一道墙怎么工作】。这一节讲的是【墙和墙之间那块地方】——教材把它放在防火墙之后，正是因为只有先理解了墙的规则，才能理解为什么要两块墙夹一块空地。

它接着网络的虚拟化② SDN 那条线：那一节讲的是让网络规则可以由软件统一下发（不用一台台去配），这一节讲的 DMZ 规则表，恰好就是【网络规则】里最典型、也最该被集中管理的那一类。而这一节的结论（云里的边界不再由子网决定）和网络的虚拟化③ 扁平网络的思路是同一个。

一、必须对外的服务放哪

先看这个问题的两难：

放进内网：方便是方便，但它一旦被打穿，攻击者就已经站在内网里了——前面那一道墙等于绕过。
放在墙外：那它就没有任何保护——等于把它直接交给互联网。

DMZ 就是这两个选项之间的第三个位置：夹在【对外那一道墙】和【对内那一道墙】之间的一块地方。它的位置本身就说明了一切——离外面近（方便被访问）、离里面远（打穿了也进不去内网）。

二、动手 Demo：DMZ 的规则表

看到什么算成功：

==================================================================================================
【Demo 6】防火墙之后的缓冲地带：DMZ
==================================================================================================
  光有一道墙还不够。真正的问题是：那些【必须对外公开】的服务放哪？
  放进内网，等于把门开在客厅里；放在墙外，又没人保护它。
  于是就有了第三个位置——DMZ（非军事区），一个夹在两墙之间的缓冲地带。

  【一】Web 服务器放内网，还是放 DMZ

  做法                  被攻破后攻击者站在哪              内网还安全吗
  --------------------------------------------------------------------------------------------
  Web 服务器放内网      已经在内网里面了                  不安全，只剩一层墙
  Web 服务器放 DMZ      被隔离的中间地带                  相对安全，还要再翻一道墙

  【二】DMZ 的规则表：三个方向都按【默认拒绝】写

  方向                  允许什么                          其余一律
  --------------------------------------------------------------------------------------------
  外网 -> DMZ           443，且只能到 Web 服务器          拒绝
  DMZ -> 内网           数据库端口，且只许指定源 IP       拒绝
  内网 -> DMZ           只留管理通道                      拒绝

  【三】DMZ 真正的功夫在【DMZ 到内网那一格】

    必须开的口子：Web 服务器 -> 数据库。但要把源 IP、目的 IP、端口都写死。
    剩下的一律堵死——这样即使 DMZ 里的一台机器被打穿，
    攻击者也只是站在缓冲地带里，走不进内网。
    最容易犯的错：DMZ 到内网写成【任意 -> 任意 -> 允许】，等于白设一个 DMZ。

  【四】云上还要不要 DMZ（2026 的答案）

    传统：两块防火墙夹一个子网，这是经典做法，今天仍然成立。
    云上：用 VPC + 安全组 + 网络 ACL，把【对外的子网】与【放数据的子网】分开。
    容器：Kubernetes 的网络策略接替了防火墙的这一层职责。
    但要注意一件事——云里【子网本身不是安全边界】：
    同一个子网里两台虚拟机可以被完全隔离，不同子网的两台也可能互相通。
    真正执行规则的是每个网卡上的防火墙规则，不是子网这块划分。
    所以把传统 DMZ 原样搬到云上，是很多团队踩的第一个坑。

读结果：

第一张表说的是【位置的差别，不是配置的差别】。同样是那台 Web 服务器，放内网还是放 DMZ，代码一个字都不用改——变的只是它站在哪一块地方。这就是 DMZ 便宜的地方：它防的是【一次失守之后能走多远】，而不是【第一次能不能进得来】。 而这一条恰恰是纵深防御最看重的东西。
第二张表里最值得注意的是【三个方向都按默认拒绝写】。很多人只想到【外网进不来】，但真实的设计里三个方向都要写规则：外网→DMZ（谁能访问你）、DMZ→内网（你能访问谁）、内网→DMZ（谁能管你）。而三条里最容易出事的，是第二条——因为业务上确实需要 Web 服务器访问数据库，这个口子非开不可。
第三段就是本节的结论句：DMZ 的成败不在【第一道墙】，在【第二道墙】。 第一道墙挡住的是陌生人，第二道墙挡住的是已经被攻破的那台机器。所以【DMZ 到内网】这条规则越具体（写死源、目的、端口）就越值钱——而写成 任意 -> 任意 -> 允许 就等于把两道墙之间的那块空地直接填平了。

三、DMZ 到内网那一格决定成败

这一段值得再展开，因为它解释了一个常见的困惑：为什么很多公司【有 DMZ】，但还是被一次 Web 漏洞带走。

原因通常是这三个：

常见错法	后果
DMZ 到内网写成【任意 -> 任意】	等于没有第二道墙
数据库直接放在 DMZ 里	数据库被打穿，数据当场泄露
管理通道和业务通道共用一条	攻击者从业务漏洞跳进管理面

一条通用的判据：问自己【从 DMZ 里任何一台机器出发，能碰到哪些东西】 ——如果它碰得到的东西比【它这个业务真正需要的】多，那份多出来的部分就是攻击者失守后能拿到的部分。

另一条：管理通道必须单独走（这也是本节 Demo 第二张表里【内网 -> DMZ 只留管理通道】那一行的用意）——因为管理面通常权限更大，一旦和业务面共享一条路径，攻破一个业务就顺路摸到了管理入口。

四、云上还要不要 DMZ

这是本节最容易被两边都说错的地方，所以 Demo 把它单列了。正确的答案是分三层看：

传统做法仍然成立：两块防火墙夹一个子网，这是经典设计，放在自己的机房里一点没过时。
云上换的是【工具】，不是【思路】：云里没有物理防火墙盒子，对应的是 VPC + 安全组 + 网络 ACL，把【对外的子网】和【放数据的子网】分开——这就是云版的 DMZ。思路是【隔离公开服务与敏感后端】，这个目标没变。
但有一个关键差异要注意：在云里，子网本身不是安全边界。 云的网络是虚拟的——同一个子网里的两台机器可以被完全隔离，不同子网的两台反而可能互通。真正执行规则的地方是每台机器网卡上的防火墙规则，不是【它属于哪个子网】这件事。所以把传统 DMZ 原样搬过来（以为【放进那个子网就安全了】），是很多团队在云上踩的第一个坑。
容器环境里，这个职责由 Kubernetes 的网络策略接替——它的粒度比子网细得多，可以做到【哪个服务能访问哪个服务】。

合起来看：DMZ 这个【夹在两墙之间】的思路一直有效，变的是——它从【一块物理区域】变成了【一组规则】。

30 秒实验

打开任意一家云服务商的【VPC / 网络】文档页，做两件事：

找【子网】和【安全组】这两个概念的定义（几乎所有厂商都有这两样）。
看看官方文档里对【安全组】的默认设置是怎么描述的——是【默认全通】还是【默认全拒】？

做完你会发现一个关键细节：各家云的安全组默认都是【入站全拒、出站全通】。 也就是说——云已经帮你把【默认拒绝】这条原则设好了，你要做的就是【按需开口子】。 但很多人不知道这个默认值，于是为了【让它先跑起来】把入站设成了 0.0.0.0/0——这一下就把本节讲的所有隔离全都作废了。 这也是【存储在公网的云事故】里占比最高的一类原因。

常见误区

错误：有了 DMZ，对内网就安全了。——纠正：DMZ 只解决【一次失守之后能走多远】，不解决【会不会失守】。它让攻击者停在缓冲地带，但前提是【DMZ 到内网那一格】确实收紧了。如果那一格写成【任意 -> 任意 -> 允许】——那 DMZ 就只是一块名字好听的空地。所以判断一个 DMZ 有没有用，不看它有没有画出来，看它的第二道墙写了什么规则。
错误：DMZ 里的服务器可以随便配置，反正它迟早会被攻破。——纠正：DMZ 里的机器应该是最【素】的，不是最随便的。原因是它离外面最近、被打的概率最高，所以它的处理原则是最小化：只装必要的软件、只开必要的端口、不放任何敏感数据、不许它主动往互联网发起连接（后面这条尤其常被忽略——被攻破的 DMZ 机器如果还能往外连，攻击者就能把它当跳板回传数据）。DMZ 的思路是【准备它被打穿】，而不是【指望它不被打穿】。
错误：DMZ 里的服务器必须能访问数据库，所以这条口子只能放开。——纠正：口子必须开，但【放开】和【写清楚】是两件事。正确写法是把源地址、目的地址、端口三样都写死（只能这一台 Web 服务器、只能连那一台数据库、只能走那一个端口）。这样即使 DMZ 里别的机器被打穿，它也用不上这条规则。差别就在这：写成【这台 -> 那台 -> 3306】，攻击者拿到它也只能连数据库；写成【任意 -> 任意】，攻击者拿到它就能扫遍内网。
错误：云上的子网就相当于 DMZ。——纠正：不是。 传统 DMZ 之所以有效，是因为它是一块【真的被两块墙夹住的物理区域】；而云里的子网只是一个地址段划分，不是安全边界（本节 Demo 第四段就是这个意思）。在云里，隔离效果来自【每张网卡上的安全组规则】，不是来自【它属于哪个子网】。 所以云上的正确做法是按【用途】给不同机器套不同的安全组——而不是【把它们放进一个叫 DMZ 的子网就不管了】。

自测三问（点开对答案）

1. 为什么【必须对外公开的服务】不能直接放进内网？ —— 因为**它一旦被打穿，攻击者的位置就是答案**。放进内网，**攻击者攻破它之后，人已经站在内网里了**——前面那道防火墙对他来说等于不存在，**他接下来只需要在内网里横向找目标**（这正是 6-3 讲的攻击链第 4 步）。而放进 DMZ，**他攻破之后站的地方是一个【和两边都有墙隔着】的区域**——**要碰到内网，还得再过一道墙**。所以这个设计的价值不在【让他进不来】，而在【让他进来之后还得再翻一次墙】。 2. 为什么说 DMZ 的成败在【第二道墙】？ —— 因为**第一道墙挡的是【外部的陌生人】，第二道墙挡的是【刚刚被打穿的那台自己人】**。而现实中的绝大多数入侵，**都是先攻破一个对外服务（第一道墙被绕过的形式），再往内走**——也就是说，**真正被反复考验的是第二道墙**。所以设计 DMZ 时最该花心思的地方，**不是【外网能访问什么】，而是【DMZ 里的机器能访问什么】**。这也是本节那句总结的由来：**第二道墙开得越松，DMZ 就越等于白设。** 3. 为什么说【云里的子网不是安全边界】？ —— 因为**云的网络是虚拟出来的，子网只是一个地址段的记号**。在物理世界里，两块区域之间要靠防火墙设备隔开，**所以【在哪个区域】本身就意味着【隔着什么】**；而在云里，**规则是由每张网卡上的安全组来执行的**——**同一个子网里的两台机器可以各套一套完全不同的规则（互相不通），不同子网的两台机器也可以因为规则允许而互通**。所以【把机器放进哪个子网】这件事本身不提供任何隔离效果，**真正起作用的是【给它套了什么规则】**。把传统 DMZ【原样搬过来】，就是把【区域】当成了【规则】，这是云上最典型的一个误判。

☐ 下一节（6-7 缓冲地带的入口：入侵检测系统 / 入侵防御系统）