Windows Defender Firewall Guide: Host Isolation, IPsec and Rule Management

Ransomware operators move between Windows machines over SMB, RPC, WinRM and RDP, and on most networks the only thing that could stop a workstation from talking to another workstation is a host firewall that is switched on but full of broad allow rules. Windows Defender Firewall is already installed on every supported Windows client and server, supports per-profile policy, application and service rules, and IPsec connection security that can require Kerberos authentication before a connection is accepted. Used deliberately, it blocks lateral movement at almost no cost. This guide covers who controls the firewall and how, rule precedence and local merge, host isolation and domain isolation with IPsec, logging and auditing, and a rollout plan through Intune or Group Policy. It is written for Windows endpoint and server engineers, Active Directory administrators and security architects.

Key takeaways

• Keep the defaults and build on them. Inbound is blocked unless solicited or allowed by a rule, outbound is allowed unless blocked; Microsoft advises never changing inbound to allow all and never stopping the MpsSvc service.
• Turn off local rule merge. Disabling AllowLocalPolicyMerge per profile stops local administrators and installers from adding their own exceptions, so only centrally managed rules apply.
• Block rules win. Explicit block beats allow, and only authenticated bypass rules (-OverrideBlockRules) for IPsec-authenticated peers can override them; there is no administrator-set rule order.
• Isolate workstations from each other. Block inbound SMB, RPC, WinRM and RDP between workstations, allowing them only from management hosts, which removes the most common lateral movement paths.
• Log and audit changes. Enable dropped and successful connection logging per profile, and audit MPSSVC rule changes (events 4946 to 4948, 4950) so tampering is visible.

How identity and access work in Windows Defender Firewall

The firewall is enforced by the Windows Filtering Platform and managed by the Windows Defender Firewall service (service name MpsSvc). Identity appears in three places: who can change policy, which network profile applies, and, through IPsec, which remote computers and users a rule trusts.

Rule precedence is simple and fixed: explicit allow rules beat the default block, explicit block rules beat conflicting allows, and more specific rules beat less specific ones except where a block applies. Microsoft states that weighted or administrator-assigned ordering is not supported.

Admin roles and privileged access

• Central policy owners: Edit rights on firewall GPOs and Intune endpoint security firewall policies are fleet-wide network access. Restrict them to a small group working from privileged access workstations, and use Intune scope tags and role-based access to separate server and workstation policy. See the Privileged Access Workstations Guide.
• Local administrators: Any local administrator can disable a profile, add rules or stop logging. Disabling local merge limits the rules they can add, but administrators can still change local settings, so remove standing local admin rights and manage the remaining accounts with LAPS. See the Local Administrator Password Solution (LAPS) Guide.
• Management hosts: Allow remote administration ports (WinRM 5985/5986, RDP 3389, SMB 445, RPC) only from jump servers and management subnets, or from computers and users that authenticate through IPsec. These rules define your administrative tiering in network terms.
• GPO editing hazards: PowerShell's Open-NetGPO and Save-NetGPO load and save the whole GPO, so concurrent edits by two administrators can overwrite each other. Coordinate firewall GPO changes through change control.

Changing firewall GPOs is a known attacker action (ATT&CK T1484.001 Group Policy Modification), so the identities that can do it are tier 0 in practice. See the Group Policy Security Guide.

Integrations, API tokens and service accounts

Scanning and management service accounts often hold local admin on every machine and are reachable from everywhere; pairing their network rules with their identity is one of the highest-value changes you can make. See the Windows Services and Service Account Security Guide.

Host isolation and IPsec

Workstation isolation without IPsec

The cheapest lateral movement control is a workstation policy that blocks inbound management protocols from other workstations. A typical design:

• Block inbound from workstation subnets: TCP 445 (SMB), TCP 135 and dynamic RPC, TCP 5985/5986 (WinRM), TCP 3389 (RDP).
• Allow inbound from management: The same ports only from jump servers, management servers and helpdesk tooling addresses.
• Remember block precedence: If you write the isolation as explicit block rules, an allow rule cannot override it; only an authenticated bypass rule can. Many designs therefore rely on the default inbound block plus narrowly scoped allow rules instead.
• Servers: Allow each server role's ports only from the clients and tiers that use them; administrative ports only from management.

Domain isolation with IPsec

IPsec connection security rules let a host require that peers authenticate before any traffic is accepted, and optionally require encryption. Microsoft's basic domain isolation policy uses a Kerberos computer authentication proposal (New-NetIPsecAuthProposal -Machine -Kerberos), a phase 1 auth set, and a rule on the Domain profile with -InboundSecurity Require -OutboundSecurity Request. Non-domain devices then cannot connect to isolated hosts at all.

• Server isolation: Add firewall rules with -Authentication Required and remote computer or user conditions so only members of named AD groups reach a sensitive server.
• Authenticated bypass: -OverrideBlockRules $true with -RemoteMachine and -RemoteUser SDDL lets authenticated management hosts through even where block rules exist. Use it sparingly, because it is a deliberate hole in every block.
• Request before require: Start with outbound and inbound Request, verify security associations form, then move inbound to Require. Exempt infrastructure such as domain controllers, DHCP and DNS as your design requires.

For protocol details and design choices, see the IPsec Security Guide.

Choosing an approach

Small organisations should do the first row everywhere and add server isolation for the domain controllers and backup servers. Large estates gain most from combining workstation isolation with IPsec for tier 0. Microsoft suggests outbound blocking only where each application's connectivity is inventoried.

Logging and detection

• Firewall log: Default path %windir%\system32\logfiles\firewall\pfirewall.log; Microsoft recommends separate files per profile, logging both dropped packets and successful connections, and a size of at least 20,480 KB (maximum 32,767 KB). The NT SERVICE\mpssvc account needs Full Control on the folder, which is a common reason custom log paths stay empty.
• Policy change auditing: Enable Audit MPSSVC Rule-Level Policy Change for success and failure. Key events: 4946 rule added, 4947 rule modified, 4948 rule deleted, 4949 settings restored to defaults, 4950 setting changed, 4954 Group Policy settings applied, 4956 active profile changed, and 4957/4958 rules not applied.
• Connection auditing: Audit Filtering Platform Connection produces 5156 (allowed) and 5157 (blocked) events. They are high volume, so collect selectively, for example on servers and for blocked events.
• Forwarding: Ship logs with Windows Event Forwarding or an agent to the SIEM. See the Windows Event Forwarding Guide.
• Tampering: Disabling profiles, adding broad allow rules or turning off logging maps to ATT&CK T1686 Disable or Modify System Firewall. Alert on 4950 profile disables and on 4946 rules created outside your management tooling.

Hardening baseline

1. Enable all profiles with Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True, default inbound Block, default outbound Allow, and -NotifyOnListen False for non-admin users. The Microsoft security baselines and CIS Benchmarks both include firewall profile settings. See the Microsoft Security Baselines and Security Compliance Toolkit Guide.
2. Inventory existing rules: Export current rules and remove unused, overly broad or undocumented ones before disabling local merge, or applications will break.
3. Disable local merge per profile through the Firewall CSP (./Vendor/MSFT/Firewall/MdmStore/DomainProfile/AllowLocalPolicyMerge and the Private and Public equivalents) or Group Policy, and deploy required application rules centrally first.
4. Build rules specifically: Full program paths (wildcard paths are not supported), AppID tags where you run App Control, consecutive port ranges and subnets rather than long lists, and rules created in all profiles but enabled only where needed.
5. Apply workstation isolation in pilot rings, using logging of dropped packets to find legitimate peer-to-peer traffic (for example delivery optimisation or collaboration tools) before broad deployment.
6. Add IPsec for tier 0: Request mode first, then Require, with documented exemptions.
7. Enable logging and auditing as above and forward events.
8. Rollback: Keep the previous policy version assigned to a group so you can move devices back; never stop MpsSvc, because Microsoft does not support it and it breaks Start menu, app installation and other features.

Framework mapping

Common misconfigurations

• Firewall disabled by stopping the service: Unsupported, breaks features, and removes IPsec rules with it.
• Local merge left on: Years of installer-created and user-approved rules that nobody reviews, many allowing any remote address.
• Domain profile as a free pass: Broad allow rules on the Domain profile on the assumption that the internal network is trusted, which is exactly the path lateral movement takes. See the Lateral Movement Guide.
• Allow rules expected to override blocks: Administrators add an allow for a management host and are surprised it does nothing because an explicit block exists.
• Logs that never write: Custom log paths without permissions for NT SERVICE\mpssvc, or default 4 MB logs that roll over in minutes.
• Two managers: Firewall policy from both Group Policy and Intune with conflicting settings; Intune notes that baseline firewall defaults may stop local and connection security rules from merging with MDM rules. See the Configuration Drift and Baseline Enforcement Guide.

Practitioner checklist

• Confirm all three profiles are enabled with default inbound Block on every device.
• Export, review and document existing rules; remove broad and unused ones.
• Disable local policy merge after central application rules are in place.
• Block workstation-to-workstation SMB, RPC, WinRM and RDP; allow them only from management hosts.
• Protect domain controllers and other tier 0 servers with IPsec or group-scoped rules.
• Restrict who can edit firewall GPOs and Intune firewall policies.
• Enable per-profile logging at 20 MB or more and fix log folder permissions.
• Audit MPSSVC rule changes and forward 4946 to 4950 events to the SIEM.
• Scan internally to verify isolation after each change.

Standards and references

• Microsoft Learn: Windows Firewall overview
• Microsoft Learn: Windows Firewall rules
• Microsoft Learn: Manage Windows Firewall with the command line
• Microsoft Learn: Configure Windows Firewall logging
• Microsoft Learn: Hyper-V firewall
• Microsoft Learn: Audit MPSSVC Rule-Level Policy Change
• Microsoft Learn: Security baselines in Intune
• MITRE ATT&CK: Disable or Modify System Firewall

Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · Windows Server Hardening Guide · IPsec Security Guide · Lateral Movement Guide · CyberArk Security Hardening Guide