juanEsVg-06/pfsense-utm-network-segmentation-lab

# pfSense UTM 与网络分段实验室 #### 实施状态：已完成 #### 文档状态：进行中 #### 难度：中级 #### 类别：基础设施安全 ### 技术： - pfSense - VMware - Windows Server - IIS - Active Directory ## 项目概述 ### 目标 使用 pfSense 2.7.0 作为统一威胁管理（UTM）平台，设计并实施一个虚拟化的边缘安全环境。该项目重点关注外部和内部网段之间的安全流量调解、通过 NAT 和端口转发控制服务的暴露，以及通过实施 LAN 和 DMZ 区域来应用网络分段原则。 开发该环境旨在评估模拟企业基础设施中的边界安全控制、服务发布机制以及管理可见性。 ### 背景 在当今的防御性网络安全领域，统一威胁管理（UTM）系统充当边界安全的核心。本研究解决的核心问题是网络管理员如何在单个节点上集中管理防火墙、NAT 和入侵检测功能。本实验记录了 pfSense 2.7.0 的实施过程，用于调解外部区域（WAN）和受控网段（LAN）之间的流量，并确保 Web 服务器等关键服务的可用性。 ## 环境 ### 物理宿主机 - Lenovo Yoga Pro 9i - Windows 11 Home - VMware Workstation Pro 25H2 ### pfSense 虚拟机 - 4 GB RAM - 1 vCPU - 20 GB 虚拟磁盘 - 三个虚拟网络适配器： - VMware NAT — WAN - VMnet1 Host-only — LAN - VMnet2 Host-only — DMZ ### 客户机系统 | 系统 | 主要角色 | | ------------------- | ---------------------------------------------------------- | | pfSense 2.7.0 | 防火墙、路由器、NAT 网关和网络分段 | | Windows Server 2022 | IIS Web 服务、DNS、Active Directory 和 GPO 验证 | ### 范围与限制 - 该环境完全通过本地虚拟化部署。 - WAN 使用的是私有 VMware NAT 网络，而非真实的公共互联网连接。 - IDS/IPS 功能未在此阶段实施。 - 高可用性仅在概念上进行了评估，但并未部署为真正的冗余 pfSense 集群。 - 某些企业服务是在数量有限的虚拟机内模拟的，而不是分离部署在专用的生产级服务器上。 - 该环境专为受控的学术测试而设计，不应将其解释为生产就绪的架构。 ## 网络拓扑 ### 架构概述 该环境围绕一个集中式 pfSense 设备设计，负责控制 WAN、LAN 和 DMZ 网段之间的流量。 第一阶段使用双区域 WAN/LAN 架构。随后通过添加专用的 DMZ 来扩展环境，以承载对外发布的 IIS Web 服务。 pfSense 负责管理数据包过滤、路由、NAT 转换、端口转发和防火墙日志记录。Windows Server 2022 提供了验证所需的内部及发布的企业服务。 ### 网络网段 | 区域 | 用途 | | ---- | ------------------------------------------------ | | WAN | 模拟外部网络，代表互联网连接 | | LAN | 受保护的内部网络，包含可信资源和管理服务 | | DMZ | 承载可公开访问服务的隔离网络网段 | ### IP 地址分配 | 组件 | 接口或区域 | 地址 | 用途 | | ------------------ | ---------------- | ---------------- | ----------------------- | | VMware NAT Network | WAN | 192.168.222.0/24 | 模拟外部网络 | | pfSense | WAN | 192.168.222.137 | 对外的防火墙接口 | | pfSense | LAN | 192.168.1.1/24 | LAN 网关 | | 初始 IIS Server | LAN | 192.168.1.2/24 | 初始内部 Web 服务 | | pfSense | DMZ | 172.16.1.1/24 | DMZ 网关 | | IIS Server | DMZ | 172.16.1.2/24 | 最终发布的 Web 服务 | ## 应用的安全原则 ### 纵深防御 通过网络分段、状态数据包过滤、NAT、特定服务规则和防火墙日志记录应用了多层安全防护。 ### 网络分段 LAN 和 DMZ 被放置在不同的网络网段中，以减少面向公众的系统与受信任系统之间不受限制的横向移动的可能性。 ### 最小权限原则 WAN 仅允许已发布的 Web 服务所需的协议和端口。 ### 受控服务暴露 IIS 服务通过特定的端口转发规则进行暴露，而不是授予对内部网络的直接外部访问权限。 ### 默认拒绝策略 未被适用防火墙规则明确允许的流量将被 pfSense 阻止。 ### 管理可见性 通过 pfSense 系统日志审查了防火墙事件和被阻止的连接，以验证规则行为。 ## 实施过程 ### 安装 在 VMware Workstation Pro 中为 pfSense 2.7.0 创建了一个专用虚拟机。 该虚拟机配置了 4 GB RAM、一个虚拟 CPU、20 GB 虚拟磁盘以及两个用于 WAN 和 LAN 连接的初始虚拟网络适配器。pfSense ISO 镜像被挂载为虚拟安装介质。 在安装过程中，配置了 GPT 分区布局和 UFS 根文件系统。安装完成后，卸载了 ISO 并从虚拟磁盘重新启动虚拟机。 随后添加了第三个虚拟网络适配器，以支持专用的 DMZ 网段。 ### 初始配置 首次启动后，pfSense 检测到了 WAN 和 LAN 接口。 WAN 接口通过 VMware NAT 网络中的 DHCP 获取了地址 `192.168.222.137`。LAN 接口被静态配置为 `192.168.1.1/24`。 WebGUI 设置向导用于配置以下内容： - 主机名：`pfSense-VJuan` - 主 DNS 服务器：`8.8.8.8` - 辅助 DNS 服务器：`1.1.1.1` - LAN 寻址 - 管理访问参数 由于模拟 WAN 使用的是 RFC1918 私有地址，因此在此实验室环境中，阻止 WAN 接口上的私有网络的选项被禁用。 在故障排除期间，临时从 pfSense 控制台使用了命令 `pfctl -d` 来禁用 Packet Filter 并恢复 WebGUI 访问。 此命令会完全禁用防火墙过滤，因此构成了重大的安全风险。它只能在隔离的实验室中临时使用，并应在解决管理访问问题后立即重新启用 Packet Filter。 ### 接口配置 最终架构使用了三个逻辑接口： | 接口 | VMware 网络 | 地址 | 功能 | | --------- | ---------------- | --------------- | -------------------- | | WAN | NAT | 192.168.222.137 | 外部连接 | | LAN | VMnet1 Host-only | 192.168.1.1/24 | 受信任的内部网络 | | DMZ | VMnet2 Host-only | 172.16.1.1/24 | 公共服务网段 | 在初始阶段，Windows Server 2022 配置为： - IP 地址：`192.168.1.2/24` - 默认网关：`192.168.1.1` - DNS 服务器：`192.168.1.1` 在 DMZ 阶段，发布的 IIS 服务被移动到： - IP 地址：`172.16.1.2/24` - 默认网关：`172.16.1.1` 这需要更新现有的 NAT 和端口转发配置，以引用新的 DMZ 地址。 ### 防火墙规则 创建了防火墙规则以控制 WAN、LAN 和 DMZ 之间的流量。 WAN 规则仅允许发往 IIS 服务已发布外部端口的 TCP 流量。未授权任何常规的 WAN 到 LAN 访问。 DMZ 遵循对 LAN 的默认拒绝方法。除非存在明确的规则，否则不允许源自公共服务网段的流量到达受信任的内部资源。 这些规则旨在： - 限制对所需 Web 服务的外部暴露。 - 阻止从 DMZ 到 LAN 的不受限制的访问。 - 保留对允许连接的状态检测。 - 在需要时为被阻止和允许的流量生成日志。 ### NAT 配置 pfSense 在 VMware WAN 网络和内部网段之间执行地址转换。 该项目通过端口转发使用了目标 NAT。这允许将发往 pfSense WAN 接口上特定端口的流量进行转换并转发到 IIS 服务器。 在实验室期间，NAT 反射在纯 NAT 模式下被启用，以允许内部客户端使用 WAN 地址测试已发布的服务。 此配置是为了方便测试，在将其部署到生产环境之前应仔细评估。 ### 端口转发 初始规则如下转发流量： ``` WAN address: TCP/81 ↓ 192.168.1.2:80 ``` 在将 IIS 服务移至 DMZ 后，规则被更新为： ``` WAN address: TCP/81 ↓ 172.16.1.2:80 ``` 端口 `81` 被用作外部监听端口，而 IIS 在内部继续监听标准的 HTTP 端口 `80`。 该规则限于 TCP 流量，并与相应的 WAN 防火墙许可相关联。 此配置代表了端口地址转换和端口转发。它不是一对一的 NAT 映射。 ### 附加服务 #### Internet Information Services IIS 安装在 Windows Server 2022 上，并托管了用于验证外部服务发布的 `Pentesting Phase Manager` Web 应用程序。 #### Active Directory 和 DNS 在实验室的企业导向阶段，使用 Windows Server 2022 评估了 Active Directory Domain Services 和内部 DNS 功能。 #### 组策略 使用组策略对象自动映射共享网络资源，演示了集中化的配置管理。 #### 防火墙日志记录 审查了 pfSense 防火墙日志，以识别被阻止的流量、验证默认拒绝行为，并在 IIS 服务移至 DMZ 后对连接进行故障排除。 ## 验证与测试 ### 测试矩阵 | ID | 测试 | 过程 | 预期结果 | 观察结果 | 状态 | | --- | ---------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------- | ------ | | T01 | 接口检测 | 安装后检查 pfSense 控制台和仪表板 | WAN 和 LAN 接口被正确检测和分配 | WAN 通过 DHCP 接收到 `192.168.222.137`，LAN 被分配了 `192.168.1.1/24`| 通过 | | T02 | 初始 LAN 连接 | 为 Windows Server 配置 `192.168.1.2/24`、网关 `192.168.1.1`并连接至 VMnet1 | 服务器通过 pfSense 作为其默认网关进行通信 | Windows Server 成功连接到受保护的 LAN 网段 | 通过 | | T03 | 初始服务发布 | 从外部主机访问 `http://192.168.222.137:81` | pfSense 将 TCP/81 转发至 `192.168.1.2:80` | 托管在 IIS 上的 Pentesting Phase Manager 应用程序成功显示 | 通过 | | T04 | DMZ 分段行为 | 在更新现有的端口转发规则之前，将发布的服务器移至 `172.16.1.2/24` | 以前的发布规则不再到达服务器 | 外部访问停止，防火墙日志记录了被阻止的流量 | 通过 | | T05 | 默认拒绝验证 | 在 DMZ 迁移后检查 `Status > System Logs > Firewall` | 未许可的流量被阻止并记录 | 观察到与默认 IPv4 拒绝规则相关联的多个条目 | 通过 | | T06 | 更新的 DMZ 发布 | 将端口转发目标更新为 `172.16.1.2:80`，并将网关/DNS 配置为 `172.16.1.1` | 通过 DMZ 恢复对 TCP/81 的外部访问 | 配置更新后成功显示 Web 应用程序 | 通过 | | T07 | 集中资源部署 | 配置 GPO 以将驱动器 `Z:` 映射到共享资源 | 通过组策略部署配置的网络资源 | 驱动器映射策略已创建并与共享路径关联 | 通过 | ### 测试范围 验证重点是功能连接性、网络分段、防火墙执行、端口转发行为和管理可见性。 在此实施过程中，未记录正式的吞吐量、延迟、丢包、RTO、RPO 或可用性测量结果。因此，结果必须被解释为定性的功能验证，而不是性能基准。 ## 结果 ### 初始 WAN 到 LAN 的发布 第一次实施成功暴露了 IIS Web 应用程序，而无需授予对整个内部网络的直接访问权限。 到达 pfSense WAN 地址上 TCP 端口 `81` 的流量被转换并转发到位于 `192.168.1.2` 的 Windows Server 实例上的 TCP 端口 `80`。 Pentesting Phase Manager 应用程序的成功显示证实了- 端口转发规则匹配了预期的流量。 - 关联的 WAN 防火墙许可已生效。 - Windows Server 使用 pfSense 作为其默认网关。 - 内部服务器地址未直接暴露给外部网段。 ### DMZ 迁移与默认拒绝行为 在将发布的服务从 LAN 移至 DMZ 地址 `172.16.1.2` 后，外部访问停止，因为以前的 NAT 目标和网络参数不再有效。 这种中断是预期的安全行为，而不是应用程序故障。防火墙日志显示，没有匹配许可规则的流量被默认拒绝策略丢弃。 这验证了以下几点： - 网络网段是独立控制的。 - 在服务移动到另一个区域后，不会自动继承现有的访问权限。 - 新的流量路径需要明确的配置。 - 防火墙日志提供了有用的故障排除和审计信息。 ### 恢复的服务发布 端口转发目标已更新为 DMZ 服务器地址，并调整了服务器网关和 DNS 配置以使用 `172.16.1.1`。 应用这些更改后，通过 `http://192.168.222.137:81` 的访问已成功恢复。 最终结果演示了通过特定协议和端口对托管在 DMZ 中的服务进行受控发布，同时保持了与受信任 LAN 网段的隔离。 ### 身份与策略管理验证 在实验室的企业服务阶段，对 Active Directory、DNS、共享资源配置和组策略进行了评估。 创建了一个 GPO 来自动将驱动器 `Z:` 映射到共享网络资源。这演示了集中管理和基于策略的资源部署。 由于实验室使用的虚拟机数量有限，因此未完全验证 Domain Controller 与面向公共的 IIS 服务器之间的永久角色分离。面向生产的实施会将这些功能部署在不同的系统和安全区域中。 ## 视觉证据 ### 1. 运行中的 pfSense 接口 pfSense 仪表板确认 WAN、LAN 和 DMZ 接口已启用并正常运行。 最终的接口地址分配为： * WAN: `192.168.222.137` * LAN: `192.168.1.1/24` * DMZ: `172.16.1.1/24` 流量图表还提供了对通过 WAN 和 DMZ 接口的活动可见性。  ### 2. 端口转发规则 在 WAN 接口上配置了目标 NAT 和端口转发规则。 该规则接收外部端口 `81` 上的 TCP 流量，并将其重定向到位于 `172.16.1.2:80` 的 DMZ 中托管的 IIS Web 服务。 出于测试目的，在纯 NAT 模式下启用了 NAT 反射，并创建了关联的防火墙规则以允许匹配的流量。  ### 3. 外部服务验证 通过 pfSense WAN 地址成功访问了 IIS 托管的 Pentesting Phase Manager 应用程序： ``` http://192.168.222.137:81 ``` 此结果确认了以下各项的功能运行： * 端口转发规则。 * 关联的 WAN 防火墙许可。 * WAN 和 DMZ 之间的路由。 * TCP 端口 `80` 上的 IIS Web 服务。 * DMZ 服务器网关配置。 浏览器将连接识别为不安全，因为该服务是通过 HTTP 而不是 HTTPS 发布的。传输加密仍然是未来的改进方向。  ### 4. DMZ 接口配置 在 pfSense 中使用静态 IPv4 寻址启用了专用的 DMZ 接口。 该接口被分配为： ``` Interface: DMZ IPv4 address: 172.16.1.1/24 Upstream gateway: None ``` 该接口充当面向公共的服务器网段的默认网关。  ### 5. 默认拒绝防火墙日志记录 pfSense 防火墙日志记录了被默认 IPv4 拒绝规则拒绝的流量。 显示的事件包括源自 DMZ 服务器 `172.16.1.2` 发往 pfSense DMZ 接口上服务的流量，包括寻址到 `172.16.1.1:53` 的 DNS 流量。 此证据表明，没有明确匹配许可规则的流量将被拒绝并记录以供管理审查。 其本身不应被解释为特定 DMZ 到 LAN 阻止测试的证明，因为显示的目标是 pfSense DMZ 接口。  ### 6. 组策略资源部署 配置了名为 `GPO_Despliegue_Recursos` 的组策略对象，以将驱动器 `Z:` 映射到共享网络资源： ``` \\192.168.1.2\Publico ``` 此配置演示了在实验室的企业服务阶段，通过 Active Directory 和组策略进行的集中资源部署。  ## 安全发现与限制 |发现|相对严重程度|影响|建议的补救措施| |---|---|---|---| |使用 `pfctl -d` 临时禁用了 Packet Filter|高|禁用防火墙执行，可能暴露所有可访问的服务|使用基于 LAN 的管理，验证防锁定规则，更正接口分配，并在故障排除后立即重新启用过滤| |在实验室期间保留了默认管理凭据|高|如果接口变得可访问，则允许未经授权的管理访问|在启用正常连接之前，将默认凭据替换为唯一的强密码| |通过未加密的 HTTP 发布 IIS 服务|中|应用程序流量在传输过程中可能被观察或修改|使用受信任或实验室证书实施 HTTPS，并将 HTTP 重定向到 HTTPS| |公共和身份管理角色未永久分离|中|Web 角色受损可能会影响域或管理服务|将 IIS 和 AD DS 部署在单独的虚拟机上，并将 Domain Controller 专门保留在 LAN 中| |无 IDS/IPS 实施|中|恶意流量仅通过防火墙规则过滤，没有基于签名的检测|集成 Suricata 或 Snort，并定义告警和调优程序| |无集中化日志收集|中|事件保持分散状态，难以关联|将 pfSense 和 Windows 日志转发到 SIEM 或集中式 syslog 平台| |使用外部端口 `81` 代替 `80`|信息|更改服务入口点，但其本身并不能提供有意义的安全性|将非标准端口视为一种操作选择，而不是安全控制| ## 经验教训 ### 获得的技术知识 - 了解 pfSense 如何执行状态数据包过滤和目标 NAT。 - 实施了具有不同外部和内部端口之间转换的端口转发。 - 在虚拟化环境中配置了 WAN、LAN 和 DMZ 接口。 - 在网络网段之间应用了默认拒绝方法。 - 使用防火墙日志分析被阻止的连接并排查路由问题。 - 强调了正确的 IP 地址、网关、DNS 和网络适配器配置的重要性。 - 使用 Windows Server 2022 评估了集中式身份、DNS 和组策略概念。 - 区分了功能性服务发布与完整的生产级安全架构。 ### 遇到的挑战 #### WebGUI 访问 对 pfSense WebGUI 的管理访问最初受到防火墙和接口配置的影响。通过 `pfctl -d` 临时禁用了 Packet Filter 以恢复访问。 虽然这允许故障排除继续进行，但它也消除了防火墙执行，构成了重大的安全风险。 #### 外部端口冲突 在实验室中，外部使用 TCP 端口 `80` 未按预期运行。因此，选择 TCP 端口 `81` 作为外部监听端口，而 IIS 继续监听 TCP 端口 `80`。 #### 服务迁移到 DMZ 将服务器从 `192.168.1.2` 移至 `172.16.1.2` 导致现有的发布规则无效。服务器还需要新的默认网关和 DNS 配置。 #### 架构限制 有限的虚拟机数量限制了演示公共 Web 服务器和身份管理服务之间永久分离的能力。 ### 应用的解决方案 - 从控制台和 WebGUI 查看了 pfSense 接口和防火墙行为。 - 仅将临时 Packet Filter 停用用作故障排除机制。 - 通过映射 `WAN TCP/81 → internal TCP/80` 发布了 Web 服务。 - 为 DMZ 添加了第三个 VMware 网络适配器。 - 将 DMZ 网关配置为 `172.16.1.1/24`。 - 将端口转发目标更新为 `172.16.1.2`。 - 更新了 Windows Server 网关和 DNS 配置。 - 查看了防火墙日志以识别默认拒绝事件。 - 在每次架构更改后重新验证了外部 HTTP 访问。 ## 关键要点 - 防火墙规则和 NAT 规则解决相关但不同的要求，必须连贯配置。 - 在安全区域之间移动服务需要检查寻址、路由、DNS、NAT 和防火墙策略。 - 默认拒绝行为是一种安全控制，最初可能会表现为连接故障。 - 防火墙日志对于区分路由、转换和策略执行问题至关重要。 - 只有在公共和受信任角色托管在不同的系统上时，DMZ 才能提供有意义的隔离。 - 非标准端口不能替代身份验证、加密、过滤或系统强化。 - 专业文档必须记录限制和不安全的故障排除决定，而不仅仅是成功的结果。 ## 未来改进 ### 架构 - 将 Domain Controller、DNS 服务和 IIS Web 服务器分离到专用虚拟机中。 - 将 Domain Controller 保留在受信任的 LAN 中，将 IIS 服务器专门保留在 DMZ 中。 - 添加专用的管理工作站或管理网络。 - 开发并包含正式的网络拓扑图。 ### 安全 - 替换所有默认凭据。 - 使用基于证书的加密实施 HTTPS。 - 添加 Suricata 或 Snort 以实现 IDS/IPS 功能。 - 从 DMZ 应用显式的出站规则。 - 将集中式日志记录与 SIEM 或 syslog 平台集成。 - 对 DMZ 服务执行漏洞扫描。 - 记录正式的防火墙规则审查流程。 ### 可用性 - 部署第二个 pfSense 节点并评估基于 CARP 的高可用性。 - 添加冗余 IIS 服务器和反向代理或负载均衡器。 - 定义并测量 RTO、RPO、正常运行时间、延迟和丢包指标。 - 实施经过测试的备份和恢复程序。 ### 远程访问 - 部署 VPN 以实现安全的管理访问。 - 将 WebGUI 管理限制为受信任的管理地址。 - 评估基于证书的身份验证和多因素身份验证。 ## 参考资料 - Netgate. _pfSense Documentation_. - Microsoft Learn. _Windows Server 2022, Active Directory Domain Services, DNS, IIS, and Group Policy Documentation_. - VMware. _VMware Workstation Pro Documentation_. - Sol Llaven, D. _Sistemas operativos: panorama para la ingeniería en computación e informática_. - Tanenbaum, A. S. _Sistemas operativos modernos_.

标签：pfSense, Terraform 安全, Windows Server, 网络安全, 网络架构, 网络隔离, 防火墙, 隐私保护