1. 为什么选择Wazuh搭建开源安全监控平台1.1 从一台被入侵的测试机说起几年前我负责维护一批对外提供服务的测试服务器某天发现其中一台机器的CPU占用率长期跑满登录上去一看有个陌生进程在疯狂往外发包。查了半天日志发现攻击者是通过一个弱口令SSH进来的而整个过程我居然毫无感知——没有告警、没有记录、没有阻断。那次之后我开始认真找一套能落地的开源安全监控方案试过ELK自己拼、试过OSSEC、也试过商业SIEM的社区版最后长期留下来的就是Wazuh。Wazuh这个东西简单说就是一套开源的安全监控平台它把SIEM安全信息与事件管理和XDR扩展检测与响应这两件事揉在了一起。它能干的事情包括主机入侵检测HIDS、日志采集与分析、文件完整性监控FIM、漏洞检测、合规基线检查、恶意软件检测以及基于规则的告警和主动响应。最关键的是它完全开源部署成本低一台普通的Ubuntu服务器就能跑起来。这篇文章适合谁看如果你是刚接触安全运维的工程师想给自己的服务器加一层监控网或者你是中小团队的运维预算有限但又需要一套能看得见攻击面的系统再或者你只是对开源安全工具感兴趣想动手搭一套玩玩——那这篇内容应该能帮你少走不少弯路。我会从零开始把安装、配置、规则编写、告警联动这些环节都拆开讲尽量做到你照着做就能跑起来。1.2 Wazuh的架构到底长什么样很多人第一次接触Wazuh会被它的组件名搞晕我先用大白话把架构捋一遍。Wazuh整体是C/S架构核心分三块Wazuh Agent装在被监控的主机上负责采集日志、监控文件变化、执行基线检查然后把数据发给Server。它很轻量资源占用低Windows、Linux、macOS都能装。Wazuh Server也就是管理端负责接收Agent上报的数据用规则引擎做分析匹配触发告警。它内部又包含wazuh-manager核心分析引擎和wazuh-indexer负责存储和检索本质是OpenSearch的定制版。Wazuh DashboardWeb界面用来查看告警、做可视化、管理Agent和规则。它基于OpenSearch Dashboards改造。数据流向是这样的Agent采集 → Server分析 → Indexer存储 → Dashboard展示。理解这条链路很重要后面排查问题的时候你得知道数据卡在哪一环。提示Wazuh 4.x版本之后官方把Elastic Stack换成了OpenSearch所以如果你看的是老教程里提到Elasticsearch那是4.0之前的架构别混用。1.3 为什么推荐在Ubuntu上部署热词里Ubuntu相关的内容占了很大比例这不是偶然。Wazuh官方对Ubuntu的支持是最好的文档全、社区案例多、踩坑少。我自己的生产环境用的是Ubuntu 22.04 LTS这个版本长期支持到2027年稳定性和软件源都很成熟。选Ubuntu还有几个实际好处一是apt包管理装依赖方便Wazuh官方也提供apt源一条命令就能装二是Ubuntu Server资源占用低2核4G的虚拟机就能跑起单机版Wazuh三是网上关于Ubuntu的教程多遇到网络配置、SSH连接、环境变量这类问题搜一下基本都有答案。如果你手上只有Windows机器可以先装个VMware或者VirtualBox再装Ubuntu虚拟机来练手。虚拟机安装Ubuntu的流程这里不展开重点提醒一句给虚拟机至少分配4GB内存和50GB磁盘Wazuh的Indexer比较吃资源配置太低跑起来会卡。2. 部署前的环境准备与关键决策2.1 硬件与系统参数怎么定在动手之前先把资源算清楚不然装到一半发现内存不够会很尴尬。Wazuh官方给的最低配置和推荐配置差距挺大我整理了一个对照表你可以根据自己的场景选组件最低配置推荐配置说明CPU2核4核以上Indexer对CPU敏感内存4GB8GB以上低于4GB Indexer容易OOM磁盘50GB100GB以上日志存储吃空间系统Ubuntu 20.04Ubuntu 22.04 LTS22.04支持周期更长这里有个坑要提前说Wazuh Indexer底层是Java写的OpenSearch默认堆内存会占用物理内存的一半。如果你给虚拟机分配4GB内存Indexer可能直接吃掉2GB再加上Manager和Dashboard系统会非常紧张。我的建议是测试环境至少8GB内存生产环境按Agent数量往上加。还有一个容易被忽略的点是文件句柄数。Wazuh在高负载下会打开大量文件描述符Ubuntu默认的ulimit可能不够。部署前先改一下# 查看当前限制 ulimit -n # 临时调整 ulimit -n 65535 # 永久生效编辑 /etc/security/limits.conf追加 * soft nofile 65535 * hard nofile 65535改完记得重新登录才生效。这个细节很多教程都不提但实际跑起来Agent一多句柄数不够会导致Manager莫名其妙丢数据。2.2 网络与主机名配置要点Wazuh各组件之间靠网络通信主机名和IP配置错了后面Dashboard连不上Indexer是常见问题。我习惯在部署前先把这几件事做掉第一设置静态IP。Ubuntu Server 22.04用netplan管理网络配置文件在/etc/netplan/下面。编辑对应的yaml文件把dhcp4改成no然后手动指定addresses、gateway4、nameservers。改完执行sudo netplan apply。这一步是为了避免IP变动导致Agent失联。第二配置hosts解析。如果你打算用主机名而不是IP来配置组件就在/etc/hosts里加上映射# /etc/hosts 192.168.1.100 wazuh-server第三确认主机名规范。Wazuh Agent注册时会用主机名做标识如果主机名是localhost或者重复管理起来会很乱。用hostnamectl set-hostname wazuh-server改一下。注意如果你在虚拟机里做实验网络模式建议选桥接而不是NAT这样局域网内其他机器也能访问Dashboard。NAT模式下外部访问需要额外做端口转发比较麻烦。2.3 系统更新与依赖安装正式装Wazuh之前先把系统更新到最新避免依赖冲突sudo apt update sudo apt upgrade -y sudo apt install -y curl apt-transport-https lsb-release gnupg这几个依赖里curl用来下载安装脚本apt-transport-https让apt支持https源gnupg用来导入Wazuh的签名密钥。别小看这几步我遇到过因为缺gnupg导致添加源失败的案例。另外如果你之前装过Docker或者改过系统源建议先确认一下/etc/apt/sources.list没有异常条目。Ubuntu环境变量配置错误、源混乱是新手常见问题装Wazuh前保持系统干净能省很多事。3. 单机版Wazuh的完整安装实操3.1 用官方脚本一键部署Wazuh官方提供了一个安装助手脚本能自动完成Indexer、Server、Dashboard的安装和证书生成。这是最省事的方式适合快速搭建测试环境。整个过程分两步第一步下载并运行安装脚本curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh curl -sO https://packages.wazuh.com/4.7/config.yml第二步编辑config.yml配置各节点的IP和密码。单机版的话把hosts里所有节点都指向同一台机器的IPnodes: indexer: - name: node-1 ip: 192.168.1.100 server: - name: wazuh-server ip: 192.168.1.100 dashboard: - name: wazuh-dashboard ip: 192.168.1.100然后执行安装sudo bash wazuh-install.sh --generate-config-files sudo bash wazuh-install.sh --wazuh-indexer node-1 sudo bash wazuh-install.sh --start-cluster sudo bash wazuh-install.sh --wazuh-server wazuh-server sudo bash wazuh-install.sh --wazuh-dashboard wazuh-dashboard这一串命令跑下来大概需要10到20分钟取决于机器性能和网络。安装完成后脚本会输出Dashboard的访问地址和默认账号密码一定要把密码记下来后面登录要用。提示安装过程中如果卡在Waiting for Wazuh indexer to be ready多半是内存不够导致Indexer启动失败。先free -h看下内存再systemctl status wazuh-indexer看服务状态。3.2 安装后的服务检查清单脚本跑完不代表万事大吉我习惯按下面的清单逐项确认# 检查三个核心服务状态 systemctl status wazuh-indexer systemctl status wazuh-manager systemctl status wazuh-dashboard # 检查端口监听 ss -tlnp | grep -E 9200|55000|443正常情况下Indexer监听9200Manager监听55000和1514/1515Dashboard监听443。如果哪个端口没起来对应的服务肯定有问题。再验证一下集群健康状态curl -k -u admin:你的密码 https://192.168.1.100:9200/_cluster/health?pretty返回的status应该是green或者yellow。yellow在单节点环境下是正常的因为副本分片没法分配如果是red说明有分片损坏得查Indexer日志。3.3 首次登录Dashboard要做的几件事浏览器访问https://192.168.1.100用安装时给的账号登录。第一次进去建议先做三件事第一改默认密码。默认密码是脚本生成的随机串虽然复杂但不好记可以在Dashboard的Security里改或者用wazuh-passwords-tool.sh批量改。第二检查Agent列表。默认情况下Server本机会作为一个Agent注册进来在Agents页面应该能看到一个状态为Active的条目。如果显示Never connected说明Agent和Manager之间的通信有问题重点查1514端口和防火墙。第三看一眼默认规则触发的告警。Wazuh自带了几千条规则装完就会有一些基础告警比如SSH登录失败。在Security events里能看到这些数据说明整条链路是通的。4. Agent部署与日志接入实战4.1 在Linux主机上装AgentServer搭好了接下来就是往被监控的主机上装Agent。Ubuntu上装Agent很简单先添加Wazuh的apt源curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import chmod 644 /usr/share/keyrings/wazuh.gpg echo deb [signed-by/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main | tee /etc/apt/sources.list.d/wazuh.list apt update然后安装Agent并指定Manager地址WAZUH_MANAGER192.168.1.100 apt install wazuh-agent装完启动服务systemctl daemon-reload systemctl enable wazuh-agent systemctl start wazuh-agent回到Dashboard的Agents页面应该能看到新注册的主机。如果没出现先看Agent日志/var/ossec/logs/ossec.log常见原因是Manager地址填错或者防火墙挡了1514端口。4.2 自定义日志采集配置Wazuh默认会采集一批系统日志但实际业务中我们往往需要监控特定的应用日志。配置入口在Agent的/var/ossec/etc/ossec.conf用localfile标签定义localfile log_formatsyslog/log_format location/var/log/nginx/access.log/location /localfile localfile log_formatjson/log_format location/var/log/myapp/app.log/location /localfilelog_format要跟日志实际格式匹配syslog格式的用syslogJSON格式的用json纯文本用command配合脚本解析。改完配置重启Agent生效。这里有个经验别一股脑把所有日志都接进来。日志量太大会拖垮Indexer也会让告警淹没在噪音里。我的做法是先明确要检测什么比如监控Nginx的404和500、监控应用日志里的ERROR关键字然后只接相关的日志文件。4.3 文件完整性监控FIM配置FIM是Wazuh的招牌功能之一能监控指定目录下文件的增删改。配置同样在ossec.conf里syscheck frequency43200/frequency directories check_allyes realtimeyes/etc,/usr/bin,/usr/sbin/directories directories check_allyes realtimeyes/var/www/html/directories ignore/etc/mtab/ignore /syscheckfrequency是扫描间隔秒realtime开启实时监控。check_all会检查文件大小、权限、属主、MD5、SHA1等属性。注意realtime模式依赖inotify监控目录太多会消耗大量文件句柄。生产环境建议只对关键目录开实时监控其他目录用定时扫描。5. 规则编写与告警调优5.1 理解Wazuh的规则结构Wazuh的规则是XML格式核心逻辑是匹配日志 → 触发规则 → 产生告警。一条最简单的规则长这样rule id100001 level10 decoded_asmyapp/decoded_as matchERROR/match description应用日志出现ERROR关键字/description /ruleid是规则编号自定义规则建议从100000开始避免和官方规则冲突。level是告警级别0到15数字越大越严重。decoded_as指定解码器match是匹配内容。规则文件放在Manager的/var/ossec/etc/rules/目录下改完用/var/ossec/bin/wazuh-logtest测试这个工具能模拟日志输入看规则是否命中非常实用。5.2 写一条检测SSH暴力破解的规则SSH暴力破解是最常见的攻击方式Wazuh自带规则能检测单次失败但连续失败需要自定义。我写一条基于频率的规则rule id100100 level12 frequency8 timeframe120 if_matched_sid5710/if_matched_sid same_source_ip / description检测到SSH暴力破解来源IP: $(srcip)/description mitre idT1110/id /mitre /rule这条规则的意思是120秒内同一个源IP触发了8次规则5710SSH登录失败就告警。mitre标签关联MITRE ATTCK框架方便做威胁分析。写完规则后用wazuh-logtest测试/var/ossec/bin/wazuh-logtest # 输入模拟日志 Failed password for root from 192.168.1.200 port 22 ssh2如果规则命中会显示匹配的规则ID和告警级别。测试通过后重启Manager生效。5.3 告警降噪的实用技巧规则写多了告警会爆炸。我总结了几个降噪手段用ignore排除已知无害的日志。比如某些健康检查产生的404直接在规则里忽略。调整level。不是所有异常都值得半夜叫醒你把低风险事件的级别调低。用frequency和timeframe做聚合。单次失败不告警连续多次才告警。配置告警抑制。Wazuh支持在ossec.conf里设置alertslog_alert_level低于这个级别的告警不记录。我自己的经验是新规则上线后先观察一周看告警量是否合理再决定要不要调整阈值。一上来就把级别设得很高结果天天被误报轰炸最后反而没人看告警了。6. 常见问题排查与避坑实录6.1 Agent显示Never connected怎么办这是新手遇到最多的问题。排查顺序如下排查项检查方法常见原因网络连通性ping Manager_IP网络不通端口开放telnet Manager_IP 1514防火墙拦截Manager地址看ossec.conf里address地址填错Agent密钥看/var/ossec/etc/client.keys密钥未注册服务状态systemctl status wazuh-agent服务未启动我遇到过最隐蔽的一次是Manager的1514端口只监听了IPv6Agent用IPv4连不上。解决办法是在Manager的ossec.conf里显式指定local_ip为IPv4地址。6.2 Indexer内存不足导致服务崩溃Wazuh Indexer默认堆内存是物理内存的一半如果机器内存小很容易OOM。调整方法在/etc/wazuh-indexer/jvm.options-Xms2g -Xmx2g把这两个值改成固定大小比如2GB。注意Xms和Xmx要设成一样避免动态调整带来的性能抖动。改完重启Indexer。如果还是频繁崩溃就得考虑加内存或者把Indexer单独部署到另一台机器上。6.3 Dashboard登录后一片空白有时候能登录但页面加载不出来多半是Dashboard和Indexer之间的连接有问题。检查/etc/wazuh-dashboard/opensearch_dashboards.yml里的opensearch.hosts配置确认指向正确的Indexer地址和端口。另外看Dashboard日志/var/log/wazuh-dashboard/里面会有具体的报错信息。还有一种情况是浏览器缓存问题换个无痕窗口试试。这个坑我踩过排查了半天发现是缓存。6.4 规则不生效的排查思路写完规则没反应按这个顺序查规则文件是否放在正确目录权限是否正确属主wazuh权限660规则ID是否和已有规则冲突用wazuh-logtest测试是否命中Manager是否重启日志是否真的被采集到了看/var/ossec/logs/archives/提示wazuh-logtest是排查规则问题的神器一定要熟练使用。它能显示日志经过解码器、规则匹配的完整过程比瞎猜高效得多。7. 从单机到分布式的扩展思路单机版跑通之后如果Agent数量上来了就得考虑分布式部署。基本思路是把Indexer做成集群至少3个节点Manager也可以多节点做负载均衡Dashboard单独部署。这样任何一台机器挂了整个系统还能继续工作。扩展的时候有几个关键点一是证书要重新生成集群节点之间的通信需要证书互信二是配置文件里的节点列表要同步更新三是负载均衡Agent上报的数据要能分发到不同的Manager。我自己的环境是3台Indexer 2台Manager 1台Dashboard支撑了大概200个Agent运行了一年多比较稳定。资源上每台Indexer给了8GB内存Manager给了4GBDashboard给了2GB。对于中小团队来说如果Agent数量在50以内单机版完全够用不用急着上分布式。先把规则和告警调优做好比堆硬件更有价值。最后分享一个我踩过的坑别在Wazuh Server本机上装太多其他服务。我曾经把Server和一台测试用的Web服务放一起结果Web服务被攻击时产生的日志把Wazuh的磁盘写满了导致Indexer无法写入。后来把Wazuh单独隔离到一台机器上问题再没出现过。安全监控平台本身也需要被保护这个道理说起来简单做起来容易忘。