下一代防火墙通用原理

一、防火墙技术发展历程七、总结对比表面试或IA阶段理解用代数名称检查深度状态?应用识别?性能典型缺陷1包过滤网络/传输层头部无无高无状态易欺骗2状态检测网络/传输层连接表有无高不检查内容3应用代理应用层有连接级需单独代理低慢、协议少4UTM多引擎串行有部分中全开后低性能瓶颈模块孤立5NGFW一体化单通道有有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 的允许策略单向放行防火墙会聪明地允许响应回来。三、什么时候需要双向放行尽管有状态检测有些场景仍然需要显式配置两个方向的策略。主要有以下几种情况1. 外网主动访问内网如端口映射、服务器对外服务外网用户访问内网 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 头源/目的 IPTCP/UDP 头源/目的端口、序列号、标志位等它默认不解析应用层载荷以保证高性能。但是像 FTP 这样的协议控制连接中会动态协商数据连接的端口。如果防火墙不解析控制连接中的 PORT/PASV 命令就无法提前知道数据连接应该使用哪个端口也就无法正确放行数据连接。二、解决方案为特定协议启用 ALG状态检测防火墙对已知存在动态端口问题的协议如 FTP、H.323、SIP、TFTP 等内置了ALGApplication 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 和 ASPFALG 和 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端口是3106256*1234。修改应用层地址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的区别与联系核心区别对比维度ASPFALG (NAT ALG)全称Application Specific Packet FilterApplication 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 表 餐厅的“预订提醒本”或“后厨配菜单”场景1NAT Server公网访问内网餐厅有一个包间内网服务器对外公开专用通道公网 IP:端口。保安在营业前就在“预订本”上写好“若有人声称要找 202 包间直接带他去 VIP 区”。这就是静态 Server-map 表提前生成用于引导外部访问。场景2ASPFFTP 主动模式内网客人张先生正在吃饭控制连接他告诉服务员“我吃完后会有人送水果来送到我的 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️⃣ 三元组 NATFull-cone NAT用于 VoIP/游戏触发条件配置nat alg或特定的三元组 NAT 策略华为部分版本支持。生成表项类似于 No-PAT 但更灵活允许任意外部 IP 通过映射后的公网 IP端口访问内网。作用解决 STUN 类应用QQ 语音、部分游戏的 NAT 穿透问题。5️⃣ 应用识别联动生成NGFW 特性触发条件开启内容安全如 URL 过滤、IPS且检测到特定应用需要动态开放端口。生成表项类型为SASecurity Awareness。作用例如某些 P2P 应用会协商动态端口防火墙通过应用识别提前生成 Server-map。面试题FTP 主动模式下防火墙如何放行数据连接场景内网 FTP 客户端192.168.1.2主动连接外网 FTP 服务器1.1.1.1使用主动模式PORT。阶段 1控制连接建立TCP 21 端口1. 客户端 SYN → 服务器防火墙首包查会话表未命中→ 过安全策略 → 创建控制连接的会话表项记为 S1。2. 后续控制报文的返回流量直接匹配 S1 快速转发。3. 客户端发送 PORT 命令PORT 192.168.1.2,12,34这个命令走的是已有的控制连接属于 S1 会话内的数据。阶段 2ASPF 解析 PORT 并创建 Server-map4. 防火墙上的 ASPF开启 FTP ALG识别出 PORT 命令解析出数据通道的 IP 和端口192.168.1.2:3106。5. 防火墙动态创建一条 Server-map 表项内容大致为Server-map等待 1.1.1.1:任意端口 - 192.168.1.2:3106动作允许并创建会话阶段 3服务器发起数据连接6. FTP 服务器从它的 20 端口或其它动态端口主动向 192.168.1.2:3106 发 SYN。7. 防火墙收到这个 SYN 报文后第一步查会话表→ 未命中因为这是一个全新的连接五元组不同。第二步查 Server-map 表→ 命中发现这个连接是预告过的于是防火墙根据 Server-map 里的信息直接创建一条新的会话表项记为 S2并跳过安全策略检查或者 Server-map 充当了临时策略。8. 防火墙将 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 区域相关配置# 查看安全区域信息包括 Local display firewall zone # 查看本地策略用于精细化控制 Local 与其他区域的流量 local-policy rule name permit-ssh-from-trust source-zone trust destination-zone local service ssh action permit接口下面的控制优先级 大于 安全策略就不用安全策略去放行了。业务口开启service-manager也能ping通web登录账号密码业务路由表没有这个双UP的路由管理路由表 实例路由表管理接口的路由跟业务接口的路由不在一张表里面试会问