Host-Based Firewall Guide: Block Lateral Movement on Every Windows, macOS and Linux Host

Host-based firewalls ship with every major operating system and are the cheapest control against lateral movement, yet in many estates they are switched off, left at defaults that allow workstation-to-workstation SMB and RDP, or buried under thousands of unreviewed local rules. Ransomware operators rely on exactly that: once one machine is compromised, admin shares, remote management and RPC on peer hosts are usually reachable. This guide sets out a cross-platform strategy for host firewalls on Windows, macOS and Linux: what to block between peers, how to design and centrally manage rules, how to roll out without breaking applications, what to log and which metrics show it is working. It is written for endpoint, infrastructure and security engineering teams. Platform click-paths live in the Windows Defender Firewall Guide and the Linux Firewall Guide; this page covers the design decisions across all of them.

Key takeaways

• Peer-to-peer traffic is the target. Most workstations never need inbound SMB, RDP, WinRM or RPC from other workstations; blocking those flows removes the easiest lateral movement paths.
• Central policy beats local rules. Manage rules from Group Policy, Intune or your configuration management tool and decide deliberately whether local rule merge is allowed.
• Disable profiles, never the service. On Windows, Microsoft says to keep the MpsSvc service running even when a profile must be off, because stopping it is unsupported and breaks other features.
• Log blocks, audit rule changes. Dropped-packet logs and Windows events 4946 to 4950 show both attempted lateral movement and attempts to weaken the firewall, mapped to ATT&CK T1686 Disable or Modify System Firewall.
• Roll out by ring with a tested rollback. Start in pilot rings, monitor blocks, then enforce; keep a single policy change that restores the previous rule set.

What a host firewall does that network firewalls do not

NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, describes firewalls as controls on traffic between networks or hosts with different security levels. A perimeter or internal segmentation firewall sees traffic between zones. It does not see two laptops on the same VLAN, two servers in the same subnet, or a device on a hotel Wi-Fi network. A host firewall enforces policy at the endpoint itself, wherever it is.

NIST SP 800-53 Rev 5 names this capability directly in SC-7(12) Host-based Protection, an enhancement of SC-7 Boundary Protection. In MITRE D3FEND it maps to D3-ITF Inbound Traffic Filtering and D3-NI Network Isolation. See the Network Segmentation Guide for how host rules fit with zone design.

Default behaviour on each platform

• Windows: Microsoft documents Windows Firewall as blocking all unsolicited inbound traffic unless a rule allows it, and allowing all outbound traffic unless a rule blocks it. Three profiles apply: Domain (set automatically when a domain controller is detected, not manually selectable), Private (trusted networks, set by an administrator) and Public (the stricter profile and the default for unidentified networks).
• macOS: the Application Firewall is managed with the com.apple.security.firewall configuration profile payload. Settings include Enable Firewall, Block all incoming connections, specific per-application allow or block entries, Enable stealth mode (do not answer probes such as ping) and logging, which Apple lists as macOS 12.0.1 or later with brief, detailed or throttled options. Apple also exposes settings to automatically allow built-in and downloaded signed software, from macOS 12.3. See the macOS Security Guide for Enterprises.
• Linux: the kernel filtering framework is present, but whether any policy is loaded depends on the distribution and image. Server images often ship with no restrictive rules. nftables is the current framework, with firewalld and ufw as common front ends. Treat "no rules loaded" as the default to check for on every Linux build.

A lateral movement baseline: what to block between peers

The highest-value rule set is a short list of inbound blocks on workstations, with narrow allows for the management hosts that genuinely need them. Port numbers below are the standard assignments.

• Scope by source, not just port: an allow rule for TCP 445 from "any" defeats the purpose. Scope to the specific server addresses or subnets of patching, backup, endpoint management and helpdesk tools.
• Use profiles: Microsoft recommends creating rules for all three profiles but enabling a rule group only where its scenario applies, for example file sharing only on Private. On Public, inbound allows should be close to none.
• Outbound: Microsoft's guidance is that allowing outbound by default suits most deployments. High-security environments can block outbound, but then need an inventory of every application that needs network access and a dedicated rule for each.

Rule design and central management

How Windows evaluates rules

Microsoft's rule design guidance sets the precedence: explicit allow rules override the default block, explicit block rules override conflicting allows, and more specific rules override less specific ones unless a block applies. Administrators cannot set rule order, so an overlapping block rule can silently cancel an intended allow. Review for overlapping blocks after every change.

Local rule merge

• Setting: AllowLocalPolicyMerge, set per profile in the Firewall CSP (./Vendor/MSFT/Firewall/MdmStore/DomainProfile/AllowLocalPolicyMerge and the Private and Public equivalents) or in Group Policy under Windows Defender Firewall with Advanced Security.
• Trade-off: disabling merge stops locally created rules, including those created by malware or by users, from taking effect. Microsoft notes it can break applications that create rules at install time, so every application that needs inbound connectivity must then be deployed centrally.
• Decision: disable merge on servers and on high-risk or privileged access workstations first; on general workstations disable it once the central rule inventory is complete.

Application-scoped rules

• Full paths only: Windows application rules do not support wildcard paths such as C:\*\app.exe, so use full paths.
• AppId tags: Windows can scope a firewall rule to processes tagged by an App Control for Business policy, using the Policy App ID setting in Intune or New-NetFirewallRule -PolicyAppId. This ties network access to an approved application identity rather than a path that malware could imitate.
• Prompts create block rules: when an application listens and no allow rule exists, a prompt appears; for a non-admin user Windows creates block rules regardless of the choice, and those must be deleted before the prompt returns. Microsoft recommends deploying allow rules before first launch and disabling inbound notifications on all profiles on non-admin devices.

Rule hygiene

Document each rule with its application, port range, owner and creation date, and deploy exceptions only for applications with a legitimate purpose. Prefer consecutive port ranges or subnets over long lists of single entries: Microsoft notes that large numbers of filters can degrade performance. For a formal review method see the Firewall Rule Review Checklist.

Choosing how strict to be

Small organisations: turn the firewall on everywhere, apply the targeted peer blocks through your MDM, and turn on logging of dropped packets. That alone closes the paths most commodity ransomware uses. Large organisations: add per-tier policies (workstations, member servers, domain controllers, privileged workstations), disable local merge by tier, use AppId or label-based scoping, and feed logs into detection engineering.

Rolling out without breaking the business

1. Discover flows: enable logging of allowed and dropped connections on a sample of devices per tier for two weeks, and list which hosts genuinely connect inbound to workstations (patching, remote support, backup, vulnerability scanners, endpoint management).
2. Write the allow list first: create scoped allow rules for those management sources before you add any block.
3. Pilot ring: apply the peer blocks to IT staff devices, then a cross-section of business users. Watch the helpdesk queue and dropped-packet logs for blocked legitimate flows.
4. Broad rings: expand in waves (for example 10 per cent, 50 per cent, 100 per cent), with a pause and review between waves.
5. Servers last and by role: servers need role-specific inbound allows; build them from the discovery data and apply per role.
6. Rollback: keep the previous policy version as a ready-to-assign object. Rolling back is reassigning that policy, not editing rules by hand on endpoints. On Windows, if a profile must be turned off, turn off the profile and leave the MpsSvc service running.
7. Lock it in: disable local merge where planned, restrict who can edit firewall policy in your management tool, and add firewall state to compliance reporting.

Detection and measurement

What to log

• Detection ideas: one workstation generating 5157 or log drops against many peers on TCP 445 or 135 in a short window (scanning or spreading); event 4946 or 4950 outside a change window; a host reporting the firewall profile off in compliance data; 4957 spikes after a policy push.
• Tampering: ATT&CK v20 tracks firewall weakening as T1686 Disable or Modify System Firewall. Pair rule-change events with process telemetry from your EDR. See the Lateral Movement Guide.
• Collection: forward the relevant event IDs centrally rather than relying on local logs. See the Windows Event Forwarding Guide.

Metrics

• Coverage: percentage of managed hosts with the firewall enabled on all profiles (target 100 per cent, with documented exceptions).
• Peer exposure: percentage of workstations reachable from another workstation on TCP 445, 3389 or 5985, measured by periodic internal scanning (target near zero).
• Policy integrity: number of hosts with local rules active where merge should be disabled.
• Unexplained changes: rule-change events (4946 to 4950) not linked to an approved change.
• Rule debt: central rules older than 12 months without a review date or owner.

Where identity fits

Host firewall rules decide which machines can reach admin services; identity decides which accounts can use them. The two work together. A shared local administrator password lets an attacker who reaches TCP 445 on a peer authenticate there, so pair peer blocks with unique local administrator passwords (Windows LAPS) and remove interactive logon rights from service accounts that only need network access. Management servers allowed through the firewall become high-value targets, because their service accounts and agents can reach every host. See the Windows Endpoint Hardening Guide and the Group Managed Service Accounts (gMSA) Guide.

Framework mapping

Common failure patterns

• Firewall disabled "temporarily" by GPO: a troubleshooting policy that turned profiles off is never reverted. Compliance reporting on firewall state catches this; spot checks do not.
• Management allows scoped to any: a rule meant for the patching server allows TCP 445 from every address, which recreates the flat network the blocks were meant to remove.
• Stopping the service instead of the profile: stopping MpsSvc is unsupported by Microsoft and breaks other Windows features, so teams then refuse to touch the firewall at all.
• Thousands of local rules: installers and user prompts accumulate rules that nobody reviews; with merge enabled, any of them can open a port.
• Linux images with no policy: cloud and container hosts launch with no rules loaded because the team assumed security groups were enough, leaving peers in the same subnet fully reachable.
• No logging of drops: without dropped-packet logs, the first sign of a spreading infection is encryption rather than a burst of blocked SMB attempts. Ransomware operators commonly move with SMB, RDP and remote management; see the Ransomware Prevention Guide.

Practitioner checklist

• Confirm the host firewall is enabled on every profile on every managed Windows, macOS and Linux host, and report exceptions.
• Block inbound SMB, RDP, WinRM and RPC between workstations, with allows scoped to named management sources.
• Restrict server inbound rules to role-specific services and administration subnets.
• Decide per tier whether local rule merge (AllowLocalPolicyMerge) is allowed, and disable it on servers and privileged workstations.
• Deploy allow rules before first launch and disable inbound notifications on non-admin Windows devices.
• Enable dropped-packet logging, Audit Filtering Platform Connection failure events and Audit MPSSVC Rule-Level Policy Change, and forward them centrally.
• Alert on firewall rule changes and disabled profiles outside approved change windows.
• Scan internally each quarter to measure peer reachability on admin ports.
• Keep the previous policy version ready to reassign as the rollback path.

Standards and references

• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• Microsoft Learn: Windows Firewall overview
• Microsoft Learn: Windows Firewall rules
• Microsoft Learn: Configure Windows Firewall logging
• Microsoft Learn: Audit MPSSVC Rule-Level Policy Change
• Microsoft Learn: Audit Filtering Platform Connection
• Apple Platform Deployment: Firewall payload settings
• MITRE ATT&CK: T1686 Disable or Modify System Firewall

Related NHI Mgmt Group resources: Windows Defender Firewall Guide · Linux Firewall Guide · Lateral Movement Guide · Network Segmentation Guide