Windows 防火墙与 IPsec 策略虽然强大，但在大规模终端管理或域环境下，组策略才是实现标准化、强制化端口封堵的最有效手段。我们直接面对的核心问题是：攻击者常常利用 135、139、445、3389 等高危端口进行横向移动或暴力破解，仅仅在单机上开启防火墙不够，必须通过组策略将“拒绝入站连接”的规则锁定，防止用户或恶意软件自行修改。下面直接进入具体的配置逻辑与操作步骤。
明确需要封堵的高危端口清单在动手之前，必须清楚哪些端口是当前威胁环境中风险最高的。这不仅是技术列表，更是安全策略的基线。对于运行 Windows 操作系统的终端，以下端口的入站流量应被严格限制，除非有明确的业务依赖且经过审批：
135 (TCP)：RPC 端点映射服务。这是勒索病毒和内网蠕虫最爱利用的端口之一，用于远程调度和命令执行。除非终端作为域控制器或 Exchange 服务器，否则普通客户端和多数服务器应直接封堵。
137、138 (UDP) 和 139 (TCP)：NetBIOS 名称服务和会话服务。这些端口负责传统的文件和打印机共享，但在现代网络中，它们是网络扫描和漏洞利用的重灾区。禁用 NetBIOS over TCP/IP 并封堵这些端口能有效阻断基于网络邻居的横向发现。
445 (TCP)：SMB over TCP。这是永恒之蓝等历史级漏洞的利用通道，也是勒索软件传播的核心途径。除非是文件服务器，否则入站 445 必须关闭。
3389 (TCP)：远程桌面协议。将 RDP 直接暴露在不可信网络中是极其危险的行为，暴力破解攻击从未停止。即使需要远程管理，也应通过堡垒机或零信任方案，而非直接开放入站 3389。
22 (TCP)：虽然 Windows 原生不开启 SSH，但部分开发环境或安装了 OpenSSH 服务的服务器会监听此端口，同样面临暴力破解风险。
5985、5986 (TCP)：WinRM 和 WinRM over HTTPS。这是 PowerShell 远程管理的通道，权限极高，必须严格控制入站来源。
1433 (TCP) 和 3306 (TCP)：SQL Server 和 MySQL 默认端口。数据库端口绝不应直接暴露给终端用户所在的网络段，入站流量必须限制在特定的应用服务器 IP 范围内。
组策略配置防火墙规则的核心路径不要直接在本地安全策略中操作，那不具备可扩展性。在域控制器上，通过“组策略管理控制台”创建或编辑作用于目标计算机的 GPO。导航路径为：计算机配置 -> 策略 -> Windows 设置 -> 安全设置 -> 高级安全 Windows 防火墙 -> 高级安全 Windows 防火墙。在这里，我们将定义入站规则，策略要比“阻止”更彻底，直接选择“阻止连接”。
创建标准化高危端口封堵规则集这里不推荐为每个端口单独创建一条规则，那样会导致规则列表臃肿且难以维护。更高效的做法是将同类风险端口归组，创建复合规则。但考虑到 Windows 防火墙规则的可读性和排错便利性，建议按服务类型分组创建规则。以下是具体步骤：
右键点击“入站规则”，选择“新建规则”。规则类型选“端口”，协议选“TCP”，并输入特定端口，例如 “135, 139, 445, 3389, 5985, 5986”。注意，多个端口用英文逗号隔开，不要加空格。在“操作”步骤中，务必选择“阻止连接”。在“配置文件”步骤中，将“域”、“专用”、“公用”全部勾选，确保无论计算机连接到何种网络环境，此规则都强制生效。最后为规则命名，例如 “Block_High_Risk_TCP_Inbound”，并在描述中注明封堵原因和例外审批流程。
对于 UDP 端口，需要另外新建一条规则。协议选“UDP”，端口输入 “137, 138”。同样选择“阻止连接”，并应用到所有配置文件。命名可以是 “Block_NetBIOS_UDP_Inbound”。
编写精确的 PowerShell 脚本用于 GPO 即时任务或本地强化在某些场景下，可能需要在没有域环境的独立服务器上执行，或者通过组策略的启动脚本强制执行。以下脚本能精确创建防火墙规则，且具备幂等性，即多次执行不会产生重复规则。
# 定义需要封堵的高危 TCP 端口
$HighRiskTCPPorts = "135", "139", "445", "3389", "5985", "5986", "1433", "3306"
# 定义需要封堵的高危 UDP 端口
$HighRiskUDPPorts = "137", "138"
# 循环创建 TCP 阻止规则
foreach ($Port in $HighRiskTCPPorts) {
$RuleName = "Block_HighRisk_Port_${Port}_TCP_Inbound"
# 检查规则是否已存在，避免重复创建
if (-not (Get-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName $RuleName `
-Direction Inbound `
-Protocol TCP `
-LocalPort $Port `
-Action Block `
-Profile Any `
-Description "Security hardening: Block inbound TCP $Port to prevent lateral movement and exploitation."
}
}
# 循环创建 UDP 阻止规则
foreach ($Port in $HighRiskUDPPorts) {
$RuleName = "Block_HighRisk_Port_${Port}_UDP_Inbound"
if (-not (Get-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName $RuleName `
-Direction Inbound `
-Protocol UDP `
-LocalPort $Port `
-Action Block `
-Profile Any `
-Description "Security hardening: Block inbound UDP $Port to prevent NetBIOS name service exploitation."
}
}
这段脚本逻辑清晰，每个端口独立生成一条规则，方便日后审计和排查。通过组策略的“启动脚本”下发此 PowerShell 脚本，可以在计算机每次启动时强制执行端口封堵策略，覆盖任何被意外修改的本地防火墙配置。
通过组策略直接部署防火墙规则的首选方式虽然脚本很灵活，但在域环境中，最规范的方式是直接在组策略编辑器中配置防火墙策略。这种方式不需要依赖 PowerShell 执行策略，且规则在 GPO 刷新间隔自动生效和修复。配置路径为：计算机配置 -> 策略 -> Windows 设置 -> 安全设置 -> 高级安全 Windows 防火墙 -> 入站规则。在此处新建规则，操作与本地相同，但优势在于，这些规则会显示在客户端防火墙的“由组策略设置”区域，本地管理员无法修改或删除，实现了真正的强制管控。
配置完成后，在客户端执行
gpupdate /force并重启防火墙服务或计算机，规则即会生效。可以通过
netsh advfirewall firewall show rule name=all或查看“高级安全 Windows 防火墙”监控节点来验证规则是否已应用。 处理业务例外与精细化的访问控制
全盘封堵端口是一种理想状态，现实中总有服务器需要对外提供 SMB 或 RDP 服务。此时，绝不能因为业务需求而放弃整条阻止规则，而应创建优先级更高的“允许”规则，并严格限定远程 IP 地址段。在组策略中，规则的顺序至关重要，Windows 防火墙按规则顺序处理，先匹配的规则生效。
例如，某台文件服务器需要向特定子网 “192.168.10.0/24” 提供 SMB 服务。我们应首先创建一条允许规则：协议 TCP，端口 445，操作“允许连接”，在“作用域”步骤中，将远程 IP 地址设置为 “192.168.10.0/24”。然后将这条允许规则移动到之前创建的 “Block_High_Risk_TCP_Inbound” 规则之上。这样，来自信任子网的 445 流量会被允许，而其他所有来源的 445 流量仍会被下方的阻止规则拦截。这种“白名单”思维是端口安全的核心。
验证与审计：确保规则真正生效策略部署下去不等于安全已经达成，验证是必须的环节。在目标计算机上，使用命令
netstat -an | findstr LISTENING检查是否还有高危端口在监听。即使防火墙阻止了入站连接，如果服务本身仍在运行，端口依然会处于监听状态，这本身也构成信息泄露风险。理想的做法是，结合组策略中的“系统服务”禁用不必要的服务，例如将 “Server” 服务（对应 SMB 445）设置为禁用，将 “Remote Desktop Services” 设置为禁用，从根源上关闭端口。
端口扫描是最终的验证手段。从同网段的另一台计算机，使用 PowerShell 的
Test-NetConnection命令进行探测。例如，执行
Test-NetConnection -ComputerName TargetIP -Port 445，结果应为 “False” 或 “失败”。如果显示 “True”，则必须回头检查 GPO 的应用顺序、是否有冲突的本地规则，以及目标计算机是否在正确的组织单位中。 将端口封堵与 IPsec 连接安全规则结合
对于极其敏感的环境，单纯的端口阻止还不够。攻击者可能利用已授权的端口进行隧道通信。此时，可以在组策略的“连接安全规则”中配置 IPsec，要求特定端口的入站连接必须进行身份验证或加密。例如，对于必须开放的 WinRM 5985 端口，可以创建一条连接安全规则，要求入站连接使用 Kerberos 身份验证。这样，即使端口在防火墙上开放，未经域认证的计算机也无法建立连接。这属于纵深防御的高级实践，能显著提升内网横向移动的难度。
持续维护与策略迭代安全是动态的，高危端口的列表也会随着新漏洞的披露而变化。例如，WannaCry 之后 445 成为焦点，而 PrintNightmare 漏洞又让打印服务相关的 RPC 端口风险升级。因此，必须建立定期审查机制，每季度或每次重大漏洞公告后，重新评估当前封堵的端口列表是否需要扩充。组策略的中央管理特性让这种更新变得高效，只需修改一条 GPO 中的规则，所有受管计算机在下一个刷新周期就会自动应用新的策略，无需逐台操作。
最终，通过组策略限制高危端口的入站流量，本质上是在网络边界防火墙之内，构建起主机层面的最后一道防线。它解决了内网东西向流量缺乏管控的痛点，是安全基线建设的基石性工作。
