初始化aide可信基线必须在系统重装完成、服务配置完毕但未接入生产网络时执行aide --init，确认/var/lib/aide/aide.db.new.gz无误后手动移为正式库并设600权限，再备份至只读挂载点且gpg签名。
直接用 aide --check 就能查，但前提是必须先在干净系统里建好可信基线——否则查出来的“变更”可能是你自己的操作，也可能是攻击者早就埋好的假基线。
怎么初始化 AIDE 基线才真正可信
基线不是装完就跑一条命令就行，关键在时机和动作闭环：
- 必须在系统重装完成、所有必要服务配置完毕、但尚未接入生产网络前执行
aide --init - 生成的
/var/lib/aide/aide.db.new.gz不能直接当基线用，要手动确认无误后才移成正式库：mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz - 执行后立刻加权限锁：
chmod 600 /var/lib/aide/aide.db.gz，防止被覆盖或删改 - 建议把这份
aide.db.gz备份到只读挂载点（如/mnt/secure/aide.db.gz）并用gpg --sign签名，避免基线本身被污染
为什么 /etc/aide.conf 一配错就天天告警
默认配置太宽泛，扫一堆动态路径必然误报。重点不是“全扫”，而是“扫对”：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 排除必须写死：用
!/var/log/.*、!/tmp/、!/proc/、!/sys/，不能只写!/var/log（子目录仍会进） - 敏感目录要带哈希：比如
/etc/ssh/ p+i+n+u+g+s+b+m+c+sha256，漏掉c（内容）或sha256就等于没校验文件体 - 别用通配符监控整个
/home；如果真要管用户配置，限定为/home/*/\.bashrc这类明确路径 - 改完配置务必运行
aide --config-check，有语法错误时aide --check会静默失败，你以为没异常，其实压根没跑
日常检查时怎么快速定位真实风险
aide --check 输出几百行，真正要盯的只有三类，且每类含义不同：
-
Added：最危险，大概率是攻击者上传的二进制或 webshell，优先查/tmp、/dev/shm、/var/www下非预期文件 -
Removed：比如/usr/bin/file消失，可能是 rootkit 替换命令的前兆，立刻用ls -la /usr/bin/file和rpm -V file（RHEL/CentOS）交叉验证 -
Changed：分两种情况——若只有mtime变而sha256不变，大概率是正常更新；若sha256变了，说明内容被改，立刻用aide --compare对比新旧哈希，再结合journalctl --since "1 hour ago" | grep -E "(yum|dnf|apt)"看是否运维操作
crontab 自动化里最容易漏掉的两个坑
定时任务看着跑成功了，其实可能根本没生效，或者结果没人看：
- 脚本里别只写
aide --check，得加返回值判断：aide --check || echo "AIDE failed with exit code $?" | mail -s "AIDE CRITICAL $(hostname)" admin@x.com，因为数据库损坏或磁盘满时它会退 2，不捕获就以为一切正常 - 邮件告警别用
grep "Changed"简单过滤——有些攻击会故意触发大量Removed来掩盖真正的Added，建议用grep -E "(Added|Removed|Changed)" | grep -v "OK$"确保只传异常行
基线一旦建歪，后续所有检查都不可信；而规则配太松，等于裸奔；配太紧，又天天收告警疲劳。真正的难点不在命令怎么敲，而在每次系统变更（内核升级、安全补丁、软件安装）后，你有没有意识去重建基线并记录原因——这个动作没人替你做，也最难坚持。
