关于 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
这如果不在异常/中断上下文就好了。
优势：
缺陷：
- 非正常的进程上下文，禁止睡眠、挂起
- 甚至仅仅是通过 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 的系统监控方案
