云原生主机防护实战：HIDS、eBPF与容器逃逸检测对比

核心要点（TL;DR）

HIDS管文件与日志完整性，eBPF管内核行为，容器逃逸检测管命名空间与能力越界，三者互补不可替代。
eBPF方案性能开销通常低于传统内核模块HIDS，但需要较新内核（4.18+）与BTF支持。
容器逃逸检测重点看特权容器、hostPID/hostNetwork、敏感挂载与capability集合。
上线前先做基线白名单，否则运行时告警会淹没真正的入侵信号。

云原生把主机边界打散了：容器生命周期以分钟计，Pod 随时漂移，传统基于文件哈希和日志的巡检往往在入侵发生几小时后才报警。很多运维的真实困境是——装了主机入侵检测系统（HIDS），告警一天几百条却分不清哪条是真入侵；想上 eBPF 又担心内核不兼容；容器逃逸更是只在出事之后才回头查配置。本文按「是什么—怎么查—怎么做」的顺序，给出可直接执行的命令与检查清单。

一、三种能力到底在防什么

先把概念对齐，避免选型时把互补关系当成替代关系。

方案	检测层面	典型能力	主要短板
HIDS	文件、日志、配置	文件完整性、暴力破解、Webshell、基线核查	短生命周期容器覆盖弱，告警噪音大
eBPF	内核行为	进程执行、网络连接、系统调用、提权行为	依赖较新内核，需要白名单治理
容器逃逸检测	命名空间与权限	特权容器、敏感挂载、capability 越界	偏配置面，需配合运行时行为

一句话：HIDS 管「东西有没有被改」，eBPF 管「进程在干什么」，逃逸检测管「权限给多了没有」。三者叠加才形成闭环。

二、先查容器逃逸面：5 分钟扫出高危配置

逃逸检测的第一步不是装工具，而是把现有工作负载的危险配置找出来。用 kubectl 快速筛查：

# 找出特权容器
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].securityContext.privileged==true) | .metadata.namespace + "/" + .metadata.name'

# 找出共享宿主机命名空间的 Pod
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.hostPID==true or .spec.hostNetwork==true or .spec.hostIPC==true) | .metadata.namespace + "/" + .metadata.name'

再检查挂载与 capability：

挂载 /var/run/docker.sock、/proc、宿主机根目录的容器，一律视为高危。
capability 含 SYS_ADMIN、SYS_PTRACE、NET_ADMIN 的，逐条确认业务必要性。
以 root 运行且未设置 readOnlyRootFilesystem 的容器，优先整改。

整改建议：用准入控制（如 OPA Gatekeeper 或 Kyverno）直接拒绝特权容器，存量工作负载按「先告警、后拦截」两阶段推进。

三、部署 eBPF 运行时检测：命令与验证

以常见的开源 eBPF 运行时安全工具为例，先确认内核条件：

uname -r
ls /sys/kernel/btf/vmlinux && echo "BTF OK"

内核 4.18 以上且有 BTF 时，可直接以容器方式部署采集器（以 DaemonSet 形式运行在宿主机命名空间）。部署后必须做三件事验证：

执行 nsenter --target 1 --mount --uts --ipc --net --pid -- bash，确认告警能捕获命名空间切换行为。
在容器内执行 cat /proc/1/root/etc/shadow，确认敏感文件读取被记录。
模拟 insmod 或写入 /etc/ld.so.preload，确认高危规则触发。

若内核过老、工具退化为 kprobe 模式，性能会明显下降，建议优先升级节点内核，而不是硬扛。

四、HIDS 保留但要做减法

HIDS 的价值在文件完整性与合规基线，不必让它承担全部运行时检测。落地时：

只对关键路径做实时监控：/etc、/usr/bin、/root/.ssh、Web 根目录。
关闭对日志目录、缓存目录、容器临时层的完整性告警。
把暴力破解、Webshell 检测规则与 eBPF 的进程行为做关联，减少重复告警。

五、上线检查清单

特权容器、hostPID/hostNetwork 已清零或有豁免记录。
eBPF 采集器覆盖全部节点，验证用例全部触发。
高危规则（写 /etc、加载模块、nsenter、反弹 shell）保持全量告警。
告警分级到人，P0 有值班通道，P2 进日报。
白名单每周复核一次，避免长期漂移。

行动建议：本周先完成第二节的逃逸面扫描，输出高危清单；下周部署 eBPF 采集并跑通三个验证用例；HIDS 同步做规则减法。若团队缺少专职安全人力，可考虑 AegisX 这类提供主机与容器统一视图的平台，把采集、基线与告警收敛在一处，降低自建维护成本。

常见问题（FAQ）

HIDS和eBPF到底该选哪个，能不能只装一个？

结论是优先eBPF做行为采集，HIDS保留文件完整性校验。eBPF擅长追踪进程、网络与系统调用，开销低、粒度细；HIDS在文件篡改、日志审计与合规检查上更成熟。只装一个会留下盲区：纯eBPF缺少基线比对，纯HIDS看不到短生命周期的容器行为。建议eBPF负责运行时检测，HIDS负责文件与配置基线，两者数据在SIEM侧关联。

容器逃逸检测最该关注哪些配置项？

结论是先查特权与命名空间共享。重点包括：privileged: true、hostPID、hostNetwork、hostIPC、挂载/var/run/docker.sock或宿主机根目录、CAP_SYS_ADMIN等危险capability、以及以root运行的容器。这些配置本身不等于被入侵，但一旦容器内出现提权或挂载行为，逃逸成本极低。建议用准入控制直接拦截特权容器，并对存量工作负载做一次全量扫描。

eBPF方案对内核版本有什么要求，老系统怎么办？

结论是4.18以上内核加BTF支持体验最好。主流发行版中Ubuntu 20.04+、CentOS Stream 8+、Debian 11+基本可用；内核低于4.14或缺少BTF时，部分工具会退化为内核模块或kprobe模式，兼容性和性能都会下降。老系统建议先升级内核或迁移节点，实在无法升级则用HIDS加审计日志兜底，并限制容器密度。

运行时告警太多，怎么降噪？

结论是先做基线白名单再谈检测。步骤：观察一周正常行为，把已知镜像、启动命令、监听端口、外联域名加入白名单；对文件路径按目录粒度放行；对高危规则（如写入/etc、加载内核模块、nsenter）保持全量告警。同时给告警分级，P0直接通知值班，P2只进日报。降噪的核心是缩小检测面而不是关规则。

中小团队没有安全专职人员，最低成本的落地方案是什么？

结论是先用开源工具搭最小闭环。主机侧部署eBPF运行时检测加文件完整性校验，容器侧开启准入控制拦截特权配置，日志统一收集到一处并配置几条高危规则告警。每周花半小时看一次新增告警与配置漂移。等团队规模上来再考虑商业化平台，AegisX这类方案可提供主机与容器统一视图，减少自建维护成本。

资讯中心