更新 AIDE baseline 需先运行 aide --init 生成 aide.db.new，再手动 cp 覆盖原数据库并修正权限；AIDE 无实时监控能力，依赖 cron 或 systemd timer 轮询触发检查；配置规则需权衡精度与性能，避免扫描虚拟文件系统，修改后必须重执行 --init 才生效。
怎么更新 AIDE 的 baseline 数据库
更新 baseline 就是重新生成当前系统文件状态的快照，覆盖旧的 aide.db。不手动触发，AIDE 永远比对的是上次初始化时的状态，哪怕文件已被篡改也不会“自动学习”新状态。
执行前确认配置文件路径（默认 /etc/aide.conf），然后运行：
aide --init
这会生成 aide.db.new，不是直接覆盖。必须手动替换才能生效：
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db- 如果用的是自定义数据库路径，记得同步更新
DBDIR或database配置项 - 权限要保持一致：
chown root:root /var/lib/aide/aide.db && chmod 600 /var/lib/aide/aide.db
漏掉 cp 这步是最常见错误——aide --check 看起来没报错，其实还在拿旧 baseline 比对。
AIDE 实时监控靠什么实现
AIDE 本身没有守护进程，也不支持 inotify 实时触发。所谓“实时检测”，全是靠外部机制轮询驱动的，比如 cron、systemd timer 或日志系统联动。
最稳妥的做法是用 systemd timer 控制频率和资源占用：
- 写一个 service 文件
/etc/systemd/system/aide-check.service，ExecStart 设为aide --check --config=/etc/aide.conf - 配 timer（如每天 3:15 执行）：
aide-check.timer，启用并启动它 - 避免高频轮询：每分钟跑一次
aide --check不仅无意义，还会因扫描全盘导致 I/O 暴涨
有人试图用 inotifywait 监控关键目录再触发 aide --check，但这是伪实时——AIDE 检查仍需完整读取数据库+遍历文件属性，无法做到毫秒级响应。
配置文件里哪些规则影响检测精度和性能
/etc/aide.conf 里的规则决定 AIDE 查什么、怎么查。写得太宽泛会拖慢速度；太窄又漏掉关键变化。
典型陷阱在哈希算法和属性组合上：
-
p+i+n+u+g+s+m+c+md5：包含权限、inode、链接数、UID/GID、大小、mtime、ctime、md5，适合根目录，但 md5 在大文件上很慢 -
p+i+n+u+g+s+b+sha256：去掉 mtime/ctime，加 sha256 和块设备校验（b），更抗时间戳伪造，且 sha256 比 md5 更现代 - 不要给
/proc、/sys、/dev写规则——这些是虚拟文件系统，每次扫描都会变，必然报错 - 敏感目录如
/etc/shadow要单独加Perms规则，否则权限变更可能被忽略
修改配置后必须重跑 aide --init，否则新规则不生效——这点常被跳过，结果发现“配置写了却没用”。
检查结果怎么看、怎么过滤误报
aide --check 输出默认是纯文本，大量信息混在一起，关键变更容易淹没。别直接肉眼扫，先用 --report=file:/tmp/aide-report.txt 导出，再 grep 关键字。
常见误报来源和处理方式：
-
mtime或ctime变动：NTP 时间校准、备份工具 touch 文件都会触发，建议规则中去掉这两个字段 -
Size变化但内容未变：日志轮转、journalctl 自动清理等，可对/var/log单独设宽松规则（如只校验p+n+u+g） -
Permission异常：重点关注/etc/passwd、/bin/su等，普通用户家目录权限变动通常可忽略
真正要警惕的是 MD5 或 SHA256 校验值变化 + Size 不变，这大概率是文件被静默替换（比如恶意二进制注入）。这种信号不能靠配置过滤，得人工介入。
