心血来潮梳理出这篇文章且看且珍惜吧若有不足也感谢大佬指点一二。最近两年笔者对于 Linux 的应用层监控和内核层监控基本全研究了一遍并落地了两套两套方案都支持 3.10 及以上的内核版本如果不是反勒索甚至能兼容到 2.6。如果有屏幕前的你也在调研此方面的技术那么可以做个参考能少走很多弯路现在的就业形式一言难尽笔者在这上面花费了大量精力到头来却发现无用武之地所以没必要在这上面浪费太多精力。笔者的两套方案具体如下最初的一套是通过 FTrace LivePatch kprobe 实现的支持监控、反勒索、文保、自保。最新的一套是通过 tracepoint kprobe 实现的同样支持以上功能。如果业务需求不高笔者十分推荐使用应用层的 fanotify。若 ebpf 配合 fanotify感觉还是会遇到内核版本问题。还有一句忠告对于系统监控我的实战经验告诉我不要过于相信AiAi会把不可行的方案说成可行会把可行的方案予以否定。应用层PreloadPreload 的本质就是劫持动态库符号表使我们的符号优先于系统库glibc中的符号被找到并使用。优势比 ptrace 性能好比驱动通用性好无需逐一编译适配缺陷极其容易被 汇编、go、rust、musl 等静态编译方式的直接与内核交互的程序绕过由于是作为被监控者的依赖库被调用线程间、进程间(fd)临界资源问题比较严重印象里好像还与原生的安全机制有冲突例如 seccomp、snap 容器化对于刻意使用 dl 系列函数加载符号的程序难以适用ptraceptrace 就是我们平时使用的 strace、gdb 的底层核心接口。当时我觉得既然 strace 可以追踪系统调用、 gdb 调试过程中又可以阻塞应用那么 ptrace 肯定可以追踪并挂起即将执行的系统调用。事实证明我觉得没错但是优势无法被汇编、静态编译绕过比驱动通用性好无需逐一编译适配缺陷性能太差 ptrace 设计之初就是给调试用的难以并发要获取系统调用参数只能8字节8字节的从寄存器保存的目标进程用户空间地址往外取频繁的进出内核进一步拖慢了性能由于被追踪的互斥性导致与gdb、strace冲突虽然普通用户不会使用开发工具容易被反侦察当目标被追踪 /proc 目录中目标进程信息会有被调试的标识fanotify这其实是我最后发现的一种监控方式支持简单的文件访问控制。如果不追求极致的安全笔者十分建议采用这种方式。由于笔者没有深入的使用以下仅是个人推断。优势无法被汇编、静态编译绕过可以配合 /proc 目录中的信息扩展访问控制能力比驱动通用性好无需逐一编译适配缺陷若扩展能力则需要频繁的与 /proc/ 目录交互会有些性能损失访问控制能力有限导致提供的安全能力受限内核层eBPF关于eBPF前期纸面调研过程中就被我pass了。优势依托于 CO-RE 机制一次编译到处运行原生支持阻断无需暴力阻断缺点需要高版本内核无法面对信创平台已经铺开的3.x、4.x的内核需求只能支持基于规则的阻断、无法睡眠也无法把数据推往杀毒引擎扫描后再决定放行与否kprobe这如果不在异常/中断上下文就好了。优势任意符号位置基本都可插入hook缺陷非正常的进程上下文禁止睡眠、挂起甚至仅仅是通过copy_from_user取用户层参数触发缺页引发了挂起都不允许需要采集驱动构建套件进行编译适配lsm这也被 pass 掉了原因是收集了一些系统平台去做编译测试部分信创系统唯独缺少关于 lsm 的编译环境和条件导致编译不通过由于未深度使用以下优缺点仅仅是个人推断。此 lsm 非 ebpf-lsm 不要混淆。最近26.07.16查阅资料得知从内核4.x 后期开始关于驱动级 lsm 注册函数不再被导出了怪不得当时编译会失败……优势由于在更底层不会出现Double Fetch的问题处于进程上下文可以和应用层安全服务阻塞式交互缺陷部分场景可能拿不到业务层需要的全部数据需要配合读取 /proc 目录中的信息进行完善需要采集驱动构建套件进行编译适配新版本内核注册函数不再被导出FTrace这是个好方法但是唯独架构支持不全。优势处于进程上下文可以和应用层安全服务阻塞式交互缺陷测试了很多 arm64 的信创系统全都不被支持如果 Hook 点太浅容易被Double Fetch需要采集驱动构建套件进行编译适配LivePatch这有点杀鸡用牛刀了。优势可以插在任意位置和地址只要你认为这安全缺陷需要有一定的对应架构的汇编能力毕竟不是内核原生框架需要防御性编程需要采集驱动构建套件进行编译适配tracepoint这个很赞。优势处于进程上下文如果没有防御手段一样会被Double Fetch支持所有架构x64、arm64、mips64el、loongarch64、sw_64缺陷个别系统监控不到事件还没抽出时间调研需要采集驱动构建套件进行编译适配syscall_table差点把它忘了。优势处于进程上下文如果没有防御手段一样会被Double Fetch不需要复杂的寄存器解嵌套、读取操作支持所有架构缺陷在内核引入地址随机化 KASLR 之后无法再使用需要采集驱动构建套件进行编译适配后期优化思路
心血来潮梳理出这篇文章且看且珍惜吧若有不足也感谢大佬指点一二。最近两年笔者对于 Linux 的应用层监控和内核层监控基本全研究了一遍并落地了两套两套方案都支持 3.10 及以上的内核版本如果不是反勒索甚至能兼容到 2.6。如果有屏幕前的你也在调研此方面的技术那么可以做个参考能少走很多弯路现在的就业形式一言难尽笔者在这上面花费了大量精力到头来却发现无用武之地所以没必要在这上面浪费太多精力。笔者的两套方案具体如下最初的一套是通过 FTrace LivePatch kprobe 实现的支持监控、反勒索、文保、自保。最新的一套是通过 tracepoint kprobe 实现的同样支持以上功能。如果业务需求不高笔者十分推荐使用应用层的 fanotify。若 ebpf 配合 fanotify感觉还是会遇到内核版本问题。还有一句忠告对于系统监控我的实战经验告诉我不要过于相信AiAi会把不可行的方案说成可行会把可行的方案予以否定。应用层PreloadPreload 的本质就是劫持动态库符号表使我们的符号优先于系统库glibc中的符号被找到并使用。优势比 ptrace 性能好比驱动通用性好无需逐一编译适配缺陷极其容易被 汇编、go、rust、musl 等静态编译方式的直接与内核交互的程序绕过由于是作为被监控者的依赖库被调用线程间、进程间(fd)临界资源问题比较严重印象里好像还与原生的安全机制有冲突例如 seccomp、snap 容器化对于刻意使用 dl 系列函数加载符号的程序难以适用ptraceptrace 就是我们平时使用的 strace、gdb 的底层核心接口。当时我觉得既然 strace 可以追踪系统调用、 gdb 调试过程中又可以阻塞应用那么 ptrace 肯定可以追踪并挂起即将执行的系统调用。事实证明我觉得没错但是优势无法被汇编、静态编译绕过比驱动通用性好无需逐一编译适配缺陷性能太差 ptrace 设计之初就是给调试用的难以并发要获取系统调用参数只能8字节8字节的从寄存器保存的目标进程用户空间地址往外取频繁的进出内核进一步拖慢了性能由于被追踪的互斥性导致与gdb、strace冲突虽然普通用户不会使用开发工具容易被反侦察当目标被追踪 /proc 目录中目标进程信息会有被调试的标识fanotify这其实是我最后发现的一种监控方式支持简单的文件访问控制。如果不追求极致的安全笔者十分建议采用这种方式。由于笔者没有深入的使用以下仅是个人推断。优势无法被汇编、静态编译绕过可以配合 /proc 目录中的信息扩展访问控制能力比驱动通用性好无需逐一编译适配缺陷若扩展能力则需要频繁的与 /proc/ 目录交互会有些性能损失访问控制能力有限导致提供的安全能力受限内核层eBPF关于eBPF前期纸面调研过程中就被我pass了。优势依托于 CO-RE 机制一次编译到处运行原生支持阻断无需暴力阻断缺点需要高版本内核无法面对信创平台已经铺开的3.x、4.x的内核需求只能支持基于规则的阻断、无法睡眠也无法把数据推往杀毒引擎扫描后再决定放行与否kprobe这如果不在异常/中断上下文就好了。优势任意符号位置基本都可插入hook缺陷非正常的进程上下文禁止睡眠、挂起甚至仅仅是通过copy_from_user取用户层参数触发缺页引发了挂起都不允许需要采集驱动构建套件进行编译适配lsm这也被 pass 掉了原因是收集了一些系统平台去做编译测试部分信创系统唯独缺少关于 lsm 的编译环境和条件导致编译不通过由于未深度使用以下优缺点仅仅是个人推断。此 lsm 非 ebpf-lsm 不要混淆。最近26.07.16查阅资料得知从内核4.x 后期开始关于驱动级 lsm 注册函数不再被导出了怪不得当时编译会失败……优势由于在更底层不会出现Double Fetch的问题处于进程上下文可以和应用层安全服务阻塞式交互缺陷部分场景可能拿不到业务层需要的全部数据需要配合读取 /proc 目录中的信息进行完善需要采集驱动构建套件进行编译适配新版本内核注册函数不再被导出FTrace这是个好方法但是唯独架构支持不全。优势处于进程上下文可以和应用层安全服务阻塞式交互缺陷测试了很多 arm64 的信创系统全都不被支持如果 Hook 点太浅容易被Double Fetch需要采集驱动构建套件进行编译适配LivePatch这有点杀鸡用牛刀了。优势可以插在任意位置和地址只要你认为这安全缺陷需要有一定的对应架构的汇编能力毕竟不是内核原生框架需要防御性编程需要采集驱动构建套件进行编译适配tracepoint这个很赞。优势处于进程上下文如果没有防御手段一样会被Double Fetch支持所有架构x64、arm64、mips64el、loongarch64、sw_64缺陷个别系统监控不到事件还没抽出时间调研需要采集驱动构建套件进行编译适配syscall_table差点把它忘了。优势处于进程上下文如果没有防御手段一样会被Double Fetch不需要复杂的寄存器解嵌套、读取操作支持所有架构缺陷在内核引入地址随机化 KASLR 之后无法再使用需要采集驱动构建套件进行编译适配后期优化思路
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
