Sysmon（System Monitor）原本是Windows平台上广受欢迎的轻量级监控工具，由微软Sysinternals团队维护，被大量企业用于安全审计和威胁狩猎。2021年微软基于eBPF技术发布了Sysmon for Linux，让这套强大的事件记录能力跨到了Linux平台。它能够记录进程创建、进程终止、网络连接、文件变更等系统事件，输出结构化日志，配合日志分析平台可以快速还原攻击链路。本文将完整介绍它的原理、安装、配置以及与其他方案的对比。
一、Sysmon for Linux的底层原理：eBPF如何实现内核级监控
Sysmon for Linux并不是简单地把Windows版本移植过来，而是基于Linux内核的eBPF（extended Berkeley Packet Filter）技术重新实现的。eBPF允许在内核态安全地运行沙箱化程序，通过挂载kprobe、tracepoint等钩子，实时捕获内核函数调用和系统事件，再把数据传递到用户态的Sysmon服务进程进行处理。
具体来说，Sysmon for Linux会在内核中挂载多个探针，当目标事件发生时，探针程序被触发，收集进程PID、父进程、可执行文件路径、命令行参数等信息，通过perf事件缓冲区传递给用户态守护进程。守护进程根据配置文件中的规则进行过滤和标记，最终将事件写入标准日志接口，可通过journalctl或syslog工具查看。
这套架构的优势非常明显：第一，监控发生在内核层，即使用户态程序被篡改或绕过，事件依然会被记录；第二，eBPF程序经过验证器检查，不会像内核模块那样存在崩溃内核的风险；第三，事件以结构化格式输出，字段固定且语义清晰，非常适合后续做日志分析。不过它也有限制，比如要求内核版本较新（一般建议4.15以上，5.x更佳），并且需要root权限运行。
二、安装步骤详解：从依赖准备到服务启动
Sysmon for Linux的源码托管在GitHub的Sysinternals仓库中，目前官方主要提供源码编译安装方式，同时微软也发布了适用于主流发行版的软件包仓库。下面分别以Ubuntu和CentOS为例演示完整流程。
在Ubuntu系统上，首先安装编译依赖和抓包库：
# 安装编译与运行依赖
sudo apt-get update
sudo apt-get install -y build-essential gdb pkg-config \
cmake libelf-dev zlib1g-dev liblzma-dev libtracecmd-dev \
libjson-c-dev libzstd-dev libmagic-dev
# 克隆并编译 Sysmon
git clone https://github.com/Sysinternals/SysmonForLinux.git
cd SysmonForLinux
mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install
CentOS或RHEL系的发行版流程类似，但包管理器不同，依赖名称也有差异，可以使用dnf安装gcc、elfutils-libelf-devel等对应的RPM包。也可以直接使用微软提供的软件源安装预编译包：
# 添加微软仓库并安装（以 Ubuntu 20.04 为例） wget -qO- https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add - sudo add-apt-repository "$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/prod.list)" sudo apt-get update sudo apt-get install sysmonforlinux
安装完成后，Sysmon会注册为systemd服务，使用systemctl status sysmon查看运行状态。如果服务没有自动启动，手动执行启动命令即可。安装包会自带一份默认配置文件，位于/opt/sysmon/config.xml，可以用它快速验证功能：
# 使用默认配置启动 sysmon sudo sysmon -u /opt/sysmon/config.xml sudo systemctl enable --now sysmon # 查看采集到的事件日志 sudo journalctl -f -t sysmon
如果一切正常，执行几个命令后就能在日志中看到带EventID字段的结构化事件，字段含义与Windows版本基本保持一致，熟悉Windows Sysmon的工程师几乎可以无缝上手。
三、配置文件编写：用规则过滤高价值事件
Sysmon的配置采用XML格式，整体结构与Windows版本兼容，但Linux版本支持的事件类型相对少一些，目前主要包括进程创建（Event ID 1）、进程终止（Event ID 5）、网络连接（Event ID 3）、文件修改等。合理编写过滤规则是发挥其威力的关键，否则日志量会非常庞大。
下面是一份实用配置示例，记录所有进程创建事件，并对网络连接事件进行条件过滤：
<Sysmon schemaversion="4.90">
<EventFiltering>
<!-- 记录所有进程创建 -->
<ProcessCreate onmatch="exclude">
<!-- 排除噪音进程，比如内核线程 -->
<Image condition="is">/usr/lib/systemd/systemd</Image>
</ProcessCreate>
<!-- 记录监听端口的网络连接 -->
<NetworkConnect onmatch="include">
<DestinationPort condition="is">22</DestinationPort>
<DestinationPort condition="is">3389</DestinationPort>
</NetworkConnect>
<!-- 记录敏感目录的文件修改 -->
<FileCreate onmatch="include">
<TargetFilename condition="begin with">/etc/</TargetFilename>
</FileCreate>
</EventFiltering>
</Sysmon>
配置中onmatch属性决定匹配模式的含义：include表示只记录匹配的规则，exclude表示排除匹配项。condition支持is、contains、begin with、end with等多种条件，可以组合使用。修改配置后需要重新加载：执行sudo sysmon -c 配置文件路径即可热更新，无需重启服务。
编写规则时有几个实践建议：一是先在测试机上跑一段时间观察日志量，再逐步收紧规则；二是进程创建事件价值最高，建议全量保留，其他的按需过滤；三是把高危路径（如/tmp、/dev/shm下执行文件）单独加规则打标签，便于告警系统直接消费。
四、与auditd、Falco的对比及选型建议
Linux下的审计工具不止Sysmon一家，传统的auditd和云原生领域流行的Falco都是常见选择，三者的定位有明显差异。
| 工具 | 技术基础 | 日志格式 | 规则生态 | 适用场景 |
|---|---|---|---|---|
| Sysmon for Linux | eBPF | 结构化XML事件 | 兼容Windows Sysmon规则 | 混合环境统一监控 |
| auditd | 内核audit子系统 | 文本日志，需解析 | 系统自带，规则手动维护 | 合规审计、传统运维 |
| Falco | eBPF或内核模块 | JSON事件流 | 规则库丰富，支持自定义宏 | 容器与K8s安全 |
auditd是内核自带的审计框架，稳定成熟，但日志可读性差，规则编写门槛高，且在高并发场景下性能损耗相对明显。Falco基于eBPF，内置大量威胁检测规则，特别适合容器环境，但它偏重实时告警而不是完整事件留存。Sysmon for Linux的最大价值在于与Windows版本的统一：如果企业同时管理Windows和Linux服务器，用一套Sysmon规则和一套日志分析逻辑覆盖两个平台，运维成本显著降低。
生产环境部署时还有几点需要注意：eBPF探针依赖内核符号，内核大版本升级后要验证探针是否仍能正常加载；日志建议转发到集中式平台（如Elastic Stack、Microsoft Sentinel）长期存储，本地只保留短期日志；同时开启日志完整性保护，防止攻击者篡改痕迹。综合来看，Sysmon for Linux为Linux主机监控提供了一个兼顾精细度和易用性的新选择，值得在安全建设体系中认真评估。
Sysmon for Linux系统监控Linux安全审计修改时间：2026-09-06 08:54:35