用 eBPF 做主机防护：内核钩子能拦住什么

主机防护这块，eBPF 这两年从「观测工具」长成了「能拦事的组件」。但把它当成万能方案，上线后很快会遇到一堆现实问题。

这篇写清它能做什么、拦不住什么，以及上线前要先想好的几件事。

为什么用 eBPF 而不是内核模块

内核模块要跟着内核版本跑，升级系统就可能编不过；写错一行还能把整台机器带崩。

eBPF 走的是内核提供的挂载点，程序先经过校验再执行，出错的爆炸半径小得多，也能在不重启服务的情况下加载和卸载。对长期运行的机器来说，这几点比极致性能更重要。

能拦住的：进程、网络、文件

• 进程：谁启动了谁、命令行参数是什么、继承关系如何
• 网络：连接目标、端口、协议，以及发起连接的进程归属
• 文件：谁读了写改了哪个路径，是否触碰敏感目录

这三类事件覆盖了主机上绝大多数可疑行为，也是规则的主要来源。

拦不住的：语义层的东西

它能告诉你「某个进程读取了一堆配置文件」，但判断不出这算不算越权——那取决于业务语义。

同样一条读取行为，在备份服务和陌生进程身上含义完全不同。所以规则必须结合进程身份、时间窗口和行为序列来看，单看一条事件一定会淹在误报里。

性能不是免费：钩子加在哪很关键

挂载点选得不好，代价会直接体现在系统调用延迟上。高频路径上的钩子，一秒钟可能被调用几十万次。

经验做法是：先只观测不拦截，看清事件频率的分布，再决定把拦截加在哪些点上。高频且低价值的事件，用采样或聚合代替逐条上报。

误报治理比规则数量重要

刚开始很容易追求规则数量，最后发现运维的精力全耗在确认真实业务行为上。

更有效的做法是给每条规则定基线：先跑一段时间只记录不告警，把正常的调用特征摸出来，再收紧阈值。同时准备好白名单机制，并且要求白名单必须写清理由和到期时间。

和其它组件的配合

eBPF 解决的是主机内部的可见性。账号体系、权限分级、以及跨主机的关联分析，仍然要靠别的组件。

把它当成链路里的一个传感器，而不是整套方案，定位会清楚很多。

日志与数据落哪

事件量比想象中大。全量落盘，几天就能堆出几十 G，还会把真正要看的线索淹没。

我的做法是分层：原始事件只在本地环形缓冲里保留很短一段时间，用于回溯现场；聚合后的指标和命中规则的记录才长期保存。

这样既能事后追查，又不会让存储成本失控。要注意的是环形缓冲的时间窗必须写进文档，别让后来的人以为能查到更早的数据。

结论

eBPF 让内核层的能力变得可编程，这是实打实的进步。但它只是把「看得见」变成「能动手」，判断什么该动手，仍然是写规则、定基线、做取舍的活。

先想清楚要防什么，再决定钩子挂在哪。

本文不构成任何安全建议，具体方案请结合自身环境与专业评估。