FissaDooz/soc-detection-validation-lab

# SOC 检测验证实验室     ## 1. 背景与目标 本项目建于一个面向 SOC/CSIRT 的培训项目（Play-Zone 2025）期间，旨在解决安全运营中的一个普遍问题：随着系统、日志源和配置的逐渐偏移，检测用例会悄无声息地随时间失效，而手动验证它们既缓慢又不一致。 目标是构建一个受控、分段的实验室环境，重现真实的企业网络，针对该环境生成并重放真实的攻击日志，并持续验证 Splunk SIEM 的检测用例是否仍按预期触发——从而将临时的用例测试转化为可重复、半自动化的流程。 主要需求： - 通过定期、可重复、自动化的测试，加快用例测试速度并提升 SOC 响应能力 - 基于真实日志自动化执行攻击场景，以验证用例的有效性 - 以受控方式生成并重放攻击日志，从而测试并保证检测能力 ## 2. 架构 该实验室重现了一个分段的企业网络，包含两个冗余的数据中心站点以及一个仅可通过站点到站点 VPN 隧道访问的专用、隔离的 SOC 网段。 ``` flowchart TB ISP((Internet)) subgraph CAMPUS["Campus network"] R1[R1] R2[R2] FW1[FW1 - Fortigate] FW2[FW2 - Fortigate] DMZ["DMZ - 10.10.30.0/24"] BASTION["Bastion - Guacamole - 10.10.40.0/24"] MLS1[MLS1 - core switch] MLS2[MLS2 - core switch] SA1[SA1 - access switch] SA2[SA2 - access switch] PC1[PC1] PC2[PC2] PC3[PC3] end subgraph DC1["Datacenter 1 - PVE1"] DC1AD["LAN AD - 10.20.20.0/24 - DC1, FS1"] DC1LX["LAN Linux - 10.20.21.0/24 - DHCP1, DNS1, TFTP1, CA1, LogCollector, Gophish"] end subgraph DC2["Datacenter 2 - PVE2"] DC2AD["LAN AD - 10.20.22.0/24 - DC2, FS2"] DC2LX["LAN Linux - 10.20.23.0/24 - DHCP2, DNS2, TFTP2, CA2"] end subgraph SOC["SOC segment"] R3[R3] FW3[FW3] PVE3["PVE3 - Splunk SIEM - 10.30.1.0/24, 10.30.2.0/24"] end ISP --- R1 ISP --- R2 R1 --- FW1 R2 --- FW2 FW1 --- DMZ FW1 --- BASTION FW1 --- MLS1 FW2 --- MLS2 MLS1 <-->|redundant link| MLS2 MLS1 --- SA1 MLS2 --- SA2 SA1 --- PC1 SA1 --- PC2 SA2 --- PC3 MLS1 --- DC1AD MLS1 --- DC1LX MLS2 --- DC2AD MLS2 --- DC2LX R2 -. IPsec IKEv2 site-to-site .- R3 R3 --- FW3 FW3 --- PVE3 ``` 设计原则： - **分段**：管理、用户、访客、DMZ 和堡垒机流量被隔离在专用的 VLAN 中（10、100、200，加上专用的 DMZ/堡垒机网段） - **冗余**：网络设备、服务器和数据中心主机成对部署（SOC 网段除外，它有意在单台路由器/防火墙/主机上运行） - **隔离**：SOC 网段仅可通过校园网与 SOC 路由器之间的 IPsec IKEv2 站点到站点隧道访问——日志是跨越该边界的唯一流量 - **集中化远程访问**：位于 Fortigate VPN 网关背后的 Guacamole 堡垒机是 SSH/RDP 访问内部服务器和网络设备的唯一入口，因此没有设备的端口被直接暴露 有关详细的客户端到站点 VPN、各站点数据中心和日志流程图，请参阅 [docs/architecture.md](docs/architecture.md)。 ## 3. 使用的技术 - **SIEM**：Splunk Enterprise 9.3.1（版本被固定以匹配目标生产环境），Rocky Linux 9.6 - **日志收集**：Splunk Universal Forwarders，rsyslog 日志收集器 - **自动化**：Ansible（Universal Forwarder 部署与配置） - **网络安全**：Fortigate 60F 防火墙，pfSense 虚拟防火墙，IPsec IKEv2（站点到站点和客户端到站点），扩展 ACL - **身份验证**：Windows Server Active Directory，内部两层 CA 层次结构 - **远程访问**：Guacamole 堡垒机 - **虚拟化**：Proxmox VE - **攻击工具（验证测试）**：Hydra，Nmap - **自定义工具**：UCT4S (Use Case Tester for Splunk) — 用于日志注入和用例验证的内部工具 - **CI/CD（计划中）**：用于自动化用例回归测试的 Forgejo pipeline ## 4. 实施 ### 4.1 基础设施 网络被划分为多个 VLAN（管理 10、用户 100、访客 200）、一个 DMZ 和一个堡垒机网段，所有流量均通过同样充当路由器的 Fortigate 防火墙进行过滤。多层交换机 (MLS1/MLS2) 负责处理 VLAN 间路由以及绑定到 IP SLA 跟踪的浮动路由，以实现自动故障转移。每个网络设备和服务器角色（DC、FS、DNS、DHCP）都在两台 Proxmox 主机 (PVE1/PVE2) 上进行了复制，以消除单点故障；而 SOC 网段（路由器、防火墙、Splunk 主机）有意采用单实例。 ### 4.2 日志收集 利用 Ansible 在 Rocky Linux 主机上部署了 Splunk Universal Forwarders，以实现安装和配置的自动化。网络设备日志（路由器、交换机、防火墙）集中在一个专用的 rsyslog 收集器上，然后通过 Universal Forwarders 转发到 Splunk，后者在接收日志前还负责执行日志预解析。 ### 4.3 收集架构评估 在确定基于 Universal Forwarder 的架构之前，我们评估了更高级的收集/标准化工具（Cribl、Splunk Connect for Syslog）。它们提供了更强大的过滤、标准化和流量控制功能，但带来了不符合项目时间限制的配置和维护开销。基于 TCP 6514 (TLS) 的安全 syslog 被确定为后续的改进方向，但并未在这个 MVP 中实施。在可用时间内，Universal Forwarders 被选为实现可运行 SIEM 的务实途径，并保留了以后迁移到 Cribl/SC4S 的选项。 ### 4.4 用例验证方法 我们评估了 Splunk 官方的 `contentctl` 工具用于用例验证。它旨在检测进入生产环境*之前*对其进行测试（数据集生成、检测建模、新用例的 CI/CD）——而不是用于诊断 Splunk 中已部署的检测是否仍能正确触发，而这正是此处的实际需求。纯粹为了这个目的而使用它，将意味着不成比例的设置成本，且收益甚微。 因此，我们设计了一款自定义工具 **UCT4S (Use Case Tester for Splunk)** 来注入合成日志、运行关联的 SPL 搜索，并持续验证检测用例——目标是每次用例更改时，自动从 Forgejo CI/CD pipeline 触发该验证。 ### 4.5 验证测试 **暴力破解 (Hydra)** — 针对 Active Directory 域控制器的 LDAP 身份验证，以检查 Splunk 是否能正确检测并关联重复的失败登录尝试。我们使用了自定义的用户名列表和常见模式的密码列表；目的是观察 AD 的锁定/延迟行为以及 SIEM 的检测有效性，而不是为了攻陷账户。未执行任何破坏性或未经授权的测试。 **侦察扫描 (Nmap)** — 对域控制器进行水平和垂直扫描，以枚举开放端口、活动主机和服务版本（确认 389/TCP 上的 LDAP），并验证由此产生的 Windows Filtering Platform 事件是否被记录在 AD 中并转发到 Splunk 与生成的告警进行关联。 ## 5. 可衡量的结果 - 针对域控制器的 Hydra 暴力破解测试为每次尝试生成了 Windows Security 事件 **4625**（登录失败）；这些事件被正确转发到 Splunk，并被检测为异常身份验证行为。 - 针对域控制器的 Nmap 扫描在端口 389/TCP 上生成了 Windows Security 事件 **5156**（Windows Filtering Platform 允许连接）；这些事件被正确转发到 Splunk，并与预期的告警进行了关联。 - 这两种事件的匿名样本可在 [logs-samples/](logs-samples/) 中找到。 定量指标（平均检测时间、整个用例目录的检测率）在此阶段未进行正式测量，因此未在此报告——验证是定性的（预期事件是否触发并到达 Splunk，是/否）。有关详细分析，请参阅 [docs/results.md](docs/results.md)。 ## 6. 经验教训 - **流量隔离与可靠性**：最初的设计试图将 SOC 管理流量和日志流量保持在不同的路径上，其中一部分流量被路由到 VPN 隧道之外。这产生了一旦日志被路由到隧道外就会丢失的风险。因此决定通过 VPN 路由所有发往 SOC 的流量——粒度稍粗，但路由更简单（通过 VTI），日志传递更可靠，并且攻击面更小。 - **`monitor://` 配置节误解**：Splunk 拒绝了使用 `recursive=true` 的 Universal Forwarder `monitor://` 配置节（`Invalid key: recursive=true`）——该属性在 UF 的 monitor 配置节中不受支持，并且 Splunk 不会自动递归到子目录中。通过显式调整受监控的路径修复了此问题。 - **`systemctl status` 未显示 `User=splunkfwd`**：最初被认为是配置错误，但这是正常的——`systemd` 并不总是会在 `systemctl status` 输出中打印每一个内部指令。尽管缺少这一行，该服务依然在正常运行。 - **时间限制下的工具选择**：`contentctl` 和高级收集器（Cribl、SC4S）均经过评估并被有意推迟——不是因为它们不如其他工具，而是因为它们的设置成本与项目的时间线和实际需求不匹配（验证已部署的检测，而不是编写新的检测）。记录*为什么*不使用主流工具被视为与记录实现了什么同等重要。 ## 许可证 MIT — 见 [LICENSE](LICENSE)。

标签：Ansible, 安全实验室, 安全运营, 扫描框架, 系统提示词