Windows Server 2025 / 检查 Defender 与 Windows 防火墙安全
检查 Windows Server 2025 防护时，应核对 Microsoft Defender Antivirus 的运行模式、更新和排除项，以及 Windows 防火墙实际采用的网络配置文件与规则。然后验证服务器需要提供的服务，只为明确需求添加最小范围的例外。本练习先查询状态，再创建一条实验规则并在结束后删除，全程保持防护启用。
记录角色与初始状态
域控制器、文件服务器和 Web 服务器需要的通信不同。变更共用设置前，先记录已安装角色、管理路径、备份及更新状态。使用授权管理会话，并保留控制台访问，因为网络设置错误可能中断远程管理。不要未经范围审查，就把 FS1 的例外直接复制到 DC1。
- 日常使用和管理操作采用不同身份。
- 仅允许获批准的电脑与网络进行远程管理。
- 记录各角色需要的服务、协议、端口与来源。
- 将防护更新和恢复测试纳入常规维护。
安全基线是逐项检查设置的参考，不是运行不明注册表修改包的理由。应确认系统版本支持、服务依赖、运行影响以及恢复原值的方法。查询与修改要分开：记录当前状态不需要关闭防病毒、篡改防护或防火墙。
检查 Defender 模式和更新
在要检查的服务器上，以管理员身份打开 Windows PowerShell。根据预定的主要防病毒产品，对照Microsoft Defender Antivirus 的运行模式解释结果。以下命令只读取状态，不修改配置：
Get-MpComputerStatus | Select-Object AMRunningMode,AntivirusEnabled,RealTimeProtectionEnabled,AntivirusSignatureLastUpdated
Get-MpPreference | Select-Object ExclusionPath,ExclusionProcess,ExclusionExtensionAMRunningMode 为 Normal 表示主动模式。如果 Defender 是主要防病毒产品，还应将 AntivirusEnabled、RealTimeProtectionEnabled 与预期状态核对；单一字段不能证明整体安全。Passive 不等于主动承担主要防病毒保护，与其他防病毒产品共存的条件取决于 Defender for Endpoint 接入情况和主要产品。在 Windows Server 上，安装第三方防病毒产品不会自动让 Defender 转为被动模式。EDR Block Mode 是终结点检测与响应（Endpoint Detection and Response，EDR）的特定配置，不是 Normal 的别称。应与已批准的保护设计比较，不在查询过程中随意切换模式。
AntivirusSignatureLastUpdated 表示安全情报的最后更新时间，不是引擎版本，也不能证明服务器没有威胁。将时间与维护要求比较，并另外检查引擎和平台更新；隔离设备应有经批准、受控的更新来源。查询失败时，应检查模块、安装、产品状态与权限，不能认定防护正常。还要区分 ExclusionPath、ExclusionProcess 和 ExclusionExtension。Windows Server 的内置与自动排除项不同于自定义排除项，可见列表为空不能代替对角色相关排除项的审查。每项例外都应有官方产品文档与已核实的需求，不要为解决性能问题而排除整个驱动器或全部可执行文件。
区分本地配置与实际生效规则
Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction
Get-NetFirewallRule -PolicyStore ActiveStore | Where-Object Enabled -eq 'True' | Select-Object DisplayName,Direction,Action,ProfileGet-NetConnectionProfile 显示各连接的网络类别，应检查 FS1 实际使用的接口。Domain 网络配置文件由域及域控制器识别决定，不能随意手动贴上“域”标签。如果预期域连接显示 Public 或 Private，应按网络诊断课程检查 DNS 和域连通性。第二行默认读取本地 PersistentStore，因此不一定代表组策略对象（GPO）的最终效果。若要比较实际生效的配置文件，按该 PowerShell 命令文档所述，在 Get-NetFirewallProfile 中加上 -PolicyStore ActiveStore 再查询。NotConfigured 不等于所有流量都被允许。第三行虽读取 ActiveStore，但 Enabled = True 也不意味着每条规则都匹配当前配置文件、方向和测试流量。
根据Windows 防火墙指南，应保持防火墙保护。针对服务分别检查是否监听、协议、端口、来源地址及网络配置文件。前面的列表没有显示端口、地址或程序，可打开 wf.msc 查看规则属性和“监视”中的规则，或查询相应筛选器对象。新建较窄的允许规则，不会让已有的较宽允许规则失效。相反，匹配的显式阻止规则通常优先于冲突的允许规则，详见防火墙规则优先关系。列表显示顺序不是管理员设置的数字优先级。
创建并删除范围受限的实验规则
只使用课程隔离域网络中的可信 FS1 和 CLIENT1。在 CLIENT1 控制台核实并记录 DHCP 当前分配的 IPv4，不要假定旧地址仍然有效。修改前，先从 CLIENT1 执行 ping 172.24.50.20，保存初始结果。在 FS1 上通过 wf.msc 或使用准确名称的 Get-NetFirewallRule 查询，确认 Lab-ICMPv4-From-Client 尚不存在，且实际连接路径采用 Domain 配置文件。如果名称已被使用，停止，不修改原规则。在 FS1 上以管理员身份打开 PowerShell，只输入已核实的 CLIENT1 IPv4。两行应分开执行：若地址转换失败，或输入的是 IPv6，不要继续创建。互联网控制消息协议第 4 版（ICMPv4）的类型 8 是回显请求，这里并不开放 TCP 或 UDP 端口：
$clientAddress = [ipaddress](Read-Host 'Current CLIENT1 IPv4 address')
New-NetFirewallRule -Name 'Lab-ICMPv4-From-Client' -DisplayName 'Lab ICMPv4 from CLIENT1' -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress $clientAddress -Profile Domain -Action AllowNew-NetFirewallRule 的预期结果是在 FS1 上创建一条已启用规则：名称为 Lab-ICMPv4-From-Client，Direction 为 Inbound，Action 为 Allow，Profile 为 Domain，协议 ICMPv4、类型 8，远程地址是已核实的 CLIENT1 IPv4。该规则不会验证用户身份，也不限制其他协议。解释 ping 结果前先在属性中确认这些字段。如果 DHCP 更换 CLIENT1 的地址，原来的 IP 匹配就不一定继续代表同一台设备。
从 CLIENT1 在相同条件下再次执行 ping 172.24.50.20。如果原先仅缺少此允许规则，且没有显式阻止或其他网络故障，预期会收到 FS1 回复。如果修改前已经能收到回复，就不能证明新规则是必要的。若仍失败，先检查输入的 IPv4、FS1 配置文件、网络路径、阻止规则，以及策略是否允许合并本地规则。不要直接扩大为 Any 或关闭防火墙来强求成功。防火墙命令行管理指南说明了查询及筛选器方法。ping 成功也不能证明文件共享或域身份验证正常。
结束后，只删除刚刚在 FS1 上创建的这一条规则，名称必须完全一致。如果该规则在练习前已存在，或本次创建失败，不要执行删除：
Remove-NetFirewallRule -Name 'Lab-ICMPv4-From-Client'确认该规则已不在本地存储中，并检查实际生效状态，再从 CLIENT1 重复同一 ping 测试，与初始结果比较。其他有效的允许规则可能使回复继续存在。不要为了让演示失败而删除全部 ICMP 规则或由 GPO 下发的规则。如果规则因策略或删除错误仍然存在，应先查明来源，再判断清理是否完成。
变更后验证防护与服务
变更后同时检查防护与相关任务，例如授权管理访问、域控制器上的域验证和 DNS，或文件服务器上的具体共享。FS1 还不必提供后续课程中的全部角色，因此端口没有服务监听，不代表防火墙发生故障。关联连接失败和安全事件时，记录时间、来源与目标。如果为了排查而启用丢弃数据包日志，应先检查配置文件、日志路径和大小，并保存原值；不要假定所有丢弃事件都已被记录。
恢复时，将配置与初始记录比较，只从相应管理来源撤销被更改的例外或策略。本练习预定的恢复操作是删除 Lab-ICMPv4-From-Client，而不是重置整个防火墙。之后再次验证合法访问与防护状态。如果服务必须关闭防护才能运行，应重新检查所需通信并设计有依据的例外，同时保留控制台与备份访问。
