Windows Firewall Configuration

Why this risk matters

Windows Firewall blocks unsolicited inbound network connections at the host level. When it is disabled or misconfigured, devices become reachable on any open port — both from the internet and from other devices on the same local network. This is the primary mechanism attackers use for lateral movement after compromising one endpoint: they scan the internal network for exposed SMB, RDP, WMI, and admin share ports on devices where the firewall is off.

Disabling the firewall is a common outcome in misconfigured enterprise builds where IT teams turn it off to avoid troubleshooting application connectivity issues. This leaves every device on the same network segment reachable by any other compromised host, dramatically lowering the cost of a ransomware operator moving from patient zero across the rest of the organisation.

Windows Firewall has three distinct profiles — Domain, Private, and Public — and all three need to be active. Devices that roam between coffee shops, home networks, and the corporate network are at particular risk if only the Domain profile is enforced.

What happens if this is abused

When Windows Firewall is disabled or set to allow all inbound traffic, attackers can:

  • Scan internal devices for open SMB (445), RDP (3389), WMI, and admin share ports and connect to them directly without needing credentials if those services have vulnerabilities.
  • Move laterally from a single compromised endpoint to any other device on the same network that has the firewall off — a key step in ransomware deployment.
  • Use exposed administrative shares (C$, ADMIN$) to deploy malware payloads or run remote commands across multiple machines simultaneously.
  • Exploit the Public network profile gap: a device that has the Domain profile firewall enforced but Public profile disabled is fully exposed whenever it connects to a non-domain network (home Wi-Fi, coffee shop, hotel).

When this is expected or acceptable

Windows Firewall being disabled or misconfigured is rarely acceptable. The following are the narrow exceptions.

  • If a third-party host-based firewall is deployed and actively managing inbound and outbound rules (e.g., CrowdStrike Falcon Firewall Management, Palo Alto Cortex XDR), Windows Firewall may be disabled in favour of that tool. Confirm the alternative tool is active, policy-enforced, and covering all three network profiles before treating the Windows Firewall finding as resolved.
  • Specific inbound rules may be required for legitimate software: remote management tools, SCCM or Intune management extensions, development environments, line-of-business applications. These should be scoped to specific ports and source IP ranges rather than open allow-all rules.
  • In domain-joined environments, the Domain network profile is typically configured more permissively than the Private or Public profiles. This is expected. A permissive Public profile is not acceptable under any circumstances.

Checks to perform before taking action

Before enforcing firewall policy or modifying existing rules:

  • Is a third-party firewall management tool deployed on this device? Check your endpoint security console for an approved alternative before pushing a native Windows Firewall policy that may conflict with existing rules.
  • Which of the three profiles is affected — Domain, Private, or Public? Public profile exposure is the highest risk. Each profile should be evaluated and remediated separately.
  • Are there specific inbound rules that need to be preserved? Review existing allow rules in Intune or directly on the device before deploying a default-block inbound policy, to avoid breaking legitimate network connectivity.
  • What is the device's primary network type? Devices that connect to public Wi-Fi regularly (remote workers, road warriors) are higher priority than devices in secured office environments.
  • Has any lateral movement been attempted from or to this device? Check Microsoft Defender for Endpoint or SIEM logs for suspicious SMB (445), RDP (3389), or WMI connection attempts before making changes.

Safe remediation steps

Enable and enforce Windows Firewall settings via Intune Endpoint Security:

  1. Audit current firewall state — in Intune, navigate to Endpoint Security → Firewall. Review devices reporting firewall as off across any of the three profiles.
  2. Create a Firewall policy — in Endpoint Security → Firewall, create a new Microsoft Defender Firewall policy for Windows 10/11. Enable all three profiles (Domain, Private, Public) and set Default Inbound Action to Block for each.
  3. Enable stealth mode — set Disable Stealth Mode = Not configured (leave stealth active) for all profiles. This reduces the device's network footprint on untrusted networks.
  4. Pilot before broad rollout — assign the policy to a pilot group first. Monitor for application connectivity issues. Common sources of breakage: custom LOB apps using unusual inbound ports, remote desktop tools, print sharing, and network discovery for file shares.
  5. Create inbound rules for legitimate traffic — if specific applications require inbound access, add explicit allow rules in the same Firewall policy rather than disabling the firewall entirely. Scope rules to specific ports, protocols, and source addresses where possible.
  6. Roll out to all devices — once the pilot is stable, assign to all device groups. Windows Firewall enforcement via Intune takes precedence over local Group Policy and cannot be disabled by standard users.
  7. Include in compliance policy — add a firewall-enabled compliance condition in Intune so non-compliant devices are flagged for Conditional Access enforcement.

How Overe Helps

Overe actively monitors and remediates this risk area. The following controls can be deployed and tracked in app.overe.io:

  • Windows Firewall Configuration — Blocks unauthorized inbound network traffic across all Windows network profiles, hiding devices from network probing.
  • Windows Device Security — Ensures Windows devices have hardware-backed security and active protection against network and malware threats.
  • Windows Device Security Hardening — Closes common Windows network attack vectors including SMBv1, insecure routing, and unauthenticated network bridges.

Supporting documentation

Related risks and follow-on checks

After reviewing Windows Firewall configuration, also check these related risk areas:

  • Windows Defender Protection — endpoint malware protection that works alongside the firewall to prevent execution of threats that do reach the device.
  • Windows Attack Surface Reduction — complementary host-hardening capability that limits exploit techniques even when a connection reaches the endpoint.
  • Windows Local Admin Control — local admin rights can be used to modify or disable Windows Firewall rules without MDM policy enforcement.
  • Intune Policy Coverage Gaps — if Endpoint Security firewall policies are not uniformly applied across the device fleet, firewall misconfiguration is expected.
  • Devices Overview — unmanaged devices will not receive firewall policy from Intune and present the same open-port risk described in this recommendation.
Free Microsoft 365 assessment

Check this risk in your own tenant

This recommendation explains what should be configured. Overe shows you where the gaps actually exist.

Find risky users, devices, apps, policies and tenant settings in minutes.

No agents. No heavy setup. Clear results in minutes.