先把基础动作做对：运行aide --init生成aide.db.new.gz，然后将其重命名为aide.db.gz，并把权限设为600。少了其中任何一步，aide --check要么直接报“database not found”，要么看起来没动静、实际已经失效。还有几个关键细节也不能忽略：排除规则要写在前面，路径必须足够精确，而最终是否生效，唯一可靠的判断标准其实是退出码。
直接用 aide，别折腾 md5sum 脚本或定时 sha256sum ——它不防增删、不看权限、不处理硬链接和 SELinux 上下文，纯属自欺欺人。
为什么必须先跑 aide --init 再重命名数据库
安装完 aide 后，aide --init 生成的是 /var/lib/aide/aide.db.new.gz，不是正式库。不重命名就执行 aide --check，会直接报错 database not found。
- 重命名命令必须是
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz（不是mv，避免跨文件系统失败） - 随后立即设权限：
sudo chmod 600 /var/lib/aide/aide.db.gz，否则非 root 用户可能篡改或读取 - 这一步只能在系统刚重装/确认干净时做一次；补做等于拿被污染的系统当基线，后续所有告警都不可信
/etc/aide.conf 配置最容易踩的三个坑
默认配置几乎必误报，新手常卡在这一步：语法没错但天天收“Changed”邮件，最后发现是 /etc/resolv.conf 或 /etc/mtab 这类动态文件没排除。
- 规则顺序敏感：排除项（如
!/var/log/）必须写在监控项（如/var/log F）之前，否则不生效 - 路径匹配要精确：
!/etc/.*.log不会匹配/etc/nginx/access.log，得写成!/etc/**.log（需开启 glob 支持）或逐条列!/etc/nginx/access.log - 数据库路径必须严格一致：配置里写的是
database=file:/var/lib/aide/aide.db.gz，少个.gz、大小写错、斜杠多一个都会让--check失败
crontab 定时检查必须判断退出码，不能只靠 grep
aide --check 的退出码，才是真正值得信赖的判断依据：0 代表没有任何变更，1 代表确实存在文件变动（Added/Removed/Changed），2 则说明执行过程中间出了问题，比如权限不够、数据库损坏。要是只是拿 grep 管道去抓输出，表面上看省事，实际上会直接漏掉 2 这类错误，也根本分不清到底是“真的发生了变更”，还是“日志写入环节出了故障”。
- 安全写法示例：
15 3 * * * /usr/bin/aide --check > /var/log/aide/$(date +%Y%m%d).log 2>&1 || echo "AIDE failed with exit code $?" | /usr/bin/mail -s "AIDE ERROR $(hostname)" admin@company.com
- 日志目录要提前建好：
sudo mkdir -p /var/log/aide && sudo chown root:root /var/log/aide - 别把
aide.db.gz和日志放在同一分区——根分区满会导致--init失败且日志也写不进去
看到 Added 或 Removed 比 Changed 更危险
收到告警后，第一反应不该是查哈希值，而是确认新增或删除行为是否合理。例如 Added: /tmp/.X11-unix/xauth-12345 是临时文件可忽略；但 Added: /usr/local/bin/.shellshock 就极可能是后门。
- 快速定位变更类型：
sudo tail -n 50 /var/log/aide/$(date +%Y%m%d).log | grep -E "(Added|Removed|Changed)" - 对比新旧哈希用
aide --compare，但它只输出差异字段，不解释原因——得结合journalctl --since "2 hours ago"查谁改的、何时改的 Changed中优先盯sha256字段：如果只有m（修改时间）变而哈希不变，大概率是运维更新；哈希变了才真正可疑
