首页/资讯中心/详情

基于Wazuh与Zabbix构建服务器挖矿木马自动化检测与响应体系

基于Wazuh与Zabbix构建服务器挖矿木马自动化检测与响应体系
📅 发布时间：2026/7/3 19:08:30

1. 项目概述：当服务器CPU莫名飙升时

最近在帮朋友处理一个线上服务器的问题，现象很典型：业务量没变，但服务器的CPU使用率在凌晨时段会间歇性飙升到90%以上，风扇狂转，业务响应变慢。登录服务器一看，除了几个正常的业务进程，top命令里还混杂着几个名字看起来“人畜无害”但CPU占用奇高的进程，比如kthreadd、kinsing之类的。经验告诉我，这八成是中了挖矿木马。

挖矿木马现在已经是服务器安全领域的“牛皮癣”了。攻击者通过各种漏洞（比如未修复的框架漏洞、弱口令、配置不当的Redis或Docker）入侵服务器，然后植入挖矿程序，悄无声息地消耗你的计算资源，电费和性能损失都是实实在在的。手动排查费时费力，而且容易有遗漏。今天要复盘的这个实战项目，核心就是如何利用Wazuh（一款开源的主机入侵检测与安全监控系统）和Zabbix（老牌的企业级监控解决方案）构建一个自动化的“挖矿木马狩猎”体系。这不是简单的工具堆砌，而是一套从“异常感知”到“线索关联”，再到“精准定位和清除”的完整作战流程。我会把用到的命令、配置思路和踩过的坑都详细列出来，你完全可以照着部署一套，给你的服务器加上一双“火眼金睛”。

2. 整体防御与检测架构设计

单纯靠某个单一工具很难应对狡猾的挖矿木马。它们会隐藏进程、篡改系统命令、设置定时任务、甚至感染系统文件。我们的思路是构建一个分层、联动的检测体系。

2.1 为什么选择Wazuh + Zabbix组合？

这个组合的核心是“行为监控” + “性能基线”双管齐下。

  • Wazuh (行为监控与入侵检测)：它就像一个7x24小时不眨眼的“安全警卫”，安装在每台需要保护的服务器（Agent端）上。它的核心能力是实时监控系统的“一举一动”：

    • 文件完整性监控：监控/bin，/usr/bin，/etc/cron.*等关键目录，任何文件被创建、修改、删除都会触发告警。挖矿木马要驻留，必然要写文件。
    • 日志集中分析：收集系统日志（auth.log,secure）、命令历史（bash_history）等，分析失败的登录、可疑的sudo提权等。
    • 进程监控与漏洞检测：监控异常进程的启动（如陌生的矿池连接进程），并关联已知的漏洞库进行扫描。
    • 主动响应：检测到恶意行为后，可以自动执行预设命令，如阻断恶意IP、杀死可疑进程、隔离文件等。

  • Zabbix (性能基线分析与异常告警)：它则是经验丰富的“系统健康管理师”，专注于监控服务器的资源指标：

    • 建立性能基线：长期监控CPU、内存、网络流量、进程数等，形成“正常状态”的基线。
    • 发现异常波动：挖矿木马运行时，CPU使用率（尤其是用户态user）、网络连接（与矿池通信）通常会有明显且持续的异常。Zabbix可以设置智能触发器，例如“CPU用户态使用率持续5分钟超过80%”且“该服务器上运行了非业务关键进程”。
    • 提供关联线索：当Zabbix告警CPU异常时，我们可以立刻关联到同一时间点Wazuh的日志，查看是否有文件被修改、是否有新进程启动，从而快速定位根源。

简单说，Zabbix告诉我们“服务器生病了（CPU高）”，而Wazuh帮我们找到“病因和病原体（是哪个木马文件、进程导致的）”。两者数据互补，能极大缩短MTTR（平均修复时间）。

2.2 架构部署拓扑

在实际部署中，我采用了经典的Server-Agent模式，兼顾了安全与效率。

  1. Wazuh Server：单独部署在一台内网服务器上，用于管理所有Agent，集中分析安全事件，并提供Web管理界面。
  2. Zabbix Server：同样单独部署，用于收集性能数据，配置告警策略。
  3. 目标业务服务器：同时安装Wazuh Agent和Zabbix Agent。两个Agent分别向各自的Server上报数据。
  4. 数据关联：通过时间戳和主机名，在Wazuh和Zabbix的Web界面中手动或通过API进行关联查询。更高级的玩法可以将两者的告警接入同一个运维平台（如Grafana或自研平台）进行关联展示。

注意：Wazuh Server和Zabbix Server对资源有一定要求，特别是Wazuh的索引性能受磁盘I/O和内存影响较大。生产环境建议为Wazuh Server分配至少4核CPU、8GB内存和100GB以上的高速存储（如SSD）。

3. Wazuh核心配置与挖矿木马检测规则

Wazuh的强大在于其丰富的检测规则和灵活的配置。针对挖矿木马，我们需要重点配置以下几个模块。

3.1 文件完整性监控配置

这是揪出木马“老巢”的关键。木马为了持久化，会在多个位置藏身。我们需要在Wazuh Agent的配置文件（通常是/var/ossec/etc/ossec.conf）中，添加或检查以下监控目录：

<syscheck> <!-- 监控频率，每12小时进行一次完整性校验 --> <frequency>43200</frequency> <!-- 重点监控目录 --> <directories check_all="yes" realtime="yes">/bin,/usr/bin,/sbin,/usr/sbin</directories> <directories check_all="yes" realtime="yes">/etc</directories> <!-- 监控cron任务，挖矿木马常在此设置定时任务 --> <directories check_all="yes" realtime="yes">/etc/cron.hourly,/etc/cron.daily,/etc/cron.weekly,/etc/cron.monthly,/etc/cron.d</directories> <!-- 监控用户家目录下的隐藏文件和脚本 --> <directories check_all="yes" realtime="yes">/home</directories> <!-- 监控临时目录，木马常在此下载和执行 --> <directories check_all="yes" realtime="yes">/tmp,/var/tmp</directories> <!-- 监控系统服务目录 --> <directories check_all="yes" realtime="yes">/etc/systemd/system</directories> <!-- 忽略一些频繁变化的文件，减少噪音 --> <ignore>/etc/mtab</ignore> <ignore>/etc/hosts.deny</ignore> <!-- 可以根据实际情况添加更多忽略项 --> </syscheck>

配置解析：

  • realtime="yes"表示实时监控，文件一有变化就立即上报，这对安全响应至关重要。
  • check_all="yes"表示检查文件的属性、权限、所有者、内容MD5等所有完整性属性。
  • 监控/home目录时要小心，在开发服务器上可能噪音较大，可以先从监控特定用户目录开始。

3.2 进程与网络连接监控

挖矿进程一定会发起网络连接（连接矿池）。Wazuh的rootcheck模块和active-response组件可以配合工作。更直接的是利用系统命令进行主动扫描，并通过Wazuh的command模块定期执行。我们可以在Agent端编写一个自定义脚本，由Wazuh调度执行。

在Agent的ossec.conf中添加：

<localfile> <log_format>command</log_format> <command>sh /var/ossec/scripts/check_mining.sh</command> <frequency>300</frequency> <!-- 每5分钟执行一次 --> </localfile>

脚本/var/ossec/scripts/check_mining.sh内容示例：

#!/bin/bash # 检查异常网络连接（常见矿池端口） netstat -tunap 2>/dev/null | grep -E ':(3333|4444|5555|6666|7777|8888|9000|14433|14444|45700)\s' | while read line; do echo "wazuh-mining-check: Suspicious mining pool connection detected: $line" done # 检查异常进程名（已知的挖矿木马进程名） ps aux | grep -E '[kK]threadd|[kK]insing|[xX]mrig|[cC]rypto|[mM]iner|[sS]ystemd-udevd' | grep -v grep | while read line; do echo "wazuh-mining-check: Suspicious process name detected: $line" done # 检查异常CPU占用的进程（启发式检查） ps aux --sort=-%cpu | head -10 | awk '{if($3>50.0 && $11 !~ /^\[/ && $11 !~ /(java|mysql|nginx|php-fpm)/) print "wazuh-mining-check: High CPU process:", $0}'

这个脚本的输出会被Wazuh Agent捕获并发送到Server，Server端有对应的规则（需自定义或启用现有规则库）来解析这些日志并产生告警。

3.3 自定义规则与告警升级

Wazuh自带了一个庞大的规则库，其中已经包含了许多针对恶意软件和异常行为的规则（如malware，syscall规则组）。但为了更精准，我们可以自定义规则。

在Wazuh Server的规则目录（如/var/ossec/etc/rules/local_rules.xml）中添加：

<group name="local,mining,"> <!-- 规则1：检测到挖矿脚本中的特征字符串 --> <rule id="100100" level="12"> <if_sid>554</if_sid> <!-- 父规则是文件完整性告警 --> <match>cryptonight|stratum+tcp|minexmr|nanopool</match> <!-- 矿池或算法关键词 --> <description>File modified containing possible cryptocurrency mining related keywords.</description> </rule> <!-- 规则2：检测自定义脚本发现的异常连接 --> <rule id="100101" level="10"> <decoded_as>wazuh-mining-check</decoded_as> <match>Suspicious mining pool connection detected</match> <description>Suspicious network connection to known mining pool port detected by active scan.</description> </rule> <!-- 规则3：检测到异常高CPU进程 --> <rule id="100102" level="8"> <decoded_as>wazuh-mining-check</decoded_as> <match>High CPU process</match> <description>Non-system, non-business process consuming excessive CPU detected.</description> </rule> </group>

规则解析：

  • level表示告警级别，数字越高越严重。我们可以根据级别设置不同的告警动作（如邮件、钉钉、短信）。
  • <if_sid>用于关联父规则，实现告警的上下文关联。
  • 自定义规则需要和日志格式匹配，<decoded_as>对应脚本输出中我们自定义的标签。

4. Zabbix监控项与触发器配置策略

Zabbix的角色是发现“异常状态”。针对挖矿木马，我们配置以下几类关键的监控项和触发器。

4.1 核心性能监控项

  1. CPU使用率（细分）：

    • system.cpu.util[,user]：用户态CPU使用率。挖矿程序几乎完全运行在用户态，此指标异常敏感。
    • system.cpu.util[,system]：内核态CPU使用率。作为对比参考。
    • system.cpu.util[,iowait]：I/O等待。挖矿通常计算密集，iowait应较低，如果两者都高，可能是其他问题。
    • 配置建议：采集间隔设为1分钟，历史数据保留30天，趋势数据保留365天。

  2. 进程监控：

    • proc.num[,,,]：监控特定进程的数量。例如，我们可以监控kinsing、kthreadd等已知恶意进程名，只要数量大于0就告警。
    • proc.cpu.util[<process_name>]：监控特定进程的CPU使用率。这需要先知道进程名，更适合事后追踪或监控已知可疑进程。

  3. 网络连接监控：

    • net.tcp.port[<ip>,<port>]：检查服务器是否主动连接了已知的矿池IP和端口。这需要维护一个矿池IP/端口黑名单。
    • net.tcp.listen[<port>]：监控服务器是否在非业务端口上开启了监听，挖矿木马有时会开启后门端口。
    • 更佳实践：使用net.tcp.socket.count[<state>]监控ESTABLISHED状态的连接数总量，结合system.cpu.util[,user]设置联合触发器，比如“用户态CPU超过80%且TCP连接数比基线增长50%”。

4.2 智能触发器设置

触发器的逻辑是检测逻辑的核心。避免单指标误报，采用多条件关联。

  • 触发器1：持续高用户态CPU

    名称：High user CPU usage on {HOST.NAME} 表达式：{Template OS Linux:system.cpu.util[,user].avg(5m)} > 80 事件严重性：警告 描述：过去5分钟平均用户态CPU使用率持续超过80%，可能存在异常计算负载。
    • avg(5m)使用了5分钟的平均值，避免瞬间峰值导致的误报。

  • 触发器2：检测到已知恶意进程

    名称：Known mining process detected on {HOST.NAME} 表达式：{Template OS Linux:proc.num[,,,kinsing].last()} > 0 事件严重性：灾难 描述：检测到已知挖矿进程“kinsing”在运行。
    • 这是非常确凿的证据，直接设为最高级别。

  • 触发器3：CPU高负载伴随异常网络连接

    名称：High CPU with suspicious connections on {HOST.NAME} 表达式：{Template OS Linux:system.cpu.util[,user].avg(5m)} > 70 and {Template OS Linux:net.tcp.socket.count[ESTABLISHED].avg(5m)} > {Template OS Linux:net.tcp.socket.count[ESTABLISHED].avg(1h)} * 1.5 事件严重性：严重 描述：用户态CPU高，且当前TCP连接数比过去1小时的平均值高出50%，疑似挖矿木马活动。
    • 这个触发器结合了绝对值（CPU>70）和相对变化（连接数激增），误报率较低，非常有效。

4.3 主动监控与自动发现

对于进程和网络连接，我们可能不知道所有恶意特征。Zabbix的“自动发现”功能可以帮我们“发现异常”。

  • 进程自动发现：配置一个自动发现规则，定期获取所有进程列表。然后，我们可以创建一个“监控项原型”，监控每个进程的CPU和内存。再创建一个“触发器原型”，当任何一个非系统、非白名单进程的CPU使用率持续超过30%时，就触发告警。这能抓住那些我们不知道名字的新变种木马。
  • 网络连接自动发现：类似地，可以自动发现所有ESTABLISHED状态的远程连接（netstat -tun），并监控每个远程IP的连接数或流量。当出现一个陌生的、连接数很高的IP时，可以触发告警。

实操心得：Zabbix的自动发现功能非常强大，但也会产生海量的监控项。务必设置好过滤条件（比如过滤掉localhost、已知的内网IP、[kernel]进程等），并合理规划数据存储周期，否则容易把Zabbix Server自己拖垮。

5. 实战排查流程与完整命令手册

当告警响起（无论是Zabbix的CPU告警还是Wazuh的安全事件告警），我们需要一套标准化的排查流程。以下命令按排查顺序排列，可以直接复制使用。

5.1 第一步：快速定位异常进程与资源占用

登录到告警服务器，首先进行快速诊断。

# 1. 综合查看系统资源占用 top/htop top -c -o %CPU # 按CPU使用率降序排列，显示完整命令 # 或使用更直观的 htop（需安装） htop # 2. 查看可疑进程的详细信息 # 假设top中看到可疑进程PID为 12345 ps -ef | grep 12345 # 查看进程全路径和父进程 ls -la /proc/12345/exe # 查看进程实际执行的文件路径（木马常会伪装） cat /proc/12345/environ | tr '\0' '\n' # 查看进程的环境变量，可能包含矿池地址 # 3. 查看网络连接，定位与矿池的通信 netstat -tunap | grep ESTABLISHED | grep <可疑PID或进程名> # 或者用更强大的 ss 命令 ss -tunp | grep <可疑PID或进程名> # 查看连接到特定矿池端口（如14444）的连接 lsof -i:14444 # 4. 检查系统负载和CPU细分，确认是用户态CPU高 uptime mpstat -P ALL 2 5 # 每2秒采样一次，共5次，查看每个CPU核心的详细状态

5.2 第二步：深入分析进程与文件

找到可疑进程后，需要深挖其关联的文件和活动。

# 1. 查看进程打开的文件 lsof -p <可疑PID> # 重点关注：当前工作目录（cwd）、打开的可执行文件（txt）、网络连接（IPv4/IPv6） # 2. 查看进程的内存映射，可能发现注入的恶意so库 pmap -x <可疑PID> cat /proc/<可疑PID>/maps | grep -v '\.so' | head -20 # 过滤掉常见系统库，看异常映射 # 3. 检查进程的父进程及其兄弟进程，挖矿木马可能有守护进程 pstree -aps <可疑PID> # 4. 检查可疑文件 file /proc/<可疑PID>/exe # 查看文件类型 strings /proc/<可疑PID>/exe | grep -i -E 'stratum|pool|mine|wallet' # 从二进制文件中提取字符串，搜索矿池特征 md5sum /proc/<可疑PID>/exe # 计算哈希值，可用于威胁情报查询

5.3 第三步：检查持久化与隐藏手段

挖矿木马为了存活，会使用各种持久化机制。

# 1. 检查定时任务（cron） crontab -l # 查看当前用户的cron ls -la /etc/cron* # 查看系统cron目录 cat /etc/crontab # 特别注意 /etc/cron.d/, /etc/cron.hourly/ 等目录下的非系统文件 # 2. 检查系统服务（systemd） systemctl list-unit-files --type=service | grep enabled systemctl status <可疑服务名> # 如果发现可疑服务 ls -la /etc/systemd/system/ # 检查自定义服务单元文件 # 3. 检查开机启动项（rc.local, init.d） cat /etc/rc.local # 如果该文件存在且可执行 ls -la /etc/init.d/ | grep -v 'README' # 4. 检查用户启动脚本 ls -la ~/.bashrc ~/.bash_profile ~/.profile ls -la /etc/profile.d/ # 全局profile脚本 # 5. 检查最近被修改的系统命令（木马可能替换了ps, top, netstat等） rpm -Va 2>/dev/null | grep -E '^..5' # 对于RPM系，检查MD5变化的文件 debsums -c 2>/dev/null # 对于Debian/Ubuntu系 # 一个快速检查：比较常用命令的大小和日期 ls -lh /bin/ps /usr/bin/top /bin/netstat /usr/bin/lsof

5.4 第四步：清理与加固

确认恶意文件和行为后，开始清理。务必先取证再清理，可以备份恶意文件样本。

# 1. 停止并杀死恶意进程 kill -9 <可疑PID> # 强制杀死 # 如果进程有守护，可能需要杀死整个进程组 kill -9 -<进程组ID> # 2. 删除恶意文件 # 根据 lsof 和 pmap 找到的路径，彻底删除 rm -f /tmp/.kinsing /etc/.kinsing.sh # 示例路径 # 删除隐藏属性文件 chattr -i -a <恶意文件路径> 2>/dev/null # 先解除可能的锁定属性 rm -f <恶意文件路径> # 3. 清理持久化项 # 从cron、systemd、启动脚本中删除恶意条目 crontab -e # 手动编辑删除 systemctl disable <恶意服务名> rm -f /etc/systemd/system/<恶意服务名>.service # 清理 rc.local, .bashrc 等文件中的恶意命令 # 4. 检查并清理其他可能位置 find / -name "*kinsing*" -o -name "*kthreadd*" -o -name "*xmrig*" 2>/dev/null # 按名称查找 find / -type f -perm /111 -newermt '2024-01-01' 2>/dev/null | head -50 # 查找近期新增的可执行文件 find /tmp /var/tmp -type f -executable -newermt '3 days ago' 2>/dev/null # 查找临时目录下的新可执行文件 # 5. 重启服务器并再次检查（可选但建议） reboot # 重启后，立即用 top, netstat, crontab -l 等命令复查。

6. 告警联动与自动化响应设想

Wazuh和Zabbix的联动可以不止于人工查看。我们可以通过它们的API或脚本实现初步的自动化响应。

  • 场景1：Wazuh主动响应。当Wazuh规则检测到确切的恶意文件创建或进程执行时，可以触发“主动响应”脚本，自动杀死进程、隔离文件、并封锁恶意IP。

    • 在Wazuh Server的ossec.conf中配置active-response命令。
    • 编写一个脚本，接收告警参数（如恶意文件路径、攻击者IP），执行清理和防火墙封锁（iptables或firewalld）。

  • 场景2：Zabbix触发器调用Webhook。当Zabbix触发“高CPU且异常连接”的告警时，可以配置一个Webhook媒介，调用一个自定义的API接口。这个接口可以：

    1. 通过Zabbix API获取告警主机的详细信息。
    2. 通过SaltStack、Ansible或SSH远程执行上述的“快速定位命令”（如top,netstat），将结果回传。
    3. 或者，更简单地，发送一条包含主机IP和告警信息的消息到运维群，提示人工介入。

  • 场景3：集成到统一告警平台。将Wazuh和Zabbix的告警都推送至同一个平台（如Prometheus Alertmanager + Grafana，或钉钉/企业微信机器人）。在告警信息中，同时包含Zabbix的性能图表链接和Wazuh的安全事件详情链接，方便运维人员一站式分析。

注意事项：自动化响应是一把双刃剑。误报可能导致合法进程被误杀，造成业务中断。因此，初期建议只对确凿无疑的高危事件（如检测到已知恶意进程哈希值）进行自动化响应，对于可疑行为告警，仍以人工研判为主。所有自动化操作必须有详细的日志记录和回滚机制。

7. 常见问题与排查技巧实录

在实际部署和排查过程中，会遇到各种问题。这里记录几个典型的坑和解决技巧。

7.1 Wazuh Agent与Server通信失败

  • 现象：Agent状态显示为“未连接”或“断开”。
  • 排查：
    1. 检查网络：在Agent端执行telnet <Wazuh_Server_IP> 1514，检查1514（TCP，用于注册和通信）端口是否通畅。
    2. 检查防火墙：确保Server和Agent的防火墙放行了相关端口（1514/TCP, 1515/TCP, 1516/TCP用于集群）。
    3. 检查Agent配置：确认Agent的/var/ossec/etc/ossec.conf中<address>指向正确的Server IP或域名。
    4. 查看日志：Agent端日志/var/ossec/logs/ossec.log和Server端日志/var/ossec/logs/ossec.log通常会有详细的错误信息，如SSL证书问题、密钥不匹配等。

7.2 Wazuh监控产生大量“噪音”告警

  • 现象：文件完整性监控频繁告警/etc目录下的一些文件变化，如/etc/resolv.conf。
  • 解决：
    1. 合理使用<ignore>：在syscheck配置中，将频繁变化的非关键文件加入忽略列表。
    2. 调整监控粒度：对于某些目录，可以只监控文件属性变化而不监控内容变化（check_sum="no"）。
    3. 使用规则排除：在Wazuh Manager端，可以编写规则忽略来自特定文件或目录的某些类型告警。

7.3 Zabbix监控的进程CPU数据不准或为0

  • 现象：使用proc.cpu.util监控某个进程，但数据一直是0，即使top里看到该进程CPU很高。
  • 原因与解决：proc.cpu.util监控的是进程在一个采样周期内的CPU使用率。如果进程是短期爆发型（瞬间占用高CPU然后睡眠），Zabbix可能抓取不到。
    • 方法1：改用system.cpu.util[,user]结合proc.num进行间接判断。
    • 方法2：缩短Zabbix Agent的采集间隔（如从1分钟改为30秒），但这会增加Server负载。
    • 方法3：编写自定义UserParameter脚本，使用ps -p <PID> -o %cpu等命令更灵活地采集。

7.4 挖矿木马清除后反复复发

  • 现象：清理后不久，CPU又高了，同样的恶意进程再次出现。
  • 根本原因：没有清除干净的持久化入口或存在漏洞。
  • 深度排查：
    1. 检查所有入口：再次彻底检查cron、systemd服务、启动脚本、用户配置文件（.bashrc,.profile）、甚至/etc/ld.so.preload（用于预加载动态库）。
    2. 检查漏洞：使用lastb查看失败登录记录，检查是否有弱口令。使用netstat -tunlp查看是否有不必要的端口对外开放（如Redis, Docker API）。使用漏洞扫描工具（如lynis, OpenVAS）对服务器进行扫描。
    3. 检查供应链：是否使用了来源不可信的软件包、镜像或代码？检查最近部署的应用。
    4. 考虑内核级rootkit：如果以上都排除了，可以使用rkhunter,chkrootkit等工具扫描rootkit，或者对比lsmod输出的内核模块与正常系统快照。

7.5 性能开销考量

  • Wazuh Agent：实时文件监控（realtime）和频繁的日志收集会带来一定的I/O和CPU开销。在I/O密集型服务器上需谨慎评估。通常对于现代服务器，开销在1%-5%之间，可以接受。
  • Zabbix Agent：常规监控项开销极低。但如果配置了过多的主动式自动发现（如监控所有进程），在进程数很多的服务器上可能会造成短暂的负载峰值。
  • 建议：先在测试环境或非核心业务服务器上部署和调优，观察资源消耗，再推广到生产环境。对于关键生产服务器，可以考虑错峰执行一些重型检查（如全盘文件完整性扫描）。

这套组合拳打下来，基本能覆盖绝大多数“野路子”的挖矿木马。其精髓不在于某个命令有多厉害，而在于建立了一套从指标异常到行为分析的闭环。Zabbix帮你快速发现“不对劲”，Wazuh帮你深入分析“哪里不对劲”和“谁干的”，最后用手动或自动化的命令进行清理。安全运维没有一劳永逸，保持组件的规则库更新（如Wazuh的病毒特征库），定期审查监控和告警策略，才能让这套体系持续生效。