[原创]关于 Linux 终端系统监控-编程技术-看雪安全社区

[原创]关于 Linux 终端系统监控

发表于: 2026-6-25 22:51 1772

[原创]关于 Linux 终端系统监控

二斌

2026-6-25 22:51

1772

<div align="center">
  <h1>关于 Linux 终端系统监控</h1>
</div>

---

心血来潮，梳理出这篇文章，且看且珍惜吧，若有不足，也感谢大佬指点一二。
最近两年笔者对于 Linux 的应用层监控和内核层监控基本全研究了一遍并落地了两套，两套方案都支持 `3.10` 及以上的内核版本，如果不是反勒索，甚至能兼容到 `2.6`。如果有屏幕前的你也在调研此方面的技术，那么可以做个参考，能少走很多弯路，现在的就业形式一言难尽，笔者在这上面花费了大量精力，到头来却发现无用武之地，所以没必要在这上面浪费太多精力。笔者的两套方案具体如下：
  - 最初的一套是通过 `FTrace + LivePatch + kprobe` 实现的，支持监控、反勒索、文保、自保、提权检测。
  - 最新的一套是通过 `tracepoint + kprobe` 实现的，同样支持以上功能。
  - 如果业务需求不高，笔者十分推荐使用应用层的 `fanotify`。
  - 若 `ebpf` 配合 `fanotify`，感觉还是会遇到内核版本问题。

还有一句忠告，对于系统监控，我的实战经验告诉我不要过于相信Ai，Ai会把不可行的方案说成可行，会把可行的方案予以否定。

---

---

<div align="center">
  <h3>Preload</h3>
</div>

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

---

<div align="center">
  <h3>ptrace</h3>
</div>

ptrace 就是我们平时使用的 strace、gdb 的底层核心接口。当时我觉得既然 strace 可以追踪系统调用、 gdb 调试过程中又可以阻塞应用，那么 ptrace 肯定可以追踪并挂起即将执行的系统调用。事实证明我觉得没错，但是！
  - 优势：
      - 无法被汇编、静态编译绕过
      - 比驱动通用性好，无需逐一编译适配
  - 缺陷：
      - 性能太差， ptrace 设计之初就是给调试用的，难以并发
      - 要获取系统调用参数只能8字节8字节的从寄存器保存的目标进程用户空间地址往外取，频繁的进出内核，进一步拖慢了性能
      - 由于被追踪的互斥性，导致与gdb、strace冲突，虽然普通用户不会使用开发工具
      - 容易被反侦察，当目标被追踪， /proc 目录中目标进程信息会有被调试的标识

---

<div align="center">
  <h3>fanotify</h3>
</div>

这其实是我最后发现的一种监控方式，支持简单的文件访问控制。如果不追求极致的安全，笔者十分建议采用这种方式。由于笔者没有深入的使用，以下仅是个人推断。
  - 优势：
      - 无法被汇编、静态编译绕过
      - 可以配合 /proc 目录中的信息扩展访问控制能力
      - 比驱动通用性好，无需逐一编译适配
  - 缺陷：
      - 若扩展能力则需要频繁的与 /proc/ 目录交互，会有些性能损失
      - 访问控制能力有限，导致提供的安全能力受限

---

---

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

---

<div align="center">
  <h3>kprobe</h3>
</div>

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

---

这也被 pass 掉了，原因是收集了一些系统平台去做编译测试，部分信创系统唯独缺少关于 lsm 的编译环境和条件，导致编译不通过，由于未深度使用，以下优缺点仅仅是个人推断。此 `lsm` 非 `ebpf-lsm` 不要混淆。最近（26.07.16）查阅资料得知从内核4.x 后期开始，关于驱动级 lsm 注册函数不再被导出了，怪不得当时编译会失败……
  - 优势：
      - 由于在更底层，不会出现Double Fetch的问题
      - 处于进程上下文，可以和应用层安全服务阻塞式交互
  - 缺陷：
      - 部分场景可能拿不到业务层需要的全部数据，需要配合读取 /proc 目录中的信息进行完善
      - 需要采集驱动构建套件进行编译适配
      - 新版本内核注册函数不再被导出

---

<div align="center">
  <h3>FTrace</h3>
</div>

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

---

<div align="center">
  <h3>LivePatch</h3>
</div>

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

---

<div align="center">
  <h3>tracepoint</h3>
</div>

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

---

<div align="center">
  <h3>syscall_table</h3>
</div>

差点把它忘了。
  - 优势：
      - 处于进程上下文
      - 如果没有防御手段，一样会被Double Fetch
      - 不需要复杂的寄存器解嵌套、读取操作
      - 支持所有架构
  - 缺陷：
      - 在内核引入地址随机化 `KASLR` 之后，无法再使用
      - 需要采集驱动构建套件进行编译适配

---

## 后期优化思路
准备模仿 eBPF 的 CO-RE 机制，让大部分符号都动态查寻获取。
或引入英伟达、英特尔、联发科的驱动思路，让底座开源，核心代码闭源为弱符号的二进制使内核平台无关。
再或者以上两者混合。
如若成功，将无需再逐内核编译适配了。

---

## 上述部分应用层方案已开源，若感兴趣可自行查看
- [二斌的GitHub：基于 ptrace 的系统监控方案](<mark class="encrypted">af6K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6w2L8$3&6Y4f1f1u0A6L8W2)9J5c8W2y4&6M7@1#2G2L8R3`.`.</mark> "二斌的GitHub")
- [二斌的GitHub：基于 Preload 的系统监控方案](<mark class="encrypted">07fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6w2L8$3&6Y4f1f1u0A6L8W2)9J5c8W2m8b7d9r3!0G2K9H3`.`.</mark> "二斌的GitHub")

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-8-16 18:39 被二斌编辑，原因：

#系统内核 #驱动开发 #HOOK/注入 #开源分享

收藏・1

点赞・2

打赏