4. 车载入侵检测系统概述

车载防火墙,说白了就是给车上的网络装个「安检门」。不是所有数据都能随便进出,得按规矩来。我做了这么多年车载安全,见过太多因为防火墙规则没配好,导致整车网络被攻破的案例。今天咱们就把这四种防火墙技术掰开揉碎了讲清楚。

4.1 状态检测防火墙

状态检测防火墙,核心思路是「记住你是谁」。它不光看每个数据包的头部,还会维护一张连接状态表。比如TCP的三次握手、序列号变化,它都盯着。

核心机制:基于连接状态做过滤,不是逐包独立判断。

我在项目里遇到过一个问题:某Tier1供应商的网关,只配了静态包过滤规则,结果攻击者伪造合法源IP,直接绕过了ACL。后来换成状态检测防火墙,所有非ESTABLISHED状态的SYN包一律丢弃,问题才解决。

状态检测的关键参数:

  • 状态表条目:每个连接占多少内存?我建议至少支持65536条并发连接。
  • 老化时间:TCP默认300秒,UDP建议60秒,ICMP建议30秒。
  • 序列号检查:防止TCP序列号预测攻击。

避坑指南:我曾经在某个项目中,状态表老化时间设得太短(15秒),结果正常的DoIP诊断会话频繁中断。后来调到120秒才稳定。记住,诊断流量和普通数据流量的老化策略要分开。

4.2 应用层防火墙

应用层防火墙,也叫深度包检测(DPI)防火墙。它不光看IP和端口,还会解析应用层协议的内容。比如DoIP的payload里是不是藏了恶意指令,SOME/IP的Service ID是否在白名单里。

你想想看,如果只靠端口过滤,攻击者完全可以把恶意数据伪装成正常的UDP 13400端口流量。应用层防火墙能识别出「这个DoIP请求的源地址不在允许列表里」,直接拦截。

常见的应用层检测场景:

  • DoIP:检查逻辑地址、诊断类型、VIN匹配。
  • SOME/IP:验证Service ID、Method ID、Event Group。
  • HTTP/REST:检查URI、Header、Body格式。
  • MQTT:验证Topic命名规范、QoS等级。
协议 检测维度 典型规则
DoIP 源逻辑地址、目标逻辑地址、诊断类型 只允许0x0E80诊断仪访问0x0001网关
SOME/IP Service ID、Method ID、Client ID 只允许Service ID 0x1234被订阅
DDS Topic名称、Partition、QoS 只允许/sensor/radar/前缀的Topic

注意:应用层防火墙的性能开销很大。我见过一个项目,DPI全开之后,网关CPU直接飙到90%。建议只对关键域间流量做深度检测,域内流量用轻量级规则。

4.3 CAN总线防火墙规则设计

CAN总线防火墙,跟以太网防火墙完全不是一个思路。CAN报文没有IP地址,没有端口号,只有11位或29位ID。所以规则设计得围绕ID和Data field来做。

我个人习惯把CAN防火墙规则分成三层:

  1. ID白名单层:只允许特定ID范围通过。比如动力域CAN只允许0x100-0x3FF的报文。
  2. DLC校验层:检查数据长度是否匹配。比如0x123报文正常是8字节,突然变成3字节,直接丢弃。
  3. Data内容层:检查特定字节的值范围。比如车速信号不能超过物理极限值。

实战案例:我在某OEM项目中,发现攻击者通过OBD口注入伪造的0x316报文(包含方向盘转角信号)。CAN防火墙规则只配了ID白名单,没做Data校验。结果车辆误判驾驶员意图,触发了紧急制动。后来加上「0x316报文的Byte0-1必须在-780°到+780°之间」的规则,才彻底堵住。

CAN防火墙规则示例(伪代码):

Rule 1: ID 0x100-0x3FF, DLC=8, Action=ALLOW
Rule 2: ID 0x316, Byte0-1 range [-780, 780], Action=ALLOW
Rule 3: ID 0x400-0x7FF, Action=DROP
Rule 4: ID 0x000, Action=DROP  // 禁止发送ID为0的报文
Rule 5: Default Action=DROP

经验之谈:CAN防火墙的规则数量不要超过64条。我测试过,规则超过128条后,CAN网关的转发延迟会从50μs飙升到200μs以上,影响实时控制。

4.4 以太网防火墙配置

车载以太网防火墙,跟IT防火墙类似,但多了很多汽车特有的规则。比如VLAN隔离、AVB/TSN流过滤、DoIP会话管理。

我建议的配置思路:

  • 接口级:每个物理端口绑定VLAN,不同VLAN之间默认隔离。
  • IP级:基于源/目标IP、端口、协议做ACL。
  • MAC级:绑定静态MAC地址,防止ARP欺骗。
  • 应用级:配合DPI做深度检测。

一个典型的车载以太网防火墙配置示例:

// 接口配置
interface eth0
  vlan-id 10
  ip address 192.168.10.1/24

interface eth1
  vlan-id 20
  ip address 192.168.20.1/24

// ACL规则
access-list 100 permit tcp 192.168.10.0/24 192.168.20.100/32 eq 13400
access-list 100 deny ip any any

// 应用层过滤
application-filter doip
  allow source-logical-address 0x0E80
  allow target-logical-address 0x0001
  deny default

重要提醒:以太网防火墙的规则顺序非常关键。我记得有一次,我把deny any any规则放在了permit规则前面,结果所有流量都被丢弃了。规则匹配是从上到下,第一条匹配就停止。所以permit规则一定要放在deny规则前面。

4.5 防火墙规则设计总览

下面这张图,是我自己总结的防火墙规则设计流程。每次做新项目,我都会按这个思路走一遍。

车载防火墙规则设计流程 1. 需求分析 2. 协议识别 3. 规则分层 4a. CAN规则设计 4b. 以太网规则设计 5. 验证与测试 说明: 规则设计必须从需求出发, 先识别协议,再分层设计。 CAN和以太网规则分开处理。

嗯,这里要注意一点:规则设计不是一次性的。我每次做完规则,都会用fuzz测试工具跑一遍,看看有没有漏掉的攻击路径。曾经有一次,fuzz测试发现了一条隐藏的绕过路径——攻击者通过CAN FD的BRS位翻转,绕过了ID白名单。后来我们在规则里加了「BRS位必须为0」的约束,才彻底封死。

总结:车载防火墙不是「配完就完」的东西。状态检测、应用层检测、CAN规则、以太网规则,每一层都有坑。我的建议是:先做最小权限原则,再逐步放开。宁可误杀,不可漏过。