车载 ECU 防火墙工程实践：部署、规则设计与测试验证

摘要车载防火墙的工程价值不在于规则数量而在于能否把风险分析、通信需求、运行状态和验证证据连成一条可追踪链路。本文从部署位置、CAN 与车载以太网的过滤维度、规则工程、失效策略和测试方法出发说明如何避免“规则很多但边界不清”“拦住攻击也拦住安全关键通信”等问题。适用范围本文是通用工程方法介绍。示例用于解释思路不是量产规则模板具体阈值、默认动作和失效策略必须由项目安全目标、功能安全目标、网络性能及 OEM 要求确定。图 1分布式车载防火墙部署架构一、先确定防火墙部署在哪里“车载防火墙”不是一个固定盒子。部署点不同可见流量、可执行动作和失效影响也不同。1. 主机防火墙主机防火墙位于 ECU 操作系统、网络栈或通信框架附近主要控制进入或离开本机的通信。它能够靠近最终服务实施最小权限但会占用 ECU 的处理器、内存和规则存储资源。2. 网络转发防火墙网络转发防火墙部署在中央网关、区域控制器、域控制器或交换设备上适合控制跨网络、跨区域或跨安全域的通信。它能集中管理边界但通常无法覆盖完全不经过该节点的域内流量。3. 协议感知防火墙协议感知防火墙不仅检查地址和端口还理解 SOME/IP、SOME/IP-SD、DoIP 等协议字段。它可以把访问控制细化到服务、方法、事件或诊断目标但规则复杂度、性能开销和升级兼容性也更高。4. 多点协同典型分工可以是中央节点限制跨域路径区域节点缩小局部攻击面端点 ECU 保护本机服务。多点部署不是简单重复相同规则而是让每个执行点承担与其可见范围相匹配的职责。设计时至少需要回答哪些通信一定经过这个执行点它能看到原始通信的哪些字段经过转换后又会丢失哪些上下文规则执行失败会影响哪些功能谁负责配置、签名、加载、更新和回滚规则多个执行点的允许与拒绝策略是否一致二、CAN/CAN FD 防火墙可以检查什么CAN/CAN FD 上常见的规则维度包括物理或逻辑总线通道报文的接收或发送方向标准帧、扩展帧及 CAN 标识符数据长度和项目允许时的部分载荷条件周期、频率、突发数量或总线负载相关条件诊断请求的寻址方式、服务范围和车辆状态网关转发时的源接口与目标接口组合。CAN 标识符不是可信身份CAN 标识符参与仲裁并表达报文语义不能简单称为“ECU 地址”。同一共享总线上的恶意节点在具备发送能力时可能发送使用其他报文标识符的帧。防火墙依据 CAN 标识符实施白名单仍然有价值但它控制的是“符合配置特征的报文”并不天然完成发送 ECU 的密码学身份认证。如果防火墙位于连接两个独立物理总线的网关它可以依据入口通道确定报文来自哪个网络分段若还需要确认报文真实性与新鲜度则应结合 SecOC 或项目定义的其他认证机制。频率规则不是越严格越好周期或频率检测需要考虑正常抖动、总线仲裁、网络管理、故障恢复、诊断和启动阶段。把通信矩阵中的名义周期直接当作硬阻断阈值可能造成误拦截。例如“某报文周期为 10 ms因此超过每秒 100 帧立即永久阻断”只能算一个不完整的教学想法。量产规则至少还需定义观察窗口、允许抖动、突发行为、启动状态、降级状态、计数恢复和误报处置。三、车载以太网防火墙可以检查什么以太网和基于 IP 的通信提供了更多可供访问控制的字段二层源/目标 MAC、VLAN、优先级、EtherType、入口和出口端口三层源/目标 IP、IP 版本、上层协议及必要的一致性条件四层TCP/UDP、源/目标端口、TCP 连接状态、连接数量应用层SOME/IP 服务、方法、事件SOME/IP-SD 服务发现条目以及 DoIP 相关字段行为条件带宽、请求速率、连接建立速率和特定车辆状态。图 2CAN 与车载以太网的典型过滤维度无状态过滤无状态过滤逐包匹配规则例如源/目标地址、协议和端口。实现相对直接但不了解前后报文的连接关系。有状态检测有状态检测维护连接或会话相关信息。例如TCP 返回流量是否属于已建立连接。它能够表达更严格的策略但需要状态表、超时管理和资源耗尽防护。深度包检查深度包检查进一步解析应用协议。AUTOSAR Adaptive Platform R25-11 防火墙规范描述了针对 SOME/IP、SOME/IP-SD、DoIP 等协议的检查能力并包含无状态、有状态、规则过滤、限流和状态相关过滤等要求。引用该规范时应说明两个边界第一这是 AUTOSAR Adaptive Platform 标准范围内的能力定义第二某个量产产品支持到什么程度应依据对应版本的正式产品文档和配置不能仅凭“AUTOSAR 兼容”推断全部功能。四、如何从安全需求导出规则一条规则至少应能追溯到业务通信需求或安全需求而不是因为“暂时不知道用途”就长期放行。推荐的数据流如下从 TARA 获取安全目标和风险处置需求。**明确要保护的资产、攻击路径、信任边界和风险降低目标。建立通信基线。汇总通信矩阵、服务接口、诊断需求、网络管理、时间同步、软件升级和生产售后需求。选择执行点。确认哪个防火墙能够看到所需上下文并且不会因网络转换丢失判断依据。形成规则。定义匹配条件、动作、适用状态、日志级别、异常计数和恢复方式。配置与保护。对规则进行版本管理、完整性保护、授权更新和回滚设计。建立验证证据。让每条高风险规则对应正向、反向、边界和性能测试。图 3从 TARA 和通信需求到规则及测试证据一个教学化规则示例以下只是表达规则要素不是可直接用于量产的配置要素教学示例执行点区域控制器的以太网入口通信诊断客户端访问目标 ECU 的 DoIP 服务允许条件授权诊断模式、指定入口、指定目标和允许的服务范围默认动作不满足条件时拒绝并按配置产生安全事件状态条件行驶、驻车、生产、售后和刷写状态分别定义保护措施认证授权、速率控制、规则完整性和审计日志验证合法访问、越权目标、错误状态、畸形报文、洪泛和恢复测试“默认拒绝”是构建最小权限策略的重要原则但也不能脱离系统启动、应急通信、诊断救援和功能安全需求机械套用。真正的默认动作应在明确通信面和状态模型后确定。五、特殊运行状态不能遗漏许多防火墙问题并不发生在稳态通信而发生在状态切换时。启动与规则加载需要定义网络栈可用但完整规则尚未加载时的行为。可选方案包括仅允许最小启动通信、使用受保护的基础规则集或延迟开放相关服务。不能让短暂的“全放行窗口”成为未经评估的默认行为。休眠与唤醒唤醒报文、网络管理和重新建立连接可能出现与稳态不同的频率和顺序。规则应覆盖正常唤醒、重复唤醒、异常唤醒和超时恢复。诊断、刷写与维护生产、售后、远程诊断和软件更新可能需要临时开放额外服务。开放条件应与认证授权、车辆状态、时间范围和目标 ECU 绑定并在会话结束或超时后收回。网络降级与故障恢复总线故障、链路切换、ECU 重启或网关降级可能改变通信路径。需要确认替代路径是否仍经过等效安全控制以及规则状态是否能安全恢复。六、fail-open 还是 fail-closed不存在适用于所有 ECU 和所有通信的统一答案。Fail-closed防火墙异常时拒绝通信有利于限制未授权访问但可能中断安全关键功能或故障恢复通信。Fail-open防火墙异常时维持通信连续性但会扩大攻击面并可能破坏既定安全目标。受控降级只保留经过论证的最小通信集合同时限制诊断、外部连接或非必要服务。决策至少需要综合网络安全目标、ISO 26262 相关安全目标、预期功能安全SOTIF影响、可用性、驾驶状态、故障持续时间和恢复机制。同一 ECU 在启动、行驶、驻车和刷写状态下也可能采用不同策略。建议把失效策略写成明确的状态和动作表而不是在需求中只写一句“防火墙故障时系统进入安全状态”。七、如何验证防火墙1. 规则静态检查是否存在永远无法命中的规则是否有范围过宽的允许规则规则顺序是否导致后续规则被遮蔽地址、端口、服务和车辆状态是否与通信需求一致多个执行点之间是否出现策略冲突规则版本是否与软件和网络配置匹配。2. 正向功能测试验证每一条必要通信在正确接口、状态、方向和时序下都能通过包括启动、唤醒、诊断、升级和降级场景。只做攻击测试而不验证合法通信可能把误拦截风险遗漏掉。3. 反向与边界测试错误源或目标地址未授权端口、服务、方法或诊断目标错误车辆状态边界长度、畸形字段和不一致的协议长度TCP 状态绕过、异常分片及产品明确支持范围内的重组场景超过允许速率、连接数量或状态表容量。4. 鲁棒性和拒绝服务测试评估洪泛、连接耗尽、日志洪泛和大量规则匹配时的行为。防火墙不仅要“拦住”还要避免自身成为 CPU、内存、存储或总线带宽耗尽的原因。5. 性能与实时性测试测量典型和最坏负载下的延迟、抖动、吞吐量、CPU、内存和状态表占用。测试应覆盖规则数量增长、深度包检查开启、日志启用和异常流量条件。6. 生命周期测试验证规则升级、断电恢复、版本回滚、配置损坏、签名验证失败和软件版本不匹配。规则本身也是需要保护和维护的软件资产。八、防火墙如何与 IdsM、IdsR 和 SOC 协同防火墙发现规则违反时可以根据配置丢弃、限流或允许但记录并向 IdsM 报告安全事件。IdsM 对事件执行过滤和聚合形成合格安全事件随后可存入安全事件存储或交给 IdsR/车载通信单元转发到后端 SOC。图 4防火墙阻断路径与 IDS 上报路径这里有三个容易误写的地方IdsM 主要处理安全传感器报告的事件不代表所有原始攻击检测都由 IdsM 完成IdsM 收到事件不等于攻击已经被阻断阻断可能由防火墙或其他响应机制执行不是所有被拒绝的报文都应无条件上报后端否则可能造成日志和通信资源耗尽。事件过滤、限频和优先级需要项目化设计。九、工程落地检查清单防火墙部署点与信任边界是否一致每条允许规则是否有明确的业务或安全需求来源是否区分启动、行驶、驻车、诊断、刷写和降级状态CAN 标识符是否被错误当成可信发送者身份加密认证与访问控制是否各自承担清晰职责规则加载失败和防火墙运行异常是否有受控策略日志和安全事件是否有限频、聚合和存储保护是否同时验证合法通信、违规通信、鲁棒性和性能规则、软件、通信矩阵和测试证据是否版本一致OTA 或售后更新后是否重新验证受影响规则。总结车载 ECU 防火墙工程不是把企业网络规则缩小后放进汽车。它必须理解固定而严格的车内通信、资源和实时性约束也必须处理车辆状态、诊断维护、功能安全和长生命周期更新。可靠的工程闭环应当是风险和通信需求决定规则规则由合适的执行点落实异常事件进入 IDS 体系所有关键行为通过测试证据证明。防火墙只是纵深防御中的一层但如果部署点、规则、状态模型和验证方法设计正确它可以显著限制攻击面和横向移动范围。参考资料AUTOSAR, Specification of Firewall for Adaptive Platform, R25-11AUTOSAR, Requirements on Firewall, R25-11AUTOSAR, Requirements on Intrusion Detection System, R25-11Vector, AUTOSAR Intrusion Detection System Manager — MICROSAR IdsMISO, ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineeringUNECE, UN Regulation No. 155 — Cyber Security and Cyber Security Management System国家市场监督管理总局、国家标准化管理委员会GB 44495—2024《汽车整车信息安全技术要求》本文依据截至 2026 年 8 月可查的公开官方资料整理。ISO/SAE 21434:2021 仍是 ISO 页面列出的已发布版本同时处于系统复审阶段。标准、法规解释和产品能力可能更新量产项目应使用正式获取的适用版本并结合 OEM、供应商及认证要求实施。