下一代防火墙通用原理

一、防火墙技术发展历程

七、总结对比表（面试或IA阶段理解用）

代数	名称	检查深度	状态?	应用识别?	性能	典型缺陷
1	包过滤	网络/传输层头部	无	无	高	无状态，易欺骗
2	状态检测	网络/传输层+连接表	有	无	高	不检查内容
3	应用代理	应用层	有（连接级）	需单独代理	低	慢、协议少
4	UTM	多引擎串行	有	部分	中（全开后低）	性能瓶颈，模块孤立
5	NGFW	一体化单通道	有	有（App-ID）	高	成本高，SSL解密复杂

1.1 包过滤

纯包过滤防火墙不仅还在用，而且用得还非常普遍 ，但通常不再作为唯一的防护手段，而是作为一种基础且高效的底层技术，存在于各类安全产品中。

以它的速度和效率优势，现在更多地出现在这些场景里：

核心网络设备的内置功能：它的核心技术（ACL）已成为几乎所有路由器、交换机的标配功能，用来在骨干链路快速过滤流量。

个人与边缘系统防护 ：我们日常接触的系统也广泛使用它，例如 Linux 系统的 iptables/nftables 或 Windows 自带的防火墙。

高速防护的"第一道闸门"：在不影响核心应用性能的前提下，专门用它迅速过滤掉海量的恶意扫描和DDoS攻击流量，再交由后方更强大的安全设备处理。

云环境和物联网设备：在云网络中提供基础的网络隔离，或用于低成本的物联网设备，限制其仅与特定服务器通信。

工控系统的特种环境：作为基础防护，定制化的工控防火墙可结合包过滤和深度解析，精准识别控制指令，保护关键生产系统。

防火墙即服务（FWaaS）的核心组件：FWaaS 虽然主打下一代防火墙（NGFW）功能，但其数据包过滤、网络监控等核心能力，本质上仍是包过滤技术的延伸。

核心局限：为何不能单靠它？

尽管应用广泛，但必须明白它的硬伤，这也正是更先进技术要解决的问题：

无法识别内容：这是最致命的缺陷。它只看"信封"，不看"信的内容"，无法阻止藏在合法数据中的恶意行为（如SQL注入、木马传输）。

安全性较弱 ：它不维护连接状态（Stateless），容易受到IP地址欺骗，且缺乏用户认证机制，也无法有效防御DDoS攻击。

管理复杂：在大型网络里，管理大量复杂规则集（ACL）的配置和排序极其容易出错。

防护片面：只做"允许/拒绝"决策，无法提供入侵防御（IPS）、防病毒（AV）等更高级的深度防护功能。

1.2 应用代理

SSLVPN

为什么应用代理防火墙没有成为主流？？？

为什么应用代理会出现？解决什么问题？

历史背景：

1980年代末，网络攻击开始从网络层向应用层迁移（如第一个蠕虫病毒 Morris Worm 1988年）。
包过滤防火墙无法阻止"看起来合法的应用流量中夹带的恶意内容"（例如通过 HTTP 上传木马）。
企业需要一种能看懂应用协议 、精细控制（比如只允许 FTP 下载，禁止上传）的防护手段。

解决方案：应用代理防火墙。它作为中间人，完全解析协议，可以：

拦截恶意命令（如 FTP 的 DELETE）
过滤 HTTP 中的 Java 小程序
要求用户认证后再访问外网

为什么应用代理没有成为主流？------ 状态检测的崛起

性能问题：应用代理每个连接都要拆包、解析、再封装，速度比包过滤慢 100 倍以上。1990年代中期互联网流量暴增，代理无法承载。
状态检测的出现 ：1994年 Check Point 发明了状态检测，它只检查头部+维护连接状态 ，不解析应用层，但能有效防欺骗、支持动态端口（如 FTP），而且速度接近包过滤。企业自然选择状态检测。
结果：应用代理退居二线，只在高安全、低流量的场景（如银行内部）使用。状态检测成为 1990s--2000s 的主流。

问题：为什么检测深度更浅的状态检测，反而被认为是比应用代理更先进的一代？

答案的核心在于："先进"不只看检测深度，更要看可部署性、性能和通用性。 应用代理虽然检测深入，但因为性能差、不透明、协议支持有限，在实际网络中几乎无法大规模部署。状态检测用更轻量的方式解决了当时最紧迫的问题（无状态、易欺骗、动态端口），并且性能接近包过滤，因此迅速成为主流。

状态检测的目标不是替代应用代理的深度检测，而是解决包过滤防火墙的致命缺陷 ，同时保持高性能和透明性。

包过滤防火墙的问题：

无状态：每个包独立检查，无法区分"外网主动发起的连接"和"内网请求的响应"。攻击者可以伪造ACK包绕过规则。

动态端口协议（如FTP、H.323）无法支持：包过滤只能静态开放高端口，不安全。

易受IP欺骗：因为没有连接状态，伪造源IP即可绕过。

状态检测的解决方案：

维护连接状态表 ：记录每个连接的方向、序列号、NAT映射等。只有匹配状态表的包才放行。

→ 天然解决了回程流量识别、防简单欺骗。

解析动态端口协议 ：状态检测可以解析FTP的PORT/PASV命令，动态开放临时端口（这就是ALG的雏形）。

→ 解决了FTP等协议的防火墙穿越问题。

高性能：仍然只检查头部，不解析应用层载荷，速度接近包过滤。

对比：

包过滤：无状态，易欺骗，不支持动态端口。

状态检测：有状态，防欺骗，支持动态端口（通过ALG），速度几乎一样快。

应用代理：有状态，深度检测，但速度慢、不透明、协议有限。

应用代理（第二代防火墙核心技术）和状态检测（第三代防火墙核心技术）都解决了包过滤的无状态问题，但解决路径完全不同 。二者在 1990 年代至 2000 年代初激烈竞争，最终状态检测凭借高性能与适度安全的平衡胜出，成为现代防火墙的基础。华为 USG 防火墙默认采用状态检测，而非纯应用代理。

1.3 状态检测（迭代最成功的版本）

ACL写的过多，繁琐

防火墙的会话表

首包流量必须通过安全策略方行，如果没有写，就过不去。

双向放行，单向放行。

一、基本概念

单向放行：只允许一个方向（比如从内网到外网）的流量通过，反方向的流量（外网到内网）默认禁止。

双向放行：允许两个方向（内网→外网和外网→内网）的流量都通过，通常需要两条策略或一条双向策略。

关键：在有状态检测防火墙中，大多数场景只需要单向放行，因为防火墙会自动放行合法的响应流量。

二、为什么有状态检测防火墙通常只需单向放行？

状态检测防火墙维护一个连接状态表。

当内网 PC 主动发起访问外网 Web 服务器的请求（SYN包），防火墙会创建一条状态表条目。

当外网服务器返回响应（SYN-ACK、数据包）时，防火墙检查状态表，发现这个响应匹配已有连接，于是自动放行，不需要再写一条"从外网到内网"的放行规则。

所以，对于"内网主动访问外网"这种常见场景，你只需要配置一条从 Trust 到 Untrust 的允许策略（单向放行），防火墙会聪明地允许响应回来。

三、什么时候需要双向放行？

尽管有状态检测，有些场景仍然需要显式配置两个方向的策略。主要有以下几种情况：

外网主动访问内网（如端口映射、服务器对外服务）

外网用户访问内网 Web 服务器。这个连接是外网主动发起 的。

防火墙看到 SYN 包是从 Untrust → Trust，如果没有配置允许，会被拦截。
需要配置一条从 Untrust 到 Trust 的策略（单向） ，允许外网访问内网服务器的指定端口。

但响应流量（内网 → 外网）会自动被状态表放行，所以不需要反向策略 。

→ 这仍然是单向策略，只不过方向相反。

2. 需要严格控制会话发起方向（如防止内部主机主动访问外部）

假设你只允许外网用户访问内网的 Web 服务，但不允许内网主机主动访问外网 。

你需要配置：

允许 Untrust → Trust（外网访问内网 Web）

禁止 Trust → Untrust（内网主动访问外网）

这里仍然都是单向策略，但明确禁止了某个方向。

3. 无状态协议或特殊场景（如某些 UDP 应用、组播）

对于无状态协议（如普通 UDP 查询），防火墙无法仅通过"第一个包"判断方向，可能需要配置双向策略保证来回。

但大多数 UDP 应用（如 DNS）仍然由状态检测处理（会临时建立 UDP 伪状态）。

问题：双向主动连接场景与策略解析

防火墙策略设计的核心原则：安全策略不是"默认双向"，而是根据业务需求"按需单向开放"。

一、核心概念：谁主动发起，谁就是"源"

主动发起连接：第一个包（TCP SYN 或 UDP 第一个包）的发送方。
防火墙策略中的 source-zone 和 destination-zone 就是按照第一个包的方向来写的。

例子：

内网用户访问外网网站：内网主动 → 策略源=Trust，目的=Untrust。
外网用户访问内网网站：外网主动 → 策略源=Untrust，目的=Trust。

这两条策略完全独立，你可以只开其中一条，也可以两条都开。

二、为什么"服务器让别人访问"不等于"两个方向都主动"？

"服务器让别人访问"通常是指：外网用户主动访问内网的服务器 。这是一个单向主动场景（外网主动 → 内网被动）

此时只需要一条策略：Untrust → Trust（允许外网访问服务器的指定端口）。

不需要 同时开放 Trust → Untrust（即内网用户主动访问外网）。

常见误解 ：认为"服务器要响应外网请求，所以内网也需要主动发出去"。
正解：服务器响应外网请求时，这些响应包属于已有连接的返回流量，由状态检测自动放行，不需要另外写策略。所以服务器自身不会主动发起新连接（除非它自己要去访问外网，比如下载更新）。

三、哪些场景需要"两个方向都主动发起连接"？

即需要同时放行 Trust → Untrust 和 Untrust → Trust（两个方向的主动连接）。常见场景：

场景	说明	策略需求
两个内部部门互访	财务部访问人事部系统，人事部也可能访问财务部系统	Trust(财务) ↔ Trust(人事) 两条策略
公司与合作伙伴通过VPN互联	双方都可能主动发起访问	两个方向各一条策略
允许员工上网，同时又对外提供Web服务	员工主动上网 + 外部访问公司网站	Trust→Untrust + Untrust→DMZ/Trust
某些P2P应用	双方都可能主动发起连接	双向策略（但通常不推荐）

四、哪些场景不允许两个方向都主动？

绝大多数企业默认策略：只允许内网主动访问外网（上网），禁止外网主动访问内网（除非特定服务器）。

场景	策略
普通员工上网	Trust → Untrust 允许
外部访问公司内部员工电脑	Untrust → Trust 禁止（默认）
外部访问DMZ的Web服务器	Untrust → DMZ 允许（单向）
内网服务器主动向外发数据（如木马回连）	Trust → Untrust 根据情况允许或禁止

安全原则：只开放必要的主动方向。外网主动访问内网的范围越窄越安全。

五、总结

"允许两个方向都主动发起连接"是指同时放行 A→B 和 B→A 的初始化流量，这通常用于对等互访或同时有内网主动访问外网和外网主动访问内网两种业务需求的场景。绝大多数企业默认只开放内网主动访问外网（上网），对外服务则单独开放外网→DMZ/Trust 的特定策略，两者独立，按需配置。

问题：会话表优先级 > 安全策略优先级

"会话表优先级 > 安全策略优先级" 是防火墙处理数据包时一个非常重要的原则。简单说：防火墙会优先查看会话表，如果命中，就直接按会话表的动作处理，不再重新匹配安全策略。

一、为什么会话表优先级更高？

防火墙的核心任务之一是高性能转发。如果每个数据包都去匹配一遍安全策略（可能有几百上千条规则），效率会非常低。

设计思想：

一个连接的第一个包（如 TCP SYN）会触发安全策略匹配，如果策略允许，防火墙就在会话表中创建一条记录，并放行该包。

后续属于同一个连接的所有包（包括 SYN-ACK、ACK、数据、FIN 等）直接查会话表，匹配到已有记录，就按照记录中的动作（通常是"允许"）快速放行，不需要再遍历安全策略。

好处：

性能高：后续包的处理速度极快（微秒级）。

状态感知：会话表记录了连接的状态（TCP 是否完成三次握手、序列号等），可以防御某些攻击（如序列号猜测）。

回程流量自动放行：响应方向的包因为能匹配会话表，自动允许，无需额外策略。

所以"优先级"是指处理顺序上的优先：先查会话表，后查安全策略。

https://chat.deepseek.com/share/bh5nwl0sun5i7x5rm9

如何在流量放行的基础上确保安全

问题：状态检测防火墙明明只检查头部，怎么能解析 FTP 的 PORT/PASV 命

这看起来矛盾，但实际上状态检测防火墙通过一个可选的辅助模块------应用层网关（ALG） 来实现对特定协议的"有限解析"。

一、状态检测防火墙的设计原则

状态检测防火墙的核心是维护连接状态表，每个数据包只检查：

IP 头（源/目的 IP）

TCP/UDP 头（源/目的端口、序列号、标志位等）

它默认不解析应用层载荷，以保证高性能。

但是，像 FTP 这样的协议，控制连接中会动态协商数据连接的端口。如果防火墙不解析控制连接中的 PORT/PASV 命令，就无法提前知道数据连接应该使用哪个端口，也就无法正确放行数据连接。

二、解决方案：为特定协议启用 ALG

状态检测防火墙对 已知存在动态端口问题的协议 （如 FTP、H.323、SIP、TFTP 等）内置了 ALG（Application Layer Gateway，应用层网关）模块 。ALG 是一个轻量级的协议解析器，只针对特定协议的特定连接启用，而不是对所有流量做通用应用层解析。

FTP ALG 的工作流程（以主动模式为例）

客户端通过控制连接（TCP 21）发送 PORT 192,168,1,100,48,57 命令。

防火墙的状态检测引擎识别出这是一个 FTP 控制连接（目的端口 21），于是将数据包交给 FTP ALG 模块。

FTP ALG 解析命令中的 IP 和端口（192.168.1.100:12345）。

ALG 通知状态检测引擎：预期将会有一个从服务器 20 端口到客户端 12345 端口的 TCP 连接，并将这个"预期连接"信息添加到状态表中（可以理解为"预开一个槽"）。

当真正的数据连接（服务器 20 → 客户端 12345）到达时，状态检测引擎检查状态表，发现匹配这个预期连接，于是放行。

数据传输完成后，状态表中的临时条目被删除。

被动模式类似：ALG 解析 PASV 响应中的服务器临时端口，并预期客户端会主动连接该端口。

三、ALG 不是全量应用层检测

关键区别：

应用代理防火墙：对所有应用层流量都做完整解析和重封装，性能极低。

状态检测防火墙 + ALG ：只对特定协议的控制连接做轻量级解析（只提取必要信息，不重组整个应用层会话），数据连接仍然只做状态检测。因此性能损耗很小。

类比：

应用代理 = 海关对每个入境旅客都开箱检查所有行李。

状态检测+ALG = 海关只对少数有嫌疑的旅客（特定协议）进行快速询问（只查关键信息），大部分旅客直接刷脸通过。

四、为什么这不算"解析应用层载荷"？

状态检测防火墙的"不解析应用层载荷"是指不对通用流量做深度包检测 （如不检查 HTTP 中的 SQL 注入）。但对于少数已知有副通道的协议，通过专门的 ALG 进行定向、有限的解析，是业界公认的合理扩展。这些 ALG 通常只解析协议中与端口协商相关的部分，而不是完整理解整个应用协议。

五、总结

状态检测防火墙通过内置的 ALG 模块，针对 FTP 等特定协议的控制连接进行有限解析，提取动态端口信息并预置状态表条目，从而实现对多通道协议的支持。这种按需解析的性能开销远低于通用应用代理，因此保持了整体高性能。

ALG 和 ASPF

ALG 和 ASPF 都是状态检测防火墙（Stateful Inspection Firewall）才具备的功能

它们都是为解决"多通道协议"问题而生，但解决思路、使用场景和实现逻辑完全不同。

第一问：ALG的具体工作流程

ALG的全称是应用层网关（Application Level Gateway） 。简单说，它的本质是在 NAT 场景下 ，帮助防火墙修改应用层报文里的地址/端口信息并开洞。

一个普通的NAT网关只能转换IP头里的地址，碰到FTP、SIP这类会在"说话内容"里也夹带私网地址的协议就会出错。ALG的核心流程，就是"听懂并篡改"：

拦截并解析控制报文 ：内网FTP客户端向服务器发送PORT 192.168.1.2,12,34命令时，ALG会拦截这个报文，计算出数据通道的地址是192.168.1.2，端口是3106（256*12+34）。

修改应用层地址（NAT ALG场景） ：ALG会将报文中的私网地址192.168.1.2替换为防火墙的公网地址（如10.0.0.1），端口3106也可能映射为新的端口51000。

动态创建"针孔"会话 ：ALG通知防火墙，在内网192.168.1.2:3106与公网服务器IP:任意端口之间创建一条临时的"针孔"会话表项，允许外部服务器主动连接进来。

转发修改后的报文 ：防火墙将修改后的PORT命令发送给FTP服务器。服务器收到后，知道要连接10.0.0.1:51000，这恰好命中针孔，数据连接成功建立。

第二问：ASPF的独立角色

ASPF的全称是应用特定包过滤（Application Specific Packet Filter） 。它在华为设备上专用于非NAT场景，核心功能是"侦听并开闸"：

核心作用 ：开启ASPF后，防火墙会监控应用层协议的协商过程，识别出动态协商的端口信息，生成Server-map表。

关键行动：ASPF本身不修改报文内容，只是基于侦听到的信息，在防火墙上临时打开一个"闸门"，让后续数据通道可以绕过安全策略，直接通过。

第三问：ALG与ASPF的区别与联系

核心区别

对比维度	ASPF	ALG (NAT ALG)
全称	Application Specific Packet Filter	Application Level Gateway
核心机制	监听、识别，创建Server-map表来"开闸"	在ASPF基础上，进一步修改报文载荷中的地址/端口信息
使用场景	纯路由转发，不涉及NAT的场景	必须部署了NAT的场景
最终目的	确保多通道协议的数据通道能被防火墙放行	确保多通道协议同时通过NAT和防火墙的考验

紧密联系

虽然各有侧重，但它们是协同工作的共同体：

技术同源：ALG的实现完全依赖于ASPF对应用层的检测能力。ASPF负责"听"和"判断"，ALG在判断后负责"改写"。

目标一致：都是为了解决FTP、SIP等多通道协议的问题。

实现统一：在华为设备中，ASPF和ALG功能常常由同一条命令控制。开启NAT ALG功能就等同于同时开启了ASPF功能。

总结

ASPF ：主要负责监控和开闸 。适用场景为非NAT模式 ，核心是创建Server-map表。
ALG ：主要负责监控、开闸和改包 。适用场景为NAT模式 ，核心是修改报文载荷。

在华为网络世界里，当流量穿越NAT时，你开启的nat alg功能，就是一个集成了ASPF（负责监控、开闸）和ALG（负责改包） 能力的复合体，共同确保复杂协议能够安全、顺畅地通过。

Server Map表跟会话表

一、知识点背景

为什么需要两张表？

会话表：解决"记忆已建立的连接"，让后续报文快速通过，避免重复策略检查。这是状态检测的基础。

Server-map 表：解决"预知未来可能出现的连接"，特别是多通道协议（如 FTP 的数据连接）和 NAT 场景下的反向连接。没有它，防火墙会像"失忆"一样，把合法的后续连接误判为新连接而拦截。

TCP/IP 模型定位 ：两者都属于状态检测防火墙的会话层/应用层辅助结构，但会话表是核心数据平面，Server-map 表是控制平面的预告机制。

二、核心定义（华为官方教材标准表述）

会话表（Session Table） ：记录当前正在进行的连接的状态信息（五元组、转换信息、老化时间、协议状态等）。每个经过防火墙的流量（TCP/UDP/ICMP）首包通过安全策略后，就会创建一条会话表项。后续报文直接匹配会话表快速转发。
Server-map 表 ：记录未来可能出现的连接 的预测信息 ，包括地址映射关系、端口范围、协议类型等。它不直接用于转发当前报文，而是用于提前创建会话 或辅助 NAT 转换。常见于 NAT Server、ASPF 动态开洞、No-PAT 等场景。

三、底层逻辑拆解（用餐厅比喻）

想象你开了一家高级私房菜餐厅，只有一个入口，有保安（防火墙）把守。

🍽️会话表 = 正在用餐的客人记录

客人进门，报上预约信息（首包），保安核对预约名单（安全策略），允许进入，并记下："张先生，2号桌，点了红烧肉"。

之后服务员上菜、倒水，不需要每次核对预约，直接看记录就知道这是张先生。

客人离开后，记录销毁（会话老化）。

会话表记录的是"正在进行的连接" ，关键词：已建立、进行中、快速查表。

📋 Server-map 表 = 餐厅的"预订提醒本"或"后厨配菜单"

场景1：NAT Server（公网访问内网）

餐厅有一个包间（内网服务器），对外公开专用通道（公网 IP:端口）。保安在营业前就在"预订本"上写好："若有人声称要找 202 包间，直接带他去 VIP 区" 。

这就是静态 Server-map 表，提前生成，用于引导外部访问。

场景2：ASPF（FTP 主动模式）

内网客人张先生正在吃饭（控制连接），他告诉服务员："我吃完后，会有人送水果来，送到我的 2 号桌，用 6000 号托盘"。服务员记下："2 号桌，预计将有一个水果托盘（数据连接）从后厨送来，使用端口 6000"。

保安看到后厨来人端水果，查"预订本"发现匹配，就放行。

这就是动态 Server-map 表，根据控制连接协商动态生成，预告未来的数据连接。

关键区别

维度	会话表	Server-map 表
记录对象	已经建立的连接	未来可能出现的连接
生成时机	首包通过安全策略后	配置静态映射时或解析应用层协议时
作用	快速转发后续同连接报文	提前开洞或执行地址映射
生命周期	连接建立到结束（老化时间）	静态（永久）或动态（几秒到几分钟）
是否用于转发当前报文	是	否（仅用于创建新会话或转换地址）
匹配后的动作	直接转发报文	创建新的会话表项，或执行 NAT 转换

四、Server-map 表的五种来源（详细拆解）

这是 HCIE 高频考点，必须分清每种来源的触发条件和作用。

1️⃣ 静态 NAT Server 配置（最常见）

触发命令 ：nat server global 1.1.1.1 inside 192.168.1.10
生成表项 ：自动创建一条 Server-map，类型为 NAT Server，内容为：公网1.1.1.1 → 内网192.168.1.10（可能带端口）。
作用：当外网报文访问 1.1.1.1 时，防火墙先查 Server-map，命中后直接做目的 NAT，然后创建会话表。
可选参数 no-reverse：如果不加，还会自动生成反向 Server-map（内网以公网 IP 为源访问外网时转换）。

2️⃣ NAT No-PAT（地址池一对一转换）

触发命令 ：nat address-group 1 1.1.1.1 1.1.1.10，并在策略中引用 nat-mode no-pat。
生成表项 ：为每个公网地址生成正反向 Server-map。例如：1.1.1.1 <-> 192.168.1.10（双向映射）。
作用：保证同一内网 IP 出去时固定使用某个公网 IP，且外网可以主动访问该公网 IP 映射到内网（需配合安全策略）。
与 NAPT 区别：NAPT（端口级复用）不会生成 Server-map，只用会话表

3️⃣ ASPF 动态生成（多通道协议）

触发条件 ：开启 firewall alg ftp 或 firewall detect ftp，且检测到 FTP 的 PORT/PASV 命令。
生成表项 ：类型为 ASPF 或 Dynamic，内容例如：FTP 数据通道：服务器:任意端口 → 客户端IP:动态端口。
作用：当 FTP 数据连接到达时，匹配 Server-map，自动创建会话表并放行，无需手动配置安全策略。
常见协议：FTP、SIP、H.323、RTSP、SQL*Net 等。

4️⃣ 三元组 NAT（Full-cone NAT，用于 VoIP/游戏）

触发条件 ：配置 nat alg 或特定的三元组 NAT 策略（华为部分版本支持）。
生成表项：类似于 No-PAT 但更灵活，允许任意外部 IP 通过映射后的公网 IP+端口访问内网。
作用：解决 STUN 类应用（QQ 语音、部分游戏）的 NAT 穿透问题。

5️⃣ 应用识别联动生成（NGFW 特性）

触发条件：开启内容安全（如 URL 过滤、IPS），且检测到特定应用需要动态开放端口。
生成表项 ：类型为 SA（Security Awareness）。
作用：例如某些 P2P 应用会协商动态端口，防火墙通过应用识别提前生成 Server-map。

面试题：FTP 主动模式下，防火墙如何放行数据连接？

场景：内网 FTP 客户端（192.168.1.2）主动连接外网 FTP 服务器（1.1.1.1），使用主动模式（PORT）。

阶段 1：控制连接建立（TCP 21 端口）

客户端 SYN → 服务器，防火墙首包查会话表（未命中）→ 过安全策略 → 创建控制连接的会话表项（记为 S1）。

后续控制报文的返回流量直接匹配 S1 快速转发。

客户端发送 PORT 命令（PORT 192.168.1.2,12,34），这个命令走的是已有的控制连接，属于 S1 会话内的数据。

阶段 2：ASPF 解析 PORT 并创建 Server-map

防火墙上的 ASPF（开启 FTP ALG）识别出 PORT 命令，解析出数据通道的 IP 和端口（192.168.1.2:3106）。

防火墙动态创建一条 Server-map 表项，内容大致为：

Server-map：等待 1.1.1.1:任意端口 -> 192.168.1.2:3106，动作：允许并创建会话

阶段 3：服务器发起数据连接

FTP 服务器从它的 20 端口（或其它动态端口）主动向 192.168.1.2:3106 发 SYN。

防火墙收到这个 SYN 报文后：

第一步：查会话表 → 未命中（因为这是一个全新的连接，五元组不同）。

第二步：查 Server-map 表 → 命中！发现这个连接是预告过的，于是防火墙根据 Server-map 里的信息，直接创建一条新的会话表项（记为 S2），并跳过安全策略检查（或者 Server-map 充当了临时策略）。

防火墙将 SYN 报文转发给客户端，后续数据通道的报文都匹配 S2 快速转发。

会话表到底干了什么？

连接类型	会话表作用
控制连接	从第一个 SYN 开始就创建了会话表（S1），后续 PORT 命令以及服务器的控制响应都靠 S1 快速转发。没有 S1，控制连接根本建不起来，更别提 PORT 解析。
数据连接	服务器发起的 SYN 匹配 Server-map 后，防火墙立即创建了数据连接的会话表（S2）。之后数据通道的 ACK、数据传输、FIN 等所有报文，都靠 S2 实现快速转发，而不是每次都重新查 Server-map。

关键结论 ：Server-map 的使命是 "在数据连接的第一个包到达时，引导防火墙创建会话表"。一旦会话表创建完成，后续数据流量就与会话表绑定，Server-map 退居二线（甚至动态 Server-map 在会话建立后很快老化删除）。

为什么面试答案通常不提"会话表"？

因为面试官问的是 "防火墙如何放行数据连接" ，重点在于解决"防火墙如何知道该放行这个陌生的数据连接" 这个核心矛盾。答案的核心是 ASPF + Server-map。

如果没有 Server-map，防火墙看到服务器主动发来的 SYN 会认为是一个未经允许的新连接，直接丢弃。

有了 Server-map，防火墙才知道"哦，这个连接是合法的，给它创建会话并放行"。

标准回答框架：

控制连接建立时，防火墙创建控制连接的会话表。

FTP 的 PORT 命令经过防火墙时，ASPF 解析出数据通道的 IP 和端口，动态生成 Server-map 表项。

服务器主动发起的数据连接 SYN 到达防火墙，先查会话表（未命中），再查 Server-map（命中）。

防火墙根据 Server-map 的信息，创建数据连接的会话表，并放行该 SYN 报文。

此后数据通道的所有报文均匹配数据连接的会话表快速转发。

总结：Server-map 解决"该不该放行"的决策问题，会话表解决"如何高效转发"的性能问题。两者缺一不可。

延伸考点：被动模式（PASV）有何不同？

模式	谁发起数据连接	Server-map 内容	会话表角色
主动（PORT）	服务器 → 客户端	目的 IP+端口为客户端	数据连接会话表仍被创建
被动（PASV）	客户端 → 服务器	目的 IP+端口为服务器	同样，数据连接会话表被创建

无论主动/被动，数据连接最终都会有自己的会话表项。Server-map 只是创建该会话表的"许可证"。

1.4 统一威胁管理

前提：访问控制流量要放行

缺点：很繁琐，UTM:入侵检测、防病毒检测，，，

会反复解封装，导致转发速率受影响，性能降低

我们之所以需要第四代防火墙------统一威胁管理（UTM），是因为攻击方式从攻击网络（Network）变成了攻击人（Content）。第三代防火墙就像大楼的保安，对每个进入者都严格盘查并记住TA是谁，但它只检查"身份证件"（IP地址和端口），而不检查"包里是否藏了危险品"。当攻击者开始把恶意代码"走私"进看似合法的包时，第三代防火墙就失效了。UTM就是为了解决这个问题而诞生的。

1.5 下一代防火墙

一次解封装，全面检查

UTM更像一个功能简单的"多功能工具箱"，而NGFW则是一个将各项功能深度融合、协同作战的"智能作战平台"。

📜 从UTM到NGFW：一场融合的质变

UTM的功能叠加困局 ：UTM将多种安全功能（如IPS、防病毒）简单叠加到一个盒子里，核心矛盾是 "功能与性能的取舍"。由于采用串行处理，开启的功能越多性能损耗越严重，导致很多企业不敢开启所有功能。同时，UTM的各安全模块信息独立，无法有效识别和关联复杂威胁的各个环节。

NGFW的单路径并行引擎 ：NGFW从设计之初就采用统一的操作系统和"一体化引擎"架构，数据包仅需一次解码，所有安全模块可并行检测，实现了 "功能与性能的平衡" 。各模块信息能够充分共享与联动，大大提升了对复杂攻击的检测和响应能力。

🎯 NGFW的核心：智能化、精细化、可视化

从"端口级"到"应用级"的精准管控：传统防火墙用端口猜应用，面对伪装流量无效。而NGFW通过DPI技术，能精确识别数千种应用，实现基于应用的精细化访问控制。

从"规则匹配"到"用户行为"的智能管理：NGFW将管控对象从抽象的IP地址，转向具体的"人"。它能与企业AD/LDAP联动，让策略随人而动，并实现多维度（如设备、位置、时间）的组合式访问控制。

从"被动防御"到"主动防御"的安全体系：NGFW能智能联动防火墙、IPS、威胁情报和沙箱，实现从被动响应到主动防御的转变。当IPS发现威胁时，防火墙可自动生成并下发策略进行阻断，并对加密流量进行解密检查。

从"看不见"到"看得清"的全网可视化：NGFW能提供详尽的可视化报告，帮助管理员直观了解网络中的用户、应用和威胁状况，为安全决策提供有力支撑。

二、安全区域

管理流量、控制流量、业务流量

为什么需要区分这三种流量？

防火墙设备本身也是一个网络节点，它既要被管理员管理 （管理流量），又要与其他网络设备交换路由协议或心跳信息 （控制流量），还要对经过它的用户数据做转发和安全检查 （业务流量）。这三种流量的安全诉求、处理方式、策略配置完全不同，混为一谈会导致配置错误或安全漏洞。

解决的痛点：

管理流量：需要加密、认证、限制访问源，防止设备被非法控制。

控制流量：需要允许必要的协议（如 OSPF、VRRP、双机热备心跳），但又要防止路由攻击。

业务流量：是防火墙最主要处理的用户数据，需要精细化安全策略。

Local区域（重要）

只要穿越防火墙的流量，Local区域是不生效的？？？

所有的接口都属于Local区域

只要流量到防火墙本身的，或者防火墙本身发出去的流量，那么Local区域就生效

同区域不会触发策略的检查

为什么要有 Local 区域？

在华为防火墙的安全区域体系中，我们定义了 Trust、Untrust、DMZ 等安全区域，用于对经过防火墙转发的业务流量 进行策略控制。但是，防火墙自身也需要收发流量 ，比如管理员登录防火墙（SSH/HTTPS）、防火墙发送日志、动态路由协议报文（OSPF、VRRP）等。这些"发往防火墙自身"或"由防火墙自身发出"的流量，不属于任何业务区域，需要一个特殊的区域来代表防火墙设备本身------这就是 Local 区域。

解决的痛点：

明确区分"流量是经过防火墙"还是"流量是发给防火墙"。
为管理流量和控制流量提供统一的区域概念，便于配置策略（本地策略）。
默认保证防火墙自身的安全（Local 区域默认具有最高信任等级）。

TCP/IP 模型定位 ：Local 区域是一个逻辑概念 ，属于防火墙的控制平面，代表设备自身。

Local 区域（Local Zone） 是防火墙设备自身所在的安全区域，代表防火墙本身。所有发往防火墙设备自身 的流量（如管理流量、控制流量）以及由防火墙设备自身发出的流量，其源或目的区域均为 Local。

查看 Local 区域相关配置

bash 复制代码

# 查看安全区域信息（包括 Local）
display firewall zone

# 查看本地策略（用于精细化控制 Local 与其他区域的流量）
local-policy
 rule name permit-ssh-from-trust
  source-zone trust
  destination-zone local
  service ssh
  action permit