AIDE 文件完整性监控实战：检测服务器文件篡改

作者

适用场景

服务器被植入后门后，攻击者通常会修改系统二进制、替换 sshd 配置或往 cron 目录塞持久化脚本。仅靠日志很难发现这类「静默篡改」，因为合法命令可能继续正常工作。AIDE（Advanced Intrusion Detection Environment）通过对关键目录生成加密哈希基线，在后续扫描中比对出新增、删除、修改的文件，是 Linux 主机上成本最低、最直接的文件完整性监控方案。本文适用于需要满足等保合规、或希望在无商业 HIDS 预算前提下建立篡改检测能力的运维团队。

前置条件

  • Debian/Ubuntu 或 RHEL/CentOS 系列主机，具备 root 权限
  • 磁盘剩余空间足够存放基线数据库（视监控范围，通常在 20MB 至数百 MB）
  • 服务器已完成初始安全加固，基线必须在确认系统干净的状态下生成，否则会把后门一起写进基线
  • 已配置可用的邮件发送能力（如 postfix 或已装 mailx），用于告警投递

原理说明

AIDE 的工作模型分三步：读取配置文件中的规则集 → 遍历目标文件计算属性摘要 → 与基线数据库比对并输出差异报告。

  • 数据库：默认基线为 /var/lib/aide/aide.db.gz，新生成的库为 aide.db.new.gz，需手动替换后才生效
  • 规则集：配置文件由「选择行」与「宏定义」组成。选择行形如 /etc Full，后者决定记录哪些属性
  • 属性宏：常用为 p（权限）、i（inode）、n（链接数）、u/g（属主/属组）、s（大小）、m（mtime）、a（atime）、c（ctime）、S（SHA512 摘要）、md5、sha256。生产环境推荐使用 R（只读文件的完整校验）与 L（日志增长类文件的宽松校验）两个内置宏

操作步骤

1. 安装 AIDE

# Debian / Ubuntu
sudo apt update && sudo apt install -y aide aide-common

# RHEL / CentOS / Rocky
sudo yum install -y aide

2. 配置监控范围

编辑 /etc/aide/aide.conf（RHEL 系列为 /etc/aide.conf），在文件末尾追加自定义规则。核心思路是「关键配置用严格校验，变动频繁的目录排除或放宽」。

# 自定义规则集 —— /etc/aide/aide.conf

# 严格校验：任一属性变化都告警
StrictChecks = p+i+n+u+g+s+m+c+sha256+sha512

# 宽松校验：用于日志、缓存类文件
LooseChecks  = p+u+g+n+sha256

# —— 严格监控：系统与安全配置 ——
/etc            StrictChecks
/boot           StrictChecks
/bin            StrictChecks
/sbin           StrictChecks
/usr/bin        StrictChecks
/usr/sbin       StrictChecks
/usr/lib/systemd StrictChecks
/root           StrictChecks
/etc/ssh        StrictChecks

# —— 宽松监控：变动频繁但需感知 ——
/var/spool/cron LooseChecks
/etc/cron.d     LooseChecks

# —— 明确排除：避免误报与性能损耗 ——
!/var/log
!/var/cache
!/var/tmp
!/tmp
!/proc
!/sys
!/dev
!/run
!/var/lib/aide
!/var/lib/docker

注意：行首 ! 表示排除，排除规则必须写在包含规则之后。若监控 Docker 宿主机的 /var/lib/docker，扫描耗时会显著增加，建议单独排除后对其上层配置目录单独监控。

3. 生成初始基线数据库

# 初始化（耗时取决于文件数量，可能数分钟）
sudo aide --init

# 检查生成结果
sudo ls -lh /var/lib/aide/

# 确认无误后替换为正式基线
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Debian 系列可用封装命令一次完成：sudo aideinit，随后 sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db。

基线文件本身必须保护，建议设置不可变属性并单独备份到离线位置：

sudo chattr +i /var/lib/aide/aide.db.gz
sudo cp /var/lib/aide/aide.db.gz /backup/aide/

4. 执行完整性检查

sudo aide --check

无异常时输出类似：

AIDE found no differences between database and filesystem. Looks okay!!

存在变更时输出详尽的差异段，例如：

File: /etc/ssh/sshd_config
  Size     : 3042                       , 3080
  Mtime    : 2026-09-01 08:12:03        , 2026-09-11 03:40:11
  SHA256   : 3f2a...c91d                , 8b7e...04af

Added files:
f++++++++++++++++: /usr/local/bin/kworker

解读方式：Size / Mtime / SHA256 不一致表示文件被修改；Added files 段中带 +++ 的是新增文件，需重点核查，尤其出现在 /bin、/usr/bin、/etc/cron* 或隐藏在 /usr/local/bin 下的可执行文件。

5. 误报确认后更新基线

对于确认合法的变更（如正常的系统更新、配置调整），需重建基线，否则每次检查都会重复告警。

# 生成新库
sudo aide --update
# 替换旧基线
sudo chattr -i /var/lib/aide/aide.db.gz
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo chattr +i /var/lib/aide/aide.db.gz

6. 配置定时扫描与告警

# /etc/cron.d/aide-check —— 每日 03:20 扫描并发邮件
20 3 * * * root /usr/bin/aide --check 2>&1 | mail -s "[AIDE] $(hostname) integrity report" ops@example.com

若未安装 mail 命令，可写入本地文件由日志采集系统（如 rsyslog、Wazuh）统一收走：

20 3 * * * root /usr/bin/aide --check >> /var/log/aide/report.log 2>&1
# 追加规则避免自监控循环
# !/var/log/aide

配置验证

确认配置语法与数据库可读：

sudo aide --config-check
sudo ls -lh /var/lib/aide/aide.db.gz

做一次主动篡改测试，验证告警确实触发：

# 制造变更
sudo touch /etc/aide_test_marker
# 执行检查
sudo aide --check | grep -A2 "aide_test_marker"
# 预期输出 Added files 段中包含该文件
# 清理
sudo rm -f /etc/aide_test_marker

检查扫描耗时，评估是否影响业务：

sudo time aide --check

若单次扫描超过数分钟且消耗大量 IO，应缩小监控范围或改用 –limit 参数分批检查（AIDE 0.17 以上支持）。

常见问题

FAQ 1：每次检查都告警一大片，是不是基线坏了？

大概率是「合法变更未同步基线」或「未排除高频变动目录」。排查步骤：

  • 先看告警集中在哪个目录。若集中在 /var/log、/var/cache、/var/lib/docker，说明排除规则未生效，检查 ! 前缀规则是否写在包含规则之后
  • 若集中在 /etc 下的若干配置文件，说明近期做过系统更新或手工调整，确认内容无异常后执行 aide --update 重建基线
  • 若出现大量 Added files 且文件名随机（如 .tmp_XXXX），需按入侵事件处置，优先检查 cron、systemd service 与 SSH 授权文件

建议把「基线更新」纳入变更流程：任何配置变更完成后，由变更执行人同步更新基线并记录原因。

FAQ 2：AIDE 与 Tripwire、Wazuh 这类方案怎么选？

三者定位不同，可按规模与预算取舍：

  • AIDE：单机、纯本地、无守护进程，部署成本最低，适合中小规模服务器与合规基线检查。不提供集中管理，需自行解决日志汇聚
  • Tripwire：商用版本提供集中策略管理与合规报表，开源版能力与 AIDE 接近但配置更复杂
  • Wazuh / OSSEC：属于 HIDS，除文件完整性外还提供日志分析、rootcheck、实时监控与集中控制台，适合主机数量多、需要统一告警的场景，但部署与调优成本明显更高

实践建议：主机数量在 20 台以内可先用 AIDE + 日志汇聚，出现「需要实时检测而非每日扫描」的需求时，再逐步引入 HIDS。

FAQ 3：基线数据库能放在被监控的机器上吗？会不会被攻击者一起改掉？

可以存储，但不能只存一处。攻击者取得 root 后完全有能力重算哈希并覆盖本地基线。正确做法是三点结合：

  • 基线文件设置 chattr +i 不可变属性，提高直接篡改门槛
  • 每日把基线副本与检查报告推送到远端日志服务器或对象存储，形成外部可信副本
  • 关键服务器可把基线放在只读介质或单独的管理网共享目录，扫描时从远端读取

总结

AIDE 的价值在于把「凭经验猜有没有被改」变成「有哈希证据可比对」。落地要点有四：基线必须在系统干净时生成，否则后门会被一并纳入；规则要分级，系统二进制与安全配置用严格校验，日志缓存类目录排除或放宽；基线要保护，chattr 加不可变属性并保存外部副本；变更要同步，把基线更新纳入配置变更流程，避免告警疲劳掩盖真实入侵。完成部署后，AIDE 可与日志审计、WebShell 查杀形成互补，覆盖「文件被改」这一日志难以察觉的盲区。