AIDE vs Wazuh：主机防篡改双方案实战，运维保命符怎么选

做运维这些年我最怕的不是半夜被一条宕机短信吵醒而是服务器被人改了文件却没人知道。防篡改这件事几乎每个季度都要被等保、IT审计和安全团队拎出来问一遍。AIDE 和 Wazuh是我在开源方案里用得最多的两套AIDE 像一把锁在保险柜里的校尺把系统文件的“指纹”全部记下来之后随时拿去比对Wazuh 则是一整套哨兵系统从文件完整性到入侵检测、日志分析全覆盖。这篇就把两套方案从部署、配置到真实篡改模拟完整摆在一起“打一架”看谁才配得上运维人“保命符”这个称号。适合正在搞等保整改又不想堆商业软件预算的运维同学也适合准备在公司内部落地主机安全加固的工程师。1. 方案选型与部署思路拆解1.1 AIDE 和 Wazuh 到底在解决什么问题很多刚接触主机安全的运维会把 AIDE 和 Wazuh 当成同一类东西其实两者的设计思路差别很大。AIDEAdvanced Intrusion Detection Environment是一个离线静态完整性校验工具。它的工作方式很朴素在系统干净的时候扫描指定目录和文件计算哈希、记录权限、属主、大小、时间戳等属性生成一份基线数据库。之后你手动或通过定时任务再跑一次扫描把当前状态和基线比对差异就会被报告出来。它不会一直盯着文件不会主动报警也不带 Web 界面所有结论都写在报告里。所以 AIDE 本质上是一个“体检工具”不是“心电监护仪”。Wazuh 则是典型的分布式主机入侵检测系统HIDS。它的核心架构是 manager 加 agent每台被监控的机器上装一个 agentagent 实时收集文件变更、登录日志、进程信息、系统配置等数据通过加密通道上报给中心端的 managermanager 再配合索引和可视化组件把告警展示在统一 Dashboard 上。Wazuh 的 FIM文件完整性监控模块可以在文件被创建、修改、删除时实时推送告警还能把文件变动和账号登录、提权操作等上下文关联起来形成一条完整的攻击链条视图。拿“防篡改”这个目标来说AIDE 回答的是“我的文件有没有变”Wazuh 回答的是“文件什么时候变的、被谁改的、改完之后还发生了什么”。这两种信息都很重要但适用的场景完全不同。1.2 选型决策按场景选方案而不是选“信仰”我在选型时从来不看谁的 star 多只看手里的服务器资源、人员精力和合规要求理清这几点方案自然就出来了。先看一个决策表维度AIDEWazuh部署架构单机工具无需中心端manager agent 分布式监控时效手动/定时触发非实时文件变化实时告警资源占用服务常驻内存几乎为零扫描时才吃 CPUagent 大约几十 MB 内存服务端和索引组件很吃资源告警能力无主动告警靠脚本发邮件自带告警规则、通知渠道、SIEM 联动集中管理各机器独立维护基线统一管理多台主机上手难度低一个配置文件加两条命令偏高需要理解四件套组件典型场景低配服务器、单机巡检、合规抽查集群环境、实时安全运营、审计留痕如果公司只有三五台服务器还是那种 1C2G 的老古董装了 Wazuh 服务端就等着 OOM 吧老老实实装 AIDE配上 cron 每天扫一遍就够了。反过来如果有几十台核心业务机还要跟 SOC 平台对接AIDE 每次都要请你登录到每台服务器去拉报告运营成本会把人逼疯。另外注意这两个方案不是非黑即白。我在不少项目里是混着用的重要节点上 Wazuh 做实时监控边上再挂一台跑 AIDE 做每天凌晨的离线兜底扫描双保险。后面我会专门讲这种组合怎么落。2. AIDE 部署实战把文件指纹锁进保险柜2.1 安装 AIDE 并生成第一份基线AIDE 几乎所有主流发行版仓库里都有直接装就行。Debian/Ubuntu 系的命令是apt update apt install aide -yRHEL/CentOS 系统对应用 yum 或 dnfyum install aide -y装完之后先别急着初始化先把配置文件改好。以常见的/etc/aide.conf为例核心是确定两个东西基线数据库存哪、检查哪些字段。database_infile:/var/lib/aide/aide.db.gz database_outfile:/var/lib/aide/aide.db.new.gz report_urlfile:/var/lib/aide/aide.report NORMAL sha256ftypepermuidgidsizeatimemtimectime LOGFILES pugftypesha256 /bin NORMAL /sbin NORMAL /etc NORMAL /usr/bin NORMAL /usr/sbin NORMAL /opt NORMAL !/var/log/ !/tmp/ !/run/ !/proc/ !/sys/ !/var/lib/docker/这几条规则的意思很直白对/bin、/etc、/usr/bin这些关键目录做哈希、权限、属主等属性的完整记录同时排除日志、临时目录、伪文件系统这些天天变的地方。新手最容易犯的错就是一开始把/var整个目录都纳进来结果日志轮转一下第二天报告里铺满几百条误报。记住一个原则先锁定关键目录跑一段时间没问题了再逐步扩大范围。配置保存后执行初始化aide --init这个过程会扫描配置里定义的目录生成/var/lib/aide/aide.db.new.gz。接下来把它改名成正式的基线库mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz这一步非常关键很多教程会漏掉说明导致后面执行校验时 AIDE 一直抱怨找不到数据库。不同发行版生成的文件名后缀可能略有差异比如有的没有.gz以你执行后实际生成的文件名称为准。生成完基线后顺手把数据库文件的权限收紧chmod 600 /var/lib/aide/aide.db.gz基线库本身就是防篡改的核心资产谁改了这个文件等于把保险柜钥匙给换了。把它权限设成仅 root 可读写是最基本的保护。2.2 配置巡检任务、降低误报、更新基线AIDE 本身没有守候进程校验靠的是定期触发。最省事的方案是写进 crontab0 3 * * * /usr/bin/aide --check /var/log/aide_check.log 21每天晚上 3 点跑一次完整校验输出到独立日志文件。加上邮件通知可以配合常见的 mailx 命令把 diff 结果发出来。我在实际运维中会把日志保留三个月等保审计或安全同事来问话时随手就是一条完整的检查曲线。跑一次校验后输出里常见两类数据Files that were added: 新出现的文件可能是软件安装遗留也可能是提权后落地的恶意脚本。Files that were changed: 文件内容或属性变化比如二进制程序被替换、配置文件被改写。看到新增文件先别慌用stat命令定位时间、属主再结合变更窗口期的操作记录判断。如果确认是自己发布版本或者配置变更导致的就需要更新基线aide --update再执行一次 mv 命令把新的aide.db.new.gz覆盖到正式数据库mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz这里有一个我踩过好几次的坑一定先确认变更合法再去更新基线。如果服务器已经被人植入了后门你直接执行aide --update等于亲手把含后门的文件状态写进“安全基准线”之后 AIDE 永远都会认为后门文件是正常的。正确做法是先对异常文件做哈希和内容分析确认干净后才允许更新基线覆盖。误报是 AIDE 使用中最大的劝退项。常见的误报来源包括/etc下用户登录会改动的lastlog、faillog软件包管理器升级后产生的大量.rpmnew文件以及容器的动态挂载目录。这些都可以通过新增忽略规则解决!/etc/lastlog !/etc/faillog !/var/lib/apt/ !/var/cache/优化配置是个反复迭代的过程前两周的误报要花时间逐条筛查等规则稳定下来AIDE 基本就能做到“不鸣则已一鸣惊人”。3. Wazuh 部署实战从零搭一套实时篡改监控3.1 安装 Wazuh 服务端并初始化环境Wazuh 的完整部署通常包含三个组件Wazuh manager负责接收 agent 上报、解析告警规则、Wazuh indexer基于 OpenSearch 做日志索引和存储、Wazuh dashboard可视化界面。生产环境这三种可以分开部署测试环境或小规模部署可以直接在一台机器上装完。虽然手动部署能加深理解但官方提供的一键安装脚本在初始化阶段确实能省掉大量配置时间。比如 4.x 版本的常见安装方式curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash ./wazuh-install.sh -a脚本会自动装好 manager、indexer、dashboard 三件套并生成索引账号和证书。安装脚本对内存有要求建议至少给 4GB 以上磁盘 50GB 起步否则部署过程中 OpenSearch 集群很容易因为内存熔断启动失败。装完最后会在终端打出 Dashboard 的访问地址和管理员密码记得保存好。如果忘了可以通过脚本工具重新生成sudo /var/ossec/bin/wazuh-passwords-tool -u admin -p WazuhAdmin123建议把打印出来的密码存到公司密码库里不要甩在默认终端记录里。Wazuh manager 的配置文件默认在/var/ossec/etc/ossec.conf。agent 上报数据默认走 1514/TCP 或 UDPagent 注册走 1515/TCP。安装完成后先在 manager 上确认接收端口在监听ss -lntp | grep 1514 ss -lntp | grep 1515如果端口没起来去翻/var/ossec/logs/ossec.log大部分问题都能在日志里找到线索。3.2 安装并注册 Agentagent 在每台被监控的服务器上安装常见发行版都可以直接用二进制包。以 RHEL 为例装 Docker 版 agent 反而复杂直接用原生包最稳curl -s https://packages.wazuh.com/4.x/yum/wazuh-agent-4.7.2-1.x86_64.rpm -o wazuh-agent.rpm yum localinstall -y wazuh-agent.rpmDebian/Ubuntu 对应使用 deb 包安装。装完先别急着启动因为 agent 还没注册到 manager 上启动也没有意义。注册方式分两种有交互的 agent-auth 和自动注册。手动注册更可控命令类似/var/ossec/bin/agent-auth -m 192.168.1.10 -p 1515这里的192.168.1.10换成你 manager 的地址。注册成功后agent 的/var/ossec/etc/ossec.conf里会把 manager 的地址写好然后启动systemctl enable --now wazuh-agent在 manager 端确认 agent 状态/var/ossec/bin/agent_control -l正常会看到 agent 名称、ID 和Active状态。如果显示Disconnected优先检查 agent 到 manager 的 1514 端口能不能通以及两台机器时间是否同步——时间漂移超过五分钟TLS 握手会直接失败这是新手最常犯的错。3.3 FIM 文件完整性模块配置与告警联调Wazuh agent 里负责文件监控的模块叫 syscheck也就是 FIM。默认配置通常已经监控了部分系统目录但要想达到等保要求的“关键目录完整性校验”最好自定义监控范围和检查频率。修改 agent 端/var/ossec/etc/ossec.conf找到syscheck段把监控目录加上去syscheck directories check_allyes/etc,/usr/bin,/usr/sbin,/opt/directories directories check_allyes realtimeyes/home/www/web/directories ignore/etc/mtab/ignore ignore/etc/hosts.deny/ignore frequency3600/frequency /syscheck这里几个参数解释一下check_allyes表示同时检查哈希、权限、属主、大小、时间戳等所有元数据和 AIDE 的 NORMAL 规则思路一致。realtimeyes开启实时监控。这个目录不是所有文件系统都支持但 ext4、xfs 这类主流文件系统没问题。frequency3600/frequency是无实时监控目录的兜底扫描周期单位是秒一小时扫一次配合实时监控覆盖例外场景。修改完重启 agentsystemctl restart wazuh-agent此时随便往被监控目录里写一个测试文件比如echo test /tmp/pwned.txt cp /tmp/pwned.txt /etc/definitely_new_file十几秒内manager 就能收到告警。登录 Wazuh Dashboard在 Security events 模块搜索data.type:file就能看到文件的增加、内容变更或删除事件包括文件路径、哈希值、触发告警的用户和进程信息。这一步就是 Wazuh 和 AIDE 拉开差距的地方AIDE 只能告诉你文件变了Wazuh 会告诉你“谁通过什么方式在什么时间把这个文件改了”这种上下文对于应急响应和事后追责非常有用。告警规则也可以自己调。FIM 产生的事件会走syscheck规则组默认规则已经覆盖新文件、修改内容、删除文件等常见场景。如果觉得某些目录过于敏感可以自定义规则提升告警级别比如对/etc/shadow的变更直接提到等级 10最高危。做法是在 manager 端/var/ossec/etc/rules/local_rules.xml里加本地规则这个后面再说。4. 真实篡改模拟两台工具同时“接招”4.1 模拟异常文件变更并观察两者表现光说不练没有说服力。我在测试环境里准备了两台干净的 CentOS 7 机器一台只装 AIDE一台装 Wazuh agent 并接入同一台 manager。两边都监控/etc和/usr/bin然后我做了以下几步操作echo backdoor simulation /usr/bin/ls echo hacked /etc/hosts touch /root/test_new_file.sh先看 Wazuh 这边。改/usr/bin/ls后大概几秒到十几秒Dashboard 上syscheck告警就弹出来了告警里直接显示/usr/bin/ls的哈希从原来的系统值变成了我们写入内容的哈希并且带上了执行操作的进程路径。这种时效性作为实时监控工具基本合格。再看 AIDE。执行aide --check输出明确列出File: /usr/bin/ls的 sha256 与基线不符。File: /etc/hosts的 sha256 与基线不符。新增文件/root/test_new_file.sh不在基线中。AIDE 准是准的但它是“马后炮”——当它发现问题的时候距离文件被篡改可能已经过去了十多个小时。这就是静态校验工具和实时监控工具的天然差别。两者的检测效果对比如下观察项AIDEWazuh检出准确性高哈希比对无歧义高FIM 同样基于哈希比对检测时效取决于定时周期通常小时级到天级实时或秒级告警上下文只有文件路径和属性变化包含进程、用户、父进程、关联登录事件是否支持集中审计单机报告统一 Dashboard可导出报表误报治理靠配置文件手工 exclude靠规则和 ignore 标签配合 Dashboard 筛选4.2 响应时效、资源占用与运营成本对比拿资源占用来说AIDE 在闲置时几乎不占系统资源因为它根本没有常驻进程。只有在执行扫描的时候CPU 才会明显跑起来。对一个几万文件的系统目录做完整哈希扫描通常需要几分钟到十几分钟期间会吃 100% 的单核 CPU但扫描结束就释放了。这个特点决定了 AIDE 特别适合放在那些业务高峰期不能有一丁点性能损耗的窄机服务器上。Wazuh agent 的常驻内存大概 40 MB 到 100 MB 之间具体取决于监控的文件量和规则套件数量。这个体量对新机器来说不算大但在 1G 内存的存量小机器上就要掂量一下了。更需要注意的是服务端成本一个得到完整体验的 Wazuh 集群manager、indexer、dashboard 三件套跑下来4G 内存几乎是底线8G 才算宽裕。如果索引保留周期是三到六个月磁盘要按每天几个 GB 的日志增量去规划。运营成本上AIDE 的胜出没有悬念一个人一台机器一个 cron 定时任务齐活。Wazuh 则要定期关注索引膨胀、升级组件、优化告警规则还要处理 agent 掉线、证书过期之类的问题。说白了AIDE 是一把称手的瑞士军刀Wazuh 是一套需要专人维护的安防系统。4.3 谁更适合做你的“保命符”实操建议别指望有哪个工具是万能的我的实操建议可以写得直白一点。如果你属于这些情况优先选 AIDE服务器数量少于 5 台没有专职安全人员。机器配置老旧装安全组件会明显影响业务。只需要应付合规检查报告能说明“我周期性地做了完整性校验”就行。对告警实时性没有硬性要求发现被篡改后走手动排查流程。如果你属于这些情况直接上 Wazuh服务器数量超过 10 台需要一个统一入口查看告警。安全团队或 SOC 平台需要实时事件推送。需要把文件篡改事件和账号登录、进程行为关联分析。应对等级保护或行业审计时需要“可检索、可追溯、可留痕”的审计证据链。在资源允许的前提下我更推荐的还是“AIDE 兜底 Wazuh 实时”的组合Wazuh 负责实时发现和快速响应AIDE 作为每天凌晨的独立复核机制两台工具交叉验证基本上能把“文件被改但没人知道”这个风险压到很低的水平。5. 常见问题与排查技巧实录5.1 AIDE 常见误报与基线恢复AIDE 用久了最闹心的是误报。我见过最典型的情况是系统用yum或apt更新软件包后第二天 AIDE 报告一堆二进制文件被修改其实只是打了补丁的正常结果。这个不属于误报但确实会干扰判断。处理方式很简单更新完系统后先执行aide --check看一下差异确认没有异常就执行aide --update把新状态固化到基线。注意时序先确认后更新。基线数据库丢失也很常见。比如误删了/var/lib/aide/aide.db.gz或者磁盘故障。这时候最优雅的恢复方式是使用离线备份的基线库。所以运维初期就要把aide.db.gz定期备份走cp /var/lib/aide/aide.db.gz /security/backup/aide.db.gz.$(date %F)如果既没有备份又必须重建基线那就只能在系统确认干净的前提下重新aide --init。怎么确认干净呢检查监听端口、最近七天新增的可疑文件、历史登录记录没有明显异常再动手。说实话这种重建基线的方法在“已经被入侵”的机器上是有风险的但在实际应急里很多老机器根本没有备份习惯也只能矮子里拔高个。这也是我反复强调“基线数据库必须定时异地归档”的原因。另外AIDE 的扫描报告会越攒越大。建议在 cron 脚本里直接对报告做按天切割并保留最近 90 天的归档超过 180 天的可以压缩打包丢去做长期归档免得/var/log被撑爆。5.2 Wazuh 注册、连接与告警不触发的排查Wazuh 部署中的坑主要集中在这几个点上。第一个是 agent 注册不上 manager。确认 agent 端命令执行完没有报错后去 manager 看日志tail -f /var/ossec/logs/ossec.log如果看到ERROR: Cannot verify agent十有八九是 TLS 证书或注册端口问题。检查防火墙是否放行了 1514/1515以及 agent-auth 的 IP 是否写对。老版本中还区分 55000 端口新版本统一用 1515别拿旧教程硬套。第二个是 agent 显示Disconnected。时间不同步是头号原因跑一下chronyc tracking先在 manager 和 agent 两边确认时间误差。超过几秒就该配 NTP 服务。其次是 agent 的 manager 地址配置错误打开/var/ossec/etc/ossec.conf里clientserver段的address核对。第三个是文件明明改了但 Dashboard 没有告警。排查路径按顺序走确认 agent 配置文件里syscheck是否启用没有被注释。确认监控目录是否包含改动发生的位置。检查 Dashboard 上 agent 本身是否活跃日志能否正常上报。检查是否被ignore或者告警规则过滤掉了。比如某些标准事件在规则里默认不告警需要到local_rules.xml里加规则升级。第四个存储问题。Wazuh 的索引数据增长非常快如果不管它磁盘迟早会被撑满。生产环境建议尽早配置索引生命周期管理ILM把 Wazuh 索引的保留周期设置为 30 天删除超过周期的历史索引。具体做法是在 Dashboard 的 Index Management 里创建策略或者用后台 API 调用设置这个细节对长期运维是非常有价值的。5.3 混合部署与长期维护经验AIDE 和 Wazuh 混装时要注意文件变化会产生两边告警但不必担心冲突。AIDE 扫描/etc时去读文件可能被 Wazuh 检测为read事件这属于正常现象不用特地去 Wazuh 里排除 AIDE 进程。我甚至会更愿意反过来利用这一点如果某个文件的改动在 Wazuh 里没有触发告警但在 AIDE 报告里出现了说明有一层防护可能被绕过需要专门排查。长期维护的另一个经验是定期做“演练”。我每隔一个季度会挑一台不重要的测试机器执行一次模拟篡改确认 AIDE 能报、Wazuh 能弹、告警能推送到钉钉或企业微信。这套机制不用花多少时间但能保证整套防篡改链路在关键时刻真的顶得住。安全工具装好不是终点定期验证才是它作为“保命符”的意义。最后再分享一个我在实战里特别常用的组合技巧Wazuh 告警出来之后先别急着信用 AIDE 的同路径文件哈希做二次校验两边结果一致这个告警才算真正坐实。两条工具链互为备份、互相印证比单用一个工具拿到的安全感要扎实得多。