服务器前立着盾牌并接受扫描光束检查，示意 AIDE 文件完整性基线监控

服务器文件完整性监控：AIDE 入侵检测基线配置

作者

很多站长都有过这样的经历：服务器明明装了防火墙、改了 SSH 端口，网站还是被悄悄挂上了赌博跳转代码，而且翻遍日志也说不清文件是什么时候被改的。这类问题的共同根源是缺少一层文件完整性监控——攻击者改动 index.php、crontab 或系统二进制时，没有任何机制报警。本文属于我们服务器运维系列的安全实战篇，教你如何用开源工具 AIDE（高级入侵检测环境，Advanced Intrusion Detection Environment）在服务器上建立文件完整性基线，让任何未经授权的文件改动在几分钟内暴露出来。无论你用的是虚拟主机上层的独立服务器，还是自己管理的 VPS（虚拟专用服务器），这套方法都适用，全部步骤可以在一台全新机器上 30 分钟内完成。

AIDE 文件完整性监控：服务器与盾牌扫描示意

为什么文件完整性监控能补上安全短板

防火墙和登录审计解决的是”把攻击者挡在外面”，但没有任何防线能保证 100% 拦截。一旦攻击者拿到 WebShell 或借道一个过期插件进入系统，他做的第一件事往往是改文件：替换支付页面、注入跳转脚本、把挖矿程序藏进系统目录。这些动作如果不比对文件”指纹”，从外部几乎看不出来。

AIDE 的解决思路很直接：为每个受监控文件计算一份指纹档案，内容包括文件大小、权限、属主、修改时间，以及 SHA256 这类哈希值（把文件内容压缩成一串固定长度的唯一摘要，内容变一个字节，摘要就完全不同）。这些档案组成”基线数据库”。之后每次巡检，AIDE 重新计算当前指纹并与基线比对，任何新增、删除或改动都会列在差异报告里。

关于服务器基础加固，可以参考我们之前整理的服务器配置相关内容，把权限与端口先收紧，再叠加文件监控。它和杀毒软件的区别在于：杀毒靠病毒特征库，只能识别已知威胁；AIDE 靠”和基线比有没有变化”，哪怕攻击者用的是从未见过的 0day 漏洞，只要动了被监控的文件，下一次巡检就会现形。对于托管在 Hostease 独立服务器上、由我们自己掌控系统权限的业务来说，这一层监控和防火墙是互补关系，而不是替代关系。

AIDE 文件完整性监控原理示意

安装 AIDE 并初始化第一份基线

基线的价值取决于”干净程度”——在一台已经被入侵的机器上初始化基线，等于把非法改动也固化成了”合法状态”。所以正确顺序是：新机器初始化、装完业务软件后立刻建立基线，再对外开放服务。

主流发行版的安装都很简单：

# Debian / Ubuntu
sudo apt update && sudo apt install aide

# CentOS / RHEL / AlmaLinux
sudo dnf install aide

安装后先确认默认配置文件位置。Debian 系是 /etc/aide/aide.conf，红帽系是 /etc/aide.conf。配置文件里的核心是规则定义，红帽系默认带了一套现成规则，例如：

PERMS   = p+u+g+acl+selinux+xattrs
CONTENT = sha512+ftype+p+u+g+n+acl+selinux+xattrs
CONTENT_EX = CONTENT+sha512

每个字母代表一类监控属性：p 权限、u 属主、g 属组、s 文件大小、mtime 修改时间、sha512 内容哈希。初始化基线：

sudo aide --init
# 生成 /var/lib/aide/aide.db.new.gz 后手动改为正式库
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

这里有一个新手最容易踩的坑：初始化完成后基线就固定了，此后你自己的每一次合法变更（升级内核、改 nginx 配置）都会出现在差异报告里。所以建议把”更新基线”纳入变更流程：每次计划内改动完成、确认无误后，再执行一次 aide --init 重建基线，让基线始终代表”最后一次确认过的正常状态”。

配置监控范围：该盯哪些目录

监控范围不是越大越好。把整个根目录都纳入哈希监控，一次巡检可能要几十分钟，而且 /var/log、/tmp 这类天然高频变动的目录会制造海量误报。比较务实的划分是把目录分成三类：

  • 必须严格监控：系统二进制 /bin、/sbin、/usr/bin、/usr/sbin，系统库 /usr/lib，这些位置一旦出现新增或被改的文件，基本可以直接判定为异常
  • 按需监控：网站根目录（如 /var/www）、/etc 配置目录、crontab 文件，这些是 Web 入侵的重灾区（WordPress 站点可以结合WordPress 教程里的加固经验一起做），但要接受正常发布也会触发差异
  • 明确排除：/var/log、/tmp、/var/cache、会话目录，只监控属性或干脆排除，避免噪音淹没真警报

在配置文件末尾追加自定义规则：

/var/www    CONTENT_EX
/etc        CONTENT_EX
/boot       CONTENT_EX
/bin        CONTENT_EX
/usr/bin    CONTENT_EX
!/var/log/.*
!/tmp/.*
!/var/cache/.*

感叹号开头的是排除项。改完配置先用 aide --check 跑一遍，观察报告里误报比例，再决定是否调整范围。一个经验参考：一台只跑 Web 服务的 2 核 4G 服务器，按上述范围做全量巡检大约需要 2-5 分钟，每天执行 1-2 次完全可接受；如果你的机器配置更低，可以把内容哈希只留给 /usr/bin 等关键目录，其余目录只查权限和属主变化。资源紧张时也可以参考网站性能优化的思路，先排查是否有异常进程在消耗 CPU。

监控范围划分示意

让报警自动送达：定时巡检与通知

AIDE 装好不会自动运行，必须靠 cron（定时任务服务）或 systemd timer 驱动定期巡检，否则基线只是躺在磁盘上的一份数据。最小可用的巡检脚本如下：

#!/bin/bash
# /etc/cron.daily/aide-check
LOG=/var/log/aide/aide-check.log
mkdir -p /var/log/aide
/usr/bin/aide --check > "$LOG" 2>&1
EXIT=$?
# 退出码含义：0=无变化 1=新文件 2=被删文件 4=被改动文件，可叠加
if [ $EXIT -ne 0 ]; then
    mail -s "AIDE 检测到文件变动: $(hostname)" you@example.com < "$LOG"
fi

几个让报警真正有用的细节：

  • 巡检结果必须离开服务器本身。攻击者入侵后第一件事可能就是改基线、清日志，把报告同时抄送到外部邮箱或集中日志服务器，才能保证”报警不可被篡改”
  • 基线数据库建议异地留一份副本，例如每天把 aide.db.gz 同步到备份主机；发现被篡改时可以用干净副本重查
  • 差异报告要人工看，不要只看退出码。一次 apt upgrade 会带来几十条正常变更，需要你逐条确认后重建基线，长期不清的差异队列会让人麻木，真正重要的警报反而被忽略

如果你管理的是多台服务器，还可以把巡检日志统一汇总到一台跳板机，用简单的关键词过滤（added、changed、removed）做集中告警，成本几乎为零。

巡检与报警流程示意

误报处理与日常维护节奏

用 AIDE 三个月后的真实体感是：技术本身不难，难的是坚持处理每天的差异报告。常见的误报来源和处理方式：

  • 系统自动更新导致的变更（如 unattended-upgrades 改了 /usr/bin 下的文件）：确认更新来源合法后重建基线即可，这类变更通常集中在补丁日，数量可预期
  • 网站程序自动生成缓存或临时文件：要么把它们加入排除列表，要么调整网站配置让缓存写到 /var/cache 等已排除目录
  • 日志轮转改动文件属性：对日志目录只监控权限和属主，不监控内容哈希

建议的维护节奏是：每天早上花 5 分钟看前一夜的巡检报告，确认所有差异都有对应解释；每周做一次基线核对，把本周计划内变更全部固化进新基线；每季度做一次演练，故意修改一个受监控文件，验证报警链路（cron → 邮件 → 人）是否完整。演练很有必要——不少团队装了监控却从没收到过邮件，等真出事才发现 cron 早已静默失效。

总结：把基线纳入你的运维习惯

AIDE 不能阻止入侵，但它能把”被入侵后数周无人察觉”压缩到”最多一个巡检周期”。核心结论是三步：在干净状态初始化基线、用 cron 定期巡检并把报告送到服务器之外、把基线更新纳入每次变更流程。如果你正在选型托管环境，我们建议在 Hostease 的独立服务器或 VPS 上部署这套基线，配合站点自带的每日备份，可以在文件层面形成”改动可发现、损失可回滚”的双保险。下一步行动很简单：今晚就在一台测试机上完成安装和初始化，跑通第一份差异报告，再逐步推广到生产环境。

发表评论