ColinMKC/secure-network-architecture-lab

GitHub: ColinMKC/secure-network-architecture-lab

一个在虚拟实验室中构建并验证纵深防御策略的安全网络架构项目,通过防火墙分段和 IDS 入侵检测来证明安全控制措施在遭受攻击时的实际有效性。

Stars: 0 | Forks: 0

# 安全网络架构实验室 这是一个在虚拟实验室中构建并验证的、采用分段和纵深防御策略的网络。本项目展示了网络分区、最小权限防火墙策略以及入侵检测——更重要的是,它记录了每个设计决策背后的*推理过程*,并证明了这些安全控制在遭受攻击时依然有效。 ## 1. 目标 设计一个小型企业级网络,以控制被攻破后的破坏范围。具体而言:如果面向公众的服务被攻破,攻击者绝不能能够访问内部或管理系统。该实验室构建了网络,通过最小权限防火墙规则对其进行加固,然后通过对边界发起攻击来验证其有效性。 **向读者展示的内容:**网络分段、默认拒绝防火墙设计、威胁建模以及基于证据的验证。 ## 2. 威胁模型 该设计假设了以下情况,并旨在抵御这些威胁: - **假设 DMZ 主机被攻破。** 公共 Web 服务器是暴露程度最高的资产。该设计的核心问题是:*一旦攻击者控制了 DMZ 主机,他们能访问什么?*答案必须是“没有任何有价值的资源”。 - **假设存在内部渗透立足点。** 企业 LAN 上的某台设备可能被攻击者控制(例如通过钓鱼攻击、恶意 USB)。它不应能够随意访问 DMZ 或管理平面。 - **管理平面是价值最高的目标。** 对防火墙的管理访问权限实际上等同于对整个网络的 root 权限,因此对其访问是受到最严格限制的边界。 本实验室不涉及的范围:物理安全、端点加固以及 DMZ 主机中的应用层漏洞(该主机是故意存在漏洞的——它是测试目标,而非受保护主体)。 ## 3. 架构 ![网络拓扑](https://static.pigsec.cn/wp-content/uploads/repos/cas/2b/2b2d40d9bfe92ba2ca9785960cd879c42ba5752b35d12fb517ce4051a8201db7.png) 四个区域,每个区域相互隔离,均通过单个防火墙 chokepoint 进行路由: | 区域 | 子网 | 用途 | 信任级别 | |------|--------|---------|-------------| | WAN | (NAT) | 模拟互联网 — 不受信任 | 无 | | Management | 10.10.10.0/24 | 防火墙管理 | 最高限制 | | Corporate LAN | 10.10.20.0/24 | 内部用户工作站 | 受信任 | | DMZ | 10.10.30.0/24 | 面向公众的服务(易受攻击的目标) | 不受信任的内部网络 | 防火墙是任何两个区域之间的唯一路径。区域之间没有直接连接。 ## 4. 防火墙策略(设计的核心) 以下每条规则都有明确的理由。未明确允许的所有流量,均会被每个接口底部的隐式默认拒绝规则拒绝。 | 源地址 | 目标地址 | 动作 | 理由 | |--------|-------------|--------|-----------| | Corporate | WAN | 允许 (HTTP/S, DNS) | 用户需要互联网访问权限 | | Corporate | DMZ | **拒绝** | 用户没有业务理由直接访问 DMZ | | Corporate | Management | **拒绝** | 用户绝不能接触管理平面 | | DMZ | WAN | 允许 (仅 HTTP/S) | 仅允许有限的出站更新流量;禁止其他流量 | | DMZ | Corporate | **拒绝** | 被攻破的 Web 服务器绝不能访问内部主机 | | DMZ | Management | **拒绝** | 将最高风险区域与管理平面隔离 | | WAN | DMZ | 允许 (仅 80/443 到 Web 服务器) | DMZ 存在的唯一原因 | | WAN | Corporate | **拒绝** | 内部主机绝不直接暴露在互联网上 | | WAN | Management | **拒绝** | 管理平面不可从外部访问 | | 指定的管理主机 | Management | 允许 | 只有一台主机可以管理防火墙 | 各接口的规则详情和截图位于 [`firewall-rules/`](firewall-rules/) 中。 注:第 4 部分(本部分)是预期策略;第 5 部分展示了实际实现和验证的内容。 ## 5. 验证 安全性并非“空口无凭”——每个边界都经过了测试。 ### CORP 区域 — 最小权限执行(已验证) CORP 区域允许出站互联网访问,但拒绝所有对 DMZ 和 Management 区域的访问。规则顺序至关重要:两条阻止规则位于允许规则之上,因此分段流量会在匹配到宽泛的互联网允许规则之前被捕获。 已从 CORP 工作站(Kali, 10.10.20.100)验证: | 测试 | 目标地址 | 结果 | 含义 | |------|-------------|--------|---------| | CORP → DMZ | 10.10.30.100 | 100% 丢包 | 阻止了针对暴露服务器的横向移动 | | CORP → Management | 10.10.10.1 | 100% 丢包 | 管理平面已对用户屏蔽 | | CORP → Internet | 8.8.8.8 | 有回复 | 合法的业务流量正常流通 | ![CORP 规则](https://static.pigsec.cn/wp-content/uploads/repos/cas/b8/b8f48fc4c9f749501e1c07a55c6ac72b06fc4b83f8d2cee0c2cd8204f7b1fd96.png) ![最小权限证明](https://static.pigsec.cn/wp-content/uploads/repos/cas/7f/7fc6368d487079351b37183102b73f5f135aba63d5aacfe63abf0af5744b8903.png) ### DMZ 区域 — 对被攻破主机的遏制(已验证) 威胁场景:假设攻击者已经攻破了 DMZ Web 服务器。他们能访问任何内部资源吗?DMZ 被视为敌对环境,仅被授予所需的最小出站权限。 策略:阻止 DMZ → Management 和 DMZ → CORP;仅允许出站 TCP 80/443;仅允许 DNS (UDP 53) 指向防火墙自身的解析器 (10.10.30.1),绝不允许指向开放互联网。 已从 DMZ 内部的主机(Kali, 10.10.30.101)验证: | 测试 | 路径 | 结果 | 含义 | |------|------|--------|---------| | ping 10.10.10.1 | DMZ → Management | 100% 丢包 | 攻击者无法访问管理平面 | | ping 10.10.20.1 | DMZ → CORP | 100% 丢包 | 攻击者无法以此为跳板访问工作站 | | curl -4 http://neverssl.com | DMZ → Web | 200 OK | 仅允许的出站 (Web) 流量成功 | 验证期间的重要发现: - 严格的“仅 TCP 80/443”规则也阻止了 DNS,导致 DMZ 无法解析名称。通过仅允许将 UDP 53 指向防火墙的解析器——而不是开放 DNS——解决了此问题,这可以防止 DNS 隧道数据泄露。 - 在 DNS 正常工作后,连接仍然失败,直到强制使用 IPv4 (`curl -4`)。解析器返回了一个 IPv6 地址,但规则集仅支持 IPv4,因此 IPv6 没有匹配的规则。教训:仅 IPv4 策略必须明确拒绝 IPv6,否则 IPv6 流量可能完全绕过控制措施。 ![DMZ 规则](https://static.pigsec.cn/wp-content/uploads/repos/cas/92/92c5c4ab01de89c7a1d135027438686672b2fe0b78519caf3e72e5826a3eb2e7.png) ![DMZ 遏制与出站流量](https://static.pigsec.cn/wp-content/uploads/repos/cas/54/5481f652d2c6cf93cc8354b13cba7b37f523417d3df8c1cac709ae3393cfe6e6.png) ### 检测层 — IDS (Suricata) Suricata 运行在 IDS(仅告警)模式,而不是 IPS(内联阻断)模式,以便在不承担测试期间阻断合法流量风险的情况下,安全地观察检测结果。 假定预防措施(防火墙规则)有时会失效,因此添加了检测层。Suricata(ET Open 规则集)以仅告警 (IDS) 模式部署在 DMZ 接口上,负责检查流经该接口的流量。 从被攻破的 DMZ 主机 (10.10.30.101) 对防火墙的 DMZ 接口 (10.10.30.1) 进行的 Nmap 扫描已被检测到并记录在日志中: | 特征签名 | 源地址 | 目标地址 | 结果 | |-----------|--------|-------------|--------| | ET SCAN Possible Nmap User-Agent Observed | 10.10.30.101 | 10.10.30.1 | 检测到并已记录 | 关键发现 — 传感器放置位置:早先在同一 DMZ 子网内的两台主机之间进行的扫描(Kali → Metasploitable)没有产生任何告警,因为子网内的流量根本不会经过 Suricata 监控的防火墙接口。只有发往防火墙或通过防火墙在不同区域间路由的流量才对传感器可见。这证实了 IDS 的可见性由传感器的放置位置决定,并且同一网段内主机到主机的流量属于监控盲区。 ![Suricata 运行中](https://static.pigsec.cn/wp-content/uploads/repos/cas/ff/ff2fad44c5c48b18003b06ef7b3a0a06bf59efed0fd7067113d41b2c6b6efb25.png) ![Nmap 检测](https://static.pigsec.cn/wp-content/uploads/repos/cas/d7/d756c155de7a31fbc765720403bdb4c3388cda3f9511685f5b1c4d5f53fa46ba.png) 关于告警日志的说明:截图中显示了两种不同的告警类型。四条 ET SCAN 条目是 Nmap 检测(优先信号)。其下方的 ET INFO 条目(“DHCP Request Packet 中可能包含 Kali Linux 主机名”)属于信息性质——Suricata 标记出有一台标识为 Kali 的主机在该网段请求了 DHCP 租约。这些并不是攻击;它们是碰巧经过受监控接口的低优先级背景观察结果(DHCP 会到达防火墙,因为它是 DHCP 服务器)。包含这些内容说明了一个实际的运维要点:IDS 会呈现出高优先级攻击特征和低优先级信息事件的混合结果,而有效使用 IDS 的关键之一就是区分它们。 ## 6. 经验教训 请参阅 [`lessons-learned.md`](lessons-learned.md),了解令我感到惊讶的地方、我会采取哪些不同做法,以及该设计存在的已知局限。 ## 7. 工具 | 工具 | 作用 | |------|------| | VirtualBox | 托管该实验室的 Hypervisor | | pfSense CE / OPNsense | 防火墙和路由器 | | Kali Linux | 攻击者 | | Metasploitable 2 | 存在漏洞的 DMZ 目标 | | Suricata | 入侵检测 | ## 8. 可能的扩展方向 - **隔离的 OT/ICS 区域** — 一个位于独立网段中、通过 Modbus 运行 OpenPLC 的设备,用于演示为什么工业协议(缺乏内置身份验证)需要严格的网络隔离。 - **IDS → IPS** — 将 Suricata 从仅告警升级为内联阻断。 - **集中式日志记录** — 将防火墙和 IDS 日志转发到统一的收集器以进行关联分析。
标签:Metaprompt, 入侵检测系统, 安全数据湖, 安全架构, 插件系统, 网络安全, 网络隔离, 虚拟实验室, 防火墙, 隐私保护