Devonstrate/elastic-siem-dual-telemetry-lab
GitHub: Devonstrate/elastic-siem-dual-telemetry-lab
该项目是一个将 Linux 主机审计与网络入侵检测双重遥测源集成到 Elastic Cloud SIEM 的端到端安全实验环境，涵盖从环境搭建、遥测采集到自定义 KQL 检测规则配置与告警触发的完整流程。
Stars: 0 | Forks: 0
# 双重遥测威胁检测流水线与 Elastic SIEM 实验环境
## 执行摘要
本项目记录了安全遥测流水线的端到端构建过程，该流水线将主机级别的进程审计和网络入侵检测集成到了 Elastic Cloud SIEM 中。通过使用 Elastic Agent、用于 Linux 的 Sysmon、系统身份验证日志（`auth.log`）和 Suricata NIDS 监控的 Ubuntu 虚拟机，利用 Nmap 和 Hydra 模拟了威胁活动，从而验证了实时数据摄取、ECS 解析和自动化阈值检测告警——从最初的环境设置一直到确认并触发高危告警。
该构建过程并非一帆风顺，记录这些问题是故意的：在这个过程中，必须诊断并解决包锁定冲突、缺失的 CD-ROM 挂载、从 Snort 到 Suricata 的方案切换、接口绑定配置错误以及 Kibana 数据视图不匹配等问题。以下如实记录了其中的每一个问题，而不是将其删减掉。
## 技术架构与遥测源
* **端点 / 主机：** Ubuntu Linux 虚拟机
* **SIEM / 管理：** Elastic Cloud（Kibana，部署版本 9.4.4，GCP us-central1）
* **日志传输器：** Elastic Agent（由 Fleet 管理）
* **主机遥测：** 用于 Linux 的 Sysmon（进程创建、网络连接、文件创建）和 `/var/log/auth.log`
* **网络遥测：** Suricata NIDS（`suricata.eve` JSON 日志）
| 遥测类型 | 来源 / 模块 | 描述 | ECS / 字段映射 |
| :--- | :--- | :--- | :--- |
| **主机身份验证** | `system.auth` | SSH 身份验证和 PAM 会话日志 | `event.action: ssh_login` |
| **主机进程** | 用于 Linux 的 Sysmon | 进程执行、网络连接、文件创建 | `process.executable` |
| **网络流量** | `suricata.eve` | Suricata 特征码、流数据、协议告警 | `data_stream.dataset: suricata-eve` |
## 阶段 0：环境设置与故障排除
在遥测数据能够流转之前，基础的 Ubuntu VM 需要进行一些修复：
* **APT dpkg 锁定冲突** — 最初安装包时失败，提示 `Could not get lock /var/lib/dpkg/lock-frontend`。通过清除陈旧的锁定文件并重试 `apt-get update` 解决了该问题。
* **DKMS 依赖安装** — 安装 DKMS 时出现了 VirtualBox Guest Additions CD-ROM 挂载失败（`no medium found on /dev/sr0`）。通过 `dmesg` 进行诊断，并在挂载前于 VirtualBox 中重新挂载 Guest Additions ISO 后得以解决。
* **Elastic Agent 注册语法错误** — 第一次尝试使用占位符值（``、``）进行安装时失败，并出现 bash 语法错误，因为这些值尚未被替换为 Fleet 生成的真实凭据。
## 阶段 1：Elastic Agent 与 Fleet 注册
Fleet 注册令牌是从 **Fleet → Enrollment tokens** 生成的：
随着环境稳定，使用真实的 Fleet Server URL 和注册令牌下载并安装了 Elastic Agent：
\`\`\`bash
curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.4.4-linux-x86_64.tar.gz
tar xzvf elastic-agent-9.4.4-linux-x86_64.tar.gz
cd elastic-agent-9.4.4-linux-x86_64
sudo ./elastic-agent install --url= --enrollment-token=
\`\`\`
注册成功，Fleet 在几分钟内确认了 **agent 注册**和**传入数据**。
## 阶段 2：用于 Linux 的 Sysmon 部署
主机遥测通过用于 Linux 的 **Sysmon** 进行了扩展，该组件通过 Microsoft 的包存储库安装：
\`\`\`bash
wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
\`\`\`
最初的安装遇到了缺少密钥环的警告（`/usr/share/keyrings/microsoft-prod.gpg is missing`），在针对新添加的存储库重新运行 `apt update` 后，该警告即被清除：
随后，使用涵盖进程创建、网络连接和文件创建事件的自定义 `sysmonconfig.xml` 对 Sysmon 进行了配置：
\`\`\`xml
\`\`\`
\`\`\`bash
sudo sysmon -i sysmonconfig.xml
\`\`\`
配置验证成功，并且 Sysmon 注册为了 systemd 服务。
## 阶段 3：网络 IDS — 从 Snort 切换至 Suricata
Snort 是网络 IDS 的最初选择，但即使在启用了 `universe` 存储库之后，也无法通过 `apt` 定位到该包：
\`\`\`bash
sudo apt install -y snort
# 错误：无法定位软件包 snort
\`\`\`
实验环境随后改用 **Suricata**。最初的 `systemctl start suricata` 尝试失败（`exit-code`）：
运行了规则集更新，加载了 **68,018 条规则**（52,084 条已启用）：
重启仍然失败，通过使用 `ip -br addr` 检查实际网络接口，查到了根本原因——正在运行的网络接口是 `enp0s3`，而不是 `suricata.yaml` 配置绑定的接口：
在验证配置并更新 `suricata.yaml` 中的 `af-packet` 接口绑定之后：
\`\`\`yaml
af-packet:
- interface: enp0s3
cluster-id: 99
\`\`\`
服务成功启动，并设置了开机自启：
\`\`\`bash
sudo systemctl start suricata
sudo systemctl enable suricata
sudo systemctl status suricata
# Active：active (running)
\`\`\`
随后，将 Suricata 集成添加到了 Fleet agent 策略中以收集 `eve.json` 日志，使该策略同时拥有 System 和 Suricata 集成：
## 阶段 4：遥测验证
针对回环地址（`127.0.0.1`）和虚拟机实际接口（`10.0.2.15`）进行的 Nmap 扫描用于生成测试遥测数据：
在 Kibana Discover 中对此进行验证时，浮现出了一个值得记录的真实调试步骤：针对默认的安全解决方案数据视图，对 `process.name : "nmap"` 的初始查询返回了**无结果**。
切换到 `logs-*` 数据视图后显示了数据摄取：
第二次严格的字段名查询依然没有命中：
将查询范围扩大到 `*nmap*` 最终匹配到了 Sysmon 侧的进程执行记录——最初的查询范围被限制在了错误的数据视图和过于严格的字段匹配中：
## 阶段 5：威胁模拟 — SSH 暴力破解
在准备暴力破解阶段时，发现默认情况下并不存在 `ssh.service`：
安装了 `openssh-server` 并启用/启动了该服务：
随后，使用 Hydra 在本地模拟了 SSH 暴力破解攻击：
\`\`\`bash
hydra -l ubuntulabenv -P /usr/share/dict/words ssh://127.0.0.1 -t 4 -V
\`\`\`
该运行在完成前进行了自我限速（`all children were disabled due too many connection errors`），且未恢复出有效凭据——这是针对强化的本地 SSH 配置的预期行为，同时依然生成了检测测试所需的身份验证失败遥测数据。
Kibana 在 `system.auth` 数据流中确认了该次攻击：
一次 `*Failed password*` 搜索返回了 **637 个匹配的文档**：
## 阶段 6：检测规则配置与告警触发验证
最后这个阶段演示了完整的自定义检测规则构建过程——从头到尾——并以一个已确认、触发的告警结束。
在 Kibana Security 的检测规则引擎中编写了一条自定义的 KQL 阈值规则：
**查询定义** — `event.dataset : "system.auth" and event.action : "ssh_login"`：
**阈值调整** — 平台默认值 200 太高了，对于本实验环境的流量来说根本不会触发，因此被特意下调至 **5**，以匹配单主机环境下真实的检测敏感度：
**Group By** 被设置为 `source.ip`，因此告警是针对每个攻击源触发的，而不是汇总触发：
**规则元数据** — 命名为“SSH Brute Force Detection - Local Host”，严重性为高，风险评分 73：
**计划** — 设置为每 5 分钟运行一次：
**最终规则摘要**，已审查并启用：
**描述：** *“检测 5 分钟时间窗口内来自单一源 IP 的多次 SSH 身份验证失败尝试，这表明本地系统可能面临暴力破解或撞库活动。”*
### 结果：已触发的告警
执行后，该规则评估了传入的 `system.auth` 事件，关联了来自 `127.0.0.1` 的高频密码失败活动，并生成了一个已确认的高危告警——从而完成了从攻击模拟到检测的闭环。
**告警详情：** *“event with source 127.0.0.1 created high alert SSH Brute Force Detection...”* — 严重性：高，风险评分：73。
## 关键要点与展示的技能
* 通过 Fleet 部署并注册了 Elastic Agent，配置了具有双重主机（System、Sysmon）和网络（Suricata）集成的策略，实现了全方位的可见性。
* 独立诊断并解决了实际的基础设施问题：apt 锁定冲突、DKMS/VirtualBox 挂载失败、缺少 GPG 密钥环，以及追溯到网络接口绑定不正确的 NIDS 服务故障。
* 在实际限制下调整了工具链，在预期可用的包无法获取时，从 Snort 切换到了 Suricata。
* 在遥测验证期间调试了 Kibana 数据视图和字段范围不匹配的问题，而不是想当然地认为数据摄取已失败。
* 执行了受控的威胁模拟（Nmap、Hydra），以生成并验证真实的检测遥测数据。
* 编写并调整了自定义 KQL 阈值检测规则，将默认阈值调整为符合真实的实验室规模流量，而不是依赖开箱即用的设置。
* 验证了全闭环检测：攻击执行 → 经过 ECS 解析的数据摄取 → 规则评估 → 已触发且确认的告警。
标签：CTI, Elastic Stack, Metaprompt, 安全运营, 安全遥测, 扫描框架, 插件系统, 流量重放, 越狱测试