Mario0111/suricata-splunk-detection-lab
GitHub: Mario0111/suricata-splunk-detection-lab
一个网络检测工程实验项目，构建了从 Suricata IDS 到 Splunk SIEM 的完整检测流水线，包含自定义检测规则、关联搜索和调查文档。
Stars: 0 | Forks: 0
# 检测工程实验室：Suricata 到 Splunk
我搭建这个实验室是为了练习检测工程师实际要做的工作。不仅仅是安装 IDS，还要将其遥测数据导入 SIEM，编写针对真实攻击流量的规则，证明它们有效，并决定如何处理在此过程中出现的噪声。
Suricata 8 运行在隔离的 VirtualBox 网络上，并通过 Universal Forwarder 将 EVE JSON 发送到 Splunk Enterprise。在此基础之上构建了三个仪表板、四个涵盖四个 ATT&CK 战术的自定义检测，以及一个将它们关联起来的关联搜索。
我始终坚持的一条原则是：在调优之前先进行调查。有两次数据中出现了意想不到的情况，我都停止了构建工作，在改变任何东西之前先弄清楚原因。
## 架构
```
flowchart LR
K["Kali Linux
Attacker
10.10.10.10"] -->|attack traffic| M["Metasploitable 2
Victim
10.10.10.20"] K -.->|observed by sensor| S M -.-> S subgraph SENSOR ["Suricata Sensor 10.10.10.30"] S["Suricata 8.0.6
AF_PACKET capture"] --> E["eve.json"] E --> UF["Universal Forwarder"] end UF -->|forwarded events| SP["Splunk Enterprise
10.10.10.40
index=suricata"] SP --> D1["Detection Health
Overview"] SP --> D2["SOC Analyst
Triage"] SP --> D3["Detection
Inventory"] ``` | 组件 | 详情 | |---|---| | Hypervisor | VirtualBox，隔离的内部网络 `10.10.10.0/24` | | 攻击者 | Kali Linux，`10.10.10.10` | | 受害者 | Metasploitable 2，`10.10.10.20` | | IDS 传感器 | Ubuntu 26.04 LTS 上的 Suricata 8.0.6，`10.10.10.30`，在 `enp0s3` 上使用 AF_PACKET | | SIEM | Ubuntu 26.04 LTS 上的 Splunk Enterprise 10.4.1，`10.10.10.40` | | 传输方式 | 通过 Universal Forwarder 传输到专门的 `suricata` 索引，sourcetype 为 `suricata:eve` | | 摄取延迟 | 从攻击发生到事件变为可搜索状态，最短 5 秒，平均 7 秒，最长 9 秒 | 更多详细信息请参见 [docs/architecture.md](docs/architecture.md)。 ## 我构建的内容 **经过验证的遥测流水线。** 从捕获到索引、可搜索的 JSON，我在其之上构建任何内容之前，都检查了时间戳和嵌套字段提取，并将其与原始的 `eve.json` 进行了核对。我实际测量了端到端的延迟，而不是凭空假设。 **四个自定义的 Suricata 检测**，涵盖侦察、初始访问、执行和发现。每个检测都有一份文档，涵盖了其背后的研究、规则逻辑及其权衡、我如何验证它，以及分析师将如何处理告警。它们位于 [detections/](detections/) 中。 **一个关联搜索**，它对攻击者在各个阶段的进展进行评分，而不是仅仅计算告警数量，因此在这个以嘈杂为主的实验环境中，它能保持安静。参见 [COR-001](detections/COR-001-recon-to-exploit-chain.md)。 **三个仪表板**，每个仪表板都针对特定的受众和问题，而不是试图用一个仪表板来满足所有人的需求。详见 [docs/dashboards.md](docs/dashboards.md)。 **两次调查**，记录了实验环境发生了一些我未预料到的情况，撰写于 [docs/investigations.md](docs/investigations.md) 中。 ## 仪表板 | 仪表板 | 受众 | 它解决的问题 | |---|---|---| | [检测健康状况概览](docs/dashboards.md#detection-health-overview) | 检测工程 | 流水线是否正在运行且表现正常？ | | [SOC 分析师分诊](docs/dashboards.md#soc-analyst-triage) | SOC 分析师 | 发生了什么，我该从哪里开始着手？ | | [检测资产清单](docs/dashboards.md#detection-inventory) | 检测工程 | 存在哪些检测，哪些噪声大，发生了什么更改？ |  ## 检测 | ID | 检测 | SID | ATT&CK | 战术 | |---|---|---|---|---| | [DET-001](detections/DET-001-sql-injection.md) | SQL 注入，URI 中的 UNION SELECT | 1000002 | T1190 | 初始访问 | | [DET-002](detections/DET-002-command-injection.md) | 命令注入，URI 中的 shell 元字符 | 1000003 | T1059 | 执行 | | [DET-003](detections/DET-003-directory-traversal.md) | 目录遍历和 LFI | 1000004 | T1083 | 发现 | | [DET-004](detections/DET-004-suspicious-user-agent.md) | 可疑的 user agent，已知的攻击工具 | 1000005 | T1595.002 | 侦察 | 这四个检测均已部署，并确认能在真实的攻击流量上触发。每条规则都经历了相同的周期：研究、设计、编写、使用 `suricata -T` 进行验证、模拟攻击、在 Splunk 中确认告警、映射到 ATT&CK，然后决定是否进行调优。完整的 ATT&CK 覆盖范围详见 [docs/mitre-mapping.md](docs/mitre-mapping.md)。 ## 值得一读的内容 这个项目中有几个部分最终被证明比单纯的设置工作更有趣。 **一条糟糕的规则会导致整个规则集失效。** 我的第一条命令注入规则加载失败，原因是 regex 字符类中包含一个分号。Suricata 的反应并不是跳过那一条规则，而是拒绝加载任何规则。如果我没有先进行验证就将其推送上线，传感器在重启后将没有任何处于激活状态的检测，但状态依然显示为健康。根本原因详见 [DET-002](detections/DET-002-command-injection.md#why-the-first-version-failed-to-load)。 **实验环境中最吵闹的签名竟然是我自己的监控工具栈。** 一个签名触发了超过 5,000 次告警，最终查明原因是 Splunk Web 正在与自身通信。在采取任何抑制措施之前，我先对其进行了溯源分析，并在 [docs/tuning.md](docs/tuning.md) 中撰写了为什么一禁了之不是正确的修复方法。 **仪表板的 KPI 与我的认知不符。** 唯一签名计数显示为 3，而我只见过 2 个。这可能是面板损坏，也可能是真实的变化，这两种可能性都需要排除。结果是真实的变化，调查过程记录在 [docs/investigations.md](docs/investigations.md) 中。 **IDS 告警证明的是意图，而不是影响。** 我所有的四次验证攻击都返回了同样无害的页面，因为 web 根目录忽略了我注入的参数。尽管如此，每条规则还是照常触发了。这是正确的行为，理解其原因的意义远比表面看起来要重要。详见 [docs/lessons-learned.md](docs/lessons-learned.md)。 ## 仓库结构 ``` docs/ architecture.md lab topology, sensor spec, pipeline design dashboards.md all three dashboards with their SPL detections.md signature inventory and detection index investigations.md the two investigations tuning.md noise analysis and tuning decisions mitre-mapping.md ATT&CK coverage lessons-learned.md detections/ DET-001 to DET-004 per detection writeups COR-001 correlation search rules/local.rules the custom rules journal/ engineering journal, OBS-001 to OBS-006 config/ sanitised Suricata, forwarder and Splunk configs screenshots/ ``` 所有的工作均是在隔离的实验室中针对具有故意漏洞的系统完成的。
Attacker
10.10.10.10"] -->|attack traffic| M["Metasploitable 2
Victim
10.10.10.20"] K -.->|observed by sensor| S M -.-> S subgraph SENSOR ["Suricata Sensor 10.10.10.30"] S["Suricata 8.0.6
AF_PACKET capture"] --> E["eve.json"] E --> UF["Universal Forwarder"] end UF -->|forwarded events| SP["Splunk Enterprise
10.10.10.40
index=suricata"] SP --> D1["Detection Health
Overview"] SP --> D2["SOC Analyst
Triage"] SP --> D3["Detection
Inventory"] ``` | 组件 | 详情 | |---|---| | Hypervisor | VirtualBox，隔离的内部网络 `10.10.10.0/24` | | 攻击者 | Kali Linux，`10.10.10.10` | | 受害者 | Metasploitable 2，`10.10.10.20` | | IDS 传感器 | Ubuntu 26.04 LTS 上的 Suricata 8.0.6，`10.10.10.30`，在 `enp0s3` 上使用 AF_PACKET | | SIEM | Ubuntu 26.04 LTS 上的 Splunk Enterprise 10.4.1，`10.10.10.40` | | 传输方式 | 通过 Universal Forwarder 传输到专门的 `suricata` 索引，sourcetype 为 `suricata:eve` | | 摄取延迟 | 从攻击发生到事件变为可搜索状态，最短 5 秒，平均 7 秒，最长 9 秒 | 更多详细信息请参见 [docs/architecture.md](docs/architecture.md)。 ## 我构建的内容 **经过验证的遥测流水线。** 从捕获到索引、可搜索的 JSON，我在其之上构建任何内容之前，都检查了时间戳和嵌套字段提取，并将其与原始的 `eve.json` 进行了核对。我实际测量了端到端的延迟，而不是凭空假设。 **四个自定义的 Suricata 检测**，涵盖侦察、初始访问、执行和发现。每个检测都有一份文档，涵盖了其背后的研究、规则逻辑及其权衡、我如何验证它，以及分析师将如何处理告警。它们位于 [detections/](detections/) 中。 **一个关联搜索**，它对攻击者在各个阶段的进展进行评分，而不是仅仅计算告警数量，因此在这个以嘈杂为主的实验环境中，它能保持安静。参见 [COR-001](detections/COR-001-recon-to-exploit-chain.md)。 **三个仪表板**，每个仪表板都针对特定的受众和问题，而不是试图用一个仪表板来满足所有人的需求。详见 [docs/dashboards.md](docs/dashboards.md)。 **两次调查**，记录了实验环境发生了一些我未预料到的情况，撰写于 [docs/investigations.md](docs/investigations.md) 中。 ## 仪表板 | 仪表板 | 受众 | 它解决的问题 | |---|---|---| | [检测健康状况概览](docs/dashboards.md#detection-health-overview) | 检测工程 | 流水线是否正在运行且表现正常？ | | [SOC 分析师分诊](docs/dashboards.md#soc-analyst-triage) | SOC 分析师 | 发生了什么，我该从哪里开始着手？ | | [检测资产清单](docs/dashboards.md#detection-inventory) | 检测工程 | 存在哪些检测，哪些噪声大，发生了什么更改？ |  ## 检测 | ID | 检测 | SID | ATT&CK | 战术 | |---|---|---|---|---| | [DET-001](detections/DET-001-sql-injection.md) | SQL 注入，URI 中的 UNION SELECT | 1000002 | T1190 | 初始访问 | | [DET-002](detections/DET-002-command-injection.md) | 命令注入，URI 中的 shell 元字符 | 1000003 | T1059 | 执行 | | [DET-003](detections/DET-003-directory-traversal.md) | 目录遍历和 LFI | 1000004 | T1083 | 发现 | | [DET-004](detections/DET-004-suspicious-user-agent.md) | 可疑的 user agent，已知的攻击工具 | 1000005 | T1595.002 | 侦察 | 这四个检测均已部署，并确认能在真实的攻击流量上触发。每条规则都经历了相同的周期：研究、设计、编写、使用 `suricata -T` 进行验证、模拟攻击、在 Splunk 中确认告警、映射到 ATT&CK，然后决定是否进行调优。完整的 ATT&CK 覆盖范围详见 [docs/mitre-mapping.md](docs/mitre-mapping.md)。 ## 值得一读的内容 这个项目中有几个部分最终被证明比单纯的设置工作更有趣。 **一条糟糕的规则会导致整个规则集失效。** 我的第一条命令注入规则加载失败，原因是 regex 字符类中包含一个分号。Suricata 的反应并不是跳过那一条规则，而是拒绝加载任何规则。如果我没有先进行验证就将其推送上线，传感器在重启后将没有任何处于激活状态的检测，但状态依然显示为健康。根本原因详见 [DET-002](detections/DET-002-command-injection.md#why-the-first-version-failed-to-load)。 **实验环境中最吵闹的签名竟然是我自己的监控工具栈。** 一个签名触发了超过 5,000 次告警，最终查明原因是 Splunk Web 正在与自身通信。在采取任何抑制措施之前，我先对其进行了溯源分析，并在 [docs/tuning.md](docs/tuning.md) 中撰写了为什么一禁了之不是正确的修复方法。 **仪表板的 KPI 与我的认知不符。** 唯一签名计数显示为 3，而我只见过 2 个。这可能是面板损坏，也可能是真实的变化，这两种可能性都需要排除。结果是真实的变化，调查过程记录在 [docs/investigations.md](docs/investigations.md) 中。 **IDS 告警证明的是意图，而不是影响。** 我所有的四次验证攻击都返回了同样无害的页面，因为 web 根目录忽略了我注入的参数。尽管如此，每条规则还是照常触发了。这是正确的行为，理解其原因的意义远比表面看起来要重要。详见 [docs/lessons-learned.md](docs/lessons-learned.md)。 ## 仓库结构 ``` docs/ architecture.md lab topology, sensor spec, pipeline design dashboards.md all three dashboards with their SPL detections.md signature inventory and detection index investigations.md the two investigations tuning.md noise analysis and tuning decisions mitre-mapping.md ATT&CK coverage lessons-learned.md detections/ DET-001 to DET-004 per detection writeups COR-001 correlation search rules/local.rules the custom rules journal/ engineering journal, OBS-001 to OBS-006 config/ sanitised Suricata, forwarder and Splunk configs screenshots/ ``` 所有的工作均是在隔离的实验室中针对具有故意漏洞的系统完成的。
标签：IP 地址批量处理, Suricata, 代码示例, 安全运营, 扫描框架, 数据分析, 现代安全运营, 网络安全实验