Windows Firewall hardening against lateral movement

Every supported Windows machine ships with a capable stateful host firewall. In many environments it is either switched off ("the network firewall handles it") or left in its default state, where installers and local admins can add inbound rules freely. Used properly, it is one of the cheapest and most effective controls against lateral movement: the technique that turns one compromised laptop into a compromised network.

This guide builds a policy for workstations and servers with Group Policy (the same settings exist in Intune under Endpoint security > Firewall).

Principles

1. All three profiles on (Domain, Private, Public), enforced by policy.
2. Default inbound: block. Only explicitly allowed traffic comes in.
3. Only central rules count. Local rule merge is disabled.
4. Admin protocols come only from admin networks. RDP, WinRM, SMB, RPC and WMI are reachable from jump hosts and PAWs, not from every other client.
5. Log drops, size the log, and collect it.

Step 1: profile settings

GPO path: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Open the properties and set, for each of the Domain, Private and Public profiles:

The PowerShell equivalent, useful for testing on a single machine:

Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
  -DefaultInboundAction Block -DefaultOutboundAction Allow `
  -NotifyOnListen False -AllowLocalFirewallRules False `
  -LogBlocked True -LogMaxSizeKilobytes 16384 `
  -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"

Check the effective state (the merged result of local and Group Policy settings):

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction, AllowLocalFirewallRules, LogBlocked

With AllowLocalFirewallRules set to False, rules that software installers created locally are ignored. This is intentional, and the reason to inventory which inbound rules your applications really need (step 3) before rollout.

Step 2: workstation rules

Workstations need very little inbound traffic. A realistic allow list:

Everything else, notably SMB, RPC and WinRM from other workstations, stays blocked. That single decision stops most "hop from laptop to laptop" movement used by ransomware affiliates.

Scoped rules look like this (GPO rules are the same with the Scope tab):

New-NetFirewallRule -DisplayName "RDP from Tier2 admin subnet" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 10.20.50.0/24 -Action Allow -Profile Domain

New-NetFirewallRule -DisplayName "SMB from management servers" -Direction Inbound `
  -Protocol TCP -LocalPort 445 -RemoteAddress 10.20.10.11,10.20.10.12 -Action Allow -Profile Domain

Be careful with the predefined rule groups such as Remote Desktop, File and Printer Sharing or Windows Remote Management: enabling the group enables rules with a remote scope of Any. Either edit their scope in the GPO or create your own scoped rules instead.

Step 3: server rules

Servers need inbound rules for the service they provide, plus scoped management:

• Application ports (HTTPS 443 on a web server, 1433 on SQL Server) scoped to the clients or load balancers that use them, not "Any" if you can avoid it.
• Management ports scoped to Tier 1 jump hosts or PAWs.
• On domain controllers, the full set of AD ports (Kerberos 88, LDAP 389/636, GC 3268/3269, DNS 53, SMB 445, RPC 135 and the dynamic range) must remain reachable by all domain members; restrict management protocols (RDP, WinRM) to Tier 0 admin hosts.

Before enforcing, inventory what actually listens and who connects:

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
  Sort-Object LocalPort -Unique

Combine that with a few days of pfirewall.log with successful connections logging turned on, so the rules match reality rather than documentation.

Outbound on servers. Most servers only need to talk to a known set of destinations: DNS, domain controllers, update servers, their database. Default-deny outbound on Tier 0 servers in particular makes command-and-control and data exfiltration much harder. Start with log successful connections to build the list, then switch the default outbound action to Block with allow rules.

Step 4: block the usual abuse

A few extra rules worth considering:

• Block inbound from the Public profile entirely on laptops (the default block does this if you add no Public allow rules).
• Block outbound SMB (TCP 445) to the internet at the host level; there is no legitimate reason for it and it prevents credential leaks via forced authentication to external hosts.
• Block mshta.exe, wscript.exe, cscript.exe and similar script hosts from making outbound connections where they are not used. Application control is the stronger fix, but this is cheap.

New-NetFirewallRule -DisplayName "Block outbound SMB to Internet" -Direction Outbound `
  -Protocol TCP -RemotePort 445 -RemoteAddress Internet -Action Block

Internet is a built-in keyword that excludes the local subnet and private ranges defined as intranet; check it matches your addressing, or list your internal ranges explicitly with an allow rule.

Step 5: logging and monitoring

pfirewall.log is a plain text log on each host. It is useful during investigations but rarely collected. Options:

• Collect it with your log agent.
• Or enable Windows Filtering Platform auditing (Advanced Audit Policy > Object Access > Filtering Platform Connection, failures only), which produces security events 5157 for blocked connections. This is very noisy with success auditing, so start with failures and filter at the collector.
• Always monitor firewall configuration changes: security events 4946-4948 (rule added, modified, deleted) and 4950 (setting changed), from Audit MPSSVC Rule-Level Policy Change.

An attacker who disables the firewall or adds an allow rule for their tool leaves exactly these events.

Checklist

• Firewall on in all profiles, enforced by GPO or Intune
• Inbound default block; local rule merge disabled
• Workstations accept RDP/WinRM/SMB/RPC only from admin and management hosts
• Predefined rule groups replaced or re-scoped
• Server rules built from listening ports and observed connections
• Tier 0 servers default-deny outbound
• Dropped packets logged; rule-change events 4946-4950 alerted

Host firewalls complement admin tiering: tiering stops privileged credentials from reaching workstations, and the firewall stops workstations from being useful stepping stones even when some credential does leak.