KaucherIslam/SIEM-Log-Engineering-Building-and-Troubleshooting-a-High-Fidelity-Data-Pipeline-in-Wazuh
GitHub: KaucherIslam/SIEM-Log-Engineering-Building-and-Troubleshooting-a-High-Fidelity-Data-Pipeline-in-Wazuh
本项目通过工程化方法在 Wazuh 中构建并修复高保真日志摄取管道，解决配置崩溃与连接失败问题。
Stars: 0 | Forks: 0
SIEM 日志工程：在 Wazuh 中构建和故障排查高保真数据管道
本项目详细介绍了将约 80,000 条真实服务器日志摄取到 Wazuh SIEM 环境中的过程。主要目标是超越教科书级别的安装，创建一个真实的“嘈杂”生产环境，用于 SOC 分析员培训和威胁狩猎。 更重要的是，本报告记录了应用行业标准配置指南时所遇到的重大技术障碍，以及为构建可用解决方案而采用的全面故障排查方法论。
阶段 1：标准的“课程式”摄取
**目标：** 使用 Google 网络安全证书课程提供的 Filebeat 配置启动日志摄取。
我首先部署了一个预定义的 Filebeat 配置文件（ingest.yml），用于监控模拟企业网络中的特定目录，包括 **邮件服务器**、Web 服务器（**www1、www2、www3**）以及 **供应商销售** 数据。此方法旨在向 SIEM 填充高保真遥测数据。
1. 起始配置（“课程”方法）
摄取过程使用课程提供的标准命令和 ingest.yml 初始化，该配置将 Filebeat 设置为向 Logstash 实例发送数据。
2. 摄取失败：初始命令
按照指南执行标准摄取命令后，Wazuh 仪表板中未显示任何数据。虽然初始输出显示“success: 1033”等，但这为假阳性。数据未到达索引器，进程随后完全崩溃，表明指标已生成但连接建立失败。这一错误引导我们深入查看系统日志。
阶段 2：技术障碍与系统故障
此阶段需要将模式从“安装”切换到“工程与故障排查”。在尝试再次运行 Filebeat 时，系统发生灾难性崩溃。
3. SIGABRT 崩溃：“操作不被允许”
标准配置指南触发了致命的 Go 运行时错误（SIGABRT - 系统中止）。这是阻止摄取的主要障碍。
根本原因分析： 崩溃由pthread_create failed: Operation not permitted. 引起。该错误由 Filebeat 的默认安全过滤器（称为 seccomp（安全计算模式））触发。在此特定虚拟化环境中，seccomp 阻止了创建新的系统线程，导致核心转储。
4. Logstash “连接被拒绝”错误
尝试重启服务后，在日志中发现另一个同样关键的后续错误：端口 5044 上持续出现“连接被拒绝”消息。 失败分析： 标准 ingest.yml 配置输出到 Logstash（端口 5044）。经调查系统服务，发现该实验室环境中未安装或未激活所需的 Logstash 实例。SIEM 正在监听端口 9200（Wazuh 索引器/Elasticsearch）。
阶段 3：SIEM 工程：设计修复方案
为继续推进，摄取管道需要重新设计。我被迫放弃“标准”指南，转而设计一个定制化、健壮的解决方案。
5. 验证可用服务
在修改配置之前，我验证了系统的可用网络端口。此步骤确认端口 9200（索引器）为正确目标。
此输出明确显示：logstash.service could not be found，而端口 9200 已在本地主机上监听。
6. 工程解决方案：修正后的 ingest.yml
我对 ingest.yml 配置应用了多步骤工程修复：
- 禁用安全过滤器： 添加
seccomp.enabled: false以绕过内核过滤器并防止 SIGABRT 崩溃。 - 重定向输出： 完全移除 output.logstash 块，并将其替换为通过 output.elasticsearch 直接连接至端口 9200 的索引器。
- 绕过本地主机命名问题： 使用 127.0.0.1 替代 localhost，以绕过导致主机查找失败的潜在内部 DNS 解析问题。
- YAML 缩进修正： 严格的 YAML 语法要求新子设置具有精确的缩进。
最终配置在技术上是合理的，包括 HTTPS 协议、管理员凭据以及必要的安全过滤器旁路。
阶段 4：验证与最终部署
最终阶段需要部署并验证数据流。
7. 清除注册表并重新摄取
为防止重复日志或与之前失败尝试产生的冲突，我强制删除了 Filebeat 注册表文件。这确保了 Filebeat 将从日志源的第一行开始读取。
清除注册表并使用新配置重启 Filebeat 后，指标确认 79,000+ 事件已成功发送并被索引器确认。
8. 最终结果：高保真“嘈杂”SIEM
数据开始流入数据库。然而，默认可视化视图（wazuh-alerts-*）仍为空，因为这些是未触发特定安全规则的原始日志。为查看原始遥测数据，我在仪表板管理控制台中手动为 filebeat-* 创建了一个新的索引模式。
Figure 6: Overview of the Dashboard.
最终输出是一个高保真环境。filebeat-* 索引中的约 80,000 次命中提供了巨大的真实流量数据量，模拟了生产企业网络的“嘈杂”特性。此成功验证了 SIEM 管理所需的日志工程技能，并为高级威胁狩猎练习提供了坚实的基础。
最终反思
本项目与其说是标准的 SIEM 安装，不如说是对真实环境中数据管道的工程与故障排查。主要收获在于解决了内核级安全过滤器崩溃，并修正了失败的“教科书式”摄取流程，以构建高保真实验环境。成功管理约 80,000 个事件证明了我处理高容量遥测数据的能力，并架起了原始数据工程与安全分析之间的桥梁。
感谢您花时间审阅我的项目，并考虑我的工作。