Linux中文件完整性扫描的配置方法与实践

AIDE 是目前更稳妥的 Linux 文件完整性监控工具，因为它原生支持权限、属主、SHA256、inode 等多字段校验，同时具备数据库压缩与增量比对能力；在实际部署时，应精简配置规则、严格限制数据库权限并准确命名文件，才能有效避免误报、漏报和检测失效。

怎么选工具：AIDE 是当前最稳妥的选择

在 Linux 中做系统级文件完整性扫描，直接使用 aide 基本就足够了，没有必要再依赖 md5sum 或手写校验脚本。原因也很明确：MD5 早已被证实存在碰撞风险，md5sum 最多只能用于发现文件意外损坏，难以防御恶意替换；即使改成纯 sha256sum 脚本，虽然能校验文件内容，但权限、属主、硬链接数、ACL、SELinux 上下文等关键元数据仍然容易遗漏。相比之下，aide 对这些字段都提供原生支持，数据库还能压缩，并支持增量比对，更适合长期运行和持续监控。

/etc/aide.conf 规则怎么写才不误报

默认配置通常过于宽泛，执行一次检查就可能满屏都是 Changed，而其中大多数只是日志文件或临时文件正常刷新导致的误报。因此配置时必须手动精简规则：

• 定义简洁且明确的规则别名，例如：F = p+i+n+u+g+s+m+c+sha256（权限、inode、链接数、用户、组、大小、mtime、ctime、SHA256）
• 只监控真正关键的系统路径：/bin F、/sbin F、/usr/bin F、/etc/ssh/ F、/etc/pam.d/ F
• 排除项必须写在对应监控路径之前，而且路径要足够精确：!/var/log/、!/tmp/、!/proc/、!/sys/、!/run/、!/etc/.*~、!/etc/*.log
• 正式启用前先检查语法是否正确：sudo aide --config-check，没有任何输出才表示通过

数据库初始化和定时任务最容易错在哪

在配置 Linux 文件完整性监控时，这两个环节最容易出错，一旦处理不当，整个扫描机制都会失效：

• aide --init 生成的是 /var/lib/aide/aide.db.new.gz，必须手动重命名为 /var/lib/aide/aide.db.gz，否则执行 aide --check 时会提示 database not found
• 数据库文件权限必须设置为 600：sudo chmod 600 /var/lib/aide/aide.db.gz，否则非 root 用户可能读取甚至篡改数据库内容
• crontab 中不能只依赖 grep 过滤输出后发邮件——aide --check 成功返回 0，发现变更返回 1，执行出错返回 2；如果仅通过管道交给 grep，就可能漏掉 2 这类关键异常（例如数据库损坏、权限不足），因此建议增加退出码判断逻辑
• 日志与数据库路径不能写错：database=file:/var/lib/aide/aide.db.gz 中的 .gz、斜杠以及大小写都必须与配置文件完全一致

怎么看出告警是真的入侵而不是运维操作

收到 Added、Removed、Changed 告警，并不代表系统一定已经被入侵，还需要结合上下文进行判断：

• Added 通常风险最高——优先检查新增文件是否出现在 /tmp、/dev/shm、/var/www 等可写目录；再用 stat -c "%y %U %G" /path/to/file 查看创建时间和属主信息
• Removed 往往比 Changed 更可疑——例如 /usr/bin/file 消失，可能意味着攻击者在清理痕迹，应优先核对 RPM 包状态：rpm -V file
• Changed 需要看具体变化字段：如果只有 m（mtime）发生变化，而 sha256 未变化，可能只是 touch 操作或日志轮转；如果 sha256 也变了，再结合 journalctl --since "2 hours ago" | grep -i "update|upgrade" 排查是否刚执行过系统更新
• 不要只看邮件摘要，最好手动执行一次 sudo aide --compare，它会输出新旧哈希值对比，更容易确认是否真的发生了内容层面的变更