心血来潮，梳理出这篇文章，且看且珍惜吧，若有不足，也感谢大佬指点一二。

最近两年笔者对于 Linux 的应用层监控和内核层监控基本全研究了一遍并落地了两套，如果有屏幕前的你也在调研此方面的技术，那么可以做个参考，能少走很多弯路，现在的就业形式一言难尽，笔者在这上面花费了大量精力，到头来却发现无用武之地，所以没必要浪费太多精力。笔者的两套方案具体如下：

• 最初的一套是通过 FTrace + LivePatch + kprobe 实现的，支持监控与反勒索。
• 最新的一套是通过 tracepoint + kprobe 实现的，同样支持以上功能。
• 如果业务需求不高，笔者十分推荐使用应用层的 fanotify。

应用层

Preload

Preload 的本质就是劫持动态库符号表，使我们的符号优先于系统库（ glibc ）中的符号被找到并使用。

• 优势：
  • 比 ptrace 性能好
  • 比驱动通用性好，无需逐一编译适配
• 缺陷：
  • 极其容易被 汇编、go 、rust 、musl 等静态编译方式的直接与内核交互的程序绕过
  • 由于是作为被监控者的依赖库被调用，线程间、进程间(fd)临界资源问题比较严重
  • 印象里好像还与原生的安全机制有冲突，例如：seccomp 、snap 容器化
  • 对于刻意使用 dl 系列函数加载符号的程序难以适用

ptrace

ptrace 就是我们平时使用的 strace 、gdb 的底层核心接口。当时我觉得既然 strace 可以追踪系统调用、gdb 调试过程中又可以阻塞应用，那么 ptrace 肯定可以追踪并挂起即将执行的系统调用。事实证明我觉得没错，但是！

• 优势：
  • 无法被汇编、静态编译绕过
  • 比驱动通用性好，无需逐一编译适配
• 缺陷：
  • 性能太差，ptrace 设计之初就是给调试用的，难以并发
  • 要获取系统调用参数只能 8 字节 8 字节的从寄存器往外取，进一步拖慢了性能
  • 容易被反侦察，当目标被追踪， /proc 目录中目标进程信息会有被调试的标识

fanotify

这其实是我最后发现的一种监控方式，支持简单的文件访问控制。如果不追求极致的安全，笔者十分建议采用这种方式。由于笔者没有深入的使用，以下仅是个人推断。

• 优势：
  • 无法被汇编、静态编译绕过
  • 可以配合 /proc 目录中的信息扩展访问控制能力
  • 比驱动通用性好，无需逐一编译适配
• 缺陷：
  • 若扩展能力则需要频繁的与 /proc/ 目录交互，会有些性能损失
  • 访问控制能力有限，导致提供的安全能力受限

内核层

eBPF

关于 eBPF 前期调研过程中就被我 pass 了。

• 优势：
  • 依托于 CO-RE 机制一次编译，到处运行
  • 原生支持阻断，无需暴力阻断
• 缺点：
  • 需要高版本内核，无法面对信创平台已经铺开的 3.x 、4.x 的内核需求
  • 只能支持基于规则的阻断、无法睡眠也无法把数据推往杀毒引擎扫描后，再决定放行与否

kprobe

• 这如果不在异常/中断上下文就好了。
  • 优势：
    • 任意符号位置，基本都可插入 hook
  • 缺陷：
    • 非正常的进程上下文，禁止睡眠、挂起
    • 甚至仅仅是通过 copy_from_user 取用户层参数触发缺页，引发了挂起，都不允许
    • 需要采集驱动构建套件进行编译适配

lsm

这也被 pass 掉了，原因是收集了一些系统平台去做编译测试，部分信创系统唯独缺少关于 lsm 的编译环境和条件，导致编译不通过，由于未深度使用，以下优缺点仅仅是个人推断。

• 优势：
  • 由于在更底层，不会出现 Double Fetch 的问题
  • 处于进程上下文，可以和应用层安全服务阻塞式交互
• 缺陷：
  • 部分场景可能拿不到业务层需要的全部数据，需要配合读取/proc 目录中的信息进行完善
  • 需要采集驱动构建套件进行编译适配

FTrace

这是个好方法，但是唯独架构支持不全。

• 优势：
  • 处于进程上下文，可以和应用层安全服务阻塞式交互
• 缺陷：
  • 测试了很多 arm64 的信创系统，全都不被支持
  • 如果 Hook 点太浅，容易被 Double Fetch
  • 需要采集驱动构建套件进行编译适配

LivePatch

这有点杀鸡用牛刀了。

• 优势：
  • 可以插在任意位置和地址，只要你认为这安全
• 缺陷：
  • 需要有一定的对应架构的汇编能力
  • 毕竟不是内核原生框架，需要防御性编程
  • 需要采集驱动构建套件进行编译适配

tracepoint

这个很赞。

• 优势：
  • 处于进程上下文
  • 如果没有防御手段，一样会被 Double Fetch
  • 支持所有架构（ x64 、arm64 、mips64el 、loongarch64 、sw_64 ）
• 缺陷：
  • 个别系统监控不到事件，还没调研
  • 需要采集驱动构建套件进行编译适配

syscall_table

差点把它忘了。

• 优势：
  • 处于进程上下文
  • 如果没有防御手段，一样会被 Double Fetch
  • 支持所有架构
• 缺陷：
  • 在内核引入地址随机化 KASLR 之后，无法再使用
  • 需要采集驱动构建套件进行编译适配

后期优化思路

准备模仿 eBPF 的 CO-RE 机制，让大部分符号都动态查寻获取。然后引入 英伟达 的驱动思路，让底座开源，核心代码闭源为弱符号的二进制使内核平台无关。如若成功，将无需再逐内核编译适配了。

上述部分应用层方案已开源，若感兴趣可自行查看

• 二斌的 GitHub：基于 ptrace 的系统监控方案
• 二斌的 GitHub：基于 Preload 的系统监控方案