abdou-4/fullstack-cyberdefense-lab

# 🏢 企业安全实验室 — 全栈网络防御模拟  ## 📖 目录 - [概述](#overview) - [实验室架构](#lab-architecture) - [阶段 1 – 基础设施与安全基础](#phase-1--infrastructure--security-foundation) - [网络隔离](#network-segmentation) - [VM 组件与资源限制](#vm-components--resource-constraints) - [网络区域与 IP 分配](#network-zones--ip-assignment) - [VirtualBox 网络配置](#virtualbox-network-configuration) - [防火墙配置](#firewall-configuration) - [Active Directory 与身份基础设施](#active-directory--identity-infrastructure) - [Agents 部署](#agents-deployment) - [初始设置与挑战](#initial-setup--challenges) - [阶段 2 – 检测工程与攻击模拟（进行中）](#phase-2--detection-engineering--attack-simulation-in-progress) - [阶段 3 – 自动化与响应（计划中）](#phase-3--automation--response-planned) - [如何复现](#how-to-replicate) - [经验教训](#lessons-learned) - [未来路线图](#future-roadmap) - [许可证与致谢](#license--acknowledgements) ## 概述 大多数网络安全家庭实验室仅侧重于单一工具或预先构建的场景。本项目另辟蹊径——构建一个**完整的企业模拟**，映射真实组织的基础设施面貌，包括随之而来的复杂性、限制与权衡。 该环境完全运行在单台物理主机上（16 GB RAM，500 GB 外部 HDD），并模拟了包含以下内容的小型企业： - **具有基于区域的隔离的边界防火墙**（IPFire）——默认拒绝策略，32 条显式规则，全部记录在案 - **网络检测与响应**（Security Onion）——通过服务器网段上的混杂模式进行被动流量捕获 - **端点检测与响应 / SIEM**（Wazuh）——跨所有端点部署的 agents，集中化告警 - **Active Directory 域**（Windows Server 2019）——为企业环境提供 DC、DNS、NTP 和 DHCP 服务 - **真实的用户和服务器区域**——加入域的工作站、Linux 服务器、Windows 服务器 - **专用的管理工作站**——对所有监控仪表板进行隔离的分析师访问 - **外部攻击机**（Parrot OS）——连接互联网，模拟真实的外部威胁行为者 本项目分阶段构建，以反映企业安全计划的实际成熟过程——首先是基础设施，然后是检测，最后是自动化。 ## 实验室架构  ## 阶段 1 – 基础设施与安全基础 ### 网络隔离 IPFire 充当边界防火墙和路由器，执行严格的基于区域的隔离。每个区域代表一个独特的信任边界——如果没有显式的防火墙规则，任何流量都不能跨越区域。 | 区域 | 目的 | 子网 | IPFire 接口 | |------|---------|--------|-----------------| | **RED** | WAN / 外部攻击者 | 10.0.2.0/24 | RED | | **GREEN** | 管理与监控 | 192.168.30.0/24 | GREEN | | **BLUE** | 服务器区域（DC，目标机） | 192.168.10.0/24 | BLUE | | **ORANGE** | 用户区域（工作站） | 192.168.20.0/24 | ORANGE | **区域信任模型：** - **RED** 在入站方向完全隔离——没有外部流量可以发起连接进入任何内部区域。Parrot OS 通过 VirtualBox NAT 直接访问互联网，完全绕过 IPFire，这准确地模拟了一个具有互联网访问权限但没有内部访问权限的外部攻击者。 - **GREEN** 具有基于源 IP 范围的对 BLUE 和 ORANGE 的访问权限——每个监控工具仅有其所需的端口。 - **BLUE** 和 **ORANGE** 具有显式的出站互联网访问权限（80/443），并与 DC 通信以获取 AD 服务。BLUE 和 ORANGE 之间的跨区域通信被阻止。 - 区域之间的所有流量都会被记录并转发到 SIEM。 ### VM 组件与资源限制 所有 VM 均运行在配备 **16 GB RAM** 和 **500 GB 外部 HDD** 的主机上的 VirtualBox 中。由于硬件限制，使用了选择性开机策略——并非所有 VM 都同时运行。会话规划决定了给定任务需要哪些 VM。 | VM | 角色 | vCPU | RAM (GB) | 存储 (GB) | 区域 | IP | |----|------|------|----------|--------------|------|----| | **IPFire** | 防火墙 / 路由器 | 1 | 1 | 10 | – | RED 上为 DHCP | | **Security Onion** | NDR — 网络监控 | 4 | 8 | 200 | GREEN | 192.168.30.2 | | **Wazuh OVA** | EDR / SIEM | 4 | 8 | 50 | GREEN | 192.168.30.3 | | **Ubuntu Desktop** | 管理工作站 | 2 | 4 | 25 | GREEN | 192.168.30.4 | | **Windows Server 2019** | DC · AD · DNS · NTP · DHCP | 2 | 2 | 40 | BLUE | 192.168.10.2 | | **Ubuntu Server** | 目标 Linux 服务器 | 1 | 2 | 25 | BLUE | 192.168.10.3 | | **Windows 10 LTSC** | 加入域的用户工作站 | 2 | 2 | 40 | ORANGE | 192.168.20.2 | | **Parrot OS** | 外部攻击者 | 2 | 4 | 40 | RED | DHCP (NAT) | ### 网络区域与 IP 分配 | 区域 | VirtualBox 网络 | 子网 | 网关 | VMs | |------|--------------------|--------|---------|-----| | RED | `nat-wan` (NAT Network) | 10.0.2.0/24 | 10.0.2.1 | Parrot OS | | BLUE | `zone-server` (Internal) | 192.168.10.0/24 | 192.168.10.1 | Windows Server, Ubuntu Server | | ORANGE | `zone-user` (Internal) | 192.168.20.0/24 | 192.168.20.1 | Windows 10 | | GREEN | `zone-monitoring` (Internal) | 192.168.30.0/24 | 192.168.30.1 | Security Onion, Wazuh, Ubuntu Desktop | **Security Onion 监控接口：** Security Onion 有第二个连接到 `zone-server` (BLUE) 的适配器，启用了**混杂模式**且没有 IP 地址。此被动捕获接口可以查看服务器网段上的所有流量，而对该网络上的主机是不可见的。 ### VirtualBox 网络配置 #### IPFire（4 个适配器） | 适配器 | 类型 | 网络名称 | IPFire 区域 | |---------|------|--------------|-------------| | 1 | NAT Network | `nat-wan` | RED | | 2 | Internal Network | `zone-server` | BLUE | | 3 | Internal Network | `zone-user` | ORANGE | | 4 | Internal Network | `zone-monitoring` | GREEN | #### Security Onion（2 个适配器） | 适配器 | 类型 | 网络名称 | IP | 混杂模式 | |---------|------|--------------|-----|-------------| | 1 | Internal Network | `zone-monitoring` | 192.168.30.2 | 禁用 | | 2 | Internal Network | `zone-server` | 无（仅用于捕获） | **允许所有** | 所有其他 VM 都有一个连接到各自区域网络的适配器。 ### 防火墙配置 默认情况下，所有跨区域流量都会被拒绝。每个允许的流都有启用了日志记录的显式规则。这确保了防火墙事件可用于 SIEM 关联和异常检测——一个被阻止的连接尝试与成功的连接尝试一样有价值。 #### 默认策略 | 链 | 策略 | 理由 | |-------|--------|-----------| | Forward | **DROP** | 所有跨区域流量都需要显式规则 | | Input | **DROP** | 没有对 IPFire 本身的主动访问 | | Outgoing | **ALLOW** | 仅允许 IPFire 发起的流量——更新、NTP、DNS | #### 端口参考 | 端口 | 协议 | 用途 | |---------|----------|---------| | 25 | TCP | 阻止出站——防止邮件数据泄露和垃圾邮件中继 | | 22 | TCP | SSH——管理工作站（`.30.4`）仅能访问 BLUE/ORANGE | | 53 | UDP/TCP | DNS——主指向 DC（`192.168.10.2`），DC 离线时回退至互联网 | | 80, 443 | TCP | 为 BLUE 和 ORANGE 区域提供出站互联网访问 | | 88 | UDP/TCP | Kerberos——Active Directory 身份验证 | | 123 | UDP | NTP——主指向 DC，DC 离线时回退至互联网 | | 135 | TCP | RPC endpoint mapper (AD) | | 389 | UDP/TCP | LDAP——Active Directory 查询 | | 445 | TCP | SMB——组策略和 SYSVOL 复制 | | 636 | TCP | LDAPS——加密 LDAP | | 1514 | TCP | Wazuh agent 事件转发 | | 1515 | TCP | Wazuh agent 注册 | | 3389 | TCP | RDP——管理工作站（`.30.4`）仅能访问 BLUE/ORANGE | | 5055 | TCP | Logstash pipeline (Elastic Agent → Security Onion) | | 8220 | TCP | Elastic Agent 注册 (Fleet Server) | | 8443 | TCP | Fleet Server 管理 (Security Onion) | | 49152–65535 | TCP | RPC 动态端口——AD 操作所需 | | — | ICMP | 连接测试，按区域方向划分范围 | #### 区域访问矩阵 | 源 | 互联网 | GREEN | ORANGE | BLUE | |--------|----------|-------|--------|------| | **GREEN** | 仅 DNS/NTP | — | 按工具 IP + 端口划分范围 | 按工具 IP + 端口划分范围 | | **ORANGE** | 仅 80/443 | 仅 agent 端口 | — | 仅 DC IP（AD 端口） | | **BLUE** | 80/443 + DNS 回退 | 仅 agent 端口 | ❌ 阻止 | — | | **RED** | — | ❌ 阻止 | ❌ 阻止 | ❌ 阻止 | #### 防火墙规则截图  #### 关键设计决策 - **所有链均实施默认拒绝**——实现此目标的先决条件是了解环境中的每一个流量。在编写规则之前，必须显式识别并论证每个服务。 - **所有 32 条规则均被记录**——防火墙事件被输入到 Wazuh 和 Security Onion 中进行关联。来自 RED 的被阻止端口扫描与端点上的恶意软件一样可被检测到。 - **GREEN 基于源 IP 划分范围，而非全区域**——Wazuh（`.30.3`）、Security Onion（`.30.2`）和管理工作站（`.30.4`）各自仅有其所需的端口。受损的管理 VM 无法在任意端口上自由转向 BLUE 或 ORANGE。 - **AD 域流量范围仅限于 DC IP**——Kerberos、LDAP、SMB 和 RPC 仅允许从 ORANGE 访问 `192.168.10.2`，而不是整个 BLUE 子网。ORANGE 无法访问 BLUE 上的 Ubuntu Server。 - **具有分层回退的 DNS/NTP 弹性**——主 DNS 和 NTP 指向 Domain Controller。当 DC 离线时（在资源受限的实验室中很常见），回退规则允许直接的互联网解析，以防止监控工具上的日志时间戳偏差和名称解析失败。 - **SMTP 在规则 1 处被阻止**——位于所有其他规则之前。任何区域都无法发送出站电子邮件，从而防止无论其他规则配置如何，都通过邮件中继进行数据泄露。 - **RED 入站完全隔离**——Parrot OS 通过 VirtualBox NAT 直接访问互联网，绕过 IPFire。这准确地模拟了外部攻击者。没有规则允许 RED 发起连接进入任何内部区域。 ### Active Directory 与身份基础设施 Windows Server 2019 (`192.168.10.2`) 作为企业模拟的身份骨干，运行多个基础设施角色： - **Active Directory 域服务**——域 `corp.local`，包含 Servers、Workstations、Users 和 Service Accounts 的组织单位 - **DNS Server**——`corp.local` 的权威服务器，将外部查询转发至 `88.8.8`。所有内部 VM 均将其用作主 DNS。 - **NTP 权威**——加入域的机器将时间同步到 DC。Linux VM 配置了 DC 作为主 NTP，并配置 `pool.ntp.org` 作为 DC 离线时的回退。 - **DHCP Server**——为 ORANGE 区域配置的作用域（`192.168.20.10–100`），通过 IPFire 的 DHCP 中继功能进行中继 **AD 结构包括：** - 域管理员账户（高特权，不用于日常任务） - 代表企业员工的标准用户账户 - 具有服务主体名称（SPN）的服务账户（专为阶段 2 攻击模拟设计，易受 Kerberoasting 攻击） - 加入到 `corp.local` 域的 Windows 10 LTSC **时间同步策略：** 所有 Linux VM（`/etc/systemd/timesyncd.conf`）均配置为： ``` NTP=192.168.10.2 FallbackNTP=pool.ntp.org ``` 在每次攻击模拟会话之前，会在所有正在运行的 VM 上强制同步时间，以确保日志时间戳对于 SIEM 关联是可靠的。 ### Agents 部署 Agents 部署在所有端点 VM（Windows Server 2019、Ubuntu Server、Windows 10 LTSC）上，以实现跨两个平台的集中监控： - **Wazuh agents** 安装在每个端点上，配置为与 `192.168.30.3`（端口 1514/1515）上的 Wazuh manager 通信。所有连接均由 agent 发起（端点推送到 manager），这反映在防火墙规则的方向中。 - **Security Onion Elastic Agents** 安装在每个端点上，使用官方 MSI 安装程序 和 Linux 安装程序注册到位于 `192.168.30.2:8220` 的 Fleet Server。在 BLUE/ORANGE 和 GREEN 之间的 IPFire 中打开了端口 8220、8443 和 5055。 - 已使用以下命令向管理 VM 授予了 Security Onion Web 界面访问权限： sudo so-firewall includehost analyst 192.168.30.4 sudo so-firewall apply 所有端点同时将日志和遥测数据转发到两个监控平台。 ### 初始设置与挑战 真实的企业部署并非一帆风顺——本实验也是如此。下面的每一个挑战都是经过独立诊断和解决的： | 挑战 | 解决方案 | |-----------|----------| | 外部 HDD 的设备名称根据 USB 端口而变化；由于 KVM 冲突，VirtualBox 拒绝启动 VM | 编写了 `/starter` bash 脚本——在启动时按 UUID 挂载 HDD 并禁用 Intel KVM | | 所有 VM 上的 Ubuntu netplan 配置在安装后丢失；Wazuh OVA 默认使用 DHCP | 为 Ubuntu VM 手动编写了 `/etc/netplan/50-cloud-init.yaml`；为 Wazuh OVA 编辑了 `/etc/systemd/network/` 以配置静态 IP、网关和 DNS | | 应用默认拒绝策略后，BLUE 区域 VM 没有互联网访问权限 | 确定了 BLUE 缺少显式的 80/443 规则；添加了按区域的出站规则 | | 切换到默认拒绝策略破坏了 agent 通信 | 审计了所有 agent 流量流，映射了每个工具的确切端口，使用正确的方向从头开始重建规则集 | | 从 ORANGE 加入 AD 域静默失败 | 确定了 ORANGE 和 DC IP 之间缺少 Kerberos (88)、LDAP (389)、SMB (445)、RPC (135, 49152–65535) 规则 | | Wazuh 手动安装反复失败 | 切换到官方 Wazuh OVA（预配置设备） | | Parrot OS 实时环境在启动时挂起 | 从 VM 虚拟存储中删除了 ISO——它正在循环引导至安装程序 | | Ubuntu VM 上的 DNS 解析中断 | 手动设置 `/etc/resolv.conf` 并禁用 `systemd-resolved` | | 资源受限 VM 上的 Systemd 服务启动超时 | 在 `/etc/systemd/system.conf` 中增加了 `DefaultTimeoutStartSec=600` | | `sudo so-firewall apply` 反复超时——Salt 配置引擎卡住 | 重启 Salt：`sudo systemctl restart salt-master salt-minion` | **配置文件：** - [starter — bash 脚本（HDD 挂载 + 禁用 KVM）](/starter) - [50-cloud-init.yaml — Ubuntu VM 的静态 IP 配置](/50-cloud-init.yaml) - [05-static-eth0.network — Wazuh OVA 的静态 IP 配置](/05-static-eth0.network) ## 阶段 2 – 检测工程与攻击模拟（进行中） 在基础设施基础稳定之后，阶段 2 侧重于生成真实的攻击遥测数据，并验证检测栈是否能够真正捕获这些攻击。 **端点遥测强化（先决条件）：** - [ ] 使用 SwiftOnSecurity 配置在 Windows Server 和 Windows 10 上部署 **Sysmon**——添加了 Windows 默认审核完全遗漏的进程创建、网络连接和文件创建事件 - [ ] 通过组策略启用**高级审核策略**：登录事件（4624/4625）、进程创建（4688）、特权使用、账户管理 - [ ] 在 BLUE/ORANGE 端点上启用 Windows 防火墙日志记录并转发至 Wazuh **网络基线文档：** - [ ] 在仅包含合法活动的情况下干净地运行环境 24–48 小时 - [ ] 在 Security Onion 中记录正常流量模式（Zeek conn 日志、每个区域的预期协议、典型的外部目的地） - [ ] 调整 Suricata 对已知良好 Windows/Microsoft 流量的抑制，以在攻击开始前减少噪声 **攻击模拟：** - [ ] 在 Windows 端点上使用 **Atomic Red Team**——模拟特定的 MITRE ATT&CK 技术（凭证访问 T1003、执行 T1059、持久化 T1547），并验证 Wazuh/Security Onion 检测是否正确触发 - [ ] 针对中 AD 中故意设置存在漏洞的服务账户进行 **Kerberoasting**——通过 Windows 事件 4769 和 Zeek Kerberos 日志验证检测 - [ ] ORANGE 和 BLUE 之间的**横向移动**模拟——测试防火墙是否正确阻止了未经授权的路径，以及被允许的路径是否生成了可检测的遥测数据 - [ ] 记录每次攻击：使用的技术 → 预期的告警 → 实际的告警 → 差距分析 **事件响应工作流：** - [ ] 在管理工作站上将 **TheHive** 部署为附加服务——练习为每次模拟攻击创建 IR 案例、记录证据和跟踪调查步骤 ## 阶段 3 – 自动化与响应（计划中） - Wazuh **主动响应**——由特定告警条件触发的自动操作（例如，在多次登录失败后阻止 IP） - **MISP** 集成——将威胁情报源连接到 Wazuh 和 Security Onion，以进行基于 IOC 的检测 - **Caldera**（MITRE 对手模拟）——运行超越单一技术的多步骤攻击链，模拟完整的入侵生命周期 - 针对严重级别告警的 **Slack/Teams** 通知 - 基于阶段 2 中建立的网络基线的 Elasticsearch ML 异常检测 ## 如何复现 1. **硬件要求** - 最低配置：16 GB RAM，500 GB 存储，支持硬件虚拟化（VT-x/AMD-V）的 CPU - 计划选择性开启 VM——Security Onion (8 GB) 和 Wazuh (8 GB) 一起将消耗全部 16 GB 的分配量 2. **软件** - VirtualBox（或 VMware Workstation） - ISO/OVA：IPFire、Security Onion、Wazuh OVA、Windows Server 2019 评估版、Windows 10 LTSC 评估版、Ubuntu Server 24.04、Ubuntu Desktop 24.04、Parrot OS Security 3. **部署顺序** - 首先部署 IPFire——在配置任何其他 VM 之前建立区域连接 - Security Onion → Wazuh OVA → Windows Server（AD/DNS 设置）→ 其他 VM - 在安装 agents 之前配置静态 IP——agent 注册后更改 IP 会导致重新注册问题 4. **网络配置** - 在 VirtualBox 中创建内部网络：`zone-server`、`zone-user`、`zone-monitoring` - 创建 NAT 网络：`nat-wan` (10.0.2.0/24) - 在添加端点 VM 之前将 IPFire 转发策略设置为**阻止**——避免在设置过程中发生意外的跨区域流量 5. **验证清单** - 所有内部 VM 都可以 ping 通各自的网关（IPFire 接口） - BLUE 和 ORANGE 可以通过 443 端口访问 `8.8.8.8` - Security Onion 捕获接口可看到流量：`sudo tcpdump -i -c 10` - Wazuh agents 在 Wazuh 仪表板中显示为活跃状态 - Windows 10 已成功加入 `corp.local` 域 ## 经验教训 - **默认拒绝迫使你了解自己的环境。** 如果不知道每个流量流，就无法实施它。构建 32 条白名单规则的过程本身就是一次关于企业工具实际如何通信的学习练习。 - **资源限制会推动更好的架构决策。** 有限的 RAM 迫使你确定优先级——你很快就能了解到哪些组件是承重墙，哪些是可选的。 - **从第一天起就记录一切。** 事后才启用防火墙日志记录意味着会丢失基线。从一开始就记录所有规则可为故障排除和检测提供即时价值。 - **Agent 发起与服务器发起的连接至关重要。** 了解每个监控工具的通信方向决定了您的防火墙规则是源 BLUE→GREEN 还是源 GREEN→BLUE。弄错这一点会静默地破坏监控。 - **NTP 在损坏之前是不可见的。** 跨工具的时间戳不匹配会使关联变得手动且不可靠。即使在 VM 可用性间歇性中断的实验室中，分层 NTP 策略（主 DC，互联网回退）也可以防止这种情况发生。 - **预先构建的设备是合理的工程选择。** 使用 Wazuh OVA 而不是手动安装并不是偷工减料——当部署可靠性比安装体验更重要时，这是真实团队会做出的相同决定。 - **在解决问题时记录问题。** 此 README 中的挑战表是在构建过程中编写的，而不是根据记忆重构的。在作品集中，真正的故障排除步骤比润色后的摘要更有价值。 ## 未来路线图 - **第二台物理主机**——实现同时运行完整环境，模拟分布式基础设施和主机之间的东西向流量 - **基于设计缺陷的 AD 错误配置**——可进行 AS-REP Roasting 攻击的账户、脆弱的 ACL、非约束性委派——现代入侵的真实目标 - **在 BLUE 区域部署蜜罐**（OpenCanary）——与它的任何连接都会立即成为高保真信号，无需调整 - **将网络拓扑图作为代码**——在 draw.io 或 Mermaid 中维护架构图，与实验室配置一起进行版本控制 ## 许可证与致谢 使用开源工具构建，用于教育和作品集目的。 - **IPFire** – GNU GPL - **Security Onion** – 各种开源许可证 - **Wazuh** – GPLv2 - **VirtualBox** – GPLv2 - **Sysmon / Atomic Red Team** – MIT *最后更新：2026 年 4 月* *阶段 1 完成 · 阶段 2 进行中 · 阶段 3 计划中*

标签：EDR, IP 地址批量处理, MIT许可证, Terraform 安全, 企业安全实验室, 攻击模拟, 活动目录, 网络分段, 网络安全, 脆弱性评估, 隐私保护, 驱动签名利用