内核级恶意程序探测应优先启用auditd或eBPF传感器（如Defender for Endpoint、Osquery），禁用LKM加载并锁定内核参数；auditd通过规则监控execve、connect等系统调用，eBPF提供安全低开销行为检测，同时需禁用modules_disabled、kptr_restrict等加固内核。
内核级恶意程序探测不依赖用户态工具，而是通过内核机制捕获进程创建、系统调用、内存映射等底层行为。配置这类能力，核心是启用并合理使用 eBPF、auditd 或轻量传感器（如 Microsoft Defender for Endpoint 的 eBPF 传感器），而非手动编写或加载传统 LKM —— 后者本身风险高、易被用于隐藏，且现代发行版普遍禁用非签名模块。
启用 auditd 进行内核级进程行为审计
auditd 是 Linux 内置的内核审计框架，可记录 execve、openat、connect 等关键系统调用，无需额外模块，稳定性强、兼容性好。
- 确认 auditd 已安装并运行：sudo systemctl enable --now auditd
- 添加规则监控可疑行为（写入 /etc/audit/rules.d/process.rules）：
-a always,exit -F arch=b64 -S execve -k proc_exec
-a always,exit -F arch=b64 -S connect -F a2&0xffffffffffffffff -k proc_connect
-a always,exit -F arch=b64 -S openat -F path=/etc/shadow -k sensitive_file - 重载规则：sudo augenrules --load && sudo systemctl restart auditd
- 实时查看告警：sudo ausearch -k proc_exec -i | grep -E "(sh|bash|python|perl)"
部署基于 eBPF 的行为监控（推荐 Defender for Endpoint 或 Osquery）
eBPF 程序在内核中安全执行，无法被用户态 rootkit 干扰，是当前最可靠、低开销的内核级行为探测方式。
- Microsoft Defender for Endpoint（Linux）：自动部署基于 eBPF 的传感器，无需编译或签名，支持行为建模（如异常 fork/exec 链、内存注入检测）、云联动响应；
安装后默认开启“行为监视”和“下一代保护”，可在 Defender 门户中设置自定义 IOC 或进程白名单策略。 - Osquery + Fleet：用 SQL 查询内核行为视图，例如：
SELECT pid, name, cmdline FROM process_events WHERE time > (strftime('%s','now') - 300) AND event_type = 'spawn';
需启用 osquery 的 --enable_process_events 和 eBPF backend（要求内核 ≥5.3）。
禁用危险内核功能，防止恶意模块加载
真正的“探测”始于杜绝攻击面。很多内核级恶意程序依赖动态模块加载或调试接口实现持久化。
- 禁止运行时加载内核模块：echo 'kernel.modules_disabled = 1' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
- 锁定内核参数（防止绕过）：sudo sysctl kernel.kptr_restrict=2（隐藏内核地址）、kernel.dmesg_restrict=1
- 检查是否已有污染模块：lsmod | grep -E '(hide|root|knark|adore)' || echo "no suspicious module"，再结合 cat /proc/sys/kernel/tainted 确认内核纯净度
补充：慎用 strace/ltrace 做“准内核级”监控
strace 不是内核模块，但能以 ptrace 方式拦截系统调用，适合临时深度分析单个可疑进程，不可长期全量启用（性能损耗大、易被规避）。
- 对 PID 为 1234 的进程做轻量行为捕获：strace -e trace=execve,connect,openat -f -s 256 -o /tmp/proc1234.log -p 1234
- 注意：该命令自身会被目标进程感知，仅适用于取证阶段，不建议作为常驻探测手段
