在 Linux 文件完整性监控这个场景里，AIDE 几乎是唯一真正靠谱且适合生产环境的选择。原因并不复杂：它从设计之初就是面向系统级文件完整性校验而来的，能够一次性检查权限、属主、文件大小、SHA256 在内的 10 多种关键属性，而且整个过程不依赖外部服务。相比之下，md5sum 或自行编写脚本的能力非常有限，像权限被篡改、属主被替换这类常见且关键的入侵痕迹，往往根本无法识别；而 rpm -Va 的检查范围也仅限于 RPM 包管理的文件，无法覆盖系统中真实存在的完整攻击面。
怎么选对扫描工具：AIDE 是唯一合理选项
不要再用 md5sum 或手写脚本去做 Linux 系统级文件完整性扫描——它们既难以抵御恶意篡改，也无法准确发现权限变化、属主替换、ACL 修改等关键安全事件。AIDE 是专门为文件完整性监控设计的工具，能够同时比对 p+i+n+u+g+s+sha256 等 10 多类属性，并且不依赖外部服务，适合长期稳定使用。
另一个常见误区是拿 rpm -Va 来替代 AIDE：它只会检查 RPM 软件包管理的文件，像 /etc/nginx/conf.d/、/usr/local/bin/、手工部署的程序文件和自定义脚本等真实高风险路径，往往都不在检测范围内。
- Debian/Ubuntu：
sudo apt install aide - RHEL/CentOS 8+：
sudo dnf install aide；CentOS 7：sudo yum install aide - 安装完成后不会自动初始化数据库，必须手动执行
aide --init
初始化数据库前必须确认三件事
AIDE 数据库一旦建立，就等同于系统的“可信基线”。如果生成基线时系统已经被入侵，或者仍存在异常进程与可疑服务，那么后续所有比对结果都会失去参考价值。因此，这一步不是建议，而是进行 Linux 文件完整性校验前的安全前提。
- 系统应当是刚完成重装，或已经通过
ps auxf、netstat -tulpn、journalctl -b明确确认不存在异常进程与异常服务 - 没有运行可疑容器，没有挂载未知来源的 NFS/Samba 共享，并且
/tmp与/var/tmp保持为空 - 执行
sudo aide --init之后，必须立即重命名数据库文件：sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz（否则执行aide --check时会一直提示database not found）
/etc/aide.conf 配置最容易踩的五个坑
默认配置通常过于宽泛，绝大多数误报都来源于这里。AIDE 规则不是写得越多越好，而是要尽量准确、稳定、可维护，这样 Linux 文件完整性监控结果才有实际意义。
database=file:/var/lib/aide/aide.db.gz这一行必须存在，路径大小写、.gz后缀以及前面的file:协议都不能写错- 排除路径要使用完整匹配：
!/var/log/.*并不能屏蔽/var/log/nginx/access.log，应写成!/var/log/**（前提是启用 glob）或逐项列出!/var/log/nginx/、!/var/log/journal/ - 像
/etc/resolv.conf、/etc/mtab这类动态变化文件必须显式排除，否则每次网络变化都可能触发Changed - 不要直接照搬网上示例中的
/etc p+i+n+u+g+s+sha512—— 如果系统并未使用 SELinux，selinux相关属性会持续变化，加入后只会干扰判断 - 正式运行前务必先检查语法：
sudo aide --config-check，没有任何输出才表示配置通过；一旦报错，就不要继续执行--check
crontab 定时任务里必须判断退出码
仅靠 grep "Changed" 来发告警邮件，是非常典型但也非常危险的误判方式——因为 AIDE 在执行出错时（例如数据库损坏、权限不足、配置错误）同样会输出文本内容，但此时返回码是 2，而不是 1。如果只盯着日志文本，而不判断退出状态，就等于放弃了故障发现能力。
- 正确写法示例（每天 2:30 执行）：
30 2 * * * /usr/bin/aide --check --config=/etc/aide.conf > /var/log/aide/$(date +%Y%m%d).log 2>&1 || echo "AIDE failed with exit code $?" | /bin/mail -s "AIDE CRITICAL $(hostname)" admin@company.com aide --check返回0：无变更；返回1：检测到变更（Added/Removed/Changed）；返回2：执行失败（如数据库损坏、配置错误、权限被拒绝）- 日志目录需要提前创建：
sudo mkdir -p /var/log/aide && sudo chown root:root /var/log/aide，否则 cron 任务可能会静默失败 - 不要把
aide.db.gz与日志文件放在同一分区——当根分区被写满时，aide --init和日志写入都可能同时失效
AIDE 真正复杂的地方不在安装过程，而在于“干净初始化”和“精准排除规则”的配置。很多人第一次执行 aide --check 时看到几百行 Changed 就以为系统被入侵，实际上常见原因只是 /etc/ 下某个临时备份文件没有排除，或者初始化后的数据库文件根本没有成功重命名。这也是 Linux 文件完整性扫描配置中最容易被忽视、却最关键的细节。
