aide监控必须依赖aide --check退出码判断：0无变更，1有改动，2/255为致命错误；日志不可靠，须用$?捕获退出码并邮件告警；配置排除规则需前置、路径名不可改、数据库需校验哈希、规则应精简禁用冗余属性。
定期比对必须依赖 aide --check 的退出码，不是看日志有没有“changed”
很多人把 aide --check 输出重定向到日志后就以为万事大吉，结果线上被植入后门却没报警。AIDE 的输出混合了调试信息、路径扫描进度和真实变更行，人工扫日志极不可靠。aide --check 的退出码才是唯一可信信号：0 表示无变更，1 表示文件有改动（added/removed/changed），2 或 255 表示数据库损坏、权限不足等致命错误。
实操建议：
- 写 cron 任务时必须用
$?判断退出码，例如：0 2 * * * /usr/bin/aide --check > /var/log/aide/$(date +\%Y\%m\%d).log 2>&1 && exit_code=$?; if [ $exit_code -eq 1 ]; then echo "ALERT: AIDE detected changes" | mail -s "AIDE Alert" admin@example.com; fi
- 日志路径要带日期且固定前缀，避免覆盖；
/var/log/aide/目录需提前mkdir -p并chown aide:root - 不要用
grep -q "changed"这类模糊匹配——日志里可能有 “configuration changed” 这种干扰项
/etc/aide.conf 规则顺序错一位，排除就失效
AIDE 按配置文件从上到下逐行匹配规则，排除项（以 ! 开头）必须写在对应监控规则之前。如果把 !/var/log/.* 放在 /var/log p+i+n+u+g+s+sha256 后面，那整条日志目录仍会被扫描并报大量误报。
常见错误场景：
-
/etc p+i+n+u+g+s+sha256后紧跟!/etc/resolv.conf→ 无效，因为/etc规则已匹配全部子路径 - 想排除所有临时文件但写成
!/tmp/*→ 不生效，AIDE 默认不启用 glob，得写!/tmp/或启用@@define GLOB后用!/tmp/** - 规则末尾多一个空格或 Windows 换行符（
\r\n）→ 配置解析失败，aide --check直接报错退出码255
数据库路径硬编码在配置里，aide.db.gz 名字不能改
AIDE 只认配置中 database=file:/var/lib/aide/aide.db.gz 这个路径。即使你生成了 aide.db.new.gz，不重命名为 aide.db.gz，后续所有 --check 都会报 database not found。它不会自动 fallback，也不会提示“试试用 new？”。
关键操作链：
- 每次改完
/etc/aide.conf，必须重新跑aide --init --force-init生成新快照 -
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz后，立刻校验：gzip -t /var/lib/aide/aide.db.gz - 强推保存指纹：
sha256sum /var/lib/aide/aide.db.gz > /root/aide.db.sha256，检查前先比对这个哈希，防数据库被替换 - 别把
aide.db.gz和日志放在同一挂载点——根分区满会导致--init失败且日志写不进去
SHA256 是底线，别碰 md5 或默认 NORMAL 规则
默认配置里的 NORMAL = R+sha512 看似省事，但 R 包含太多冗余属性（如 ACL、xattrs），在 CentOS/RHEL 上常因 SELinux 上下文微变导致误报；而 md5 已被证实可碰撞，攻击者能构造不同内容但相同 MD5 的 /bin/ls 替换体。
生产环境应显式定义最小可用规则：
- 只监核心路径：用
F = p+i+n+u+g+s+m+c+sha256（权限、inode、链接数、用户、组、大小、修改时间、ctime、SHA256） - 禁用
sha512——虽更安全但慢 30%，SHA256 对抗篡改已足够 - 绝对不监控
/proc、/sys、/run、/dev，这些是伪文件系统，每次扫描都变 - 对
/etc/shadow这类敏感文件，单独加一行规则并确保sha256在列，别指望父目录规则继承
真正难的不是写 cron 或改配置，是每次初始化前确认系统干净、每次更新后验证数据库指纹、每次报警后能区分是运维操作还是入侵痕迹——这些环节断一环，整个监控就形同虚设。
