diff --git a/windows/security/threat-protection/windows-firewall/TOC.md b/windows/security/threat-protection/windows-firewall/TOC.md index 6d788f1ee0..00a5fecc08 100644 --- a/windows/security/threat-protection/windows-firewall/TOC.md +++ b/windows/security/threat-protection/windows-firewall/TOC.md @@ -165,6 +165,8 @@ ## [Troubleshooting]() ### [Troubleshooting UWP app connectivity issues in Windows Firewall](troubleshooting-uwp-firewall.md) +### [Filter origin audit log improvements](filter-origin-documentation.md) +### [Quarantine behavior](quarantine.md) ### [Firewall settings lost on upgrade](firewall-settings-lost-on-upgrade.md) @@ -179,3 +181,4 @@ + diff --git a/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md b/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md new file mode 100644 index 0000000000..7ef38e690b --- /dev/null +++ b/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md @@ -0,0 +1,171 @@ +--- +title: Filter origin audit log improvements +description: Filter origin documentation audit log improvements +ms.reviewer: +ms.author: v-bshilpa +ms.prod: w10 +ms.sitesec: library +ms.pagetype: security +ms.localizationpriority: normal +author: Benny-54 +manager: dansimp +ms.collection: +- m365-security-compliance +- m365-initiative-windows-security +ms.topic: troubleshooting +--- + +# Filter origin audit log improvements + +Debugging packet drops is a continuous issue to Windows customers. In the past, customers had limited information about packet drops. + +Typically, when investigating packet drop events, a customer would use the field `Filter Run-Time ID` from Windows Filtering Platform (WFP) audits 5157 or 5152. + +![Event properties](images/event-properties-5157.png) + +The filter ID uniquely identifies the filter that caused the packet drop. The filter ID can be searched in the WFP state dump output to trace back to the Firewall rule where the filter originated from. + +However, the filter ID is not a reliable source for tracing back to the filter or the rule, as the filter ID can change for many reasons despite the rule not changing at all. This makes the diagnosis process error-prone and difficult. + +For customers to debug packet drop events correctly and efficiently, they would need more context about the blocking filter such as its origin. + +The blocking filters can be categorized under these filter origins: + +1. Firewall rules + +2. Firewall default block filters + + a. AppContainer loopback + + b. Boottime default + + c. Quarantine default + + d. Query user default + + e. Stealth + + f. Universal Windows Platform (UWP) default + + g. Windows Service Hardening (WSH) default + +The next section describes the improvements made to audits 5157 and 5152, and how the above filter origins are used in these events. These improvements were added in Iron release. + + ## Improved firewall audit + +The two new fields added to the audit 5157 and 5152 events are `Filter Origin` and `Interface Index`. + +The `Filter Origin` field helps identify the cause of the drop. Packet drops from firewall are explicitly dropped by default block filters created by the Windows Firewall service or a firewall rule that may be created by users, policies, services, apps, etc. + +`Filter Origin` specifies either the rule ID (a unique identifier of a Firewall rule) or the name of one of the default block filters. + +The `Interface Index` field specifies the network interface in which the packet was dropped. This field helps to identify which interface was quarantined, if the `Filter Origin` is a `Quarantine Default`. + +To enable a specific audit event, run the corresponding command in an administrator command prompt: + +|**Audit #**|**Enable command**|**Link**| +|:-----|:-----|:-----| +|**5157**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable`|[5157(F): The Windows Filtering Platform has blocked a connection.](https://docs.microsoft.com/windows/security/threat-protection/auditing/event-5157)| +|**5152**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable`|[5152(F): The Windows Filtering Platform blocked a packet.](https://docs.microsoft.com/windows/security/threat-protection/auditing/event-5152)| + +## Example flow of debugging packet drops with filter origin + +As the audit surfaces `Filter Origin` and `Interface Index`, the network admin can determine the root cause of the network packet drop and the interface it happened on. + +![Event audit](images/event-audit-5157.png) + +The next sections are divided by `Filter Origin` type, the value is either a rule name or the name of one of the default block filters. If the filter origin is one of the default block filters, skip to the section, **Firewall default block filters**. Otherwise, continue to the section **Firewall rules**. + +## Firewall rules + +Run the following PowerShell command to generate the rule information using `Filter Origin`. + +```Powershell +Get-NetFirewallRule -Name “” +Get-NetFirewallRule -Name " {A549B7CF-0542-4B67-93F9-EEBCDD584377} " +``` + +![Firewall rule](images/firewallrule.png) + +After identifying the rule that caused the drop, the network admin can now modify/disable the rule to allow the traffic they want through command prompt or using the Windows Defender UI. The network admin can find the rule in the UI with the rule’s `DisplayName`. + +>[!NOTE] +> Firewall rules from Mobile Device Management (MDM) store cannot be searched using the Windows Defender UI. Additionally, the above method will not work when the `Filter Origin` is one of the default block filters, as they do not correspond to any firewall rules. + +## Firewall default block filters + +**AppContainer loopback** + +Network drop events from the AppContainer loopback block filter origin occur when localhost loopback is not enabled properly for the Universal Windows Platform (UWP) app. + +To enable localhost loopback in a local debugging environment, see [Communicating with localhost](https://docs.microsoft.com/windows/iot-core/develop-your-app/loopback). + +To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged win32 app, see [uap4:LoopbackAccessRules](https://docs.microsoft.com/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules). + +**Boottime default** + +Network drop events from the boottime default block filter origin occur when the computer is booting up and the firewall service is not yet running. Services will need to create a boottime allow filter to allow the traffic. It should be noted that it is not possible to add boottime filters through firewall rules. + +**Quarantine default** + +Network drops from the quarantine default block filter occur when the interface is temporarily quarantined by Firewall service. The firewall service quarantines an interface when it detects a change on the network, and based on several other factors, the firewall service may put the interface in quarantine as a safeguard. When an interface is in quarantine, the quarantine default block filter will block any new non-loopback inbound connections. + +Run the following PowerShell command to generate more information about the interface: + +```Powershell +Get-NetIPInterface –InterfaceIndex +Get-NetIPInterface –InterfaceIndex 5 +``` + +![Quarantine default block filter](images/quarantine-default-block-filter.png) + +To learn more about the quarantine feature, see [Quarantine behavior](quarantine.md). + +>[!NOTE] +> Quarantine-related packet drops are often transient and signify nothing more than a network change on the interface. + +**Query user default** + +Network packet drops from query user default block filters occur when there is no explicit rule created to allow an inbound connection for the packet. When an application binds to a socket but does not have a corresponding inbound rule to allow packets on that port, Windows generates a pop up for the user to allow or deny the app to receive packets on the available network categories. If the user clicks to deny the connection in this popup, subsequent inbound packets to the app will be dropped. To resolve the drops: + +1. Create an inbound firewall rule to allow the packet for this application. This will allow the packet to bypass any query user default block filters. + +2. Delete any block query user rules that may have been auto generated by the firewall service. + +To generate a list of all the query user block rules, you can run the following PowerShell command: + +```Powershell +Get-NetFirewallRule | Where {$_.Name -like "*Query User*"} +``` + +![Query user default block filter](images/query-user-default-block-filters.png) + +The query user pop-up feature is enabled by default. + +To disable the query user pop-up, you can run the following in administrative command prompt: + +```Console +Netsh set allprofiles inboundusernotification disable +``` +Or in PowerShell: + +```Powershell +Set-NetFirewallProfile -NotifyOnListen False +``` + +**Stealth** + +Network drops from stealth filters are typically made to prevent port scanning. + +To disable stealth-mode, see [Disable stealth mode in Windows](https://docs.microsoft.com/troubleshoot/windows-server/networking/disable-stealth-mode). + +**UWP default** + +Network drops from Universal Windows Platform (UWP) default inbound/outbound block filters are often caused by the UWP app not being configured correctly (that is, the UWP app is missing the correct capability tokens or loopback is not enabled) or the private range is configured incorrectly. + +For more information on how to debug drops caused by UWP default block filters, see [Troubleshooting UWP App Connectivity Issues](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall). + +**WSH default** + +Network drops from Windows Service Hardening (WSH) default filters indicate that there wasn’t an explicit Windows Service Hardening allow rule to allow network traffic for the protected service. The service owner will need to configure allow rules for the service if the block is not expected. + diff --git a/windows/security/threat-protection/windows-firewall/images/event-audit-5157.png b/windows/security/threat-protection/windows-firewall/images/event-audit-5157.png new file mode 100644 index 0000000000..a81af9fd83 Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/event-audit-5157.png differ diff --git a/windows/security/threat-protection/windows-firewall/images/event-properties-5157.png b/windows/security/threat-protection/windows-firewall/images/event-properties-5157.png new file mode 100644 index 0000000000..8b0fc9cc89 Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/event-properties-5157.png differ diff --git a/windows/security/threat-protection/windows-firewall/images/firewallrule.png b/windows/security/threat-protection/windows-firewall/images/firewallrule.png new file mode 100644 index 0000000000..040511d279 Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/firewallrule.png differ diff --git a/windows/security/threat-protection/windows-firewall/images/quarantine-default-block-filter.png b/windows/security/threat-protection/windows-firewall/images/quarantine-default-block-filter.png new file mode 100644 index 0000000000..e57ad13f93 Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/quarantine-default-block-filter.png differ diff --git a/windows/security/threat-protection/windows-firewall/images/quarantine-default1.png b/windows/security/threat-protection/windows-firewall/images/quarantine-default1.png new file mode 100644 index 0000000000..4c7a173be7 Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/quarantine-default1.png differ diff --git a/windows/security/threat-protection/windows-firewall/images/quarantine-interfaceindex1.png b/windows/security/threat-protection/windows-firewall/images/quarantine-interfaceindex1.png new file mode 100644 index 0000000000..d6679e1e0e Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/quarantine-interfaceindex1.png differ diff --git a/windows/security/threat-protection/windows-firewall/images/query-user-default-block-filters.png b/windows/security/threat-protection/windows-firewall/images/query-user-default-block-filters.png new file mode 100644 index 0000000000..ca61aae7e2 Binary files /dev/null and b/windows/security/threat-protection/windows-firewall/images/query-user-default-block-filters.png differ diff --git a/windows/security/threat-protection/windows-firewall/quarantine.md b/windows/security/threat-protection/windows-firewall/quarantine.md new file mode 100644 index 0000000000..6cce740d60 --- /dev/null +++ b/windows/security/threat-protection/windows-firewall/quarantine.md @@ -0,0 +1,213 @@ +--- +title: Quarantine behavior +description: Quarantine behavior is explained in detail. +ms.author: v-bshilpa +author: Benny-54 +manager: dansimp +ms.assetid: +ms.reviewer: +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security +ms.localizationpriority: normal +audience: ITPro +ms.collection: M365-security-compliance +ms.topic: conceptual +ms.date: 11/17/2020 +--- + +# Quarantine behavior + +One of the security challenges that network admins face is configuring a machine properly after a network change. + +Network changes can happen frequently. Additionally, the operations required to recategorize the network after a change and apply the correct security policies on a machine are non-trivial and may require considerable CPU time. This is especially true for machines that are part of the domain. In the past, the delay in applying security policies during network recategorization has been successfully exploited for vulnerabilities. + +To counter this potential exploitation, Windows Firewall will quarantine an interface until the system has successfully recategorized the network and Windows Filtering Platform (WFP) has the correct filters applied for the updated interface configuration. During quarantine, all new inbound connections without exceptions are blocked to the machine. + +While the quarantine feature has long been a part of Windows Firewall, the feature behavior has often caused confusion for customers unaware of quarantine and its motivations. + +Ultimately, the goal of this document is to describe the quarantine feature at a high level and help network admins understand why the application traffic is sometimes blocked by quarantine. + +## Quarantine filters + +The quarantine feature creates filters that can be split into three categories: + +- Quarantine default inbound block filter +- Quarantine default exception filters +- Interface un-quarantine filters + +These filters are added in the FWPM_SUBLAYER_MPSSVC_QUARANTINE sublayer and these layers are: + +1. FWPM_LAYER_ALE_AUTH_CONNECT_V4 + +2. FWPM_LAYER_ALE_AUTH_CONNECT_V6 + +3. FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 + +4. FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6 + +>[!NOTE] +> Any firewall rules added by the customers will not affect the filters in the quarantine sublayer as filters from Firewall rules are added in the FWPM_SUBLAYER_MPSSVC_WF sublayer. In other words, customers cannot add their own exception filters to prevent packets from being evaluated by quarantine filters. + +For more information about WFP layers and sublayers, see [WFP Operation](https://docs.microsoft.com/windows/win32/fwp/basic-operation). + +### Quarantine default inbound block filter + +The quarantine default inbound block filter effectively blocks any new non-loopback inbound connections if the packet is not explicitly permitted by another filter in the quarantine sublayer. + +### Quarantine default exception filters + +When the interface is in quarantine state, the quarantine default exception filters will permit new inbound connections given that they meet the conditions of an exception filter. One example of the exception filters is the quarantine default inbound loopback exception filter. This exception filter allows all loopback packets when the interface is in quarantine state. + +### Interface un-quarantine filter + +The interface un-quarantine filters allow all non-loopback packets if the interface is successfully categorized. + +## Quarantine flow + +The following describes the general flow of quarantine: + +1. There is some change on the current network interface. + +2. The interface un-quarantine filters will no longer permit new inbound connections. The interface is now in quarantine state. + +3. All non-loopback inbound connections are either permitted by quarantine default exception filters or dropped by the quarantine default inbound block filter. + +4. The WFP filters applicable to the old interface state are removed. + +5. The WFP filters applicable to the new interface state are added, which include the un-quarantine filters for this interface. These filters are updated to match the interface's current state. + +6. The interface has now exited quarantine state as the interface un-quarantine filters permit any new non-loopback packets. + +## Quarantine diagnostics + +There are two methods of identifying packet drops from the quarantine default inbound block filter. + +Given that the network connectivity issue is reproducible, diagnostic traces can be collected by running the following in an administrative command prompt: + +```console +Netsh wfp cap start + +Netsh wfp cap stop +``` + +These commands generate a wfpdiag.cab. Inside the .cab exists a wfpdiag.xml, which contains drop `netEvents` and filters that existed during that reproduction. + +Inside the wfpdiag.xml, search for `netEvents` that have `FWPM_NET_EVENT_TYPE_CLASSIFY_DROP` as the `netEvent` type. To find the relevant drop events, search for the drop events with matching destination IP address, package SID, or application ID name. + +The characters in the application ID name will be separated by periods: + +```XML + \\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\\.w.i.n.d.o.w.s.\\.s.y.s.t.e.m.3.2.\\.s.v.c.h.o.s.t...e.x.e... +``` + +The `netEvent` will have more information about the packet that was dropped including information about its capabilities, the filter that dropped the packet, and much more. + +If the filter that dropped that packet was by the quarantine default inbound block filter, then the drop `netEvent` will have `filterOrigin` as `Quarantine Default`. + +The following is a sample `netEvent` with `filterOrigin` as `Quarantine Default`. + +```XML + +
+ 2020-10-07T01:03:56.281Z + + FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET + FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET + FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET + FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET + FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET + FWPM_NET_EVENT_FLAG_APP_ID_SET + FWPM_NET_EVENT_FLAG_USER_ID_SET + FWPM_NET_EVENT_FLAG_IP_VERSION_SET + FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET + + FWP_IP_VERSION_V4 + 17 + 255.255.255.255 + 10.195.33.252 + 21 + 61706 + 0 + + 5c00640065006d00330032005c0073007600630068006f00730074002e006500780065000000 + \.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\.w.i.n.d.o.w.s.\.s.y.s.t.e.m.3.2.\.s.v.c.h.o.s.t...e.x.e... + + S-1-5-19 + FWP_AF_INET + S-1-0-0 + + 0 + +
+ FWPM_NET_EVENT_TYPE_CLASSIFY_DROP + + 66241 + 44 + 0 + 0 + 0 + MS_FWP_DIRECTION_OUT + false + + 0 + 0 + + + + FWPM_NET_EVENT_INTERNAL_FLAG_FILTER_ORIGIN_SET + + + 0 + + + + 66241 + FWPP_SUBLAYER_INTERNAL_FIREWALL_QUARANTINE + FWP_ACTION_BLOCK + + + 74045 + FWPP_SUBLAYER_INTERNAL_FIREWALL_WSH + FWP_ACTION_BLOCK + + + 73602 + FWPP_SUBLAYER_INTERNAL_FIREWALL_WF + FWP_ACTION_BLOCK + + + Quarantine Default + 5 + + + +``` + +Alternatively, If the Filtering Platform Connection failure auditing is enabled, the drop event will be logged in Windows Event Viewer. + +To enable Filtering Platform Connection audits, run the following command in an administrative command prompt: + +```console +Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable +``` + +Sample drop audit with `filterOrigin` as `Quarantine Default`. + +![Quarantine default](images/quarantine-default1.png) + +Once the drop’s filter origin has been identified as the quarantine default inbound block filter, the interface should be further investigated. To find the relevant interface, use the `InterfaceIndex` value from the `netEvent` or event audit in the following PowerShell command to generate more information about the interface: + +```Powershell +Get-NetIPInterface –InterfaceIndex +Get-NetIPInterface –InterfaceIndex 5 +``` + +![Quarantine Interfaceindex](images/quarantine-interfaceindex1.png) + +Using the interface name, event viewer can be searched for any interface related changes. + +To enable more networking audit events, see [Enable IPsec and Windows Firewall Audit Events](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754714(v=ws.10)?redirectedfrom=MSDN). + +Packet drops from the quarantine default inbound block filter are often transient and do not signify anything more than a network change on the interface.