如何在Linux中配置完整性扫描

先把基础动作做对：运行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（修改时间）变而哈希不变，大概率是运维更新；哈希变了才真正可疑