关于 Linux 终端安全监控

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

最近两年笔者对于 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 机制，让大部分符号都动态查寻获取。然后引入英伟达的驱动思路，让底座开源，核心代码闭源为弱符号的二进制使内核平台无关。如若成功，将无需再逐内核编译适配了。

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

No Comments Yet

Linux 安全监控 ebpf

[原创]关于 Linux 终端安全监控