deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-16 02:43:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Light updates to legacy firewall content

Browse Source
This commit is contained in:
Paolo Matarazzo
2023-11-07 13:35:32 -05:00
parent 9d6d577bf2
commit 7543036398
6 changed files with 823 additions and 872 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
windows/security/operating-system-security/network-security/windows-firewall/basic-firewall-policy-design.md
View File

@ -1,14 +1,12 @@
--- ---
title: Basic Firewall Policy Design title: Basic Firewall Policy Design
description: Protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses by using basic firewall policy design. description: Protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses by using basic firewall policy design.
ms.prod: windows-client
ms.topic: conceptual ms.topic: conceptual
ms.date: 12/31/2017 ms.date: 11/07/2023
--- ---
# Basic Firewall Policy Design # Basic Firewall Policy Design
Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but don't have a host-based firewall enabled on each device in the organization. Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but don't have a host-based firewall enabled on each device in the organization.
The Basic Firewall Policy Design helps you to protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each device in your organization to allow traffic that is required by the programs that are used. Traffic that doesn't match the rules is dropped. The Basic Firewall Policy Design helps you to protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each device in your organization to allow traffic that is required by the programs that are used. Traffic that doesn't match the rules is dropped.
@ -17,22 +15,16 @@ Traffic can be blocked or permitted based on the characteristics of each network
Many network administrators don't want to tackle the difficult task of determining all the appropriate rules for every program that is used by the organization, and then maintaining that list over time. In fact, most programs don't require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy: Many network administrators don't want to tackle the difficult task of determining all the appropriate rules for every program that is used by the organization, and then maintaining that list over time. In fact, most programs don't require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy:
- On client devices, the default firewall behavior already supports typical client programs. Programs create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another device. - On client devices, the default firewall behavior already supports typical client programs. Programs create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another device
- When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you. For example, when you install a server role, the appropriate firewall rules are created and enabled automatically
- When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you. - For other standard network behavior, the predefined rules that are built into Windows can be configured in a GPO and deployed to the devices in your organization. For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols.
For example, when you install a server role, the appropriate firewall rules are created and enabled automatically.
- For other standard network behavior, the predefined rules that are built into Windows 11, Windows 10, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, and Windows 7 can easily be configured in a GPO and deployed to the devices in your organization.
For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols.
With a few exceptions, the firewall can be enabled on all configurations. Therefore, we recommend that you enable the firewall on every device in your organization. The term "device" includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network. With a few exceptions, the firewall can be enabled on all configurations. Therefore, we recommend that you enable the firewall on every device in your organization. The term "device" includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network.
> [!CAUTION] > [!CAUTION]
> Stopping the service associated with Windows Defender Firewall with Advanced Security is not supported by Microsoft. > Stopping the service associated with Windows Defender Firewall with Advanced Security is not supported by Microsoft.
By default, in new installations, Windows Defender Firewall with Advanced Security is turned on in Windows Server 2012, Windows 8, and later. Windows Defender Firewall with Advanced Security is turned on by default.
If you turn off the Windows Defender Firewall service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting. If you turn off the Windows Defender Firewall service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting.
@ -42,22 +34,18 @@ An organization typically uses this design as a first step toward a more compreh
After implementing this design, you'll have centralized management of the firewall rules applied to all devices that are running Windows in your organization. After implementing this design, you'll have centralized management of the firewall rules applied to all devices that are running Windows in your organization.
> [!IMPORTANT] > [!IMPORTANT]
> If you also intend to deploy the [Domain Isolation Policy Design](domain-isolation-policy-design.md), or the [Server Isolation Policy Design](server-isolation-policy-design.md), we recommend that you do the design work for all three designs together, and then deploy in layers that correspond with each design. > If you also intend to deploy the [Domain Isolation Policy Design](domain-isolation-policy-design.md), or the [Server Isolation Policy Design](server-isolation-policy-design.md), we recommend that you do the design work for all three designs together, and then deploy in layers that correspond with each design.
The basic firewall design can be applied to devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the firewall settings and rules. The basic firewall design can be applied to devices that are part of an Active Directory forest. Active Directory is required to provide the centralized management and deployment of Group Policy objects that contain the firewall settings and rules.
For more information about this design: For more information about this design:
- This design coincides with the deployment goal to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md). - This design coincides with the deployment goal to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)
- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md)
- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md). - Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)
- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md)
- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md). - For a list of detailed tasks that you can use to deploy your basic firewall policy design, see [Checklist: Implementing a Basic Firewall Policy Design](checklist-implementing-a-basic-firewall-policy-design.md)
- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md).
- For a list of detailed tasks that you can use to deploy your basic firewall policy design, see [Checklist: Implementing a Basic Firewall Policy Design](checklist-implementing-a-basic-firewall-policy-design.md).
> [!div class="nextstepaction"] > [!div class="nextstepaction"]
> [Domain Isolation Policy Design](domain-isolation-policy-design.md) > [Domain Isolation Policy Design](domain-isolation-policy-design.md)

88
windows/security/operating-system-security/network-security/windows-firewall/create-windows-firewall-rules-in-intune.md
View File

@ -1,18 +1,16 @@
--- ---
title: Create Windows Firewall rules in Intune title: Create Windows Firewall rules in Intune
description: Learn how to use Intune to create rules in Windows Defender Firewall with Advanced Security. Start by creating a profile in Device Configuration in Intune. description: Learn how to use Intune to create rules in Windows Defender Firewall with Advanced Security. Start by creating a profile in Device Configuration in Intune.
ms.prod: windows-client
ms.topic: conceptual ms.topic: conceptual
ms.date: 12/31/2017 ms.date: 11/07/2023
--- ---
# Create Windows Firewall rules in Intune # Create Windows Firewall rules in Intune
>[!IMPORTANT] >[!IMPORTANT]
>This information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. >This information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
To get started, Open the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), and then go to **Devices** > **Windows** > **Configuration profiles** > **Create profile** > Choose **Windows 10 and later** as the platform, Choose **Templates**, then **Endpoint protection** as the profile type. To get started, Open the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), and then go to **Devices** > **Windows** > **Configuration profiles** > **Create profile** > Choose **Windows 10 and later** as the platform, Choose **Templates**, then **Endpoint protection** as the profile type.
Select Windows Defender Firewall. Select Windows Defender Firewall.
:::image type="content" source="images/windows-firewall-intune.png" alt-text="Example of a Windows Defender Firewall policy in Microsoft Intune and the Intune admin center."::: :::image type="content" source="images/windows-firewall-intune.png" alt-text="Example of a Windows Defender Firewall policy in Microsoft Intune and the Intune admin center.":::
@ -24,76 +22,86 @@ Select Windows Defender Firewall.
The firewall rule configurations in Intune use the Windows CSP for Firewall. For more information, see [Firewall CSP](/windows/client-management/mdm/firewall-csp). The firewall rule configurations in Intune use the Windows CSP for Firewall. For more information, see [Firewall CSP](/windows/client-management/mdm/firewall-csp).
## Application ## Application
Control connections for an app or program.
Apps and programs can be specified either file path, package family name, or Windows service short name.
The file path of an app is its location on the client device. Control connections for an app or program.
For example, C:\Windows\System\Notepad.exe. Apps and programs can be specified either file path, package family name, or Windows service short name.
[Learn more](/windows/client-management/mdm/firewall-csp#filepath)
Package family names can be retrieved by running the Get-AppxPackage command from PowerShell. The file path of an app is its location on the client device.
[Learn more](https://aka.ms/intunefirewallPackageNameFromPowerShell) For example, C:\Windows\System\Notepad.exe.
[Learn more](/windows/client-management/mdm/firewall-csp#filepath)
Windows service short names are used in cases when a service, not an application, is sending or receiving traffic. Package family names can be retrieved by running the Get-AppxPackage command from PowerShell.
Default is All. [Learn more](https://aka.ms/intunefirewallPackageNameFromPowerShell)
Windows service short names are used in cases when a service, not an application, is sending or receiving traffic.
Default is All.
[Learn more](/windows/client-management/mdm/firewall-csp#servicename) [Learn more](/windows/client-management/mdm/firewall-csp#servicename)
## Protocol ## Protocol
Select the protocol for this port rule. Transport layer protocols—TCP and UDP—allow you to specify ports or port ranges. For custom protocols, enter a number between 0 and 255 representing the IP protocol.
Default is Any. Select the protocol for this port rule. Transport layer protocols—TCP and UDP—allow you to specify ports or port ranges. For custom protocols, enter a number between 0 and 255 representing the IP protocol.
Default is Any.
[Learn more](/windows/client-management/mdm/firewall-csp#protocol) [Learn more](/windows/client-management/mdm/firewall-csp#protocol)
## Local ports ## Local ports
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
[Learn more](/windows/client-management/mdm/firewall-csp#localportranges) [Learn more](/windows/client-management/mdm/firewall-csp#localportranges)
## Remote ports ## Remote ports
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
[Learn more](/windows/client-management/mdm/firewall-csp#remoteportranges) [Learn more](/windows/client-management/mdm/firewall-csp#remoteportranges)
## Local addresses ## Local addresses
Comma-separated list of local addresses covered by the rule. Valid tokens include: Comma-separated list of local addresses covered by the rule. Valid tokens include:
- \* indicates any local address. If present, this token must be the only one included.
- A subnet can be specified using either the subnet mask or network prefix notation. If a subnet mask or a network prefix isn't specified, the subnet mask default is 255.255.255.255. - `*` indicates any local address. If present, this token must be the only one included
- A valid IPv6 address. - A subnet can be specified using either the subnet mask or network prefix notation. If a subnet mask or a network prefix isn't specified, the subnet mask default is 255.255.255.255
- An IPv4 address range in the format of "start address-end address" with no spaces included. - A valid IPv6 address
- An IPv6 address range in the format of "start address-end address" with no spaces included. Default is Any address. - An IPv4 address range in the format of "start address-end address" with no spaces included
- An IPv6 address range in the format of "start address-end address" with no spaces included. Default is Any address
[Learn more](/windows/client-management/mdm/firewall-csp#localaddressranges) [Learn more](/windows/client-management/mdm/firewall-csp#localaddressranges)
## Remote addresses ## Remote addresses
List of comma separated tokens specifying the remote addresses covered by the rule. Tokens are case insensitive. Valid tokens include:
- \* indicates any remote address. If present, this token must be the only one included.
- Defaultgateway
- DHCP
- DNS
- WINS
- Intranet (supported on Windows versions 1809+)
- RmtIntranet (supported on Windows versions 1809+)
- Internet (supported on Windows versions 1809+)
- Ply2Renders (supported on Windows versions 1809+)
- LocalSubnet indicates any local address on the local subnet.
- A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255.
- A valid IPv6 address.
- An IPv4 address range in the format of "start address-end address" with no spaces included.
- An IPv6 address range in the format of "start address-end address" with no spaces included.
Default is Any address. List of comma separated tokens specifying the remote addresses covered by the rule. Tokens are case insensitive. Valid tokens include:
- `*` indicates any remote address. If present, this token must be the only one included
- Defaultgateway
- DHCP
- DNS
- WINS
- Intranet
- RmtIntranet
- Internet
- Ply2Renders
- LocalSubnet indicates any local address on the local subnet
- A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255
- A valid IPv6 address
- An IPv4 address range in the format of "start address-end address" with no spaces included
- An IPv6 address range in the format of "start address-end address" with no spaces included
Default is Any address
[Learn more](https://aka.ms/intunefirewallremotaddressrule) [Learn more](https://aka.ms/intunefirewallremotaddressrule)
## Edge traversal (UI coming soon) ## Edge traversal (UI coming soon)
Indicates whether edge traversal is enabled or disabled for this rule. The EdgeTraversal setting indicates that specific inbound traffic is allowed to tunnel through NATs and other edge devices using the Teredo tunneling technology. In order for this setting to work correctly, the application or service with the inbound firewall rule needs to support IPv6. The primary application of this setting allows listeners on the host to be globally addressable through a Teredo IPv6 address. New rules have the EdgeTraversal property disabled by default. This setting can only be configured via Intune Graph at this time.
Indicates whether edge traversal is enabled or disabled for this rule. The EdgeTraversal setting indicates that specific inbound traffic is allowed to tunnel through NATs and other edge devices using the Teredo tunneling technology. In order for this setting to work correctly, the application or service with the inbound firewall rule needs to support IPv6. The primary application of this setting allows listeners on the host to be globally addressable through a Teredo IPv6 address. New rules have the EdgeTraversal property disabled by default. This setting can only be configured via Intune Graph at this time.
[Learn more](/windows/client-management/mdm/firewall-csp#edgetraversal) [Learn more](/windows/client-management/mdm/firewall-csp#edgetraversal)
## Authorized users ## Authorized users
Specifies the list of authorized local users for this rule. A list of authorized users can't be specified if the rule being authored is targeting a Windows service. Default is all users.
Specifies the list of authorized local users for this rule. A list of authorized users can't be specified if the rule being authored is targeting a Windows service. Default is all users.
[Learn more](/windows/client-management/mdm/firewall-csp#localuserauthorizedlist) [Learn more](/windows/client-management/mdm/firewall-csp#localuserauthorizedlist)

83
windows/security/operating-system-security/network-security/windows-firewall/filter-origin-documentation.md
View File

@ -1,20 +1,19 @@
--- ---
title: Filter origin audit log improvements title: Filter origin audit log improvements
description: Filter origin documentation audit log improvements description: Filter origin documentation audit log improvements
ms.prod: windows-client
ms.topic: troubleshooting ms.topic: troubleshooting
ms.date: 12/31/2017 ms.date: 11/07/2023
--- ---
# Filter origin audit log improvements # 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. 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. 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) ![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. 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 isn't 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 change in ID makes the diagnosis process error-prone and difficult. However, the filter ID isn't 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 change in ID makes the diagnosis process error-prone and difficult.
@ -23,29 +22,21 @@ For customers to debug packet drop events correctly and efficiently, they would
The blocking filters can be categorized under these filter origins: The blocking filters can be categorized under these filter origins:
1. Firewall rules 1. Firewall rules
1. Firewall default block filters
2. Firewall default block filters 1. AppContainer loopback
1. Boottime default
a. AppContainer loopback 1. Quarantine default
1. Query user default
b. Boottime default 1. Stealth
1. Universal Windows Platform (UWP) default
c. Quarantine default 1. Windows Service Hardening (WSH) 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 the Windows Server 2022 and Windows 11 releases. 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 the Windows Server 2022 and Windows 11 releases.
## Improved firewall audit ## Improved firewall audit
The two new fields added to the audit 5157 and 5152 events are `Filter Origin` and `Interface Index`. 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. 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. `Filter Origin` specifies either the rule ID (a unique identifier of a Firewall rule) or the name of one of the default block filters.
@ -54,12 +45,12 @@ The `Interface Index` field specifies the network interface in which the packet
To enable a specific audit event, run the corresponding command in an administrator command prompt: To enable a specific audit event, run the corresponding command in an administrator command prompt:
|**Audit #**|**Enable command**|**Link**| |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.](../../../threat-protection/auditing/event-5157.md)| |5157|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable`|[5157(F): The Windows Filtering Platform has blocked a connection.](../../../threat-protection/auditing/event-5157.md)|
|**5152**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable`|[5152(F): The Windows Filtering Platform blocked a packet.](../../../threat-protection/auditing/event-5152.md)| |5152|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable`|[5152(F): The Windows Filtering Platform blocked a packet.](../../../threat-protection/auditing/event-5152.md)|
## Example flow of debugging packet drops with filter origin ## 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. 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.
@ -69,7 +60,7 @@ The next sections are divided by `Filter Origin` type, the value is either a rul
## Firewall rules ## Firewall rules
Run the following PowerShell command to generate the rule information using `Filter Origin`. Run the following PowerShell command to generate the rule information using `Filter Origin`.
```Powershell ```Powershell
Get-NetFirewallRule -Name "<Filter Origin>" Get-NetFirewallRule -Name "<Filter Origin>"
@ -85,7 +76,7 @@ After identifying the rule that caused the drop, the network admin can now modif
## Firewall default block filters ## Firewall default block filters
**AppContainer loopback** ### AppContainer loopback
Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn't enabled properly for the Universal Windows Platform (UWP) app. Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn't enabled properly for the Universal Windows Platform (UWP) app.
@ -93,19 +84,19 @@ To enable localhost loopback in a local debugging environment, see [Communicatin
To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged win32 app, see [uap4:LoopbackAccessRules](/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules). To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged win32 app, see [uap4:LoopbackAccessRules](/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules).
**Boottime default** ### Boottime default
Network drop events from the boottime default block filter origin occur when the computer is booting up and the firewall service isn't yet running. Services will need to create a boottime allow filter to allow the traffic. It should be noted that it's not possible to add boottime filters through firewall rules. Network drop events from the boottime default block filter origin occur when the computer is booting up and the firewall service isn't yet running. Services will need to create a boottime allow filter to allow the traffic. It should be noted that it's not possible to add boottime filters through firewall rules.
**Quarantine default** ### 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. 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: Run the following PowerShell command to generate more information about the interface:
```Powershell ```Powershell
Get-NetIPInterface –InterfaceIndex <Interface Index> Get-NetIPInterface -InterfaceIndex <Interface Index>
Get-NetIPInterface –InterfaceIndex 5 Get-NetIPInterface -InterfaceIndex 5
``` ```
![Quarantine default block filter.](images/quarantine-default-block-filter.png) ![Quarantine default block filter.](images/quarantine-default-block-filter.png)
@ -115,13 +106,12 @@ To learn more about the quarantine feature, see [Quarantine behavior](quarantine
>[!NOTE] >[!NOTE]
> Quarantine-related packet drops are often transient and signify nothing more than a network change on the interface. > Quarantine-related packet drops are often transient and signify nothing more than a network change on the interface.
**Query user default** ### Query user default
Network packet drops from query user default block filters occur when there's no explicit rule created to allow an inbound connection for the packet. When an application binds to a socket but doesn't 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: Network packet drops from query user default block filters occur when there's no explicit rule created to allow an inbound connection for the packet. When an application binds to a socket but doesn't 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 packet will allow the packet to bypass any query user default block filters. 1. Create an inbound firewall rule to allow the packet for this application. This packet will allow the packet to bypass any query user default block filters
1. Delete any block query user rules that may have been auto generated by the firewall service
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: To generate a list of all the query user block rules, you can run the following PowerShell command:
@ -131,31 +121,32 @@ Get-NetFirewallRule | Where {$_.Name -like "*Query User*"}
![Query user default block filter.](images/query-user-default-block-filters.png) ![Query user default block filter.](images/query-user-default-block-filters.png)
The query user pop-up feature is enabled by default. The query user pop-up feature is enabled by default.
To disable the query user pop-up, you can run the following command in administrative command prompt: To disable the query user pop-up, you can run the following command in administrative command prompt:
```Console ```cmd
Netsh set allprofiles inboundusernotification disable Netsh set allprofiles inboundusernotification disable
``` ```
Or in PowerShell: Or in PowerShell:
```Powershell ```Powershell
Set-NetFirewallProfile -NotifyOnListen False Set-NetFirewallProfile -NotifyOnListen False
``` ```
**Stealth** ### Stealth
Network drops from stealth filters are typically made to prevent port scanning. Network drops from stealth filters are typically made to prevent port scanning.
To disable stealth-mode, see [Disable stealth mode in Windows](/troubleshoot/windows-server/networking/disable-stealth-mode). To disable stealth-mode, see [Disable stealth mode in Windows](/troubleshoot/windows-server/networking/disable-stealth-mode).
**UWP default** ### 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 isn't enabled) or the private range is configured incorrectly. 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 isn't 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](troubleshooting-uwp-firewall.md). For more information on how to debug drops caused by UWP default block filters, see [Troubleshooting UWP App Connectivity Issues](troubleshooting-uwp-firewall.md).
**WSH default** ### 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 isn't expected. 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 isn't expected.

11
windows/security/operating-system-security/network-security/windows-firewall/firewall-settings-lost-on-upgrade.md
View File

@ -1,9 +1,8 @@
--- ---
title: Troubleshooting Windows Firewall settings after a Windows upgrade title: Troubleshooting Windows Firewall settings after a Windows upgrade
description: Firewall settings lost on upgrade description: Firewall settings lost on upgrade
ms.prod: windows-client
ms.topic: troubleshooting ms.topic: troubleshooting
ms.date: 12/31/2017 ms.date: 11/07/2023
--- ---
# Troubleshooting Windows Firewall settings after a Windows upgrade # Troubleshooting Windows Firewall settings after a Windows upgrade
@ -14,9 +13,9 @@ Use this article to troubleshoot firewall settings that are turned off after upg
To help you organize your list, individual built-in firewall rules are categorized within a group. For example, the following rules form part of the Remote Desktop group. To help you organize your list, individual built-in firewall rules are categorized within a group. For example, the following rules form part of the Remote Desktop group.
- Remote Desktop – Shadow (TCP-In) - Remote Desktop - Shadow (TCP-In)
- Remote Desktop – User Mode (TCP-In) - Remote Desktop - User Mode (TCP-In)
- Remote Desktop – User-Mode (UDP-In) - Remote Desktop - User-Mode (UDP-In)
Other group examples include **core networking**, **file and print sharing**, and **network discovery**. Grouping allows administrators to manage sets of similar rules by filtering on categories in the firewall interface (wf.msc). Do this filtering by right-clicking on either **Inbound** or **Outbound Rules** and selecting **Filter by Group**. Optionally, you can use PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch. Other group examples include **core networking**, **file and print sharing**, and **network discovery**. Grouping allows administrators to manage sets of similar rules by filtering on categories in the firewall interface (wf.msc). Do this filtering by right-clicking on either **Inbound** or **Outbound Rules** and selecting **Filter by Group**. Optionally, you can use PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch.
@ -24,7 +23,7 @@ Other group examples include **core networking**, **file and print sharing**, an
Get-NetFirewallRule -Group <groupName> Get-NetFirewallRule -Group <groupName>
``` ```
> [!NOTE] > [!NOTE]
> Microsoft recommends to enable or disable an entire group instead of individual rules. > Microsoft recommends to enable or disable an entire group instead of individual rules.
Microsoft recommends that you enable/disable all of the rules within a group instead of one or two individual rules. This recommendation is because groups aren't only used to organize rules and allow batch rule modification by type, but they also represent a 'unit' by which rule state is maintained across a Windows upgrade. Rule groups, as opposed to individual rules, are the unit by which the update process determines what should be enabled/disabled when the upgrade is complete. Microsoft recommends that you enable/disable all of the rules within a group instead of one or two individual rules. This recommendation is because groups aren't only used to organize rules and allow batch rule modification by type, but they also represent a 'unit' by which rule state is maintained across a Windows upgrade. Rule groups, as opposed to individual rules, are the unit by which the update process determines what should be enabled/disabled when the upgrade is complete.

1438
windows/security/operating-system-security/network-security/windows-firewall/troubleshooting-uwp-firewall.md
View File

File diff suppressed because it is too large Load Diff

41
windows/security/security-foundations/zero-trust-windows-device-health.md
View File

@ -1,14 +1,11 @@
--- ---
title: Zero Trust and Windows device health title: Zero Trust and Windows device health
description: Describes the process of Windows device health attestation description: Describes the process of Windows device health attestation
ms.reviewer:
ms.topic: conceptual ms.topic: conceptual
manager: aaroncz manager: aaroncz
ms.author: paoloma ms.author: paoloma
author: paolomatarazzo author: paolomatarazzo
ms.prod: windows-client ms.date: 11/07/2023
ms.technology: itpro-security
ms.date: 12/31/2017
--- ---
# Zero Trust and Windows device health # Zero Trust and Windows device health
@ -17,11 +14,9 @@ Organizations need a security model that more effectively adapts to the complexi
The [Zero Trust](https://www.microsoft.com/security/business/zero-trust) principles are: The [Zero Trust](https://www.microsoft.com/security/business/zero-trust) principles are:
- **Verify explicitly**. Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and monitor anomalies. - **Verify explicitly**. Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and monitor anomalies
- **Use least-privileged access**. Limit user access with just-in-time and just-enough-access, risk-based adaptive policies, and data protection to help secure data and maintain productivity
- **Use least-privileged access**. Limit user access with just-in-time and just-enough-access, risk-based adaptive policies, and data protection to help secure data and maintain productivity. - **Assume breach**. Prevent attackers from obtaining access to minimize potential damage to data and systems. Protect privileged roles, verify end-to-end encryption, use analytics to get visibility, and drive threat detection to improve defenses
- **Assume breach**. Prevent attackers from obtaining access to minimize potential damage to data and systems. Protect privileged roles, verify end-to-end encryption, use analytics to get visibility, and drive threat detection to improve defenses.
The Zero Trust concept of **verify explicitly** applies to the risks introduced by both devices and users. Windows enables **device health attestation** and **conditional access** capabilities, which are used to grant access to corporate resources. The Zero Trust concept of **verify explicitly** applies to the risks introduced by both devices and users. Windows enables **device health attestation** and **conditional access** capabilities, which are used to grant access to corporate resources.
@ -45,25 +40,19 @@ Windows includes many security features to help protect users from malware and a
A summary of the steps involved in attestation and Zero Trust on the device side are as follows: A summary of the steps involved in attestation and Zero Trust on the device side are as follows:
1. During each step of the boot process, such as a file load, update of special variables, and more, information such as file hashes and signature are measured in the TPM PCRs. The measurements are bound by a [Trusted Computing Group specification](https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) (TCG) that dictates what events can be recorded and the format of each event. 1. During each step of the boot process, such as a file load, update of special variables, and more, information such as file hashes and signature are measured in the TPM PCRs. The measurements are bound by a [Trusted Computing Group specification](https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) (TCG) that dictates what events can be recorded and the format of each event
1. Once Windows has booted, the attestor/verifier requests the TPM to fetch the measurements stored in its Platform Configuration Register (PCR) alongside a TCG log. The measurements in both these components together form the attestation evidence that is then sent to the attestation service
1. The TPM is verified by using the keys/cryptographic material available on the chipset with an [Azure Certificate Service](/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation)
1. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Microsoft Entra Conditional Access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device
1. The attestation service does the following tasks:
2. Once Windows has booted, the attestor/verifier requests the TPM to fetch the measurements stored in its Platform Configuration Register (PCR) alongside a TCG log. The measurements in both these components together form the attestation evidence that is then sent to the attestation service. - Verify the integrity of the evidence. This verification is done by validating the PCRs that match the values recomputed by replaying the TCG log
- Verify that the TPM has a valid Attestation Identity Key issued by the authenticated TPM
- Verify that the security features are in the expected states
3. The TPM is verified by using the keys/cryptographic material available on the chipset with an [Azure Certificate Service](/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation). 1. The attestation service returns an attestation report that contains information about the security features based on the policy configured in the attestation service
1. The device then sends the report to the Microsoft Intune cloud to assess the trustworthiness of the platform according to the admin-configured device compliance rules
4. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Microsoft Entra Conditional Access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device. 1. Conditional access, along with device-compliance state then decides to allow or deny access
5. The attestation service does the following tasks:
- Verify the integrity of the evidence. This verification is done by validating the PCRs that match the values recomputed by replaying the TCG log.
- Verify that the TPM has a valid Attestation Identity Key issued by the authenticated TPM.
- Verify that the security features are in the expected states.
6. The attestation service returns an attestation report that contains information about the security features based on the policy configured in the attestation service.
7. The device then sends the report to the Microsoft Intune cloud to assess the trustworthiness of the platform according to the admin-configured device compliance rules.
8. Conditional access, along with device-compliance state then decides to allow or deny access.
## Other Resources ## Other Resources