[原创]常见 Linux 端点监控手段
常见 Linux 端点监控手段
心血来潮，梳理出这篇文章，且看且珍惜吧，若有不足，也感谢大佬指点一二。
前两年笔者花费大量精力对 Linux 的应用层监控和内核层监控基本全研究了一遍并落地了两套，且都支持 3.10 及以上的内核版本，如果不是反勒索代码兼容成本有点高，甚至能兼容到 2.6，如果有屏幕前的你也在调研此方面的技术，那么可以做个参考，能少走很多弯路，虽说精力花费巨大，但到头来却发现就业岗位非常之稀缺，EDR狂热的时代已经过去了……所以也就没必要在这上面浪费太多精力了。
笔者的两套方案具体如下：
- 最初的一套是通过
FTrace + LivePatch + syscall_table + kretprobe混合实现的，支持监控、反勒索、文保、自保、提权检测…… - 最新的一套则是通过
tracepoint + kretprobe实现的，同样支持以上功能，但大幅降低了维护成本 - 如果服务的客户有很多老旧系统，推荐直接采用
tracepoint + kretprobe方案 - 如果追求战未来以及进一步降低维护成本
eBPF + fnotify其实也很不错
由于时间跨度之久（2023.06~2026.03），导致文章中对个别监控方法的特点描述可能会有些许出入，本人发现错误也会及时修改，望谅解。
还有一句忠告，对于系统监控，实战经验告诉我不要过于相信当前（~2026）的Ai，很多的场景还是需要实际着手验证最为稳妥。
应用层
Preload
Preload 的本质就是劫持动态库符号表，使我们的符号优先于系统库（glibc）中的符号被找到并使用。
- 特点：
- 比 ptrace 性能好
- 比驱动通用性好，无需逐一编译适配
- 极其容易被 汇编、go、rust、musl 等静态编译方式的直接与内核交互的程序绕过
- 由于是作为被监控者的依赖库被调用，线程间、进程间(fd)临界资源问题比较严重
- 印象里好像还与原生的安全机制有冲突，例如： seccomp、snap 容器化
- 对于刻意使用 dl 系列函数加载符号的程序难以适用
ptrace
ptrace 就是我们平时使用的 strace、gdb 的底层核心接口。当时我觉得既然 strace 可以追踪系统调用、 gdb 调试过程中又可以阻塞应用，那么 ptrace 肯定可以追踪并挂起即将执行的系统调用。事实证明我觉得没错，但是我高兴早了……
- 特点：
- 无法被汇编、静态编译绕过
- 比驱动通用性好，无需逐一编译适配
- 性能太差， ptrace 设计之初就是给调试用的，难以并发
- 要获取系统调用参数只能8字节8字节的从寄存器保存的目标进程用户空间地址往外取，频繁的进出内核，进一步拖慢了性能
- 由于被追踪的互斥性，导致与gdb、strace冲突，虽然普通用户不会使用开发工具
- 容易被反侦察，当目标被追踪， /proc 目录中目标进程信息会有被调试的标识
fanotify
这其实是我最后发现的一种监控方式，支持简单的文件访问控制，甚至高一些的内核版本可以区分文件执行行为。
如果不追求极致的同步，笔者十分建议采用这种方式。由于笔者没有深入的使用，以下仅是个人推断。
- 特点：
- 自身访问控制能力有限
- 需要一定的内核版本支持
- 无法被汇编、静态编译绕过
- 比驱动通用性好，无需逐一编译适配
- 可以配合 /proc目录中的信息 弥补信息采集上的一些缺陷
- 可以配合 eBPF 弥补自身监控能力不全的缺陷
内核层
eBPF
eBPF是内核社区的新宠，是当下也会是未来的安全主力；其属于内核层，但不属于驱动类。
- 特点：
- 原生支持阻断，无需暴力阻断
- 无需关心 Double Fetch 问题
- 依托于 CO-RE 机制一次编译，到处运行
- 相较于驱动要适配不同的内核版本、补丁版本，维护成本大大降低
- 需要高版本内核支持，无法面对信创平台已经铺开的3.x、4.x的内核需求
- 只能支持基于规则的阻断、无法睡眠也无法把数据推往杀毒引擎扫描后，再决定放行与否，但可以与 fanotify 打配合
kprobe
这如果不在异常/中断上下文就好了。
- 特点：
- 任意符号位置，基本都可插入 hook
- 非正常的进程上下文，禁止睡眠、挂起
- 甚至仅仅是通过 copy_from_user 取用户层参数触发缺页中断，引发了挂起，都不允许
- 需要采集驱动构建套件进行编译适配
lsm
收集了一些系统平台去做编译测试，部分信创系统唯独缺少关于 lsm 的编译环境和条件，导致编译不通过，查阅资料得知从内核4.x 后期开始，关于驱动级 lsm 注册函数不再被导出了。由于未深度使用，以下特点仅是个人推断。此 lsm 非 ebpf-lsm 。
- 特点：
- 由于在更底层，不会出现 Double Fetch 的问题
- 处于进程上下文，可以和应用层安全服务阻塞式交互
- 部分场景可能拿不到业务层需要的全部数据，需要配合读取 /proc 目录中的信息进行完善
- 需要采集驱动构建套件进行编译适配
- 新版本内核注册函数不再被导出
FTrace
这是个好方法，但是唯独架构支持不全。
- 特点：
- 处于进程上下文，可以和应用层安全服务阻塞式交互
- 测试了很多 arm64、mips64el 的信创系统，全都不被支持
- 如果 Hook 点太浅，容易被 Double Fetch
- 需要采集驱动构建套件进行编译适配
LivePatch
这有点杀鸡用牛刀了。
- 特点：
- 需要有一定的对应架构的汇编能力
- 可以插在任意位置和地址，只要你认为这安全
- 毕竟不是内核原生框架，需要防御性编程
- 需要采集驱动构建套件进行编译适配
tracepoint
这个很赞。
- 特点：
- 处于进程上下文
- 如果没有防御手段，一样会被 Double Fetch
- 支持所有架构（x64、arm64、mips64el、loongarch64、sw_64）
- 个别系统监控不到事件，还没抽出时间调研
- 需要采集驱动构建套件进行编译适配
syscall_table
差点把它忘了。
- 特点：
- 支持所有架构
- 处于进程上下文
- 需要采集驱动构建套件进行编译适配
- 不需要复杂的寄存器解嵌套、读取操作
- 如果没有防御手段，一样会被 Double Fetch
- 在内核引入地址随机化
KASLR之后，无法再使用
后期优化思路
- 思路一：
- 模仿 eBPF 的 CO-RE机制 将大部分符号指针化，驱动中仅保留少部分符号，然后通过修改已编译的驱动，达到兼容各个内核版本的目的。
- 思路二：
- 效仿各个知名硬件厂商的做法，将驱动拆分为开源底座 + 闭源业务逻辑的形式，通过现编译的底座加载预编译的业务逻辑bin文件，达到兼容各个内核版本的目的。
以上两者均可提高驱动的通用性。
浙公网安备 33010602011771号