📚 课程目录第4章 ECU主机安全监测概述

4. ECU主机安全监测概述

ECU（Electronic Control Unit，电子控制单元）主机安全监测，是在车载计算平台内部建立一套持续感知、采集、判定与上报的安全能力。它不等同于传统功能安全中的故障诊断，也不只是把日志集中收集起来，而是围绕“谁在运行、运行是否偏离预期、是否出现攻击或异常行为”这一主线，对ECU内部的关键活动进行可观测化。监测的目标不是追求采集越多越好，而是用有限的算力、存储和总线带宽，抓住最能反映安全状态的对象与位置。

核心判断：ECU主机安全监测的价值，在于把不可见的内部行为转化为可判定的证据链。监测点选得准，数据来源覆盖得全，后续的事件响应才有依据。

一、监测目标：从“看见”到“可判定”

ECU主机安全监测通常围绕四类目标展开。第一类是完整性目标，确认启动链、固件、关键配置和标定数据未被篡改；第二类是行为目标，确认进程、任务、系统调用和通信行为符合预期基线；第三类是资源目标，确认CPU、内存、存储和总线负载没有因恶意行为出现异常占用；第四类是响应目标，确认异常能够被记录、分级、上报，并触发隔离、降级或安全重启等动作。

这些目标需要落到可度量的指标上。例如，启动阶段关注安全启动校验结果、镜像哈希和签名验证状态；运行阶段关注进程创建频率、特权指令调用次数、内存页权限变化、CAN报文周期抖动和网络连接五元组。只有把目标翻译成指标，监测系统才能从“看见日志”升级为“可判定事件”。

二、监测点选择：按攻击面与关键路径布点

监测点选择应遵循“关键路径优先、攻击面覆盖、低侵入可观测”三项原则。关键路径包括启动链、诊断服务、OTA升级、远程控制指令和密钥使用；攻击面包括外部网络接口、诊断接口、USB/蓝牙等外设入口以及共享内存区；低侵入则要求监测点尽量利用已有钩子、内核tracepoint、总线监听和硬件计数器，避免为了监测而引入新的实时性风险。

实践中，监测点可分为主机内与主机外两类。主机内监测点包括内核态的系统调用入口、LSM钩子、进程调度事件、内存映射变化和文件完整性校验点；主机外监测点包括CAN/CAN FD总线监听点、以太网镜像端口、诊断请求入口和网关转发点。两者需要时间对齐，否则难以还原攻击链。

三、监测数据来源：五类数据各有边界

ECU主机安全监测的数据来源通常包括日志、总线、系统调用、内存和网络流量。它们不是互相替代的关系，而是从不同层次还原同一台ECU的行为。

数据来源	典型内容	优势	局限
日志	内核日志、应用日志、审计日志、诊断日志	语义清晰，便于追溯和取证	可能被篡改或丢失，实时性有限
总线	CAN/CAN FD报文、以太网帧、周期与事件报文	直接反映通信行为，适合检测注入与重放	难以直接关联到具体进程
系统调用	open/read/write/execve/socket等调用序列	行为粒度细，适合异常检测与沙箱判定	数据量大，需采样与聚合
内存	页表权限、映射区域、堆栈变化、内存占用	可发现代码注入、越权执行和异常驻留	采集侵入性较高，需硬件或内核支持
网络流量	五元组、会话、TLS握手、异常端口与协议	适合检测远程攻击、C2通信和数据外传	加密流量可见性受限，需结合元数据

四、方法流程：从采集到响应的闭环

一个可落地的ECU主机安全监测流程通常分为五步：确定监测目标、选择监测点、采集并归一化数据、基于基线与规则进行判定、触发响应并留存证据。采集层要尽量使用低开销接口，例如Linux tracepoint、eBPF、CAN监听和硬件性能计数器；归一化层要统一时间戳、ECU标识、进程标识和报文ID；判定层要结合白名单、行为基线、序列规则和关联分析。

# 示例：采集系统调用与网络事件并归一化输出
# 1) 采集execve调用
trace-cmd record -e syscalls:sys_enter_execve -e syscalls:sys_enter_socket

# 2) 采集CAN报文（socketcan）
candump can0,123:7FF -n 100

# 3) 归一化字段示例
{
  "ecu_id": "VCU-01",
  "ts": "2025-03-18T10:22:31.482Z",
  "source": "syscall",
  "event": "execve",
  "pid": 1042,
  "comm": "diag_svc",
  "path": "/usr/bin/sh",
  "risk": "high"
}

判定阶段要避免“单点即告警”。例如，单独一次execve调用可能是正常升级脚本；但如果它由诊断服务发起、随后出现socket连接外部地址、同时CAN总线上出现异常高频报文，就应提升为高优先级事件。关联分析是降低误报的关键。

五、案例与误区复盘

某车型VCU在路试中出现偶发动力中断。初期只查看应用日志，未发现明显错误；后来将CAN总线报文、系统调用和网络流量按时间对齐，发现诊断服务在特定条件下被触发执行了非预期命令，并伴随一次外部网络连接尝试。若只依赖日志，该行为可能被淹没在正常诊断记录中；而总线与系统调用的联合分析，才把攻击链还原出来。

常见误区：一是只采集日志，忽视总线与系统调用，导致攻击链断裂；二是监测点布得过密，影响ECU实时性；三是没有统一时间基准，多源数据无法关联；四是只告警不响应，监测系统沦为“记录仪”。

工程建议：优先在启动链、诊断入口、OTA通道和外部网络接口布点；对系统调用和网络流量采用采样加聚合；对内存监测优先使用只读页表与完整性校验；所有监测数据必须带统一时间戳和ECU标识，便于跨域关联。

综上，ECU主机安全监测的核心不是堆砌数据源，而是围绕监测目标选择监测点，再让日志、总线、系统调用、内存和网络流量在统一时间轴上形成互补证据。只有这样，后续的事件响应才能从“事后翻日志”走向“实时可判定、可处置”。