AIDE文件完整性监控发现网站被篡改的告警设置

服务器半夜报警，短信提示网站根目录下的index.php文件校验值发生改变。登录后台一看，首页被植入了赌博网站的隐藏链接和一段加密的webshell代码。这不是假设场景，而是每天都在发生的真实入侵。攻击者通过某个插件漏洞上传了恶意脚本，悄无声息地篡改了你的核心文件。如果没有AIDE这类文件完整性监控工具的告警，你可能要等到搜索引擎标记网站为危险、或者用户投诉后才能发现异常，而那时损失已经造成。

AIDE（Advanced Intrusion Detection Environment）的工作方式并不复杂，它先为所有受监控的文件生成一个快照数据库，记录下每个文件的哈希值、权限、inode、修改时间等属性。当再次运行时，它将当前文件状态与数据库中的记录逐一比对。任何差异都会被标记并输出。问题在于，默认的AIDE告警是静默的，它只是把结果打印到终端或者写入日志文件。如果你没有主动去查看，入侵发生了你依然不知道。真正的价值在于把“比对结果”转化为“即时通知”。

在设置告警之前，必须先确保监控规则本身是有效的。很多管理员直接使用AIDE默认规则，这会导致两个问题：要么监控范围太大产生海量噪音，要么遗漏了网站动态目录。针对网站防篡改场景，你需要聚焦在Web根目录下的可执行文件与容易被替换的静态资源。

创建一个专门针对网站的配置文件，比如/etc/aide.conf.d/website.conf：

# 网站根目录核心监控
/var/www/html/www.example.com/index.php NORMAL
/var/www/html/www.example.com/wp-config.php NORMAL
/var/www/html/www.example.com/.htaccess NORMAL

# 主题与插件目录，重点关注PHP和JS文件
/var/www/html/www.example.com/wp-content/themes/ PERMS+INODE+OWNER+GROUP
/var/www/html/www.example.com/wp-content/plugins/ PERMS+INODE+OWNER+GROUP

# 忽略缓存和临时上传目录，减少噪音
!/var/www/html/www.example.com/wp-content/cache
!/var/www/html/www.example.com/wp-content/uploads

NORMAL规则会检查文件类型、权限、inode、属主、属组、大小、以及所有哈希值。对于主题和插件目录，由于开发者可能经常更新，使用PERMS加基础属性检查即可，避免每次正常更新都触发告警。忽略缓存和上传目录是因为这些位置文件频繁变化，不属于篡改特征。

规则定义好后，需要在服务器处于绝对干净的状态下生成基准数据库。如果你不确定当前系统是否已被入侵，应该从备份中还原网站文件，或者在刚部署完生产环境后立刻执行初始化。

# 初始化数据库
aide --init --config=/etc/aide.conf.d/website.conf

# 将新生成的数据库重命名为正式库
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

这一步非常关键。如果基准数据库本身就包含后门文件，那么AIDE将永远不会报警，因为攻击者的文件已经被当作合法状态记录下来了。

AIDE本身只负责比对，我们需要一个外壳脚本来执行检查、捕获输出，并根据结果触发通知。下面是一个生产环境可用的脚本示例：

#!/bin/bash
# 网站文件篡改检测与告警脚本

MAIL_TO="admin@example.com"
WEBHOOK_URL="https://hooks.slack.com/services/xxx/xxx/xxx"
HOSTNAME=$(hostname)
LOG_FILE="/var/log/aide-check.log"

# 执行AIDE检查
/usr/bin/aide --check --config=/etc/aide.conf.d/website.conf > /tmp/aide_result.txt 2>&1
EXIT_CODE=$?

# 如果退出码非0，说明有文件变化
if [ $EXIT_CODE -ne 0 ]; then
    # 提取新增、删除、修改的文件列表
    CHANGES=$(grep -E "^(Added|Removed|Changed)" /tmp/aide_result.txt)
    
    # 记录日志
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] ALERT: File integrity violation detected on $HOSTNAME" >> $LOG_FILE
    echo "$CHANGES" >> $LOG_FILE
    
    # 发送邮件告警
    echo -e "Subject: [紧急] 网站文件篡改告警 - $HOSTNAME\n\n服务器 $HOSTNAME 检测到文件完整性异常：\n\n$CHANGES\n\n请立即登录服务器核查。完整报告见附件。" | /usr/sbin/sendmail $MAIL_TO
    
    # 发送Webhook告警（企业微信/钉钉/Slack）
    curl -X POST -H 'Content-type: application/json' --data "{\"text\":\"网站文件篡改告警：$HOSTNAME\n$CHANGES\"}" $WEBHOOK_URL
fi

# 清理临时文件
rm -f /tmp/aide_result.txt

这个脚本做了三件事：执行AIDE检查、解析变化列表、通过邮件和即时通讯工具双通道推送告警。退出码判断是核心，AIDE在发现文件变化时会返回非0值，这正是触发通知的条件。

告警设置完成后，第一个遇到的麻烦通常是误报。当你通过WordPress后台升级了某个插件，或者修改了主题的footer.php文件，AIDE会立刻发出告警。这不是系统故障，而是它忠实地执行了职责。你需要建立一套基准更新机制来区分“授权变更”和“恶意篡改”。

操作流程应该是：每次计划内更新网站文件后，立即重新初始化AIDE数据库。这可以通过在部署脚本末尾追加一条命令来实现：

# 在网站更新脚本中加入
aide --update --config=/etc/aide.conf.d/website.conf
cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

这样就把新的合法状态写入了基准库，后续的告警将不再包含这次更新。关键纪律在于：任何未经此流程的数据库更新操作都应被视为可疑。如果某天凌晨三点突然收到告警，而你确认没有任何团队成员在操作服务器，那就是真正的入侵事件。

告警脚本需要通过crontab定期执行。检查频率取决于网站的重要性和服务器性能。对于金融类或电商网站，建议每5到10分钟扫描一次；对于企业展示类网站，每30分钟扫描一次即可。

# 每10分钟执行一次文件完整性检查
*/10 * * * * /usr/local/bin/aide_alert.sh > /dev/null 2>&1

需要注意的是，AIDE在校验大量文件时会消耗CPU和磁盘IO。如果你的网站文件数量超过十万个，全量扫描可能需要数分钟。这种情况下应该进一步细化监控范围，只监控核心目录和关键配置文件，而不是整个Web根目录。

原始的AIDE输出信息非常技术化，包含了大量的哈希值和属性细节。直接把这些内容推送到手机上，阅读体验很差，而且容易让人忽略关键信息。你应该在告警脚本中对输出做一层过滤和格式化。

重点关注三类变化：Added表示出现了新文件，这通常是webshell或后门脚本的典型特征；Changed表示原有文件内容被修改，可能是植入了恶意代码；Removed表示文件被删除，可能是攻击者在清理痕迹或者破坏网站功能。

可以在脚本中增加判断逻辑，当检测到新增.php文件时，将告警级别标记为“严重”；当检测到图片目录新增文件时，标记为“一般”。这样运维人员能根据告警等级决定响应优先级。

很多管理员配置完告警后就认为万事大吉，实际上邮件可能被拦截，Webhook地址可能已经过期。你需要进行一次模拟篡改测试来验证整个告警链路。

在网站根目录创建一个无害的测试文件，然后运行检查脚本，确认是否收到通知：

# 模拟文件新增
echo "test" > /var/www/html/www.example.com/test_alert.txt
/usr/local/bin/aide_alert.sh

# 确认收到告警后删除测试文件并更新基准库
rm /var/www/html/www.example.com/test_alert.txt
aide --update --config=/etc/aide.conf.d/website.conf
cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

如果测试后没有收到告警，逐一排查：AIDE是否正确安装且数据库路径无误、脚本是否有执行权限、sendmail服务是否正常运行、Webhook URL是否有效、crontab语法是否正确。每一个环节都可能成为告警链路断裂的点。

文件完整性监控告警不应该孤立存在。当AIDE检测到篡改时，你可以触发一系列自动响应动作。比如在告警脚本中加入iptables规则封锁可疑IP，或者自动备份被篡改前的文件版本，甚至立即将网站切换到静态维护页面。

更实用的做法是将AIDE的告警接入集中日志平台，例如ELK或Graylog。这样文件变更事件就能与Web访问日志、系统认证日志进行关联分析。当某个IP在修改文件之前有过异常登录行为，你就能快速定位入侵路径。这种多源数据联动远比单一告警更有价值。

AIDE文件完整性监控的真正威力不在于它发现了多少篡改，而在于它把入侵者的行动时间窗口压缩到了极致。从攻击者修改文件到运维人员收到告警，这个间隔越短，损失就越可控。花一个小时把告警脚本和定时任务配置好，可能在未来某个深夜为你挡下一次灾难性的数据泄露。