eBPF 主机入侵检测原理与开源工具选型

核心要点（TL;DR）

eBPF HIDS 通过内核探针采集进程、文件、网络事件，开销远低于传统 auditd 全量审计。
选型先看事件模型与规则表达力，再看是否支持容器上下文与内核版本兼容性。
上线前必须验证内核 BTF 与 tracepoint 可用性，否则探针加载会静默失败。
规则调优的核心是收敛高危事件白名单，把告警量压到可运营的水平。

服务器被植入挖矿木马，登录日志却干干净净；容器里突然多出一个反弹 Shell，传统 HIDS 只留下一堆无关的文件完整性告警。问题往往不在「有没有监控」，而在于监控的粒度太粗。eBPF 主机入侵检测把观测点下沉到内核，能在进程执行、文件写入、网络连接发生的瞬间拿到上下文，这正是本文要解决的问题：用可落地的命令和清单，把 eBPF HIDS 真正跑起来。

一、eBPF 主机入侵检测到底在观测什么

eBPF 允许把沙箱程序挂载到内核的固定挂载点，事件发生时先在内核里过滤，再把命中数据送到用户态。主机入侵检测常用的挂载点有三类：

tracepoint：内核预置的稳定事件点，如 syscalls/sys_enter_execve，适合监控进程执行。
kprobe：挂到内核函数入口，如文件写入相关调用，灵活但受内核版本影响。
LSM 钩子：在安全决策点拦截，可读取安全上下文，适合做策略阻断。

相比 auditd 全量审计，eBPF 的优势是「先过滤后上报」，不会把每条系统调用都写进日志。代价是需要较新内核与 BTF 支持，规则写错时可能静默失效。

二、上线前的环境自检（必做）

探针加载失败最常见的原因是内核能力不足。先执行以下检查：

uname -r
ls /sys/kernel/btf/vmlinux
mount | grep -E 'tracefs|debugfs'
sysctl kernel.unprivileged_bpf_disabled

判定标准：内核 5.4 以上、BTF 文件存在、tracefs 已挂载。若 unprivileged_bpf_disabled 为 1，属正常加固配置，探针需以 root 或具备 CAP_BPF 的权限运行。容器环境还要确认宿主机已挂载 /sys/kernel/debug 与 /sys/fs/bpf。

三、用 Tetragon 快速验证一条检测规则

以「非预期 Shell 启动」为例，先跑通最小闭环，再扩展规则。安装后编写策略文件 shell.yaml：

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-shell
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "In"
        values:
        - "/bin/sh"
        - "/bin/bash"
      matchActions:
      - action: Sigkill

应用并观察事件：kubectl apply -f shell.yaml，随后用 tetra getevents -o compact 查看实时事件。先在测试机把 Sigkill 改为 Post 只告警，确认误报可控后再切换为阻断。

四、开源工具选型对比

工具	定位	规则表达	适合场景
Tetragon	eBPF 运行时安全与策略执行	TracingPolicy，支持内核态阻断	Kubernetes、云原生主机
Falco	运行时威胁检测与告警	Falco 规则语言，生态成熟	主机与容器混合环境
Tracee	事件追踪与取证	签名规则，侧重行为分析	应急排查、行为审计

选型时优先看三点：是否带容器与进程树上下文、规则能否表达父子进程关系、内核版本兼容范围。团队人力有限时，可把开源探针作为采集层，告警聚合与主机侧防护交由 AegisX 统一处理，减少自建运营成本。

五、误报调优与上线检查清单

规则上线后第一周重点压告警量。按进程路径、父进程、容器镜像三个维度统计高频事件，把包管理、日志轮转、健康检查加入白名单，文件类规则限定监控目录。上线前逐项确认：

内核与 BTF 检查通过，探针进程常驻且无重启。
高危规则先在告警模式运行 72 小时。
每条规则日均告警量低于 10 条。
阻断类策略有回滚开关。
事件已接入集中日志，保留期满足合规要求。

行动建议：今天先在一台预发机完成环境自检与 Tetragon 最小规则验证，把「Shell 启动」和「敏感目录写入」两条规则跑通；一周内完成白名单收敛，再逐步扩展到容器逃逸与反弹连接检测。工具只是起点，规则运营才是 eBPF 主机入侵检测真正产生价值的地方。

常见问题（FAQ）

eBPF 主机入侵检测会不会拖慢服务器性能？

通常不会明显拖慢。eBPF 程序在内核中执行，事件过滤在采集端完成，只有命中规则的数据才复制到用户态，避免了传统审计把全量日志写盘的开销。实际影响取决于挂载点数量和事件频率，建议先用 Tetragon 或 Tracee 在预发环境观察 CPU 占用，再逐步扩大监控范围。

内核版本太低能跑 eBPF HIDS 吗？

需要满足最低版本要求。多数工具要求 Linux 4.18 以上，完整 BTF 支持建议 5.4 以上，使用 LSM 钩子则需 5.7 以上。低版本内核可退回 kprobe 模式，但可移植性和稳定性下降。上线前用 uname -r 与 ls /sys/kernel/btf/vmlinux 确认，缺失 BTF 时优先考虑升级内核。

Falco 和 Tetragon 应该怎么选？

看你的主要场景。Falco 规则生态成熟、告警表达力强，适合以检测和告警为主的传统主机与容器混合环境；Tetragon 基于 eBPF 做内核态过滤与策略执行，适合云原生环境做运行时阻断。两者也可并存，用 Tetragon 做执行层、Falco 做告警层，但要注意事件重复与资源叠加。

规则写好了但告警太多怎么办？

先做白名单收敛而不是直接关规则。统计高频触发的进程路径、父进程与容器镜像，把已知的包管理、日志轮转、健康检查行为加入例外；对文件写入类规则限定监控目录，对网络规则限定目的端口。建议按周迭代，把单条规则日均告警压到个位数再上线。

开源方案能替代商业 HIDS 吗？

多数场景可以覆盖核心检测需求。开源工具在进程执行、敏感文件访问、反弹 Shell 等检测上已足够，差距主要在托管运营、威胁情报联动与合规报表。团队有安全运维能力时优先自建，缺少人力可在开源探针之上叠加集中管理与告警降噪能力，例如结合 AegisX 的主机防护与告警聚合。

资讯中心