防范代码执行类篡改入侵的核心是保持系统关键组件的可验证原始状态，通过一致性审计比对运行态与可信基线，覆盖系统命令、动态库、启动配置、内核模块及应用入口，并以哈希+gpg签名固化基线，结合auditd、ebpf等运行时监控和自动化闭环响应实现主动防御。
要防范代码执行类篡改入侵，核心不是等攻击发生后再响应，而是让系统关键组件始终保持可验证的“原始状态”。一致性审计就是定期比对当前运行态与可信基线的差异，一旦发现非授权变更——比如被注入的恶意函数、被替换的二进制文件、被劫持的共享库加载路径——就能第一时间定位风险源头。
明确哪些组件属于“关键”并建立可信基线
不是所有文件都需要审计，重点盯住那些具备执行能力或直接影响执行流的组件：
- 系统级可执行文件：/bin、/usr/bin 下的核心命令（如 bash、ls、ps、curl），以及 /sbin 中的管理工具（如 ifconfig、iptables）
- 动态链接库：/lib、/lib64、/usr/lib 中的 libc.so、libssl.so 等高频加载库，特别是被 setuid 程序依赖的模块
- 启动与服务配置：/etc/init.d、/etc/systemd/system、/etc/cron.* 目录下的脚本和服务定义，它们决定系统开机后“自动跑什么”
- 内核模块与加载机制：/lib/modules/$(uname -r)/kernel/ 下的.ko 文件，以及 /etc/modules、/etc/modprobe.d/ 中的加载规则
- 应用层关键入口：Web 服务器的模块目录（如 Apache 的 modules/、Nginx 的 modules/）、PHP 扩展目录（/usr/lib/php/*/ext/）、Python site-packages 中的常用安全/运维类包（如 requests、paramiko）
用哈希+签名双校验实现可信基线固化
仅靠一次 MD5 或 SHA256 校验不够——攻击者可能同步篡改校验值。必须把基线本身“锁死”在可信位置：
- 首次采集时，在离线环境或已确认干净的宿主机上，用 sha256sum 对上述关键路径生成完整哈希清单，并用 GPG 私钥签名（例如：sha256sum -r /bin/* | gpg --clearsign > baseline.sha256.asc）
- 将签名后的基线文件（.asc）存放在独立于被审计系统的介质上，如只读 USB 设备、Air-gapped 服务器或硬件安全模块（HSM）中
- 每次审计前，先用公钥验证签名有效性（gpg --verify baseline.sha256.asc），再解压比对哈希，杜绝基线被伪造
监控运行时加载行为，捕获“看不见”的篡改
有些篡改不改文件本身，而是绕过文件系统直接干预执行过程，例如 LD_PRELOAD 注入、eBPF 程序挂载、LKM 模块加载。这类行为需通过运行时观测补位：
- 启用 auditd 规则，持续记录 execve() 系统调用、openat() 对关键路径的访问、init_module() 和 delete_module() 内核模块操作
- 定期检查 /proc/[pid]/maps 和 /proc/[pid]/environ，识别进程是否加载了非白名单路径的 so 库或设置了可疑环境变量
- 使用 eBPF 工具（如 bpftrace）监控 syscalls 中的 ptrace、mmap(PROT_EXEC)、bpf(BPF_PROG_LOAD) 等高危行为，这些常被 VoidLink 等高级恶意软件用于隐蔽驻留
自动化审计+闭环响应，避免人工漏检
人工巡检既慢又不可持续。应构建轻量级自动化流水线：
- 每天凌晨定时执行基线比对脚本，输出差异报告；若发现哈希不匹配或新增未签名文件，立即触发告警并冻结对应服务（如 systemctl stop nginx）
- 集成到 CI/CD 流程中：新镜像构建时自动扫描其 rootfs，对比已知安全基线镜像（如官方 Ubuntu:22.04 的 manifest hash），拒绝非一致镜像部署
- 配合 Defender for Servers 的 File Integrity Monitoring 功能，将审计结果同步至云端控制台，满足 PCI-DSS 等合规要求中的“变更检测与审计日志留存”条款
