Windows Firewall Management with CrowdStrike Falcon

Overview

CrowdStrike Falcon Firewall Management is a Falcon platform module that centrally manages host firewall policy on Windows, macOS, and Linux. It is delivered through the same Falcon sensor and console as the rest of the platform.[1][2][4] This article covers the Windows side: how Falcon enforces policy on a Windows host, how that relates to Windows Defender Firewall and other policy sources (local, Group Policy, Intune), and how to verify, troubleshoot, and roll back changes safely.

How to read this article. Statements about Falcon come from CrowdStrike’s public product pages, its data sheet, a CrowdStrike trial guide, the CrowdStrike Developer Center (API and Terraform references), and CrowdStrike’s own open-source tooling. Much of CrowdStrike’s operational documentation is only available inside the Falcon console to signed-in customers. Anything that couldn’t be confirmed from public sources is marked Verify in the Falcon console documentation instead of being guessed. All examples are illustrative. Hostnames and addresses use reserved documentation values (example.com, RFC 5737 ranges).

How Falcon Firewall Management works with Windows Defender Firewall

The enforcement layer: Windows Filtering Platform

Windows Filtering Platform (WFP) is the set of Windows APIs and system services that network filtering products are built on. Microsoft notes that WFP is “a development platform and not a firewall itself”. Windows Defender Firewall with Advanced Security is implemented on WFP, and any product written against WFP shares the same filter arbitration logic.[18]

CrowdStrike describes Falcon Firewall Management as a way to manage “host firewalls that are native to the operating system”.[3] CrowdStrike’s open-source PowerShell module CRWD-HBFW shows how this works on Windows:[11]

• The host-based firewall is enabled through the Falcon sensor on the endpoint and controlled through a channel file delivered to that endpoint.
• The sensor creates WFP filters, named CrowdStrike WFP Filter, that represent the active Falcon policy rules. CRWD-HBFW finds them by enumerating WFP filters, not Windows Defender Firewall rules.
• When a policy uses multiple network locations, the sensor adds or removes WFP filters depending on which location is currently active.

In practice, Falcon rules are WFP filters created by the sensor. Rules you create in wf.msc, netsh advfirewall firewall, Group Policy, or Intune are Windows Defender Firewall rules that the Windows Firewall service turns into its own WFP filters. Both end up in the same WFP engine, so both affect the same traffic. They are just managed and inspected with different tools.

What “Enforce policy” does to native rules

CrowdStrike’s Terraform provider documentation describes the policy enforce setting this way: when enabled, Falcon will “override the firewall settings on each assigned host” and “disables native firewall rules”. When enforce is false, “the policy’s rules are not applied”.[5][8]

Microsoft’s guidance for non-Microsoft firewalls is consistent with this. Third-party firewall software “can programmatically disable only the rule types of Windows Firewall that need to be disabled for compatibility”. Administrators shouldn’t disable Windows Firewall themselves, and should never stop the MpsSvc service, which Microsoft doesn’t support.[12]

Verify in the Falcon console documentation

• Exactly which Windows Defender Firewall settings and rule types an enforced Falcon policy disables or overrides, and whether Windows Defender Firewall profiles show as on or off afterwards.
• Whether Falcon registers as the active firewall provider in Windows Security, and what Windows Security shows.
• What happens to native Windows rules (local, GPO, Intune) when enforcement is turned off or the policy is unassigned. Are they restored automatically?
• CrowdStrike’s recommended state for Windows Defender Firewall profiles, MpsSvc, and existing GPO or Intune firewall policies on hosts that receive an enforced Falcon policy.

The building blocks

CrowdStrike’s trial guide and API references describe three core objects, plus network locations:[3][5][6][9]

According to the data sheet, policies can start empty, from your own template, or from a CrowdStrike template. Rule groups can be cloned from a CrowdStrike library. Rules are validated to stop faulty entries, and changes are audited, showing what changed, who changed it, and when.[2][9]

Prerequisites, licensing, permissions, and supported systems

What is publicly documented

• Sensor. Falcon Firewall Management is delivered through the Falcon sensor and the same cloud console. No separate agent is described.[1][2]
• Licensing. It is a separately named module of the Falcon platform (“Falcon Firewall Management”), and CrowdStrike calls the host-based firewall “a module from the CrowdStrike Endpoint Protection Platform”.[2][11]
• Operating systems. Windows, macOS, and Linux are supported.[1][4] The data sheet links to a separate list for specific OS versions.[2]
• Access control. The data sheet states that role-based access control limits who can view and manage firewall rules.[2]
• API access. The Falcon APIs use the scopes Firewall management: READ and Firewall management: WRITE. Managing firewall policy precedence through Terraform also needs Sensor Download: READ in some multi-tenant (Flight Control) setups.[5][7][9][10]
• Endpoint tooling. The CRWD-HBFW module requires Windows 10/11 or Windows Server 2016 and later, an elevated session, the Base Filtering Engine (BFE) service running, and the Falcon sensor installed. These are requirements for that diagnostic module, not for the Falcon product itself.[11]

Verify in the Falcon console documentation

• Which subscription bundles include Falcon Firewall Management, and whether it is licensed per endpoint.
• The supported Windows client and server versions and the minimum sensor version for each firewall feature (FQDN rules, network locations, service-name rules, local logging).
• The names of the Falcon console roles that can view, edit, and assign firewall policies and rule groups.
• Any conflicts with other host firewalls or network filtering products, and any required exclusions.

Firewall policies, host groups, precedence, and rule ordering

Assigning policies to hosts

A firewall policy only applies to hosts in a host group that the policy is assigned to. CrowdStrike describes a host group as a set of hosts with similar characteristics, such as operating system or type of user.[3] The Firewall Policies API supports add-host-group, remove-host-group, add-rule-group, remove-rule-group, enable, and disable actions.[10] The trial guide describes a default policy that exists alongside any custom policies.[3]

Policy precedence

Firewall policies are ranked per platform. The API sets precedence “based on the order of IDs specified”, and the Terraform reference states that the first ID has the highest precedence and the last ID the lowest. The precedence operation covers non-default policies.[7][10]

Verify in the Falcon console documentation

• Which policy a host receives when it belongs to several host groups that are assigned different firewall policies. The common Falcon model is that the highest-precedence policy wins, but confirm this for firewall policies specifically.
• How the default firewall policy applies to hosts that aren’t in any assigned group, and whether its settings (enforcement, default actions) can be edited.

Rule-group and rule order

• Rule groups inside a policy. The order of rule_group_ids sets precedence, and the first group has the highest priority.[5][8]
• Rules inside a group. Rule precedence is set by the order of rules in the group.[6] The console lets you reorder rules, for example with the “Edit Precedence” control described in the trial guide.[2][3] The API can return a policy’s effective rules “in precedence order”.[9]

Verify in the Falcon console documentation: whether Falcon uses first-match evaluation across the ordered rule list, and how an explicit allow and an explicit deny interact when both match the same traffic.

How this differs from Windows Defender Firewall

Windows Defender Firewall doesn’t support administrator-assigned rule ordering. Microsoft documents these precedence behaviors instead:[13]

1. Explicit allow rules take precedence over the default block setting.
2. Explicit block rules take precedence over any conflicting allow rules.
3. More specific rules take precedence over less specific ones, except where rule 2 applies.

Underneath both products, WFP evaluates filters by sublayer and weight. Across sublayers, “Block” overrides “Permit” by default, and a filter-generated block is a hard block that a lower-priority sublayer can’t override.[19] This is why a block from one policy source can defeat an allow from another, even when both look correct in their own management tools.

Inbound vs. outbound rules, profiles, and default actions

Falcon policy defaults

Each Falcon firewall policy has a default inbound action and a default outbound action. Each can be set to ALLOW (shown as “Allow all” in the console) or DENY (“Block all”). The documented defaults are inbound: DENY and outbound: ALLOW.[5] The trial guide describes this as the “Default traffic rules” section: by default, all inbound traffic is blocked and all outbound traffic is allowed.[3]

Falcon rule direction and location

• direction can be IN, OUT, or BOTH.[6]
• network_location can be one of the built-in values ANY, DOMAIN, PRIVATE, or PUBLIC, or a custom network location ID. Only ANY is valid on Linux.[6]
• FQDN matching (including wildcards such as *.example.com) is valid only on outbound rules.[6]
• service_name scopes a rule to a Windows service. It is valid only on Windows.[6]

Verify in the Falcon console documentation: how the sensor decides that a Windows host is on the DOMAIN, PRIVATE, or PUBLIC location (for example, whether it uses the Windows network category), how custom network locations are evaluated against the built-in ones, and how often location checks run (the API exposes “polling intervals” metadata but public docs don’t give values).[9]

Windows Defender Firewall profiles (for comparison)

Windows uses three network profiles: Domain, Private, and Public. Public is the default for unidentified networks.[12] Get-NetConnectionProfile shows each interface’s category (Public, Private, DomainAuthenticated).[25] Windows default actions are set per profile, for example blockinbound and allowoutbound in netsh advfirewall set ... firewallpolicy.[26] Microsoft recommends keeping inbound default-block. It suggests allowing outbound by default in most deployments, unless an organization accepts the operating cost of default-deny outbound.[13]

Falcon-managed settings vs. Windows, Group Policy, and Intune

Warning: one manager per control. A Windows host can receive firewall policy from Falcon, Group Policy (domain or local), Intune/MDM through the Firewall CSP, and local administrators all at once. They all end up in the same WFP engine, and blocks generally win.[19] Running more than one active firewall manager on the same host is the most common source of rules that look correct but don’t work. Choose one authoritative manager per host population, document it, and remove or neutralize the others.

Two Microsoft details matter when Windows policy sources coexist:

• Local Group Policy still applies even when rule merging is turned off through MDM or domain Group Policy.[13]
• Partial Intune deployments. On Windows versions earlier than Windows 11 21H2/22H2 and Windows 10 21H2, an error inside an Atomic block of rules from Intune can leave rules only partly applied. Newer builds apply each Atomic block all-or-nothing.[31]

Verifying the assigned policy, application status, and effective rules

On the Falcon side

What’s publicly documented:

• Policy objects expose enabled, enforce, monitor_mode, local_logging, default actions, attached host_groups, and rule_group_ids in precedence order, along with who changed them and when.[8]
• The API can list a policy’s member hosts (queryCombinedFirewallPolicyMembers) and return a policy’s rules in precedence order (query_policy_rules).[9][10]
• Firewall events retrieved through the API include fields such as host_name, policy_name, rule_action, connection_direction, network_profile, local_port/remote_port, remote_address, and image_file_name.[9]
• The console’s activity view shows matched rules and monitored network connections.[1][2]

Verify in the Falcon console documentation

• Where the console shows, for a single host, the firewall policy assigned to it, the policy version, and whether that version was successfully applied, and what the possible status values mean.
• The expected delay between saving a policy change and the sensor applying it, and whether the host has to be online at that moment.
• Which firewall events reach the cloud while a policy is enforced versus in monitor mode, and how often event summaries are sent.

On the Windows endpoint (read-only commands)

Run these in an elevated PowerShell or Command Prompt. All commands in this section are read-only. None of them changes firewall state. Some write an output file when you ask them to.

1. Network category per interface

# Read-only: which network category each interface is in
Get-NetConnectionProfile | Select-Object InterfaceAlias, Name, NetworkCategory

2. Effective Windows Defender Firewall profile settings

ActiveStore is the sum of every policy store that applies to the computer: Group Policy RSOP, the local persistent store, and the Windows service hardening stores.[22][23] Microsoft recommends reading enforced global settings from ActiveStore as well.[24]

# Read-only: effective profile state, default actions, merge setting, logging
Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
                AllowLocalFirewallRules, LogFileName, LogAllowed, LogBlocked

# Read-only: effective global firewall settings
Get-NetFirewallSetting -PolicyStore ActiveStore

REM Read-only equivalents (Command Prompt)
netsh advfirewall show allprofiles
netsh advfirewall show currentprofile
netsh advfirewall monitor show currentprofile
netsh advfirewall monitor show firewall

show allprofiles reports state, default inbound/outbound policy, settings, and logging for each profile. monitor show firewall shows the runtime firewall state.[26]

3. Effective Windows rules and where they came from

# Read-only: enabled Windows Defender Firewall rules in the merged active policy,
# with the policy store each rule came from (e.g., GroupPolicy)
Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -TracePolicyStore |
  Select-Object DisplayName, Direction, Action, Profile,
                PolicyStoreSource, PolicyStoreSourceType |
  Sort-Object Direction, Action, DisplayName

# Read-only: Group Policy-delivered rules only
Get-NetFirewallRule -PolicyStore RSOP |
  Select-Object DisplayName, Direction, Action, Enabled, Profile

-TracePolicyStore fills in PolicyStoreSource and PolicyStoreSourceType, which identify the originating store, for example GroupPolicy.[22][32] Ports, addresses, and programs live in separate filter objects. Get them with Get-NetFirewallPortFilter, Get-NetFirewallAddressFilter, Get-NetFirewallApplicationFilter, and Get-NetFirewallServiceFilter.[15][32]

# Read-only: show the conditions of one rule (illustrative rule name)
$rule = Get-NetFirewallRule -PolicyStore ActiveStore -DisplayName 'Example - Inbound - App Service'
$rule | Get-NetFirewallPortFilter
$rule | Get-NetFirewallAddressFilter
$rule | Get-NetFirewallApplicationFilter

4. Group Policy result

REM Read-only: computer-scope RSoP summary, or a full HTML report
gpresult /scope computer /r
gpresult /scope computer /h C:\Temp\gpresult.html

gpresult requires an output option (/r, /v, /z, /x, or /h). /scope computer limits output to computer policy.[28]

5. Falcon-created WFP filters

Falcon rules don’t appear in Get-NetFirewallRule. To see what is actually enforced in WFP, including filters created by the Falcon sensor, dump the filters:

REM Read-only: write current WFP filters / state to XML files for review
netsh wfp show filters file=C:\Temp\filters.xml
netsh wfp show state file=C:\Temp\wfpstate.xml

REM Read-only: filters relevant to a specific flow (illustrative: outbound TCP 443 to 192.0.2.10)
netsh wfp show filters file=- protocol=6 remoteaddr=192.0.2.10 remoteport=443 dir=out

show filters accepts protocol, address, port, appid, userid, dir, and verbose parameters. file=- prints to the console instead of writing a file.[27] In the output, search for filters named CrowdStrike WFP Filter.[11]

CrowdStrike’s CRWD-HBFW module wraps this enumeration and returns only Falcon filters, with readable conditions (ports, addresses, application).[11]

Optional, changes system state: installing a PowerShell module modifies the host. Get approval under your change process first, and prefer a lab or test host.

powershellCopy

# State-changing (installs a module from PowerShell Gallery). Optional.
Install-Module crwd-hbfw

Once installed, querying is read-only:

powershellCopy

# Read-only: Falcon WFP filters permitting inbound TCP 3389 (illustrative)
Get-CrwdHbfw -ActionType 'Permit' -LPort 3389 -Protocol Tcp | Format-Table

# Read-only: Falcon block filters toward a documentation subnet (illustrative)
Get-CrwdHbfw -ActionType 'Block' -RIP 198.51.100.0/24 | Format-Table

6. GUI

wf.msc (Windows Defender Firewall with Advanced Security) shows Windows rules and profile settings. It doesn’t show Falcon WFP filters, and Microsoft notes that rules from the MDM store can’t be searched in the Windows Firewall UI.[17]

Troubleshooting

Blocked connections

Use a fixed sequence instead of editing whichever rule looks most relevant. Microsoft’s diagnostic order is: confirm the application is listening, confirm routing and name resolution, confirm the active network profile, inspect the active policy store, identify the matching rule and where it came from, check its address/port/program/service/profile conditions, then correlate logs and packet capture.[32]

Find the filter that blocked the traffic. With WFP auditing enabled (see Logging), a blocked connection produces Security event 5157, and a dropped packet produces 5152.[20] Event 5157 records the application, direction, addresses, ports, and the Filter Run-Time ID.[21] On Windows 11 and Windows Server 2022 and later, 5157 and 5152 also include Filter Origin and Interface Index:[17]

• If Filter Origin is a Windows Firewall rule ID, look it up with Get-NetFirewallRule -Name "<Filter Origin>".[17]
• If it names a default block filter (Boot time default, Quarantine default, Query user default, Stealth, UWP default, WSH default, and so on), follow Microsoft’s guidance for that origin. Quarantine-related drops are often transient and follow a network change.[17]
• Otherwise, search the WFP state dump (netsh wfp show state) for the Filter Run-Time ID to find which filter it is. Filter IDs can change, so capture the state immediately after reproducing the problem.[17][21] If the matching filter is named CrowdStrike WFP Filter, the block came from Falcon policy.[11] Continue in the Falcon console (firewall events, matched rule) instead of in Windows tools.

Interpreting a Falcon-originated block through Filter Origin is an inference from Microsoft and CrowdStrike documentation, not a documented CrowdStrike procedure. Verify in the Falcon console documentation what value Filter Origin shows for Falcon filters.

# Read-only: most recent WFP "connection blocked" events (requires auditing enabled)
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 5157 } -MaxEvents 20 |
  Select-Object TimeCreated, Id, Message

Check Windows profile drops. If firewall logging is on, dropped packets appear in pfirewall.log (default %windir%\system32\logfiles\firewall\pfirewall.log).[16] A drop record proves the packet reached the host firewall. It doesn’t prove the application was listening or that authentication succeeded.[33]

Policy conflicts (Falcon vs. GPO vs. Intune vs. local)

Signs of a conflict:

• Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore shows enabled rules from GroupPolicy or MDM sources on a host that is also assigned an enforced Falcon policy.
• A flow is allowed in Falcon but still blocked, and the blocking filter turns out to be a Windows rule or default filter. Or the reverse.
• Settings “revert” after you change them locally. That usually means a central manager (GPO, Intune, or Falcon) is reapplying policy.

Things to check:

1. Merge settings. AllowLocalFirewallRules on each profile in ActiveStore.[23] Remember that Local Group Policy applies even when merge is disabled.[13]
2. Overlapping explicit blocks. A Windows block rule beats a Windows allow rule,[13] and a WFP hard block in one sublayer can’t be overridden by a permit in another.[19]
3. Intune Atomic-block failures on older Windows builds can leave partial rule sets.[31]
4. Ownership. Confirm which manager is meant to own the firewall for this host group, then remove the others’ firewall policy targeting for those hosts. That change happens in the GPO, Intune, or Falcon assignments, not on the endpoint.

Changes that haven’t applied

Falcon policy changes

• Confirm the policy is enabled, enforce is on, and the rule group and rule are enabled. The data sheet notes that individual rules, rule groups, and policies can each be turned on or off independently.[2][5][6]
• Confirm whether monitor mode (policy level) or watch mode (rule level) is on. Monitor mode allows all traffic and reports blocks as “would be blocked”, so nothing is actually blocked.[5][6]
• Confirm the host is in a host group assigned to the policy, and that no higher-precedence firewall policy also applies to it.[7][10]
• Confirm the rule’s direction, protocol, and network location match the traffic. FQDN conditions only apply to outbound rules.[6]
• On the endpoint, look for the expected CrowdStrike WFP Filter entries (via netsh wfp show filters or CRWD-HBFW).[11][27]

Verify in the Falcon console documentation: how to confirm on a specific host that the latest policy version was received and applied, the expected delivery time, and whether any host-side action is supported or needed to apply it.

Group Policy changes

By default, Group Policy refreshes in the background every 90 minutes with a random 0–30 minute offset. Firewall changes rewrite WFP filters and can briefly disconnect IPsec connections.[14] Microsoft warns that turning on “Process even if the Group Policy objects haven’t changed” makes WFP filters reapply at every refresh and can leave settings incomplete if an error happens. Leave it at its default.[14] gpupdate /force is Microsoft’s temporary fix and needs connectivity to a domain controller.[14]

Intune changes

Check for Atomic-block failures (see above) and confirm the device received the policy.[31]

Logging

Windows Defender Firewall log

• Logging of dropped packets and successful connections is off by default.[33] The default log path is %windir%\system32\logfiles\firewall\pfirewall.log, and the default maximum size is 4,096 KB.[16]
• Microsoft recommends at least 20,480 KB (the maximum is 32,767 KB) and a separate log file per profile.[16]
• The Windows Firewall service (mpssvc) must have write permission on the log folder. If logging is configured by policy, the folder may need to be created manually.[16]
• Logging can be configured through Intune (Endpoint security › Firewall), Group Policy, PowerShell, or netsh.[16][33]

This log covers Windows Defender Firewall decisions. Verify in the Falcon console documentation whether traffic dropped by Falcon WFP filters appears in pfirewall.log. Use WFP auditing (below) for complete coverage.

Optional, changes system state: turning on logging changes firewall configuration. On hosts where GPO or Intune manages logging, change it there instead of locally.

powershellCopy

# State-changing. Optional. Enables logging on all profiles (per Microsoft Learn).
Set-NetFirewallProfile -Profile Domain,Private,Public -LogBlocked True -LogAllowed True

WFP audit events

WFP auditing is disabled by default. The relevant subcategories and events are:[20]

auditpol /get reports the current audit policy without changing it.[29]

REM Read-only: current audit settings for the WFP subcategories
auditpol /get /subcategory:"Filtering Platform Connection"
auditpol /get /subcategory:"Filtering Platform Packet Drop"

Optional, changes system state: turning on auditing changes the audit policy, and “success” auditing on Filtering Platform Connection can generate very high event volume. Prefer failure-only for troubleshooting, limit it to the affected host, and revert it afterwards. If audit policy is managed by GPO, change it there.

textCopy

REM State-changing. Optional. Commands as published on Microsoft Learn.
auditpol /set /subcategory:"Filtering Platform Connection" /failure:enable
auditpol /set /subcategory:"Filtering Platform Packet Drop" /failure:enable

The commands above match Microsoft’s Filter Origin article.[17] Category and subcategory names are localized, so scripts can use the subcategory GUIDs instead.[20]

Falcon-side logging

• Local logging (policy setting) saves “a record of all firewall rule events” on the host’s local drive to help troubleshooting.[5]
• Per-rule logging is a rule attribute (log).[9]
• Firewall events are available in the console activity view and through the Firewall Management API (query_events and get_events).[1][9]
• Audit trail. Rule and policy changes are audited: what changed, who changed it, and when.[2]

Verify in the Falcon console documentation: the on-disk location and format of the local firewall log, and its retention and size limits; which events are sent to the cloud while a policy is enforced versus in monitor mode; and the event names to use when hunting firewall rule matches in Falcon event search.

Practical troubleshooting checklist

1. Scope the problem. Record the source, destination, protocol, port, direction, application, time (UTC), and affected host group.
2. Identify the firewall owner for this host: Falcon, GPO, Intune, or local. Check the Falcon policy assignment, gpresult /scope computer /r, and the Intune assignment.
3. Check the Falcon policy state. Is it enabled? Is enforce on? Is monitor mode on? Are the relevant rule groups and rules enabled? Is watch mode on for the rule? What precedence do the policy, rule group, and rule have?
4. Check the network location. Run Get-NetConnectionProfile, and compare with the Falcon rule’s network location.
5. Check the effective Windows policy. Run Get-NetFirewallProfile -PolicyStore ActiveStore and Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore.
6. Check what is actually enforced. Run netsh wfp show filters (or CRWD-HBFW) and look for CrowdStrike WFP Filter entries.
7. Reproduce and capture evidence. Collect event 5157/5152 (Filter Origin, Filter Run-Time ID), pfirewall.log, Falcon firewall events, and netsh wfp show state taken right after reproducing.
8. Attribute the block. Is it a Windows rule, a Windows default filter, or a Falcon filter?
9. Make one controlled change with the owning manager, retest, and compare evidence.[32] Don’t stop the firewall service, add unrestricted allow rules, or remove block rules without understanding why they exist.[32]
10. Document the outcome: the rule changed, why, who approved it, and how to roll it back.

Rollback considerations

Falcon

These rollback levers are documented:

• Turn off a single rule, a rule group, or the whole policy. The data sheet calls out this ability specifically for faster troubleshooting.[2] The Firewall Policies API exposes disable and enable actions.[10]
• Switch to monitor mode. This allows all traffic while still reporting what would have been blocked. Monitor mode requires enforce to be on.[5] For a single rule, use watch mode.[6]
• Turn off enforcement. With enforce false, “the policy’s rules are not applied”.[5]
• Unassign the host group from the policy (remove-host-group), or change policy precedence so that a known-good policy applies.[7][10]
• Use the audit trail to see exactly what changed and who changed it, then reverse that change.[2]

Verify in the Falcon console documentation: what each of these actions leaves in place on the endpoint (for example, whether native Windows Firewall rules and profile settings return to their previous state), how long rollback takes to reach hosts, and whether rule or policy version history can be restored directly.

Windows

• Export before you change. Exporting the current Windows Firewall policy creates a restore point for Windows-managed rules. This writes a file but doesn’t change firewall behavior.[26]

  textCopy

  REM Writes a policy file; does not change firewall behavior.
  netsh advfirewall export "C:\Temp\wfas-before-change.wfw"
  

• Fix GPO and Intune settings at the source. Local edits are overwritten at the next refresh.[14]

• Avoid destructive shortcuts. netsh advfirewall reset restores Windows defaults and discards local configuration, and netsh advfirewall import replaces the local policy.[26] Neither undoes Falcon policy, and both can cut off remote management. Use them only under an approved change with console or out-of-band access. Don’t stop MpsSvc, which Microsoft doesn’t support.[12]

Safe-change pattern (illustrative)

Example: a new outbound allow rule for app.example.com over TCP 443 is tested first in a Falcon policy assigned to a small pilot host group with monitor mode on. Firewall events are reviewed for “would be blocked” results. Then monitor mode is turned off for the pilot group, and the policy is promoted to wider host groups in stages, using precedence and host group assignment. This is a generic pattern built from documented capabilities, not a description of a specific deployment.

References

1. CrowdStrike, “Falcon Firewall Management” product page. https://www.crowdstrike.com/en-us/platform/endpoint-security/falcon-firewall-management/
2. CrowdStrike, “Falcon Firewall Management” data sheet. https://assets.crowdstrike.com/is/content/crowdstrikeinc/crowdstrike-falcon-firewall-management-data-sheetpdf
3. CrowdStrike, “Falcon Firewall Trial Guide” (2020). https://www.crowdstrike.com/wp-content/uploads/2020/10/falcon-firewall-trial-guide.pdf
4. CrowdStrike, “CrowdStrike Deployment FAQ”. https://www.crowdstrike.com/en-us/products/faq/
5. CrowdStrike Developer Center, Terraform provider, firewall_policy resource. https://developer.crowdstrike.com/cac/terraform/provider/firewall-management/resources/firewall-policy/
6. CrowdStrike Developer Center, Terraform provider, firewall_rule_group resource. https://developer.crowdstrike.com/cac/terraform/provider/firewall-management/resources/firewall-rule-group/
7. CrowdStrike Developer Center, Terraform provider, firewall_policy_precedence resource. https://developer.crowdstrike.com/cac/terraform/provider/firewall-management/resources/firewall-policy-precedence/
8. CrowdStrike Developer Center, Terraform provider, firewall_policies data source. https://developer.crowdstrike.com/cac/terraform/provider/firewall-management/data-sources/firewall-policies/
9. CrowdStrike Developer Center, “Firewall Management” API service collection. https://developer.crowdstrike.com/api-reference/collections/firewall-management/
10. CrowdStrike Developer Center, “Firewall Policies” API service collection. https://developer.crowdstrike.com/api-reference/collections/firewall-policies/
11. CrowdStrike, CRWD-HBFW PowerShell module (GitHub). https://github.com/CrowdStrike/CRWD-HBFW
12. Microsoft Learn, “Windows Firewall overview”. https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/
13. Microsoft Learn, “Windows Firewall rules”. https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules
14. Microsoft Learn, “Windows Firewall tools”. https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/tools
15. Microsoft Learn, “Manage Windows Firewall with the command line”. https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line
16. Microsoft Learn, “Configure Windows Firewall logging”. https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging
17. Microsoft Learn, “Filter Origin Audit Log”. https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/filter-origin-documentation
18. Microsoft Learn, “Windows Filtering Platform”. https://learn.microsoft.com/en-us/windows/win32/fwp/windows-filtering-platform-start-page
19. Microsoft Learn, “Filter Arbitration” (WFP). https://learn.microsoft.com/en-us/windows/win32/fwp/filter-arbitration
20. Microsoft Learn, “Auditing” (WFP). https://learn.microsoft.com/en-us/windows/win32/fwp/auditing-and-logging
21. Microsoft Learn, “5157(F): The Windows Filtering Platform has blocked a connection”. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5157
22. Microsoft Learn, “Get-NetFirewallRule”. https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallrule
23. Microsoft Learn, “Get-NetFirewallProfile”. https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallprofile
24. Microsoft Learn, “Get-NetFirewallSetting”. https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallsetting
25. Microsoft Learn, “Get-NetConnectionProfile”. https://learn.microsoft.com/en-us/powershell/module/netconnection/get-netconnectionprofile
26. Microsoft Learn, “netsh advfirewall”. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-advfirewall
27. Microsoft Learn, “netsh wfp”. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wfp
28. Microsoft Learn, “gpresult”. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult
29. Microsoft Learn, “auditpol get”. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/auditpol-get
30. Microsoft Learn, “Firewall CSP”. https://learn.microsoft.com/en-us/windows/client-management/mdm/firewall-csp
31. Microsoft Learn, “Firewall policy for endpoint security in Intune”. https://learn.microsoft.com/en-us/intune/intune-service/protect/endpoint-security-firewall-policy
32. Microsoft Learn (training), “Troubleshoot active policy”. https://learn.microsoft.com/en-us/training/modules/understand-advanced-windows-firewall/10-troubleshoot-active-policy
33. Microsoft Learn (training), “Collect firewall evidence”. https://learn.microsoft.com/en-us/training/modules/understand-advanced-windows-firewall/9-collect-firewall-evidence