3.1 防火墙与边界防御

3.1 防火墙与边界防御

本节摘要：防火墙（Firewall）按预设规则控制网络流量的进出，是边界防御的基本器械；现代防火墙已从"按地址和端口放行"进化到"能理解应用层内容"的下一代形态。本节讲清防火墙的工作位置、规则逻辑、五代演进，以及它天生管不到的事情。承接第 2 章的攻击视角，本节开始逐件鉴定守方器械，通往 3.2 节的检测类装备。

最古老也最被误解的器械

防火墙是安全行业资格最老的产品品类，老到几乎每个机房都有一台，也老到积累了一堆误解。最常见的两个：一是"有防火墙就安全了"——防火墙只管它看得懂的流量，第 2 章的注入载荷走的是防火墙放行的 80 和 443 端口，门是开着的，坏货从门里正常寄进来；二是"防火墙是台盒子"——云时代它更像一组分布式的过滤策略，跟着工作负载走，物理形态反而模糊了。

鉴定它，先把它放回本职位置：防火墙是访问控制的网络层实现，它的语言是"五元组"（源地址、源端口、目的地址、目的端口、协议）加上越来越丰富的应用层上下文。凡是能用这套语言表达的策略，它管得了；表达不了的，再贵也管不了。

验明正身：规则是怎么工作的

防火墙的规则集按顺序匹配，命中即执行动作，走完全程没有命中就按默认策略。看一段典型的边界规则（示意语法）：

# 规则表自上而下匹配, 首条命中即生效
1. 允许  any  →  10.0.2.10:443   tcp   # 对外开放的 Web 服务
2. 允许  内网管理段 → 10.0.2.0/24:22  tcp   # SSH 仅限管理网段
3. 允许  10.0.2.10 → 10.0.3.5:3306  tcp   # Web 服务器可访问数据库
4. 拒绝  any  →  10.0.3.0/24     any   # 数据库网段其余访问全禁
5. 默认  拒绝所有未明确允许的流量            # 默认拒绝兜底
​

注意第 3 条和第 4 条的组合：不是"数据库不许访问"，而是"只有明确需要的访问被点名允许"。这就是 1.3 节讲过的默认拒绝原则在边界层的落地。还有一条新手最容易踩的坑：规则有顺序，如果把"拒绝所有"放在第一行，后面的允许全部作废；如果把宽泛的"允许内网全部"放在精细规则之前，精细规则永远没机会命中。规则表是要像代码一样做评审和测试的，改一条要看上下文。

验明正身：从包过滤到下一代

防火墙的进化史就是"看得懂的深度"的进化史。用 mermaid 把这条演进线画出来：

每一代解决上一代的一个盲区：包过滤不认识连接，攻击者伪造响应包就能骗过；状态检测记住了"这条连接是我放出去的那个请求的回应"，伪造包失效；应用网关能看协议内容但性能贵；下一代防火墙（NGFW）把应用识别（不看端口看行为——跑在 80 端口上的未必是网页）、用户身份、入侵防御特性整合进来；云原生形态则把策略从"绑在网线接口上"改成"跟着虚拟机与容器走"。

图 3-1 纵深防御中的防火墙部署位置

工程实践要点

DMZ 是防火墙思想的精髓。 图 3-1 中间那块蓝区值得多说一句：把必须对外的服务单独圈出来，让它天生就"预期失陷"——Web 服务器被打穿是概率问题，被打穿后能不能摸到内网数据库才是设计问题。内外两道防火墙把 DMZ 夹在中间，对内只放行点名服务。这套"预期失陷 + 限制后果"的思路，是整个纵深防御哲学的缩影，5.1 节讲安全域时还会扩展它。

规则审计要定期做。 防火墙策略的熵只增不减：临时开的口子没人关、离职管理员的老规则没人删。可行的做法是半年一次全量审计，用实际流量数据反问每条规则"过去九十天你拦过或放过谁"，零命中的规则进候选删除名单。

⚠️ 常见坑：把防火墙当杀毒用。有人指望边界设备拦下所有恶意内容——现代攻击的主信道是 HTTPS 加密流量，防火墙看不到内容（除非做解密代理，那又是性能与隐私的巨额代价）。拦内容是 3.2 节端点检测的主场，边界的主场是管连接。

💡 关键直觉：判断一个防火墙策略是否健康，就看它能不能用一句话回答"为什么这条规则存在"。答不出来的规则，要么是历史遗留，要么是某次救火的临时口子——两者都该被清掉。

鉴定结论

• 防火墙是网络层访问控制，规则顺序、默认拒绝、定期审计是使用它的三门基本功；
• 下一代防火墙的价值在应用识别与用户维度，但加密流量是它天然的手电筒盲区；
• 单台设备不值钱，DMZ 式的纵深结构才是防火墙思想的完整形态；
• 门管好了，接下来要解决"已经进来的怎么发现"——下一节鉴定 IDS、IPS 与 EDR。

附卷：一次策略评审的现场记录

把一份真实的评审记录（脱敏改写）摆上台面，看看评审者给每条规则写了什么判词：

规则: permit any any 443          判词: 太宽 —— 443 是端口, 不是授权;
                                       应限定到对外服务的 VIP 与网段
规则: permit 办公网 any any       判词: 危险 —— "办公网全放行"让内层策略
                                       形同虚设, 至少按目的端口细分
规则: deny any any log            判词: 方向对 —— 但日志没接 SIEM,
                                       拦了什么没人知道, 等于白拦
规则: permit 管理段 22            判词: 合格 —— 来源限定明确, 保留
规则: (无默认拒绝显式声明)        判词: 补上 —— 隐式默认拒绝要写成
                                       明规则, 让审计有落点
​

这份记录里最有价值的是第二条的判词。宽口径的"内网全放行"是历史欠账的典型形态：当年为了救一次割接开的口子，一开就是五年。评审的意义就是让每条规则重新回答"你为什么存在"（3.1 节正文的关键直觉在此落地）。

再补一个云时代的新问题：本地防火墙与云端安全组的策略漂移。同一个业务在虚拟机里有一份 iptables 规则、在云平台有一份安全组规则、在容器平台还有一份网络策略——三处各自维护、口径各异，漂移几乎必然发生。务实的治理办法是定一个"唯一真相源"：对外暴露的口径以云安全组为准并纳入版本管理，主机层防火墙只做纵深兜底，容器策略跟随应用清单自动生成。三处规则如果注定要并存，至少要让它们从同一份声明生成，而不是三拨人各写各的。

附卷二：云安全组与本地策略的职责切分

三层规则并存时的分工，用一张表钉死：

切分的原则是"外层管暴露、内层管兜底"：暴露口径只在云安全组一处定义，主机层不再重复定义暴露（否则漂移必然发生），应用层只保证自己不主动全零绑定。三层各自单调，策略熵就上不去。落地时最有效的一步是把云安全组定义成代码进版本库——评审、回滚、审计全部免费获得，3.1 节的"半年审计"也因此有了抓手。

最后附一条给交接场景的建议：接手别人维护的防火墙时，先导出全量规则跑一遍"零命中分析"再看拓扑——规则表是这太系统真实的"宪法"，比任何交接文档都诚实。读懂规则表里的历史层次（哪些是老架构遗留、哪些是救火产物、哪些是真正的设计），你就接住了前人的全部判断，也看清了他们欠下的债。