很多团队上了容器和 K8s 之后，主机侧的安全反而更看不清了：容器生命周期短、进程行为动态，传统基于文件完整性和日志采集的 HIDS 要么采不到容器内行为，要么 agent 开销大到不敢全量开。结果是入侵发生了却只能事后翻日志。eBPF 主机入侵检测正是为解决这个矛盾出现的：它把观测点放进内核，用极低开销拿到进程、文件、网络、权限的真实行为。本文面向要动手落地的运维和站长，讲清原理、给出可执行的部署与调优步骤。

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

eBPF 允许把经过校验的小程序挂载到内核的 tracepoint、kprobe、cgroup hook 上，事件触发时在内核态完成过滤和聚合，只把有价值的数据送到用户态。相比传统 agent 轮询 /proc、解析 auditd 日志，它有三个直接好处：

• 低开销：避免大量上下文切换与日志落盘，高频 syscall 场景优势明显。
• 不可绕过：观测点在系统调用层，容器内进程难以隐藏行为。
• 上下文完整：能同时拿到 pid、cgroup、容器 ID、命令行、父进程链。

一句话：它把「谁在什么容器里、对什么文件、发起了什么系统调用」变成可检索的结构化事件，这正是入侵检测需要的原始素材。

二、部署前必须先做的内核与环境检查

eBPF 能力与内核版本强相关，跳过检查直接装，最常见的结果是规则静默不生效。按顺序执行：

uname -r
ls /sys/kernel/btf/vmlinux
mount | grep cgroup
bpftool feature probe kernel | head -40

• 内核建议 5.8+，最低 4.18；容器场景需 cgroup v2。
• /sys/kernel/btf/vmlinux 存在说明有 BTF，CO-RE 程序可直接移植。
• 缺少 BTF 时安装 kernel-devel 对应版本，或升级内核。
• 确认 kernel.unprivileged_bpf_disabled=1，避免非特权进程滥用 eBPF。

检查清单：内核版本、BTF、cgroup v2、SELinux/AppArmor 状态、节点是否已装其他 tracing agent（避免 hook 冲突）。

三、开源方案对比与选型

方案	定位	适合场景	注意点
Falco	运行时威胁检测	快速建立告警基线	规则多，需调优降噪
Tetragon	eBPF 策略与执行	关键路径阻断	策略编写需理解内核语义
Tracee	事件追踪与检测	取证与规则开发	事件量大，注意采样

实践建议：先用 Falco 建立「看得见」的检测能力，再把必须拦截的场景（如容器内起 shell、写入 /etc）交给 Tetragon 做内核态阻断。两者可同节点共存，但同一 hook 点不要重复挂载。

四、分步落地：从部署到第一条有效告警

步骤 1：以 Helm 部署并保持观察模式

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true

先只开告警不阻断，观察 3 到 7 天，采集正常业务行为。

步骤 2：只启用高价值规则

初期聚焦三类：容器内交互式 shell、敏感文件写入（/etc、/root/.ssh）、反弹 shell 与外连异常端口。用 falcoctl 管理规则集，按 tag 过滤启用，避免一次加载上千条规则。

步骤 3：白名单与基线调优

• 按 namespace、镜像标签、进程名加例外，而不是简单按告警文本屏蔽。
• CI 构建、包管理器、日志轮转是误报大户，单独建规则组。
• 每周复盘告警，保留能闭环的规则，删掉长期无人处理的。

步骤 4：验证检测是否真的生效

kubectl exec -it test-pod -- /bin/sh
# 在容器内执行后应产生告警
echo test > /etc/passwd

若未触发，依次检查 eBPF 程序是否加载（bpftool prog show）、规则是否被禁用、告警通道是否通。

五、告警降噪与运营闭环

eBPF 检测最大的坑不是采不到，而是采太多。建议把告警分三级：高危（反弹 shell、提权、敏感文件篡改）实时推送到 IM 并电话升级；中危（异常外连、可疑进程）进工单；低危仅留存供取证。每条高危告警必须绑定处置动作，例如隔离 Pod、抓取进程树与命令行快照。防护建议上，可在节点侧配合 AegisX 的主机与容器运行时防护能力，把检测到的异常行为与拦截策略联动，减少人工响应延迟。

六、行动建议

先在一个非核心集群完成内核检查与 Falco 观察模式部署，只启用三类高价值规则，跑满一周后做第一次白名单收敛。稳定后再扩展到 Tetragon 做关键路径阻断，并把告警接入现有值班流程。记住：规则数量不等于安全水位，能闭环的告警才有价值。

常见问题（FAQ）

eBPF 主机入侵检测对内核版本有什么要求？

结论：建议 5.8 以上内核，最低 4.18。eBPF 的 tracepoint、kprobe 与 ring buffer 能力随内核演进差异较大，容器场景还需 cgroup v2 与 BTF 支持。部署前用 uname -r 查看版本，并确认 /sys/kernel/btf/vmlinux 存在；缺失时需升级内核或安装对应 kernel-devel 包，否则部分探针与规则会静默失效。

eBPF 检测会不会拖慢业务性能？

结论：正常配置下开销通常在个位数百分比。eBPF 程序在内核态执行，避免了传统 agent 频繁上下文切换与用户态复制。但挂载过多 kprobe、开启全量事件上报或在高频 syscall 上做复杂过滤时，CPU 会明显上升。建议先用默认规则集压测，再用 bpftool prog show 观察程序数量，按需裁剪事件类型。

Falco 和 Tetragon 应该怎么选？

结论：要快速上手选 Falco，要内核级策略执行选 Tetragon。Falco 规则生态丰富、告警渠道多，适合先建立检测基线；Tetragon 基于 eBPF 做进程与网络策略，支持在内核态直接阻断。两者可并存：Falco 负责发现与告警，Tetragon 负责关键路径的强制拦截，按团队运维能力分阶段引入。

容器环境里怎么减少误报？

结论：先建基线再开告警，白名单按镜像与命名空间收敛。容器内进程行为高度动态，直接套用主机规则会大量误报。建议先以观察模式运行一周，采集正常行为，再针对 CI 构建、包管理、日志轮转等高频动作加白名单，并按 namespace 与镜像标签做规则分组，逐步收紧。

没有专职安全团队能落地吗？

结论：可以，从单集群最小规则集起步。先选一个非核心集群部署开源方案，只启用进程执行、敏感文件写入、反弹 shell 三类高价值规则，告警接入现有 IM。稳定后再扩展规则与集群范围。关键是控制告警量，保证每条告警都有人看、能闭环，而不是追求规则数量。