Windows服务器3389端口防暴破：用IPSec策略实现精准IP白名单访问控制

说来也巧，前阵子帮朋友处理一台被爆破的Windows Server，登录日志里密密麻麻全是3389的失败尝试，看时间间隔就知道是脚本在跑字典。远程桌面端口一旦暴露在公网，被扫描和暴破几乎就是家常便饭。很多人的第一反应是改端口号，但这只是降低了被扫描到的概率，治标不治本；还有人会在防火墙上加IP白名单，可一旦防火墙策略被误改成放行，同样等于裸奔。这次我分享一个经常被低估、但效果非常扎实的方案：用Windows自带的IPSec策略，对3389端口做基于源IP的精准访问控制。不需要装任何第三方工具，纯系统原生功能，就能实现“只有白名单里的IP能连远程桌面，其他流量全部丢弃”的效果。很适合Windows服务器运维、等保整改、以及想给RDP端口加一道硬锁的朋友参考。

1. 为什么选IPSec做3389端口访问控制

1.1 3389端口为什么会被盯上

做过公网业务运维的朋友应该都有体会，只要服务器安全组放行了3389，不出半天，登录日志里就会出现大量来自世界各地IP的连接尝试。原因很简单：3389是Windows远程桌面的默认端口，扫描器根本不需要猜，扫到开放的3389就直接上字典跑密码。

3389端口被盯上，本质上是三件事叠加的结果：

• 端口固定且知名，扫描成本极低；
• RDP服务本身的认证入口面向网络开放，只要密码够弱就存在被爆破成功可能；
• 很多管理员习惯用Administrator账号直接登录，又没有配置账户锁定策略，字典可以无限跑。

常见的应对手段各有各的短板。修改默认端口，比如从3389改成8888，确实能避开大多数“无脑扫3389”的脚本，但高级扫描器照样能通过指纹识别找到RDP服务，而且改端口本身会给日常运维增加记忆成本。用防火墙做IP白名单，比如Windows防火墙或云安全组，比改端口靠谱，但这类策略通常属于“平台级”配置，一旦网络层面策略被覆盖或误改，主机本身没有兜底能力。账号锁定策略能提高爆破成本，但前提是你敢在生产环境启用，锁了别人的账号也是个麻烦事。

在这时候，IPSec策略就体现出独特的价值：它运行在主机系统内部，做的是网络栈层面的端口和地址匹配，不依赖任何外部设备或第三方软件，天然适合作为主机侧的“最后一道门”。

1.2 IPSec策略和Windows防火墙到底什么关系

先理清一个概念。我们常说的IPSec，全称Internet Protocol Security，是IP层的一个安全协议框架。在Windows系统里，它被封装成了“IP安全策略”（IP Security Policy），可以通过本地安全策略管理单元或组策略来配置。

IPSec策略做的事情，是对进入和离开本机的IP数据包做匹配：源IP是谁、目标IP是谁、走什么协议、访问哪个端口、要不要加密或签名，只要命中匹配规则，就可以执行“许可”、“阻止”或“协商安全”的动作。

很多人会问：Windows防火墙也能做端口过滤，为什么还要用IPSec？我列个对比表：

从这个表能看出，IPSec策略更适合做“基于源地址的精细准入控制”：你完全可以配置成只允许某个固定IP访问本机3389，其余IP全部丢弃。而Windows防火墙虽然也能配置指定IP，但它的强项在于按程序、按端口做常规过滤，两者可以配合，并不冲突。

1.3 这套方案适合谁、不适合谁

先说适合的场景。第一种是内网服务器没有硬件防火墙，或者云安全组粒度不够细，需要在主机层面做源IP白名单；第二种是等保测评、安全加固整改时，测评项明确要求“对3389等远程管理端口进行访问控制”，IPSec策略可以作为一个标准加固项来应对；第三种是AD域环境，管理员希望把访问控制策略通过GPO批量下发给所有服务器，这样就不用一台台去点。

不适合的场景也要说实话。如果业务前面已经有成熟的云安全组或硬件防火墙，并且已经做了源IP白名单，那完全没必要在主机里再叠一套IPSec，维护成本会增加。另外，IPSec解决的是网络层访问控制，如果业务被应用层攻击（比如针对RDP协议的漏洞利用），这不是IPSec的职责范围，还需要配合补丁更新和入侵检测。

我的建议是：把IPSec策略当成纵深防御的一环，而不是唯一的救命稻草。上层有防火墙做粗粒度隔离，主机内部再用IPSec做细粒度兜底，这种组合在实战中最稳。

2. 配置前必须搞懂的几个核心概念

2.1 IP安全策略、IP筛选器列表、筛选器操作三件套

第一次打开IPSec配置界面的人，很容易被“IP安全策略”“IP筛选器列表”“筛选器操作”这几个术语绕晕。我打个比方：IP安全策略是一份“门禁管理规定”，IP筛选器列表是“访客登记台账”，筛选器操作则是“保安的处置动作”。

• IP安全策略（IP Security Policy）：是整个配置的容器，一个策略里面可以包含多条规则；
• IP筛选器列表（IP Filter List）：用来描述“我要管什么样的流量”，比如“从192.168.1.100访问本机3389端口的TCP流量”；
• 筛选器操作（Filter Action）：匹配之后怎么办，有三个选项——许可（Permit）、阻止（Block）、协商安全（Negotiate Security）。

理解这个三层结构，后面配置就不会迷路。顺便提一句，做端口访问控制时，我们通常只需要“许可”和“阻止”两种操作，不涉及协商安全，因为协商安全面向的是需要加密通信的场景，单纯做白名单准入用不上。

2.2 白名单模型和黑名单模型的取舍

访问控制有两种建模思路。

黑名单模型是“默认放行，只封指定的IP”，适合需要封禁少数恶意来源的场景。但它的隐患很大：你永远不知道下一个恶意IP是谁，只要有一个漏网的IP进来，3389依然暴露在所有扫描器面前。

白名单模型是“默认拒绝，只放行白名单里的IP”，这是我在生产环境里强烈推荐的思路。配置思路是两条规则：

1. 允许规则：源IP=白名单IP，目标IP=本机IP，目标端口=3389，动作=许可；
2. 阻止规则：源IP=任何IP，目标IP=本机IP，目标端口=3389，动作=阻止。

这两条规则的先后顺序非常关键。IPSec策略里，规则按列表顺序从上到下匹配，命中第一条就不再往下走。所以“允许白名单”这条规则必须排在“阻止所有”前面，否则白名单IP也会被后面的阻止规则拦死。这个细节我在实操中见过太多人栽跟头，后面会专门讲。

2.3 方向错一个，整个配置就废了

新手配置3389访问控制时最容易犯的错误，是把源端口和目标端口搞反。

RDP连接的数据包从外部客户端发往服务器，方向是“入站”：包的源IP是客户端IP，源端口是客户端随机分配的高端口（比如50123）；目标IP是服务器IP，目标端口是3389。所以在创建IP筛选器时，应该是：

• 源地址：白名单IP或“任何IP”；
• 目标地址：本机IP地址；
• 协议类型：TCP；
• 源端口：从任意端口；
• 目标端口：到此端口3389。

如果有人在“源端口”里填3389，那就完全错了，因为客户端发起连接时源端口根本不是3389，这会导致筛选器永远匹配不上，规则形同虚设。

还有一个容易被忽略的选项：创建IP筛选器时，向导会问你是否“镜像”数据包。镜像的意思是把源和目标互换后也视为匹配。对RDP入站控制来说，不应该勾选镜像，因为一旦勾上，本机发往其他机器的3389出站流量也会被匹配，可能会影响本机作为客户端去连其他远程桌面的场景。

3. 实操：一步步配置3389端口精准访问控制

3.1 打开本地安全策略管理单元

首先，在Windows服务器或Windows 10/11专业版上，打开本地安全策略管理单元。按Win+R，输入secpol.msc回车，会打开“本地安全策略”窗口。左侧导航里找到“IP安全策略，在本地计算机”，右键单击这个节点，选择“创建IP安全策略”。

如果系统提示“IP安全策略”节点不存在，多刷新几次，或者确认当前系统版本支持该功能。域控环境下默认可能由组策略管理，但本地策略的入口依然存在。

3.2 创建IP安全策略

在弹出的向导里，点击“下一步”，给策略起个名字，比如“RDP-Access-Control”，描述可以写“仅允许指定IP访问3389端口”。

向导中间会有一个页面询问“默认响应规则”，果断取消勾选。默认响应规则是给不支持IPSec的计算机通信用的，在纯访问控制场景里不需要，勾上反而可能引入不必要的网络协商请求。

完成后，策略会出现在右侧列表里，但此时还是“未指派”状态，先别急，接下来要往策略里添加两条规则。

3.3 添加“放行指定IP”筛选器

双击刚创建的策略，打开策略属性窗口。在“规则”标签页里，点击“添加”按钮，会弹出“安全规则向导”。

第一步先不配隧道，保持默认的“此规则不指定隧道”。网络类型选择“所有网络连接”，这样可以覆盖所有网卡。下一步进入“IP筛选器列表”页面，这里需要先创建一个筛选器列表。

点击“添加”，输入筛选器列表名称，比如“Allow-RDP-From-192.168.1.100”，然后点击“添加”按钮创建具体的IP筛选器。在筛选器属性窗口里：

• 源地址选择“一个特定的 IP 地址”，填入你允许访问RDP的客户端IP；
• 目标地址选择“我的 IP 地址”；
• 协议类型选择“TCP”；
• 源端口选择“从任意端口”；
• 目标端口选择“到此端口”，填3389。

注意检查一下“镜像”复选框，建议取消勾选，理由前面已经说过。

如果白名单里有多个IP，比如办公网出口IP和运维跳板机IP，可以在同一个筛选器列表里继续点击“添加”，创建多个筛选器。多个筛选器之间存在“或”逻辑，只要匹配任意一个就放行，这样一条规则就能覆盖多个白名单IP。

3.4 添加“阻止所有IP”筛选器

在同一个策略的“安全规则向导”里，再添加一条规则，对应第二个筛选器列表。这次筛选器列表名称叫“Block-RDP-All”，具体筛选器配置为：

• 源地址选择“任何 IP 地址”；
• 目标地址选择“我的 IP 地址”；
• 协议类型选择“TCP”；
• 源端口选择“从任意端口”；
• 目标端口选择“到此端口”，填3389。

同样取消镜像勾选。这条规则的作用就是把来源不明的3389入站流量全部拦掉。

3.5 组合规则并调整顺序

规则创建好之后，回到策略属性的“规则”标签页，会看到两条规则。这时必须确认顺序：第一条是“Allow-RDP-From-192.168.1.100”，第二条是“Block-RDP-All”。如果顺序反了，策略会先匹配“阻止所有”，白名单IP也进不来。选中规则后可以用“上移”“下移”按钮调整顺序，把允许规则放到最上面。

筛选器操作的选择也很关键。在规则向导的“筛选器操作”页面，选择“许可”；在阻止规则里，选择“阻止”。如果系统内置的筛选器操作列表里没有“许可”或“阻止”，可以点击“添加”自定义，安全方法选择相应动作即可。

另外，规则向导后面还会让你选择“身份验证方法”，因为我们用的是“许可/阻止”动作，不涉及安全协商，这一项保持默认就行了，不用填证书或预共享密钥。

3.6 指派策略并验证生效

规则全部就位后，最后一步是“指派”。回到“IP安全策略，在本地计算机”列表，右键点击“RDP-Access-Control”，选择“指派”。指派成功后，策略描述栏会显示“是”，表示当前策略已经激活。

指派是立即生效的，不需要重启服务器。验证方式很简单：

从白名单IP的机器上，打开命令行，执行：

powershell复制Test-NetConnection -ComputerName 服务器IP -Port 3389

如果返回TcpTestSucceeded为True，说明白名单放行正常。从非白名单IP的机器上执行同样的命令，应该会一直卡住，直到最终超时，这代表IPSec的“阻止”动作已经把包静默丢弃了。

3.7 用命令行/批处理快速部署

图形界面配置适合单台机器，批量部署时就效率太低了。更推荐用netsh命令，写成一个批处理脚本，几秒钟就能完成整套配置。下面是一个可直接套用的模板：

bat复制@echo off
set POLICY_NAME=RDP-Access-Control

REM 创建策略
netsh ipsec static add policy name=%POLICY_NAME%

REM 创建白名单筛选器列表，并添加多个白名单IP
netsh ipsec static add filterlist name="Allow-RDP-Whitelist"
netsh ipsec static add filter filterlist="Allow-RDP-Whitelist" srcaddr=192.168.1.100 dstaddr=me protocol=TCP srcport=any dstport=3389
netsh ipsec static add filter filterlist="Allow-RDP-Whitelist" srcaddr=192.168.1.101 dstaddr=me protocol=TCP srcport=any dstport=3389

REM 创建阻止筛选器列表
netsh ipsec static add filterlist name="Block-RDP-All"
netsh ipsec static add filter filterlist="Block-RDP-All" srcaddr=any dstaddr=me protocol=TCP srcport=any dstport=3389

REM 创建筛选器操作
netsh ipsec static add filteraction name="Permit" action=permit
netsh ipsec static add filteraction name="Block" action=block

REM 添加规则到策略，允许规则在前
netsh ipsec static add rule name="Allow-RDP" policy=%POLICY_NAME% filterlist="Allow-RDP-Whitelist" filteraction="Permit"
netsh ipsec static add rule name="Block-RDP" policy=%POLICY_NAME% filterlist="Block-RDP-All" filteraction="Block"

REM 指派策略
netsh ipsec static set policy name=%POLICY_NAME% assign=yes

脚本里filterlist下面可以重复添加多条filter，对应不同白名单IP。如果以后要调整白名单，把srcaddr=后面的IP改掉重跑一遍脚本即可。这个脚本我一般会在新服务器初始化阶段直接执行，省时省力。

4. 验证效果与流量特征分析

4.1 授权IP的实测结果

配置完成后，从白名单IP的机器尝试远程桌面连接，过程和无策略时几乎没有区别，输入账号密码就能正常登录。延迟上没有任何可感知的差异，因为“许可”动作只是放行数据包，不改变包内容，也不引入额外的封装。

我用ping和远程桌面同时验证过，白名单IP的通信畅通无阻。用netstat -an | findstr 3389查看，服务器3389端口依然是LISTENING状态，说明RDP服务正常对外监听，只是由IPSec在更前一层做了流量准入。

4.2 非授权IP的实测结果

从非白名单IP发起3389连接，表现可以用三个字形容：卡、超、断。

具体来说，用Test-NetConnection测试时，连接不会立即收到拒绝（RST），而是长时间没有任何响应，直到TCP连接超时。这是因为IPSec的“阻止”动作是静默丢弃数据包，不会返回任何错误信息，作为连接方看起来就是“对方不存在”一样。

这个特征很有用：如果你在测试时发现连接被“秒拒”（RST），那通常不是IPSec在起作用，而更像是端口根本没开或者防火墙返回了拒绝。反之，如果连接一直挂起到超时，大概率是IPSec的丢弃规则命中了。

4.3 抓包确认流量特征

为了验证得更彻底，我建议在非白名单IP的机器上抓个包看看。

用Wireshark或tcpdump抓包时，可以看到客户端发出TCP SYN包，然后就没有然后了——服务器端没有回SYN-ACK，也没有回RST，TCP重传几次之后，客户端放弃。这个现象说明数据包在到达RDP服务之前就被IPSec层静默丢弃了。

如果是没有配置IPSec策略的服务器，即使RDP服务没有绑定到该网卡，内核也会回一个RST包，连接会立刻失败。所以从抓包行为上，可以非常明确地判断IPSec是否在起作用。

4.4 策略状态和事件日志

平时巡检时，我习惯用下面几个命令确认IPSec策略状态：

bat复制netsh ipsec static show all
netsh ipsec static show policy name="RDP-Access-Control"

第一个命令会列出当前机器上所有IPSec策略、筛选器列表、筛选器操作和规则，第二个命令可以单独查看某一策略的详细配置。如果策略处于“指派”状态，输出里会有明确标识。

另外，如果IPSec策略加载失败或者规则语法有问题，系统事件日志里通常会有来源为“IPSec”或“PolicyAgent”的警告或错误事件。排查时可以打开事件查看器，看“Windows日志 -> 系统”，筛选来源“PolicyAgent”，确认策略服务当前状态是否正常。

5. 高频故障与避坑经验

5.1 策略指派了，为什么还是连不上或拦不住

这类问题十有八九出在筛选器配置细节上。我梳理过几个最常见的坑：

• 规则的顺序反了。这是最隐蔽的错误。如果“阻止所有3389”排在“允许白名单”前面，所有IP都会被拦掉，包括白名单。可以在策略属性里调整规则顺序，把允许规则放在第一条。
• 镜像勾选状态不对。入站控制时勾了镜像，会导致出站RDP流量也受规则影响，可能影响本机作为客户端访问其他远程桌面。
• 源端口填了3389。前面强调过，客户端发起连接时源端口是随机高端口，不是3389，填了必废。
• 协议类型选错。RDP走TCP，如果策略里配成了UDP或ICMP，自然拦不住TCP数据包。不过如果你要彻底封禁UDP 3389辅助传输，需要单独加一条UDP规则，这也是容易被忽略的细节。
• 策略没有“指派”。创建了策略但忘了右键指派，等于白配。指派列显示“是”才算生效。

5.2 误把自己锁在门外怎么办

这是所有做IPSec策略的人最怕的局面：配置完一测试，发现自己当前IP不在白名单里，远程桌面直接断了。真遇到这种情况，请记住，最直接的恢复方法是到服务器本地控制台操作。

如果服务器在机房或者有带外管理（iLO/iDRAC），直接通过控制台登录，打开命令行执行：

bat复制netsh ipsec static set policy name="RDP-Access-Control" assign=no

策略立刻失效，3389恢复可访问。然后再仔细检查白名单配置，确认无误后重新指派。

如果连本地控制台都要远程才能上，那就比较尴尬了。所以在生产环境配置之前，我强烈建议做三件预防措施：

1. 先把当前管理员IP加入白名单，再添加阻止规则；
2. 配置完成后不要立刻退出当前远程桌面，先用另一个测试IP验证一遍，确认没问题再断；
3. 如果需要远程操作且没有带外管理，可以在计划任务里加一条“15分钟后自动取消指派”的救援命令，给自己留一条退路。

救援计划任务的命令参考：

bat复制schtasks /create /tn "RollbackIPSec" /tr "netsh ipsec static set policy name=RDP-Access-Control assign=no" /sc once /st 14:00

这种方式虽然粗犷，但在关键时刻真的能救命。

5.3 IPSec策略和Windows防火墙的叠加坑

IPSec策略和Windows防火墙是两条独立链路，并不是“IPSec放行了，防火墙就一定会放行”。实际效果是两者都要满足，流量才能到达RDP服务。

也就是说，如果IPSec策略里放行了某个IP的3389流量，但Windows防火墙的入站规则里没有放开3389，连接依然会失败。反之，防火墙放开了但IPSec没放行，同样连不上。

所以在验证阶段，如果发现白名单IP也连不上，除了检查IPSec规则顺序，还要确认Windows防火墙入站规则里是否允许TCP 3389。等保整改时我一般会同时检查这两层，避免出现“策略之间互相打架”的问题。

5.4 域环境下被组策略覆盖

加入AD域的服务器，本地IP安全策略有可能被域的组策略策略覆盖。具体表现就是：本地明明指派的策略，组策略一刷新，权限甚至策略本身就没用了。

想确认当前生效的是本地策略还是域策略，可以执行：

bat复制gpresult /h C:\gpreport.html

打开生成的HTML报告，查找“IP 安全策略”相关条目，看看是否有域GPO在应用IPSec设置。如果有，就别在本地折腾了，直接在AD域控上把这套策略做成GPO，下发给目标服务器组织单元，这样既能统一管理，又能避免本地配置和域策略互相冲突。

5.5 多网卡、UDP 3389这些容易被忽略的细节

如果服务器有多块网卡，IP筛选器“目标地址”选择“我的 IP 地址”时，会匹配本机所有网卡的IP。但某些场景下你只想限制其中一个网卡开放3389，比如内网网卡可以访问，外网网卡不允许。这时候目标地址就不要选“我的 IP 地址”，而是选择“一个特定的 IP 地址”，并填入那个网卡的IP。筛选器就会精确到单块网卡。

另一个容易被忽略的是UDP 3389。从Windows Server 2012开始，远程桌面默认启用UDP 3389作为辅助传输，用于提升流畅度。很多人配置IPSec时只拦了TCP，UDP通道完全裸奔。虽然没有UDP也连不上RDP，但从精简攻击面的角度，我建议把UDP 3389也加入阻止规则，做法和TCP规则一样，只是协议类型改成UDP。

5.6 问题速查表

最后再分享一个我在实际维护中的体会：IPSec策略是一个典型“配置简单但细节致命”的加固手段，它真正适合和改端口、账号锁定策略、NLA（网络级别身份验证）组合起来用。我自己的标准操作是防火墙放行运维IP的3389，IPSec再做一层白名单兜底，同时把远程桌面的账户锁定阈值设为5次，四管齐下之后，3389基本不会成为服务器的短板。这套配置我已经整理成一个脚本模板，每次初始化新机器时直接跑一遍，配合资产清单维护白名单IP，运维和安全的压力都会小很多。