2. 终端数据采集架构设计

EDR 的检测能力上限，首先由终端侧能采到什么数据决定。采集架构设计要回答三个问题：采什么（数据源分类）、怎么采（代理部署模式）、怎么送（标准化与传输通道）。三者构成一条从内核事件到分析平台的完整链路，任何一环设计不当，都会导致检测规则“无米下锅”或数据在传输中失真。

一、三类终端的数据源分类

Windows、Linux、macOS 的内核机制差异很大，数据源不能一概而论。工程上通常按“进程、文件、网络、注册表/配置、账号、驱动/内核模块”六个维度归类，再映射到各平台的具体采集接口。

Windows 侧的核心是 ETW（Event Tracing for Windows）与内核回调。进程创建可订阅 Microsoft-Windows-Kernel-Process 提供程序，拿到 PID、父进程 PID、映像路径与命令行；文件操作依赖内核过滤驱动（minifilter）挂载在 IRP_MJ_CREATE 等操作上；网络连接可通过 WFP（Windows Filtering Platform）或 ETW 的 Microsoft-Windows-Kernel-Network 获取五元组；注册表改动由 CmRegisterCallbackEx 捕获；登录事件来自 Security 日志的 4624/4625；驱动加载对应 7045 或 Sysmon 的 Event ID 6。Sysmon 是常见的折中方案，它把上述多数事件统一为 Event ID 1/3/11/12/13 等，部署成本低，但可定制性弱于自研驱动。

Linux 侧以 eBPF 为主流。进程执行可挂载 tracepoint/sched/sched_process_exec，配合 bpf_get_current_task 读取父进程信息；文件访问挂 kprobe 到 vfs_open、vfs_write；网络连接挂 tracepoint/syscalls/sys_enter_connect 或使用 kprobe 到 tcp_connect；账号与提权关注 /var/log/secure 或 auditd 的 EXECVE、SYSCALL 记录；内核模块加载可监听 init_module/finit_module。相比传统 auditd，eBPF 的过滤在内核态完成，高并发下丢包率明显更低，但需要内核 4.9+ 且开启 CONFIG_BPF 相关选项。

macOS 侧受 SIP 限制，用户态无法直接挂钩内核。主流做法是使用 Apple 的 Endpoint Security（ES）框架，通过 es_new_client 订阅 ES_EVENT_TYPE_NOTIFY_EXEC、NOTIFY_OPEN、NOTIFY_CONNECT 等事件；文件完整性可用 FSEvents 做粗粒度补充；账号与授权事件来自 OpenBSM 审计或统一日志（Unified Log）。ES 需要用户授予“完全磁盘访问”与系统扩展权限，且每个客户端有事件配额，设计时必须做事件裁剪。

二、采集代理的部署模式

代理部署不是“装上去就行”，而要按终端角色选择模式。常见有四类：

• 常驻轻量代理：以系统服务/守护进程运行，采集高频事件（进程、网络），资源占用控制在 CPU 1%～3%、内存 80～150MB。适合办公终端与服务器。
• 内核驱动 + 用户态代理：驱动负责事件捕获与初步过滤，用户态负责富化与上报。检测能力最强，但驱动崩溃会导致蓝屏，必须做签名与回滚机制。
• 无代理旁路采集：通过 Sysmon、auditd、ES 等系统自带能力输出到本地文件，再由转发器（如 Filebeat、Fluent Bit）收集。部署快，但事件字段不统一、易被攻击者关闭。
• 按需临时采集：用于取证或排障，通过远程下发脚本采集内存、进程树、网络连接快照，用完即撤。不参与常态检测。

实际工程中常采用“常驻代理 + 内核驱动”组合：驱动只做事件捕获与最小过滤，用户态代理做字段富化、规则初筛和缓冲。这样即使驱动出问题，用户态仍可降级为轮询模式，保证基本可见性。

三、数据标准化与传输通道选型

三类终端上报的原始字段千差万别，必须先归一化。推荐以 ECS（Elastic Common Schema）或 OCSF 为参考，定义统一事件模型。核心字段包括：

{
  "event": { "category": "process", "action": "start", "time": "2025-03-11T08:12:33.421Z" },
  "host":  { "name": "win-fin-023", "os": "windows", "ip": "10.20.3.17" },
  "process": { "pid": 4820, "ppid": 1120, "name": "powershell.exe",
               "command_line": "powershell -enc SQBFAF...", "hash_sha256": "9f2c..." },
  "user":  { "name": "CORP\\zhangsan" },
  "agent": { "id": "edr-7f3a", "version": "3.4.1" }
}

归一化时要注意三点：时间统一为 UTC 毫秒级，避免多时区排序错乱；进程标识用 PID + 启动时间 + 主机名组合，防止 PID 复用导致血缘错乱；命令行与路径做长度截断与转义，防止注入与超长字段拖垮管道。

传输通道选型取决于数据量与网络条件。低频关键事件（进程、登录、驱动加载）走 gRPC 或 HTTPS 长连接，保证可靠与低延迟；高频文件与网络事件先本地聚合，按秒级批量压缩后上报；隔离网或弱网终端采用本地磁盘队列 + 断点续传，队列上限建议 500MB～2GB，超限时按优先级丢弃低价值事件。传输层必须启用 mTLS 双向认证，防止伪造终端注入脏数据。

把三层串起来看，一个典型的进程创建事件从产生到入库大约经历：内核回调捕获 → 用户态代理补全父进程与用户信息 → 归一化为统一 JSON → 按优先级进入发送队列 → mTLS 通道上报 → 平台解析入库。整条链路的延迟目标通常控制在 3～10 秒，超过 30 秒的告警在应急响应中价值会大幅下降。