我的首次 SIEM 部署：日志、经验与些许混乱

Others 2026-07-30 17:34:33 7

如果你想知道第一次搭建 SIEM（安全信息和事件管理）是什么体验，我告诉你：那是兴奋、困惑、成就感混合在一起，时不时还会冒出"这端口怎么又关了"的抓狂时刻。这周，我终于在 CloudShare 实验室环境里部署了一套 SIEM——来聊聊这段经历。

剧透：没有爆炸。但有几样东西确实"着火"了——比喻意义上的。

搭建舞台：我的 CloudShare 实验环境与配置

我一直在用 CloudShare 作为自己的网络安全沙盒——一个可控的多 VM（虚拟机）拓扑，包含一台 Windows Server 靶机、一台 Ubuntu Linux 工作站，还有我们的 SIEM 集群。在部署 SIEM 并摄入遥测数据之前，我做了一些针对性的环境配置，确保日志能正常生成和转发：

Windows Server 审计策略与 Sysmon 部署

高级审计策略：通过组策略在 Windows 靶机上启用了详细审计（gpedit.msc -> 计算机配置 -> Windows 设置 -> 安全设置 -> 高级审计策略配置）。具体开启了审计登录（成功/失败）和审计进程创建。

Sysmon 安装：安装了系统监控工具（Sysmon v14），配置了自定义规则文件（sysmonconfig-export.xml），用于记录进程创建、网络连接和 PowerShell 活动，写入 Microsoft-Windows-Sysmon/Operational 日志。

命令行日志记录：通过管理模板启用了"在进程创建事件中包含命令行"（系统 -> 审计进程创建），以捕获完整的执行字符串。

Linux Syslog 转发（rsyslog）

为了将 Linux 系统和认证事件通过 UDP 514 端口转发到 SIEM：

修改了 Ubuntu VM 上的 /etc/rsyslog.conf，添加远程日志指令：
. @192.168.1.50:514（使用标准 RFC 3164 syslog 格式）。

重启 rsyslog 服务：sudo systemctl restart rsyslog。

网络与防火墙调整

Windows Defender 防火墙：添加了入站规则，允许 UDP 514 端口（Syslog）和 TCP 5985/5986 端口（WinRM，用于事件收集）。

CloudShare 网络规则：调整了内部安全组，允许 514 端口（Syslog）和 1514/1515 端口（代理与管理端通信）通信。

🛠️ 部署 SIEM：关键时刻

这次我选了一个轻量级、开源友好的 SIEM 套件。部署流程包括：

启动 SIEM 管理节点 VM：在 CloudShare 上部署托管 SIEM 套件的实例，并更新系统仓库。

代理安装与配对：在 Windows 和 Linux 端点安装代理软件，通过 TCP 1514 端口安全连接到管理节点 IP。

日志源配置：配置管理节点解析传入的 Windows 事件日志（安全、系统、应用程序和 Sysmon），以及 Linux 的 /var/log/auth.log 和 /var/log/syslog。

验证：通过 SIEM 仪表盘验证日志摄入，确认事件实时填充。

🔬 运行实验：也就是"看看什么会挂"

一切连接就绪后，我执行了针对性模拟，观察 SIEM 如何解析、关联和告警原始遥测数据。

🧪 实验一：RDP 暴力破解模拟

使用的命令/工具：从攻击者主机执行 Hydra，对 Windows Server 发起自动化字典攻击：
hydra -l Administrator -P /usr/share/wordlists/rockyou.txt rdp://192.168.1.10

生成的日志与告警：

Windows 安全日志中反复触发事件 ID 4625（账户登录失败）。

捕获的关键日志字段：TargetUserName: Administrator, WorkstationName, IpAddress: 192.168.1.100。

SIEM 将多次阈值违规关联为高危告警：检测到多次 RDP 登录失败（疑似暴力破解）。

经验总结：基于阈值的告警至关重要。单次登录失败随时可能发生（手滑打错字！），但追踪事件速率（60 秒内超过 10 次失败）有助于从噪音中过滤出真正的攻击。

🧪 实验二：可疑 PowerShell 执行

使用的命令：在 Windows 靶机上运行编码的 PowerShell 载荷，模拟混淆的恶意执行：
powershell.exe -e aT33eCAtRW5jb2RlZENvbW1hbmQ...（base64 编码字符串）

生成的日志与告警：

Sysmon 事件 ID 1（进程创建）记录了父进程（cmd.exe）、子进程（powershell.exe）和完整命令行参数。

Windows 事件 ID 4104（脚本块日志记录）捕获了解码后的执行块。

SIEM 生成了中高危告警：检测到混淆的 PowerShell 执行。

经验总结：标准进程日志不够用；命令行参数和 Sysmon 事件 ID 1 对于识别攻击者的混淆技术和"living-off-the-land"二进制文件（LOLBins）至关重要。

🧪 实验三：Linux 未授权 SSH 访问尝试

使用的命令：尝试对 Linux VM 进行无效 SSH 登录，同时监控本地认证日志：
ssh invalid_user@192.168.1.20

生成的日志与告警：

直接在 /var/log/auth.log 中捕获：
Failed password for invalid user invalid_user from 192.168.1.100 port 54321 ssh2

通过 rsyslog 以 UDP 514 转发到 SIEM，映射到规则 ID 5710（尝试使用不存在的用户登录）。

经验总结：Syslog 解析规则严重依赖正则表达式。统一 Linux 和 Windows 主机的时区时间戳（使用 UTC）对正确的事件关联至关重要。

📊 除了"检查端口"之外学到的

首次部署 SIEM 让我明白了几件重要的事：

日志源决定一切。没有结构化、详细的日志，SIEM 就像没有线索的侦探。启用 Sysmon 和高级审计策略让一切变得不同。

规范化很重要。Windows 事件 ID 和 Linux Syslog 使用完全不同的模式格式；SIEM 充当中央翻译器，使跨平台关联成为可能。

噪音是真实存在的。即使是只有 3 个节点的小型实验室，每小时也会产生数千个事件。微调基线规则是防止告警疲劳的必要工作。

实验是最好的老师。在受控环境中生成真实攻击，让你直接了解事件响应时 SOC 分析师在屏幕上看到的是什么。

🚀 最终感想：还会再来吗？必须的。

搭建起我的第一个 SIEM，就像在网络安全成长路上升了一级。并不完美，确实犯了不少语法和端口配置的错，但这就是实验室环境的魅力所在——它是一个安全的学习场所，可以搞砸东西、建立信心。

下一步：调优检测规则、编写自定义规则、抑制误报。但现在，我正在欣赏实时日志在仪表盘上刷过的感觉！

📚 参考资料

Microsoft Learn：高级安全审计策略设置

Microsoft Sysinternals：Sysmon v14.1 文档与下载

RSYSLOG 文档：Rsyslog 配置参考

MITRE ATT&CK：技术 T1110：暴力破解

TripleTen 网络安全课程：第 11 阶段 SIEM 部署实验指导