手把手教你防篡改：AIDE vs Wazuh 真实部署大乱斗，谁才是运维人的“保命符”？

对于那几十台跑着核心业务、或者是Java应用的服务器，我咬牙上了Wazuh。虽然部署的时候骂骂咧咧，但用起来是真香，领导看大屏也开心。对于那些边缘的、跑着Nginx反代或者仅仅是作为跳板机的服务器，直接装个AIDE，扔个Crontab，每天发个邮件日报，心里有个底就行。至于我自己的个人博客，我就用了Git大法。好几次我看日志发现有IP在扫我后台上传漏洞，我心里毫无波澜，甚至想笑。兄弟们，安全这东西

qq_31815769

343人浏览 · 2026-01-11 22:05:08

qq_31815769 · 2026-01-11 22:05:08 发布

这周那个被挂马的哥们又来找我了，说：“老哥，你上次说的那几个工具，我回去想装，但是文档太长看不懂啊，有没有那种傻瓜级的教程？”

我说你这就不懂了，运维哪有傻瓜级的？越是强大的工具，配置越像天书。不过既然你问到了，我也刚好趁着周末没事，把这几套方案都在虚拟机上跑了一遍，顺便做了个压力测试。

咱们今天不讲虚的，直接上“买家秀”。如果你还在犹豫选哪个，看完这篇实操和对比，心里就有数了。

第一回合：穷人的法拉利 —— AIDE 实战

AIDE (Advanced Intrusion Detection Environment) 这玩意儿，我愿称之为“静态防御之王”。它不要数据库服务，不要Web界面，就是一个二进制文件加一个文本库。

测试环境：CentOS 7.9 (2核4G)

1. 极速安装

不用去官网下源码编译，那太累。直接yum，咱们追求的是效率。

# 先装个epel源，虽然一般都有，但为了保险
yum install epel-release -y
# 直接安装
yum install aide -y

装完你看一下版本 aide -v，一般是v0.15或者v0.16，够用了。

2. 配置文件的“坑”与“填坑”

配置在 /etc/aide.conf。这地方我得着重说一下，很多新手死就死在这里。

默认配置会把整个Linux系统都扫描一遍。兄弟，你别傻乎乎地直接跑。Linux系统里那些 /proc、/sys、/var/run 是一直在变的，你扫这些目录，生成的报告能有几十兆，全是误报。

来，跟我改，咱们只做减法。

打开配置文件：
vim /etc/aide.conf

找到 Define 区域，先把这几个规则看懂：

NORMAL = R+sha512 (普通模式，查权限、所有者、哈希)
DIR = p+i+n+u+g (只查目录属性，不管内容)

然后往下翻，把不想扫的目录统统注释掉或者用 ! 排除掉。我一般这么配，只监控核心网站目录和系统命令：

# 自定义一个规则，叫 WebRule，查得细一点
WebRule = p+i+n+u+g+s+b+m+c+sha512

# 监控网站根目录
/var/www/html WebRule

# 监控关键配置
/etc/nginx WebRule
/etc/passwd WebRule
/etc/shadow WebRule

# 监控常用命令（防止被替换成木马）
/bin WebRule
/sbin WebRule
/usr/bin WebRule

# ! 表示忽略，千万把日志忽略了！
!/var/log
!/tmp
!/var/www/html/uploads  # 假设这是用户上传目录，经常变，要忽略

3. 初始化：建立“指纹库”

配置改好了，现在要让AIDE给你的文件拍第一张“X光片”。

aide --init

这个时候你可以去泡杯咖啡。如果你的文件多，这步大概要跑个一两分钟。
跑完之后，它会在 /var/lib/aide/ 下生成一个 aide.db.new.gz。

注意！关键操作来了！
你必须把这个 .new 的文件，重命名为 aide.db.gz。AIDE的设计逻辑是：每次检查对比的是 aide.db.gz，每次更新生成的是 .new。

mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

4. 模拟篡改与检测

现在，我是黑客，我进来了。

# 往首页里插个广告
echo "<script>alert('澳门首家线上赌场上线啦')</script>" >> /var/www/html/index.html
# 再偷偷把ls命令改个名字（模拟）
cp /bin/ls /bin/ls_back

好，现在运维（我）回来了，开始检查：

aide --check

大概过了几十秒，屏幕上吐出了一大段报告：

AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2026-01-11 10:00:00

Summary:
  Total number of entries:    500
  Added entries:              1
  Removed entries:            0
  Changed entries:            1

---------------------------------------------------
Added entries:
---------------------------------------------------

f++++++++++++++++: /bin/ls_back

---------------------------------------------------
Changed entries:
---------------------------------------------------

f >... ..C.. : /var/www/html/index.html

---------------------------------------------------

效果点评：
你看，它很诚实。告诉你 /bin/ls_back 是新加的（Added），index.html 变了（Changed）。
但是！它不会告诉你谁改的，也不会告诉你什么时候改的（只能看到扫描时间）。而且，这玩意是被动的，你不跑 --check，它就永远不说话。

平时我们都是把 aide --check | mail -s "AIDE Report" admin@example.com 扔到 crontab 里，每天凌晨跑一次。

第二回合：重装机甲 —— Wazuh 部署实录

如果说AIDE是把老猎枪，Wazuh就是带红外瞄准镜的加特林。

但我得吐槽一句，Wazuh的单机源码安装极其繁琐，依赖多到让人崩溃。所以，强烈建议用 Docker。咱们是为了解决问题，不是为了学编译原理。

测试环境：Ubuntu 20.04 (4核8G) —— 没错，这货吃资源。

1. 服务端部署（Docker Compose）

前提是你装好了 Docker 和 Docker Compose。

# 克隆官方的docker仓库
git clone https://github.com/wazuh/wazuh-docker.git -b v4.7.0
cd wazuh-docker/single-node/

这里有个小技巧，官方默认配置会起一大堆证书生成的脚本，挺慢的。咱们直接把 docker-compose.yml 里的资源限制稍微改大点，不然ES启动会卡死。

然后一键启动：

docker-compose up -d

这步取决于你网速，拉镜像可能要一会。等全都 Up 之后，访问 https://你的IP。默认账号 admin，密码在 wazuh-install-files/wazuh_passwords.txt 里面找。

进去之后，那个界面，真的，一看就是“大厂风”，深色模式，各种仪表盘。

2. Agent 部署（被监控端）

服务端跑起来了，现在我要监控我的 web 服务器（假设是另一台 CentOS）。

在 Wazuh 的 Web 界面上，点 “Add Agent”，它会自动给你生成一串命令。这就很舒服，不用自己敲。

大概长这样：

curl -so wazuh-agent.rpm https://packages.wazuh.com/4.x/yum/wazuh-agent-4.7.0-1.x86_64.rpm
WAZUH_MANAGER='192.168.1.100' WAZUH_AGENT_GROUP='default' rpm -ihv wazuh-agent.rpm

执行完，启动服务：

systemctl enable wazuh-agent
systemctl start wazuh-agent

3. 开启 FIM (文件完整性监控)

默认情况下，Wazuh Agent 已经开启了 FIM，但是策略很宽泛。咱们需要去修改 Agent 端的配置文件 /var/ossec/etc/ossec.conf。

（也可以在服务端通过 Group 配置远程下发，但咱们今天手动改，更直观）

找到 <syscheck> 模块：

<syscheck>
  <!-- 扫描频率，默认是12小时，太慢了！咱们测试改成 60秒 -->
  <frequency>60</frequency>
  
  <!-- 实时监控！这才是Wazuh的杀手锏 -->
  <!-- realtime="yes" 表示利用内核inotify机制，秒级响应 -->
  <directories check_all="yes" realtime="yes" report_changes="yes">/var/www/html</directories>
  
  <ignore>/var/www/html/cache</ignore>
</syscheck>

改完重启 agent：systemctl restart wazuh-agent。

4. 真实效果炸裂

现在，我再次扮演黑客，修改 /var/www/html/index.php。

echo "Hack" >> /var/www/html/index.php

只过了不到2秒钟！

我在 Wazuh 的 Web 界面 -> Modules -> Integrity monitoring 里，立马看到了一条红色报警。

点开详情，它展示了：

File: /var/www/html/index.php
Event: Modified
Who: uid: 0 (root) —— 甚至能看到是 root 用户改的！
Process: 甚至能追踪到是哪个进程（审计功能开启的话）。
Diff: 如果你配置了 report_changes="yes"，它甚至会把修改前和修改后的代码差异给你列出来！

这就很恐怖了。不仅知道有人拆家，还知道他拆了哪块砖，手里拿的什么锤子。

第三回合：土法炼钢 —— Git 自动复原流

有些兄弟说，Wazuh 太重了，我这就一台 1核2G 的阿里云，跑不动。AIDE 又太慢。有没有轻量又实时的？

有。Git。

这招特别适合纯静态的前端项目。

实操流程：

把你的网站目录变成 Git 仓库。
```
cd /var/www/html
git init
git add .
git commit -m "Initial Site Release"
```
这时候，这就是你的“黄金备份”。

写个死循环脚本 watch_dog.sh：

#!/bin/bash
TARGET="/var/www/html"

# 用 inotifywait 监听目录，一旦有写入、删除、移动，立马触发
/usr/bin/inotifywait -mrq -e modify,create,delete,move $TARGET | while read file
do
    echo "Alert: File $file changed! Reverting..."
    cd $TARGET
    # 强制复原
    git reset --hard HEAD
    git clean -fd
    
    # 顺便发个钉钉报警（这里省略curl命令）
done

后台运行：nohup ./watch_dog.sh &

效果测试：
我刚用 vim 打开 index.html，随便敲了个乱码，保存 :wq。
瞬间！真的是瞬间，文件就变回去了。
因为脚本监测到了写入事件，直接触发 git 回滚。

这种感觉就像你往墙上泼了一桶油漆，墙壁自己把自己刷新了一遍。这招对付挂马脚本简直是降维打击。

终极对比：到底该选谁？

实验做完了，数据我也跑了一下，咱们来个横向大对比。

维度	AIDE	Wazuh	Git脚本流
部署难度	⭐ (极简，yum一下就好)	⭐⭐⭐⭐⭐ (复杂，又是Docker又是配置XML)	⭐⭐ (需要懂点Shell)
资源占用	极低 (平时不占，扫描时占CPU)	高 (Java+ES，没个4G内存别玩)	极低 (inotify非常轻)
实时性	差 (依赖定时任务，有空窗期)	完美 (秒级响应)	完美 (秒级响应)
证据能力	弱 (只知道变了)	强 (谁改的、改了啥、对比差异)	无 (直接复原了，证据都没了)
适用场景	老旧服务器、合规应付检查、静态归档站	核心业务系统、等保三级要求、有专门运维	个人站长、纯静态前端、极客玩家