初次运行 aide --init 后数据库文件不在 /var/lib/aide/aide.db，因为默认生成路径为 /var/lib/aide/aide.db.new，需手动复制才能生效。
为什么初次运行 aide --init 后数据库文件不在 /var/lib/aide/aide.db
因为 aide --init 默认生成的数据库会放在 /var/lib/aide/aide.db.new，不是直接覆盖主库。这是设计上的安全机制：避免初始化失败或配置错误导致主库被毁。
必须手动复制才能生效：
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
常见错误是跳过这步就直接执行 aide --check，结果报错：AIDE database not found: /var/lib/aide/aide.db。别急着重装，先确认文件是否存在、路径是否拼错。
如何让 Aide 监控 /etc/passwd 但忽略密码字段（即不因 shadow 升级误报）
Aide 默认对 /etc/passwd 做全字段哈希（包括第2字段），而某些系统在用户登录或 PAM 更新时会临时改写该字段（如加锁标记 LK），导致每次检查都告警。
解决方法是在配置中启用 Content 规则并排除特定字段：
- 编辑
/etc/aide.conf，添加规则：/etc/passwd CONTENT p+i+n+u+g+sm+c+md5
- 其中
CONTENT表示只校验文件内容（不含元数据），p+i+n+u+g+sm+c控制权限/所有者/大小/修改时间等，md5是内容哈希算法 - 更稳妥的做法是用
Content+sha256（比 md5 更抗碰撞）：/etc/passwd CONTENT p+i+n+u+g+sm+c+sha256
注意：不要用 Content 监控整个 /etc，否则 /etc/shadow 权限变更也会触发大量误报——它本就该频繁变。
aide --check 报 “entries missing” 或 “entries added” 是不是被入侵了
不一定。Aide 的“新增/缺失条目”通常指配置里声明监控的路径在当前系统中不存在（missing），或存在但没在配置里声明（added）。比如：
-
missing：你配置了监控/usr/local/bin/myscript，但它被删了 -
added：你在/etc/下新建了一个未声明的配置文件，比如/etc/myapp.conf
真正可疑的是 changed —— 文件内容或属性与数据库不一致。这时要结合 stat 和 ls -l --time=ctime 看变更时间，再查 journalctl --since "2 hours ago" | grep -i aide 确认是否有人刚运行过 aide --update。
另外，如果 /boot/vmlinuz-* 显示 changed，大概率只是内核升级了，不是入侵——只要确认是预期中的新内核版本即可。
定时校验后如何只邮件通知异常，且不暴露敏感路径
直接用 crontab 调 aide --check 并管道发邮件太粗糙，容易把完整差异输出到邮箱（含 /etc/shadow 的哈希摘要等）。
推荐做法是加一层过滤：
aide --check 2>/dev/null | grep -E "(changed|added|missing)" | mail -s "AIDE ALERT on $(hostname)" admin@example.com
关键点：
-
2>/dev/null屏蔽 stderr（比如数据库加载警告），只处理 stdout 中的差异行 - 用
grep -E精准匹配三类状态，避免把“Summary”这类统计行也发出去 - 不要用
aide --check | mail，默认输出包含完整路径和哈希，有泄露风险
如果系统禁用了 sendmail，记得提前配置好 ssmtp 或 msmtp，否则 cron 任务看似成功，实则邮件根本没发出。
最易被忽略的一点：Aide 数据库本身必须严格限制权限（600），且不能放在 NFS 或可写挂载点上——否则攻击者删库或替换为旧版，审计就彻底失效了。
