告警疲劳这件事干过安全运营的都懂被几千条日志淹到怀疑人生。最近半年我在复盘几次真实入侵的时候发现很多告警规则不是没用而是从来没有人验证过它到底能不能在特定日志形态下触发。与其在生产环境里赌运气不如在一个可控的检测实验室里把规则炸明白。下面这些内容就是我用Wazuh搭检测实验室的完整过程从选型、部署到三个检测场景的实际复现适合刚开始接触Wazuh的安全同学、想搭蓝队验证环境的运维以及天天被告警淹没的运营朋友参考。1. 先搞清楚这个检测实验室解决什么问题1.1 我为什么需要搭建这样的环境很多人在生产环境里直接部署Wazuh然后等着告警自己冒出来。这个思路不能说错但问题在于你真的知道某条规则在什么日志下会触发吗同一个攻击行为在CentOS上用auth.log记录在Ubuntu上可能走journald在Windows上是Security日志格式完全不同。解码器解不出来规则写得再漂亮也是废纸。我搭这个实验室的初衷很简单在隔离的内网环境里用最接近真实的攻击流量去测试Wazuh的检测能力。比如SSH暴力破解进来以后告警能不能在预期时间内出现等级是否合理会不会误报主动响应能不能自动封禁。这些东西不在实验室里砸出来上了生产环境根本不敢开。另一个刚需是规则测试。Wazuh的规则分成解码器decoder和规则rule两层写一条自定义规则很容易但写完之后它到底会不会被触发需要一次真实的攻击事件来验证。Wazuh内置了一个叫wazuh-logtest的工具可以直接喂日志看匹配结果。这个工具我在实验室里用了无数次后半部分会详细讲。1.2 Wazuh到底是个什么物种Wazuh是一个开源的统一安全监控平台业内通常叫它HIDS主机入侵检测系统但因为它自带日志分析、文件完整性监控、漏洞检测、合规基线检查和云工作负载保护能力实际使用中更像一个轻量级的SIEM/XDR。它的前身是OSSEC很多老运维应该听过。Wazuh在OSSEC的基础上重构了架构引入了索引和可视化层所以告警查询比传统OSSEC舒服太多。它的基本组件分四块Agent负责在被监控主机上采集日志、做文件监控、执行主动响应Manager负责接收Agent上报的数据跑解码器和规则引擎产生告警Indexer负责存储告警和日志并提供全文检索底层是基于OpenSearch的Dashboard则是浏览器里的可视化界面。四者合在一起就是一套能自洽的检测分析平台。2. 实验室架构与组件选型2.1 单机All-in-One部署方案Wazuh官方支持三种部署模式All-in-One全都装在一台机器上、分布式Manager单独一台、Indexer集群、Dashboard单独一台以及Kubernetes部署。实验室环境我强烈建议用All-in-One。原因很直接组件之间通信不需要走外部网络排障链路短资源占用低而且官方安装脚本对单机模式支持最好一条命令就能拉起全套。生产环境当然不建议这样玩因为Indexer一旦挂了整个告警查询和存储就都断了单点故障太明显。但实验室里我们要的是快速验证不是高可用。我自己用一台4核8G内存的虚拟机就够了磁盘给了100G。如果以后要导入大量历史日志做分析可以加到200G但基础实验100G完全够。2.2 各组件角色的一句话理解刚接触Wazuh的人容易把Manager和Indexer搞混。我一般用一个生活类比来说明Manager像门卫负责检查每个进来的包裹日志是否符合规矩、有没有夹带危险品这就是解码和规则匹配的过程Indexer像仓库管理员把通过检查的包裹登记造册、分门别类放好你要查的时候能快速翻出来Dashboard就是监控室的屏幕让你不用天天跑仓库就能看到所有情况。Agent则是派驻在每台被监控机器上的哨兵。它会把系统日志、文件变动、进程执行、网络连接这些信息实时上报给Manager。Agent本身很轻量单机内存占用大概几十MB所以在生产环境的服务器上批量部署不会有太大负担。这个架构理解清楚了后续配置和排障就会顺手很多。2.3 网络规划与虚拟机准备我在一台宿主机上用VirtualBox搭了三台虚拟机一台装Wazuh服务端一台Ubuntu 22.04作为Agent主机一台Kali Linux作为攻击模拟机。网络全部用内网Host-Only模式IP段随意只要三台能互通就行。我这里用的地址是服务端192.168.10.10Agent主机192.168.10.20攻击机192.168.10.30。这里有一个值得注意的点千万不要把实验室直接放在公司办公网段里。攻击模拟工具一旦失控或者Agent的主动响应配置有误可能会误伤隔壁同事的机器。我见过有人做实验时把防火墙封禁规则写错结果把自己运维跳板机的IP封掉折腾一下午才解封。实验室就该有实验室的隔离态度。3. 从零搭建Wazuh检测实验室3.1 服务端安装前的环境准备先把服务端虚拟机装好我用的是Ubuntu 22.04 LTS Server版最小安装就行。进入系统后先做三件事设置静态IP、改好主机名、确认系统时间同步。第三点容易被忽略但Wazuh对告警时间戳非常敏感如果Agent和服务端时间漂移超过几十秒事件排序和关联分析就会出问题。直接装个chrony或者用系统自带的timedatectl同步即可。内存分配上我给服务端虚拟机分了6G因为Indexer本身有一定内存需求加上Manager和Dashboard都在这台机器上4G也能跑但查询大日志时会有明显卡顿。CPU给了4核。磁盘100G。这样的配置跑完整套实验毫无压力。如果你机器紧张2核4G也可以但Dashboard打开时的响应速度会让你怀疑人生。3.2 安装Wazuh服务端Manager、Indexer、DashboardWazuh提供了官方安装脚本4.x版本都是通过wazuh-install.sh完成。All-in-One模式下只需要执行下面两条命令curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh sudo bash wazuh-install.sh -a这个脚本会自动完成索引器、Dashboards、Manager以及Filebeat的安装和配置。整个安装过程大概十几分钟取决于网络速度。脚本执行过程中会在最后输出Dashboard的访问地址和初始账号密码一定要记下来或者找到脚本生成的wazuh-passwords.txt文件保存好。安装完成后浏览器打开https://192.168.10.10就能看到Wazuh Dashboard登录页。用脚本生成的admin账号登录左侧菜单里能看到Security events、Integrity monitoring、Vulnerabilities这些大板块说明服务端已经起来了。3.3 部署Agent并完成注册Agent部署用的是反向注册enrollment机制只要Agent配置里写了Manager的IP和端口它会自动向Manager的1515端口请求注册拿到证书后建立连接。这个过程很省心不像老版本还要手动拷贝agent key。我在这台Ubuntu Agent主机上执行的是curl -s https://packages.wazuh.com/4.x/apt/wazuh-agent_4.9.0_amd64.deb -o wazuh-agent.deb sudo WAZUH_MANAGER192.168.10.10 dpkg -i wazuh-agent.deb sudo systemctl daemon-reload sudo systemctl enable wazuh-agent sudo systemctl start wazuh-agent装完以后去Dashboard的Agents页面等几十秒正常情况下就能看到这台机器出现在列表里状态是Active。如果一直显示Disconnected或者Never connected多半是1515端口的注册请求被防火墙拦了或者Manager地址写错。这个我在后面排查部分会细说。3.4 上线前必做的日志采集检查Agent装好只是一个开始真正要看的是日志到底有没有上来。Wazuh Agent默认会在ossec.conf里配置好几个本地日志文件包括/var/log/auth.log、/var/log/syslog等。但实际环境里比如你用的是CentOS认证日志路径变成/var/log/secureAgent默认配置覆盖不到什么都不采集。所以上线前一定要先确认Agent的本地日志采集配置在Agent机器的/var/ossec/etc/ossec.conf文件里找到localfile段按需加上目标日志文件路径。这个动作能省掉后面大量的为什么没有告警排查时间。日志采集这块检查完再确认Syscheck文件完整性监控和Syscollector系统资产采集模块是启用的这两个模块是后面实验场景的主角。4. 核心实操三个检测场景的完整复现4.1 场景一SSH暴力破解检测实验第一个实验我选了最经典的SSH暴力破解。先确认Agent主机上sshd服务运行正常然后我在攻击机Kali上准备了一份常见的弱口令字典执行hydra对Agent主机做暴力破解hydra -l root -P passwords.txt ssh://192.168.10.20这里提醒一句hydra只能在自己的实验环境里打自己的机器别拿去做任何未经授权的测试。实验环境的好处就是可以放心大胆地做。hydra跑起来没两分钟Dashboard的Security events页面就开始刷告警了。搜一下SSH或者brute force关键字能看到认证失败的告警一条一条进来等级从5级开始直到触发Wazuh内置的高危告警规则等级直接跳到10。点开告警详情还能看到源IP、目标IP、用户名、解码后的日志原文。这个实验验证的核心结论是Wazuh对SSH暴力破解的检测依赖Agent上报的auth.log内容解码器能第一时间识别登录失败的事件而规则引擎则通过统计短时间内同一来源的失败次数来判定暴力破解。所以只要日志能正常采集告警几乎是实时的。如果在生产环境里遇到检测不到的情况优先排查的不是规则而是日志根本没到Manager。4.2 场景二自定义规则检测Web目录新文件SSH暴力破解用的是Wazuh内置规则第二个实验我改成完全自定义规则专门盯Web目录。这个场景模拟的是webshell上传黑客通过漏洞往Web目录丢了一个新的PHP文件文件完整性监控立刻发现再配合自定义规则产生高等级告警。先确认Agent的Syscheck模块监听范围包含了Web目录。默认情况下它监控的是/etc、/usr/bin、/bin等系统目录Web目录往往不在里面。我在Agent的ossec.conf里加了一段syscheck directories check_allyes/var/www/html/directories /syscheck然后在Manager上写自定义规则。Wazuh的管理端规则目录是/var/ossec/etc/rules/自定义规则统一放在local_rules.xml里。我写的是针对新增文件事件的规则group namelocal,webshell, rule id100100 level12 if_sid554/if_sid field namefile/var/www/html/field descriptionWeb目录出现新文件疑似webshell上传/description /rule /group这里if_sid 554是Wazuh内置的New file added规则我用field匹配把范围缩小到/var/www/html目录。level设成12属于高危告警级别。写完规则后重启Manager生效。接下来模拟攻击行为我用scp往Agent主机的/var/www/html目录丢了一个名为shell.php的文件。几秒钟后Dashboard的Integrity monitoring板块里出现了一条新事件同时Security events里也出现了我自定义的100100规则告警。说明规则链路完整跑通了Syscheck感知文件变动解码器解析事件自定义规则命中告警生成。这里想多说一点规则调试的细节。Wazuh自带一个非常有用的工具在Manager上执行/var/ossec/bin/wazuh-logtest然后粘贴一条模拟日志进去它会告诉你这条日志经过哪个解码器解析、匹配了哪些规则、最终触发的是哪条。我在写自定义规则的时候几乎每次都会先拿真实日志在这个工具里跑一遍确认匹配逻辑符合预期再重启服务。这样可以省掉大量反复重启的时间。4.3 场景三配置主动响应自动封禁第三个实验是重头戏让Wazuh在被检测到攻击后自动执行封禁动作。Wazuh的主动响应机制是在Agent本地执行脚本等于把封禁动作下沉到每一台被保护的主机上。我用的是最经典防火墙封禁方案。在Agent节点的ossec.conf里加上command namefirewall-drop/name executablefirewall-drop.sh/executable timeout_allowedyes/timeout_allowed /command active-response commandfirewall-drop/command locationlocal/location rules_id100100/rules_id timeout300/timeout /active-response这个配置的含义是当Agent本地触发100100规则命中的告警时立即执行firewall-drop.sh这个脚本把攻击源IP用iptables封禁300秒。脚本本身在Agent的/var/ossec/active-response/bin目录下Wazuh默认自带firewall-drop.sh权限是root用户可执行不需要额外下载。配置完重启wazuh-agent服务然后重新做一次webshell上传实验。这次会看到不仅Dashboard出告警攻击机再尝试连接Agent的Web服务时已经不通了说明封禁生效。5分钟后再试连接恢复自动解封。主动响应最容易踩的坑是timeout设置。我曾经图省事把timeout设成0意思是不自动解封。结果实验做完忘了第二天发现自己的运维IP被Agent封了一整天。所以我现在的习惯是所有主动响应必须设置明确的timeout宁可短一点多跑几次实验也别把自己的运维通道堵死。4.4 告警验证与规则调优的关键点三个实验做完我对规则调优的理解比之前深了不少。核心体会是一条检测规则要经过三个维度的验证才算合格。第一真实攻击能不能触发第二正常操作会不会误报第三告警的等级和描述是不是能让运营人员快速判断优先级。我在实验里刻意做了一些正常操作来测误报比如通过合法FTP上传一个普通文档到Web目录看会不会触发webshell规则。结果发现我写的规则过于宽泛任何新文件都会命中。后来我加了文件扩展名匹配只关注.php、.jsp、.asp这类可执行脚本文件误报立刻降了下来。这个调优过程在实验环境里做很安全在生产环境里就只能靠血泪教训积累了。5. 常见问题与排查速查5.1 高频故障排查表我在整个搭建和实验过程中踩了不少坑整理成一张速查表遇到类似问题可以直接照着查。症状可能原因排查动作Agent状态一直DisconnectedAgent连不上Manager的1515注册端口在Agent机上telnet一下Manager IP 1515端口看网络通不通Agent显示Active但看不到日志Agent的localfile路径配置不对打开ossec.conf检查localfile段确认日志路径和系统版本匹配Dashboard上告警很多但都是等级3以下规则threshold没达到攻击量太小适当增加攻击频率或者调低规则触发的失败次数阈值自定义规则写完不生效规则ID冲突或XML语法错误检查Manager日志/var/ossec/logs/ossec.log用wazuh-logtest验证语法主动响应没执行rules_id写错或脚本权限不对核对告警详情里的实际规则ID检查脚本是否有root执行权限Dashboard查询很慢Indexer索引堆积太多检查磁盘空间和索引生命周期策略可调整日志保留天数5.2 三个容易忽略的细节第一个容易忽略的是时间同步。Wazuh做告警关联分析时非常依赖时间一致性AgentManager和Indexer三者间如果时间偏差过大轻则告警顺序错乱重则规则匹配异常。我在每台虚拟机里都装了chrony实验全程没有出现过一次时间相关的问题。第二个容易被忽略的是磁盘空间。Wazuh的Indexer会持续存储日志和告警实验环境跑几天就发现磁盘少了几个G。建议在实验开始就配置好Indexer的索引生命周期策略别让它在后台无限堆积。具体路径是Dashboard里的Indexer Management找到wazuh相关的索引模板设置合理的删除周期比如7天。第三个细节是Agent的主动响应脚本路径。很多人以为Active Response脚本在Manager上实际上Locallocation时执行的是Agent本机的脚本。所以修改防火墙封禁逻辑时要改的是Agent机器上/var/ossec/active-response/bin下的脚本而不是Manager上同路径的文件。我当时在这个问题上绕了两圈才发现。6. 一些经验体会整个实验室搭下来最大的感受是Wazuh的检测能力其实非常依赖使用者对规则的调教能力。工具本身装好只是第一步真正有价值的是把规则放到真实攻击流量里去验证、调优、再验证这个循环。Wazuh内置的规则库覆盖了大部分常见攻击场景但每个企业的业务环境、日志格式、目录结构都不一样完全依赖默认规则一定会出现既有的不查、查的不准的问题。所以我现在的习惯是每上一个新的检测场景都要先在实验室里用真实攻击手法打一遍自己的规则同时配合normal日志做误报测试。这个过程虽然耗时但换来的是生产环境里告警的置信度。另外wazuh-logtest这个工具真的是调试利器建议每个用Wazuh的人都熟练掌握。最后再分享一个小技巧实验环境的虚拟机建议定期做快照。我在调主动响应的时候把Agent的网络策略搞坏过好几次没快照的话就得全部重装有快照一句话就回滚了。折腾检测实验室就是这样踩的坑越多后面用起来越顺手。