Windows服务器的端口安全巡检从来不是“扫一遍就完事”的活。真正的问题往往藏在那些看似正常、长期开放、但早已没人维护的端口背后。比如一个已经废弃的ERP系统留下的1433端口，或者某次临时调试打开的3389备用端口，都可能成为攻击者横向移动的入口。巡检的核心不是数清楚开了多少个端口，而是搞清楚每个端口为什么开、被谁用、是否还需要、暴露面有多大。
先说最基础的端口枚举。很多人习惯用netstat -ano直接看，但生产环境里输出结果动辄几百行，人工看不过来。更有效的方式是结合进程和路径做过滤。在PowerShell里执行下面这条命令，可以把监听端口、进程ID、进程名和可执行文件路径一次性拉出来，方便快速定位可疑项：
Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess,@{Name="ProcessName";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}},@{Name="Path";Expression={(Get-Process -Id $_.OwningProcess).Path}} | Sort-Object LocalPort | Format-Table -AutoSize
这条命令的价值在于，它把端口和具体的二进制文件路径对应起来了。比如你发现本地445端口被一个不在System进程下的程序监听，或者某个高端口对应的可执行文件位于临时目录，基本可以判定有问题。巡检时建议把输出结果导出成CSV存档，方便和上一次巡检做差异对比。端口变化本身就是一个重要信号，新增的监听端口比长期存在的端口更值得警惕。
远程端口扫描方面，Windows服务器上不一定有nmap，但可以用PowerShell自带的Test-NetConnection做基础探测。不过这个命令逐个端口测效率很低。更实用的做法是用.NET的TcpClient类写一个简单的多线程扫描脚本，针对关键端口做快速批量检测：
$ports = 21,22,23,25,53,80,110,135,139,143,443,445,1433,3306,3389,5432,6379,8080,8443,27017
$target = "127.0.0.1"
foreach ($port in $ports) {
$client = New-Object System.Net.Sockets.TcpClient
$result = $client.BeginConnect($target,$port,$null,$null)
$wait = $result.AsyncWaitHandle.WaitOne(500,$false)
if ($wait -and $client.Connected) { Write-Host "端口 $port 开放" -ForegroundColor Red }
$client.Close()
}
这个脚本只检测本机回环地址，适合快速自查。如果要扫描内网其他服务器，把target改成对应IP即可，但要注意扫描频率和范围，避免触发安全设备的告警。巡检时建议优先检查135、139、445、3389、1433、5985、5986这些Windows环境下的高危端口，尤其是5985和5986，WinRM服务如果暴露在不受控的网络里，配合弱口令就是一条完整的远程命令执行链路。
防火墙规则和端口开放情况必须放在一起看。很多管理员只检查Windows防火墙是否开启，却不看入站规则里具体放行了哪些端口。一条“允许所有本地端口”的规则就能让防火墙形同虚设。用下面这条PowerShell命令可以列出所有启用的入站规则及其放行的端口：
Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True | Get-NetFirewallPortFilter | Where-Object {$_.Protocol -eq "TCP" -or $_.Protocol -eq "UDP"} | Select-Object Protocol,LocalPort,RemotePort | Sort-Object LocalPort -Unique | Format-Table -AutoSize
这里要特别留意LocalPort显示为“Any”的规则。如果一条入站允许规则没有限定端口，意味着所有端口都对外放行，这比单个端口暴露严重得多。还要检查规则的RemoteAddress字段，确认放行范围是“Any”还是特定的管理网段。很多服务器被入侵后发现防火墙开着，但规则里有一条“Any Any”的入站允许，等于大门敞开。
端口和服务的对应关系也需要核实。Windows服务可以自定义监听端口，不能想当然认为某个端口就是某个服务。比如IIS默认80和443，但管理员完全可以改成8080和8443。SQL Server默认1433，但命名实例会使用动态端口。巡检时要结合服务配置来确认。对于IIS，可以用appcmd或者IISAdministration模块查看站点绑定：
Import-Module IISAdministration
Get-IISSite | ForEach-Object { Get-IISBinding -Name $_.Name } | Select-Object Site,Protocol,BindingInformation,Port | Format-Table -AutoSize
对于SQL Server，需要检查TCP/IP协议配置里的监听端口设置。打开SQL Server Configuration Manager，在“SQL Server网络配置”下查看“协议”中的TCP/IP属性，重点看“IP地址”标签页里每个IP的TCP端口和TCP动态端口设置。如果“TCP动态端口”不为空，说明实例在使用动态端口，每次重启服务端口都可能变化，这会给防火墙规则和巡检带来不确定性。建议生产环境固定SQL Server的监听端口，关闭动态端口。
远程桌面服务是Windows服务器最常见的暴露面之一。3389端口如果直接对公网开放，暴力破解尝试几乎不会停。巡检时不能只看3389是否开放，还要检查RDP的安全配置。用下面命令查看RDP是否启用了网络级别身份验证（NLA）：
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication | Select-Object UserAuthentication
UserAuthentication值为1表示启用了NLA，值为0则没有。没有NLA的RDP服务在用户输入凭据之前就会暴露登录界面，攻击面更大。另外还要检查是否有非标准的RDP端口。有些管理员为了“安全”会把RDP端口改到其他端口，比如3390或者4000以上的端口。这种做法只能绕过最基础的扫描，不能替代真正的安全措施，反而会给运维带来麻烦。巡检时如果发现RDP端口不是3389，要确认这个改动是否有记录、是否有对应的防火墙规则配合。
SMB相关端口（139和445）的检查要结合共享配置。用net share命令可以列出当前所有共享资源，包括默认的管理共享（C$、ADMIN$等）。如果服务器不需要提供文件共享服务，建议直接禁用Server服务，这样139和445端口就不会监听。如果必须保留共享，要检查共享权限和NTFS权限是否匹配最小权限原则。下面命令可以查看共享及其权限：
Get-SmbShare | ForEach-Object { Get-SmbShareAccess -Name $_.Name | Select-Object Name,AccountName,AccessControlType,AccessRight }
重点看是否有Everyone或者匿名账户拥有读取或完全控制权限。很多勒索软件就是通过扫描445端口配合弱口令或者漏洞利用来传播的。如果服务器不承担文件共享角色，关闭Server服务是最直接的加固方式：
Stop-Service LanmanServer -Force Set-Service LanmanServer -StartupType Disabled
执行前要确认没有依赖Server服务的业务组件，比如某些备份软件或者集群功能。生产环境操作前务必在变更窗口内执行，并做好回滚准备。
WinRM端口5985和5986经常被忽视。Windows Server 2012及以后版本默认开启了WinRM服务，用于远程管理。如果服务器不在域环境或者没有使用PowerShell远程管理的需求，建议关闭WinRM。检查WinRM状态：
Get-Service WinRM | Select-Object Status,StartType
如果状态为Running且启动类型为Automatic，说明服务在运行。可以通过以下命令停止并禁用：
Stop-Service WinRM -Force Set-Service WinRM -StartupType Disabled
如果业务确实需要WinRM，至少要限制监听地址和可连接的IP范围。WinRM默认监听所有地址，可以通过winrm命令配置只监听内网管理网段。另外还要检查WinRM的认证方式，确保没有启用Basic认证，因为Basic认证会以明文形式传输密码。
端口巡检不能只看TCP，UDP端口同样重要。DNS（53）、SNMP（161）、NTP（123）等UDP端口如果暴露，可能被用于反射放大攻击。Windows服务器上如果运行了DNS服务，要确认递归查询是否对公网开放。用下面命令查看DNS服务状态和配置：
Get-Service DNS | Select-Object Status,StartType Get-DnsServerRecursion
如果服务器不是公网DNS服务器，递归查询应该设置为仅对内网客户端开放。SNMP服务在Windows上默认不安装，但如果安装了，要检查Community字符串是否还是默认的public或private。SNMP使用UDP 161端口，默认Community字符串相当于明文密码，一旦泄露，攻击者可以读取系统信息甚至修改配置。
端口巡检的另一个重要维度是历史对比。建议每次巡检把端口清单、防火墙规则、服务状态导出存档，下次巡检时用脚本做差异对比。新增端口、删除端口、规则变化、服务启动类型变化，这些都是需要关注的信号。可以用Compare-Object命令快速对比两次导出的端口列表：
$old = Import-Csv "port_scan_202501.csv" $new = Import-Csv "port_scan_202502.csv" Compare-Object $old $new -Property LocalPort,ProcessName | Format-Table -AutoSize
这种对比能发现很多隐蔽的变化。比如某个服务更新后自动添加了一个新的监听端口，或者某个被禁用的服务被重新启动。端口清单的稳定性和可预测性是安全运维的重要指标，任何非预期的变化都应该触发告警和排查流程。
对于暴露在公网的Windows服务器，建议在边界防火墙或者安全组层面做端口白名单控制，而不是仅仅依赖主机防火墙。主机防火墙和网络防火墙是两层防线，不能互相替代。巡检时要同时检查两个层面的规则是否一致。比如边界防火墙只放行了443端口，但主机防火墙却允许所有入站，这种情况下一旦边界防火墙出现配置错误，主机就完全暴露了。反过来，如果主机防火墙规则很严格，但边界防火墙放行了大量端口，攻击者仍然可以到达主机端口进行探测和攻击。
最后要强调的是，端口巡检不是一次性任务，而是需要纳入日常运维流程的持续性工作。建议至少每月做一次完整的端口和防火墙规则审计，每季度做一次全面的暴露面评估。对于关键业务服务器，可以考虑部署主机入侵检测系统（HIDS）来实时监控端口变化和异常连接。端口是网络攻击的第一道门，把这道门看好了，能挡住大部分自动化攻击和扫描工具。
