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

Firewall freshness and docfx

Browse Source
This commit is contained in:
Paolo Matarazzo
2023-11-10 09:21:26 -05:00
parent c2f71410f8
commit dba380983c
8 changed files with 167 additions and 256 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
windows/security/operating-system-security/network-security/windows-firewall/TOC.yml
View File

@ -21,7 +21,7 @@ items:
href: restrict-access-to-only-specified-users-or-devices.md
- name: Implementation designs
items:
- name: Mapping goals to a design
- name: Map goals to a design
href: mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md
- name: Basic firewall design
href: basic-firewall-policy-design.md
@ -45,11 +45,11 @@ items:
href: certificate-based-isolation-policy-design-example.md
- name: Design planning
items:
- name: Planning your design
- name: Plan your design
href: planning-your-windows-firewall-with-advanced-security-design.md
- name: Planning settings for a basic firewall policy
- name: Plan settings for a basic firewall policy
href: planning-settings-for-a-basic-firewall-policy.md
- name: Planning domain isolation zones
- name: Plan domain isolation zones
items:
- name: Domain isolation zones
href: planning-domain-isolation-zones.md
@ -61,21 +61,21 @@ items:
href: boundary-zone.md
- name: Encryption zone
href: encryption-zone.md
- name: Planning server isolation zones
- name: Plan server isolation zones
href: planning-server-isolation-zones.md
- name: Planning certificate-based authentication
- name: Plan certificate-based authentication
href: planning-certificate-based-authentication.md
items:
- name: Documenting the Zones
- name: Document the Zones
href: documenting-the-zones.md
- name: Planning group policy deployment for your isolation zones
- name: Plan group policy deployment for your isolation zones
href: planning-group-policy-deployment-for-your-isolation-zones.md
items:
- name: Planning isolation groups for the zones
- name: Plan isolation groups for the zones
href: planning-isolation-groups-for-the-zones.md
- name: Planning network access groups
- name: Plan network access groups
href: planning-network-access-groups.md
- name: Planning the GPOs
- name: Plan the GPOs
href: planning-the-gpos.md
items:
- name: Firewall GPOs
@ -102,41 +102,41 @@ items:
href: gpo-domiso-encryption.md
- name: Server isolation GPOs
href: server-isolation-gpos.md
- name: Planning GPO deployment
- name: Plan GPO deployment
href: planning-gpo-deployment.md
- name: Planning to deploy
- name: Plan to deploy
href: planning-to-deploy-windows-firewall-with-advanced-security.md
- name: Deployment guide
items:
- name: Deployment overview
href: windows-firewall-with-advanced-security-deployment-guide.md
- name: Implementing your plan
- name: Implement your plan
href: implementing-your-windows-firewall-with-advanced-security-design-plan.md
- name: Basic firewall deployment
items:
- name: "Checklist: Implementing a basic firewall policy design"
- name: "Checklist: Implement a basic firewall policy design"
href: checklist-implementing-a-basic-firewall-policy-design.md
- name: Domain isolation deployment
items:
- name: "Checklist: Implementing a Domain Isolation Policy Design"
- name: "Checklist: Implement a Domain Isolation Policy Design"
href: checklist-implementing-a-domain-isolation-policy-design.md
- name: Server isolation deployment
items:
- name: "Checklist: Implementing a Standalone Server Isolation Policy Design"
- name: "Checklist: Implement a Standalone Server Isolation Policy Design"
href: checklist-implementing-a-standalone-server-isolation-policy-design.md
- name: Certificate-based authentication
items:
- name: "Checklist: Implementing a Certificate-based Isolation Policy Design"
- name: "Checklist: Implement a Certificate-based Isolation Policy Design"
href: checklist-implementing-a-certificate-based-isolation-policy-design.md
- name: Best practices
items:
- name: Configuring the firewall
- name: Configure the firewall
href: best-practices-configuring.md
- name: Securing IPsec
- name: Secure IPsec
href: securing-end-to-end-ipsec-connections-by-using-ikev2.md
- name: PowerShell
href: windows-firewall-with-advanced-security-administration-with-windows-powershell.md
- name: Isolating Microsoft Store Apps on Your Network
- name: Isolate Microsoft Store Apps on Your Network
href: isolating-apps-on-your-network.md
- name: How-to
items:
@ -220,31 +220,31 @@ items:
href: verify-that-network-traffic-is-authenticated.md
- name: References
items:
- name: "Checklist: Creating Group Policy objects"
- name: "Checklist: Create Group Policy objects"
href: checklist-creating-group-policy-objects.md
- name: "Checklist: Creating inbound firewall rules"
- name: "Checklist: Create inbound firewall rules"
href: checklist-creating-inbound-firewall-rules.md
- name: "Checklist: Creating outbound firewall rules"
- name: "Checklist: Create outbound firewall rules"
href: checklist-creating-outbound-firewall-rules.md
- name: "Checklist: Configuring basic firewall settings"
- name: "Checklist: Configure basic firewall settings"
href: checklist-configuring-basic-firewall-settings.md
- name: "Checklist: Configuring rules for the isolated domain"
- name: "Checklist: Configure rules for the isolated domain"
href: checklist-configuring-rules-for-the-isolated-domain.md
- name: "Checklist: Configuring rules for the boundary zone"
- name: "Checklist: Configure rules for the boundary zone"
href: checklist-configuring-rules-for-the-boundary-zone.md
- name: "Checklist: Configuring rules for the encryption zone"
- name: "Checklist: Configure rules for the encryption zone"
href: checklist-configuring-rules-for-the-encryption-zone.md
- name: "Checklist: Configuring rules for an isolated server zone"
- name: "Checklist: Configure rules for an isolated server zone"
href: checklist-configuring-rules-for-an-isolated-server-zone.md
- name: "Checklist: Configuring rules for servers in a standalone isolated server zone"
- name: "Checklist: Configure rules for servers in a standalone isolated server zone"
href: checklist-configuring-rules-for-servers-in-a-standalone-isolated-server-zone.md
- name: "Checklist: Creating rules for clients of a standalone isolated server zone"
- name: "Checklist: Create rules for clients of a standalone isolated server zone"
href: checklist-creating-rules-for-clients-of-a-standalone-isolated-server-zone.md
- name: "Appendix A: Sample GPO template files for settings used in this guide"
href: appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md
- name: Troubleshooting
items:
- name: Troubleshooting UWP app connectivity issues in Windows Firewall
- name: Troubleshoot UWP app connectivity issues in Windows Firewall
href: troubleshooting-uwp-firewall.md
- name: Filter origin audit log improvements
href: filter-origin-documentation.md

58
windows/security/operating-system-security/network-security/windows-firewall/add-production-devices-to-the-membership-group-for-a-zone.md
View File

@ -2,50 +2,37 @@
title: Add Production Devices to the Membership Group for a Zone
description: Learn how to add production devices to the membership group for a zone and refresh the group policy on the devices in the membership group.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
ms.topic: how-to
ms.date: 11/10/2023
---
# Add Production Devices to the Membership Group for a Zone
After you test the GPOs for your design on a small set of devices, you can deploy them to the production devices.
**Caution**  
For GPOs that contain connection security rules that prevent unauthenticated connections, ensure you set the rules to request, not require, authentication during testing. After you deploy the GPO and confirm that all of your devices are successfully communicating by using authenticated IPsec, then you can modify the GPO to require authentication. Don't change the boundary zone GPO to require mode.
> [!CAUTION]
> For GPOs that contain connection security rules that prevent unauthenticated connections, ensure you set the rules to request, not require, authentication during testing. After you deploy the GPO and confirm that all of your devices are successfully communicating by using authenticated IPsec, then you can modify the GPO to require authentication. Don't change the boundary zone GPO to require mode.
The method discussed in this guide uses the **Domain Computers** built-in group. The advantage of this method is that all new devices that are joined to the domain automatically receive the isolated domain GPO. To define this setting successfully, you must make sure that the WMI filters and security group filters exclude devices that must not receive the GPOs. Use device groups that deny both read and apply Group Policy permissions to the GPOs, such as a group used in the CG\_DOMISO\_NOIPSEC example design. Devices that are members of some zones must also be excluded from applying the GPOs for the main isolated domain. For more information, see the "Prevent members of a group from applying a GPO" section in [Assign Security Group Filters to the GPO](assign-security-group-filters-to-the-gpo.md).
The method discussed in this guide uses the *Domain Computers* built-in group. The advantage of this method is that all new devices that are joined to the domain automatically receive the isolated domain GPO. To define this setting successfully, you must make sure that the WMI filters and security group filters exclude devices that must not receive the GPOs. Use device groups that deny both read and apply Group Policy permissions to the GPOs, such as a group used in the *CG_DOMISO_NOIPSEC* example design. Devices that are members of some zones must also be excluded from applying the GPOs for the main isolated domain. For more information, see the "Prevent members of a group from applying a GPO" section in [Assign Security Group Filters to the GPO](assign-security-group-filters-to-the-gpo.md).
Without such a group (or groups), you must either add devices individually or use the groups containing device accounts that are available to you.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO.
In this topic:
- [Add the group Domain Devices to the GPO membership group](#to-add-domain-devices-to-the-gpo-membership-group)
- [Refresh Group Policy on the devices in the membership group](#to-refresh-group-policy-on-a-device)
- [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
- [Add the group Domain Devices to the GPO membership group](#to-add-domain-devices-to-the-gpo-membership-group)
- [Refresh Group Policy on the devices in the membership group](#to-refresh-group-policy-on-a-device)
- [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
## To add domain devices to the GPO membership group
1. Open Active Directory Users and Computers.
2. In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then the container in which you created the membership group.
3. In the details pane, double-click the GPO membership group to which you want to add computers.
4. Select the **Members** tab, and then click **Add**.
5. Type **Domain Computers** in the text box, and then click **OK**.
6. Click **OK** to close the group properties dialog box.
1. Open Active Directory Users and Computers
1. In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then the container in which you created the membership group
1. In the details pane, double-click the GPO membership group to which you want to add computers
1. Select the **Members** tab, and then click **Add**
1. Type **Domain Computers** in the text box, and then click **OK**
1. Click **OK** to close the group properties dialog box
After a computer is a member of the group, you can force a Group Policy refresh on the computer.
@ -53,8 +40,8 @@ After a computer is a member of the group, you can force a Group Policy refresh
From an elevated command prompt, type the following command:
``` syntax
gpupdate /target:computer /force
``` cmd
gpupdate.exe /target:computer /force
```
After Group Policy is refreshed, you can see which GPOs are currently applied to the computer.
@ -63,15 +50,6 @@ After Group Policy is refreshed, you can see which GPOs are currently applied to
From an elevated command prompt, type the following command:
``` syntax
gpresult /r /scope:computer
``` cmd
gpresult.exe /r /scope:computer
```

52
windows/security/operating-system-security/network-security/windows-firewall/add-test-devices-to-the-membership-group-for-a-zone.md
View File

@ -2,44 +2,33 @@
title: Add Test Devices to the Membership Group for a Zone
description: Learn how to add devices to the group for a zone to test whether your Windows Defender Firewall with Advanced Security implementation works as expected.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
ms.topic: how-to
ms.date: 11/10/2023
---
# Add Test Devices to the Membership Group for a Zone
Before you deploy your rules to large numbers of devices, you must thoroughly test the rules to make sure that communications are working as expected. A misplaced WMI filter or an incorrectly typed IP address in a filter list can easily block communications between devices. Although we recommend that you set your rules to request mode until testing and deployment is complete. We also recommend that you initially deploy the rules to a few devices only to be sure that the correct GPOs are being processed by each device.
Add at least one device of each supported operating system type to each membership group. Make sure every GPO for a specific version of Windows and membership group has a device among the test group. After Group Policy has been refreshed on each test device, check the output of the **gpresult** command to confirm that each device is receiving only the GPOs it's supposed to receive.
**Administrative credentials**
Add at least one device of each supported operating system type to each membership group. Make sure every GPO for a specific version of Windows and membership group has a device among the test group. After Group Policy has been refreshed on each test device, check the output of the `gpresult.exe` command to confirm that each device is receiving only the GPOs it's supposed to receive.
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the membership of the group for the GPO.
In this topic:
- [Add the test devices to the GPO membership groups](#to-add-test-devices-to-the-gpo-membership-groups)
- [Refresh Group Policy on the devices in each membership group](#to-refresh-group-policy-on-a-device)
- [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
- [Add the test devices to the GPO membership groups](#to-add-test-devices-to-the-gpo-membership-groups)
- [Refresh Group Policy on the devices in each membership group](#to-refresh-group-policy-on-a-device)
- [Check which GPOs apply to a device](#to-see-which-gpos-are-applied-to-a-device)
## To add test devices to the GPO membership groups
1. Open Active Directory Users and Computers.
2. In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then expand the container that holds your membership group account.
3. In the details pane, double-click the GPO membership group to which you want to add devices.
4. Select the **Members** tab, and then click **Add**.
5. Type the name of the device in the text box, and then click **OK**.
6. Repeat steps 5 and 6 for each extra device account or group that you want to add.
7. Click **OK** to close the group properties dialog box.
1. Open Active Directory Users and Computers
1. In the navigation pane, expand **Active Directory Users and Computers**, expand *YourDomainName*, and then expand the container that holds your membership group account
1. In the details pane, double-click the GPO membership group to which you want to add devices
1. Select the **Members** tab, and then click **Add**
1. Type the name of the device in the text box, and then click **OK**
1. Repeat steps 5 and 6 for each extra device account or group that you want to add
1. Click **OK** to close the group properties dialog box
After a device is a member of the group, you can force a Group Policy refresh on the device.
@ -47,8 +36,8 @@ After a device is a member of the group, you can force a Group Policy refresh on
From an elevated command prompt, run the following command:
``` syntax
gpupdate /target:device /force
``` cmd
gpupdate /target:device /force
```
After Group Policy is refreshed, you can see which GPOs are currently applied to the device.
@ -57,15 +46,6 @@ After Group Policy is refreshed, you can see which GPOs are currently applied to
From an elevated command prompt, run the following command:
``` syntax
``` cmd
gpresult /r /scope:computer
```
 
 

34
windows/security/operating-system-security/network-security/windows-firewall/appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md
View File

@ -3,21 +3,21 @@ title: Appendix A Sample GPO Template Files for Settings Used in this Guide
description: Use sample template files import an XML file containing customized registry preferences into a Group Policy Object (GPO).
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
ms.date: 11/10/2023
---
# Appendix A: Sample GPO Template Files for Settings Used in this Guide
# Appendix A: aample GPO template files for settings used in this guide
You can import an XML file containing customized registry preferences into a Group Policy Object (GPO) by using the Preferences feature of the Group Policy Management Console (GPMC).
To manually create the file, build the settings under **Computer Configuration**, **Preferences**, **Windows Settings**, **Registry**. After you have created the settings, drag the container to the desktop. An .xml file is created there.
To manually create the file, build the settings under **Computer Configuration** > **Preferences** > **Windows Settings** > **Registry**. After you create the settings, drag the container to the desktop. An .xml file is created there.
To import an .xml file to GPMC, drag it and drop it on the **Registry** node under **Computer Configuration**, **Preferences**, **Windows Settings**. If you copy the following sample XML code to a file, and then drag and drop it on the **Registry** node, it creates a **Server and Domain Isolation** collection with the six registry keys discussed in this guide.
To import an .xml file to GPMC, drag it and drop it on the **Computer Configuration** > **Preferences** > **Windows Settings** > **Registry** node. If you copy the following sample XML code to a file, and then drag and drop it on the **Registry** node, it creates a **Server and Domain Isolation** collection with the six registry keys discussed in this guide.
The following sample file uses item-level targeting to ensure that the registry keys are applied only on the versions of Windows to which they apply.
>**Note:**  The file shown here is for sample use only. It should be customized to meet the requirements of your organization’s deployment. To customize this file, import it into a test GPO, modify the settings, and then drag the Server and Domain Isolation Settings node to your desktop. The new file will contain all of your customization.
> [!NOTE]
> The file shown here is for sample use only. It should be customized to meet the requirements of your organization's deployment. To customize this file, import it into a test GPO, modify the settings, and then drag the Server and Domain Isolation Settings node to your desktop. The new file will contain all of your customization.
```xml
<?xml version="1.0" encoding="utf-8"?>
@ -31,11 +31,11 @@ The following sample file uses item-level targeting to ensure that the registry
image="12"
changed="2008-05-30 20:37:37"
uid="{52C38FD7-A081-404C-A8EA-B24A9614D0B5}"
desc="&lt;b&gt;Enable PMTU Discovery&lt;/b&gt;&lt;p&gt;
desc="<b>Enable PMTU Discovery</b><p>
This setting configures whether computers can use PMTU
discovery on the network.&lt;p&gt;
&lt;b&gt;1&lt;/b&gt; -- Enable&lt;br&gt;
&lt;b&gt;0&lt;/b&gt; -- Disable"
discovery on the network.<p>
<b>1</b> -- Enable<br>
<b>0</b> -- Disable"
bypassErrors="1">
<Properties
action="U"
@ -53,14 +53,14 @@ The following sample file uses item-level targeting to ensure that the registry
image="12"
changed="2008-05-30 20:33:32"
uid="{AE5C505D-283E-4060-9A55-70659DFD56B6}"
desc="&lt;b&gt;IPsec Default Exemptions for Windows Server 2008
and later&lt;/b&gt;&lt;p&gt;
desc="<b>IPsec Default Exemptions for Windows Server 2008
and later</b><p>
This setting determines which network traffic type is exempt
from any IPsec authentication requirements.&lt;p&gt;
&lt;b&gt;0&lt;/b&gt;: Exempts multicast, broadcast, RSVP, Kerberos, ISAKMP&lt;br&gt;
&lt;b&gt;1&lt;/b&gt;: Exempts multicast, broadcast, ISAKMP&lt;br&gt;
&lt;b&gt;2&lt;/b&gt;: Exempts RSVP, Kerberos, ISAKMP&lt;br&gt;
&lt;b&gt;3&lt;/b&gt;: Exempts ISAKMP only"
from any IPsec authentication requirements.<p>
<b>0</b>: Exempts multicast, broadcast, RSVP, Kerberos, ISAKMP<br>
<b>1</b>: Exempts multicast, broadcast, ISAKMP<br>
<b>2</b>: Exempts RSVP, Kerberos, ISAKMP<br>
<b>3</b>: Exempts ISAKMP only"
bypassErrors="1">
<Properties
action="U"

61
windows/security/operating-system-security/network-security/windows-firewall/assign-security-group-filters-to-the-gpo.md
View File

@ -2,69 +2,48 @@
title: Assign Security Group Filters to the GPO
description: Learn how to use Group Policy Management MMC to assign security group filters to a GPO to make sure that the GPO is applied to the correct computers.
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/07/2021
ms.topic: how-to
ms.date: 11/10/2023
---
# Assign Security Group Filters to the GPO
To make sure that your GPO is applied to the correct computers, use the Group Policy Management MMC snap-in to assign security group filters to the GPO.
>[!IMPORTANT]
>This deployment guide uses the method of adding the Domain Computers group to the membership group for the main isolated domain after testing is complete and you are ready to go live in production. To make this method work, you must prevent any computer that is a member of either the boundary or encryption zone from applying the GPO for the main isolated domain. For example, on the GPOs for the main isolated domain, deny Read and Apply Group Policy permissions to the membership groups for the boundary and encryption zones.
 
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the relevant GPOs.
In this topic:
- [Allow members of a group to apply a GPO](#to-allow-members-of-a-group-to-apply-a-gpo)
- [Prevent members of a group from applying a GPO](#to-prevent-members-of-a-group-from-applying-a-gpo)
- [Allow members of a group to apply a GPO](#to-allow-members-of-a-group-to-apply-a-gpo)
- [Prevent members of a group from applying a GPO](#to-prevent-members-of-a-group-from-applying-a-gpo)
## To allow members of a group to apply a GPO
Use the following procedure to add a group to the security filter on the GPO that allows group members to apply the GPO.
1. Open the Group Policy Management console.
2. In the navigation pane, find and then click the GPO that you want to modify.
3. In the details pane, under **Security Filtering**, click **Authenticated Users**, and then click **Remove**.
1. Open the Group Policy Management console
1. In the navigation pane, find and then select the GPO that you want to modify
1. In the details pane, under **Security Filtering**, select **Authenticated Users**, and then select **Remove**
>[!NOTE]
>You must remove the default permission granted to all authenticated users and computers to restrict the GPO to only the groups you specify. If the GPO contains User settings, and the **Authenticated Users** group is removed, and new security filtering is added using a security group that only contains user accounts, the GPO can fail to apply. Details and various workarounds are mentioned in this [Microsoft blog](https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/Who-broke-my-user-GPOs/ba-p/258781).
>You must remove the default permission granted to all authenticated users and computers to restrict the GPO to only the groups you specify. If the GPO contains User settings, and the **Authenticated Users** group is removed, and new security filtering isdded using a security group that only contains user accounts, the GPO can fail to apply. Details and various workarounds are mentioned in this [Microsoft blog](https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/Who-broke-my-user-GPOsa-p/258781).
4. Click **Add**.
1. Se;ect **Add**
1. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to apply the GPO, and then select **OK**. If you do not know the name, you can select **Advanced** to browse the list of groups available in the domain
5. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to apply the GPO, and then click **OK**. If you do not know the name, you can click **Advanced** to browse the list of groups available in the domain.
## To prevent members of a group from applying a GPO
## To prevent members of a group from applying a GPO
Use the following procedure to add a group to the security filter on the GPO that prevents group members from applying the GPO. This is typically used to prevent members of the boundary and encryption zones from applying the GPOs for the isolated domain.
1. Open the Group Policy Management console.
2. In the navigation pane, find and then click the GPO that you want to modify.
3. In the details pane, click the **Delegation** tab.
4. Click **Advanced**.
5. Under the **Group or user names** list, click **Add**.
6. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then click **OK**. If you do not know the name, you can click **Advanced** to browse the list of groups available in the domain.
7. Select the group in the **Group or user names** list, and then select the box in the **Deny** column for both **Read** and **Apply group policy**.
8. Click **OK**, and then in the **Windows Security** dialog box, click **Yes**.
9. The group appears in the list with **Custom** permissions.
1. Open the Group Policy Management console
1. In the navigation pane, find and then select the GPO that you want to modify
1. In the details pane, select the **Delegation** tab
1. Select **Advanced**
1. Under the **Group or user names** list, select **Add**
1. In the **Select User, Computer, or Group** dialog box, type the name of the group whose members are to be prevented from applying the GPO, and then select **OK**. If you do not know the name, you can select **Advanced** to browse the list of groups lable in the domain
1. Select the group in the **Group or user names** list, and then select the box in the **Deny** column for both **Read** and **Apply group policy**
1. Select **OK**, and then in the **Windows Security** dialog box, select **Yes**
1. The group appears in the list with **Custom** permissions

142
windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md
View File

@ -1,132 +1,112 @@
---
title: Best practices for configuring Windows Defender Firewall
description: Learn about best practices for configuring Windows Defender Firewall
title: Best practices for configuring Windows Firewall
description: Learn about best practices for configuring Windows Firewall
ms.prod: windows-client
ms.date: 11/09/2022
ms.collection:
- highpri
- tier3
- must-keep
ms.date: 11/10/2023
ms.topic: best-practice
---
# Best practices for configuring Windows Defender Firewall
# Best practices for configuring Windows Firewall
Windows Defender Firewall with Advanced Security provides host-based, two-way
network traffic filtering and blocks unauthorized network traffic flowing into
or out of the local device. Configuring your Windows Firewall based on the
following best practices can help you optimize protection for devices in your
network. These recommendations cover a wide range of deployments including home
networks and enterprise desktop/server systems.
Windows Firewall with Advanced Security provides host-based, two-way network traffic filtering and blocks unauthorized network traffic flowing into or out of the local device. Configuring your Windows Firewall based on the following best practices can help you optimize protection for devices in your network. These recommendations cover a wide range of deployments including home networks and enterprise desktop/server systems.
To open Windows Firewall, go to the **Start** menu, select **Run**,
type **WF.msc**, and then select **OK**. See also [Open Windows Firewall](open-windows-firewall-with-advanced-security.md).
To open Windows Firewall, select **Start** > **Run**, type **wf.msc**, and then select **OK**. See also [Open Windows Firewall](open-windows-firewall-with-advanced-security.md).
## Keep default settings
When you open the Windows Defender Firewall for the first time, you can see the default settings applicable to the local computer. The Overview panel displays security settings for each type of network to which the device can connect.
When you open the Windows Firewall for the first time, you can see the default settings applicable to the local computer. The Overview panel displays security settings for each type of network to which the device can connect.
![Windows Defender Firewall with Advanced Security first time opening.](images/fw01-profiles.png)
*Figure 1: Windows Defender Firewall*
![Windows Firewall with Advanced Security first time opening.](images/fw01-profiles.png)
1. **Domain profile**: Used for networks where there's a system of account authentication against an Active Directory domain controller
1. **Private profile**: Designed for and best used in private networks such as a home network
1. **Public profile**: Designed with higher security in mind for public networks, like Wi-Fi hotspots, coffee shops, airports, hotels, or stores
View detailed settings for each profile by right-clicking the top-level **Windows Defender Firewall with Advanced Security** node in the left pane and then selecting **Properties**.
To view detailed settings for each profile, right-click the top-level **Windows Defender Firewall with Advanced Security** node in the left pane and then select **Properties**.
Maintain the default settings in Windows Defender
Firewall whenever possible. These settings have been designed to secure your device for use in most network scenarios. One key example is the default Block behavior for Inbound connections.
Maintain the default settings in Windows Firewall whenever possible. These settings have been designed to secure your device for use in most network scenarios. One key example is the default Block behavior for Inbound connections.
![A screenshot of a cell phone Description automatically generated.](images/fw03-defaults.png)
*Figure 2: Default inbound/outbound settings*
:::image type="content" source="images/fw03-defaults.png" alt-text="Screenshot of the default inbound/outbound Firewall settings.":::
> [!IMPORTANT]
> To maintain maximum security, do not change the default Block setting for inbound connections.
For more on configuring basic firewall settings, see [Turn on Windows Firewall and Configure Default Behavior](turn-on-windows-firewall-and-configure-default-behavior.md) and [Checklist: Configuring Basic Firewall Settings](checklist-configuring-basic-firewall-settings.md).
## Understand rule precedence for inbound rules
## Rule precedence for inbound rules
In many cases, a next step for administrators will be to customize these profiles using rules (sometimes called filters) so that they can work with user apps or other types of software. For example, an administrator or user may choose to add a rule to accommodate a program, open a port or protocol, or allow a predefined type of traffic.
In many cases, a next step for administrators is to customize the firewall profiles using *rules* (sometimes called *filters*), so that they can work with applications or other types of software. For example, an administrator or user may choose to add a rule to accommodate a program, open a port or protocol, or allow a predefined type of traffic.
This rule-adding task can be accomplished by right-clicking either **Inbound Rules** or **Outbound Rules**, and selecting **New Rule**. The interface for adding a new rule looks like this:
The rule-adding task can be accomplished by right-clicking either **Inbound Rules** or **Outbound Rules**, and selecting **New Rule**. The interface for adding a new rule looks like this:
![Rule creation wizard.](images/fw02-createrule.png)
*Figure 3: Rule Creation Wizard*
> [!NOTE]
>This article doesn't cover step-by-step rule configuration. See the [Windows Firewall with Advanced Security Deployment Guide](windows-firewall-with-advanced-security-deployment-guide.md) for general guidance on policy creation.
In many cases, allowing specific types of inbound traffic is required for applications to function in the network. Administrators should keep the following rule precedence behaviors in mind when allowing these inbound exceptions:
1. Explicitly defined allow rules take precedence over the default block setting
1. Explicit block rules take precedence over any conflicting allow rules
1. More specific rules take precedence over less specific rules, except if there are explicit block rules as mentioned in 2. For example, if the parameters of rule 1 include an IP address range, while the parameters of rule 2 include a single IP host address, rule 2 takes precedence.
> [!TIP]
> Because of 1 and 2, when designing a set of policies you should make sure that there are no other explicit block rules that could inadvertently overlap, thus preventing the traffic flow you wish to allow.
A general security recommended practice when creating inbound rules is to be as specific as possible. However, when new rules must be made that use ports or IP addresses, consider using consecutive ranges or subnets instead of individual addresses or ports where possible. This approach avoids creation of multiple filters under the hood, reduces complexity, and helps to avoid performance degradation.
> [!NOTE]
>This article does not cover step-by-step rule configuration. See the [Windows Firewall with Advanced Security Deployment Guide](windows-firewall-with-advanced-security-deployment-guide.md) for general guidance on policy creation.
In many cases, allowing specific types of inbound traffic will be required for applications to function in the network. Administrators should keep the following rule precedence behaviors in mind when allowing these inbound exceptions.
1. Explicitly defined allow rules will take precedence over the default block setting.
1. Explicit block rules will take precedence over any conflicting allow rules.
1. More specific rules will take precedence over less specific rules, except if there are explicit block rules as mentioned in 2. (For example, if the parameters of rule 1 include an IP address range, while the parameters of rule 2 include a single IP host address, rule 2 will take precedence.)
Because of 1 and 2, it's important that, when designing a set of policies, you make sure that there are no other explicit block rules in place that could inadvertently overlap, thus preventing the traffic flow you wish to allow.
A general security best practice when creating inbound rules is to be as specific as possible. However, when new rules must be made that use ports or IP addresses, consider using consecutive ranges or subnets instead of individual addresses or ports where possible. This approach avoids creation of multiple filters under the hood, reduces complexity, and helps to avoid performance degradation.
> [!NOTE]
> Windows Defender Firewall does not support traditional weighted, administrator-assigned rule ordering. An effective policy set with expected behaviors can be created by keeping in mind the few, consistent, and logical rule behaviors described above.
> Windows Firewall doesn't support weighted, administrator-assigned rule ordering. An effective policy set with expected behaviors can be created by keeping in mind the few, consistent, and logical rule behaviors as described.
## Create rules for new applications before first launch
### Inbound allow rules
When first installed, networked applications and services issue a listen call specifying the protocol/port information required for them to function properly. As there's a default block action in Windows Defender Firewall, it's necessary to create inbound exception rules to allow this traffic. It's common for the app or the app installer itself to add this firewall rule. Otherwise, the user (or firewall admin on behalf of the user) needs to manually create a rule.
When first installed, networked applications and services issue a listen call specifying the protocol/port information required for them to function properly. As there's a default block action in Windows Firewall, it's necessary to create inbound exception rules to allow this traffic. It's common for the app or the app installer itself to add this firewall rule. Otherwise, the user (or firewall admin on behalf of the user) needs to manually create a rule.
If there's no active application or administrator-defined allow rule(s), a dialog box will prompt the user to either allow or block an application's packets the first time the app is launched or tries to communicate in the network.
If there's no active application or administrator-defined allow rule(s), a dialog box prompts the user to either allow or block an application's packets the first time the app is launched or tries to communicate in the network.
- If the user has admin permissions, they'll be prompted. If they respond *No* or cancel the prompt, block rules will be created. Two rules are typically created, one each for TCP and UDP traffic.
- If the user has admin permissions, they're prompted. If they respond *No* or cancel the prompt, block rules are created. Two rules are typically created, one each for TCP and UDP traffic.
- If the user isn't a local admin, they won't be prompted. In most cases, block rules are created.
- If the user isn't a local admin, they won't be prompted. In most cases, block rules will be created.
In either of the scenarios above, once these rules are added they must be deleted in order to generate the prompt again. If not, the traffic will continue to be blocked.
In either of these scenarios, once the rules are added, they must be deleted to generate the prompt again. If not, the traffic continues to be blocked.
> [!NOTE]
> The firewall's default settings are designed for security. Allowing all inbound connections by default introduces the network to various threats. Therefore, creating exceptions for inbound connections from third-party software should be determined by trusted app developers, the user, or the admin on behalf of the user.
> The firewall's default settings are designed for security. Allowing all inbound connections by default introduces the network to various threats. Therefore, creating exceptions for inbound connections from third-party software should be determined by trusted app developers, the user, or the admin on behalf of the user.
### Known issues with automatic rule creation
When designing a set of firewall policies for your network, it's a best practice to configure allow rules for any networked applications deployed on the host. Having these rules in place before the user first launches the application will help ensure a seamless experience.
When designing a set of firewall policies for your network, it's a recommended practice to configure *allow rules* for any networked applications deployed on the host. Having the rules in place before the user first launches the application helps to ensure a seamless experience.
The absence of these staged rules doesn't necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime require user interaction and administrative privilege. If the device is expected to be used by non-administrative users, you should follow best practices and provide these rules before the application's first launch to avoid unexpected networking issues.
To determine why some applications are blocked from communicating in the network, check for the following instances:
1. A user with sufficient privileges receives a query notification advising them that the application needs to make a change to the firewall policy. Not fully understanding the prompt, the user cancels or dismisses the prompt.
1. A user lacks sufficient privileges and is therefore not prompted to allow the application to make the appropriate policy changes.
1. Local Policy Merge is disabled, preventing the application or network service from creating local rules.
1. A user with sufficient privileges receives a query notification advising them that the application needs to make a change to the firewall policy. Not fully understanding the prompt, the user cancels or dismisses the prompt
1. A user lacks sufficient privileges and is therefore not prompted to allow the application to make the appropriate policy changes
1. Local Policy Merge is disabled, preventing the application or network service from creating local rules
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
:::image type="content" alt-text="Windows Firewall prompt." source="images/fw04-userquery.png":::
*Figure 4: Dialog box to allow access*
See also [Checklist: Creating Inbound Firewall Rules](checklist-creating-inbound-firewall-rules.md).
## Establish local policy merge and application rules
Firewall rules can be deployed:
1. Locally using the Firewall snap-in (**WF.msc**)
1. Locally using PowerShell
1. Remotely using Group Policy if the device is a member of an Active Directory Name, System Center Configuration Manager, or Intune (using workplace join)
1. Locally using the Firewall snap-in (**wf.msc**)
1. Locally using PowerShell
1. Remotely using Group Policy if the device is a member of an Active Directory Name or managed by Configuration Manager
1. Remotely, using a mobile device management (MDM) solution like Microsoft Intune
Rule merging settings control how rules from different policy sources can be combined. Administrators can configure different merge behaviors for Domain, Private, and Public profiles.
Rule merging settings control how rules from different policy sources can be combined. Administrators can configure different merge behaviors for *Domain*, *Private*, and *Public profiles*.
The rule-merging settings either allow or prevent local administrators from creating their own firewall rules in addition to those rules obtained from Group Policy.
![Customize settings.](images/fw05-rulemerge.png)
*Figure 5: Rule merging setting*
> [!TIP]
> In the firewall [configuration service provider](/windows/client-management/mdm/firewall-csp), the equivalent setting is *AllowLocalPolicyMerge*. This setting can be found under each respective profile node, *DomainProfile*, *PrivateProfile*, and *PublicProfile*.
@ -139,14 +119,14 @@ Management (MDM), or both (for hybrid or co-management environments).
As a best practice, it's important to list and log such apps, including the network ports used for communications. Typically, you can find what ports must be open for a given service on the app's website. For more complex or customer application deployments, a more thorough analysis may be needed using network packet capture tools.
In general, to maintain maximum security, admins should only push firewall exceptions for apps and services determined to serve legitimate purposes.
In general, to maintain maximum security, admins should only deploy firewall exceptions for apps and services determined to serve legitimate purposes.
> [!NOTE]
> The use of wildcard patterns, such as *C:\*\\teams.exe* is not supported in application rules. We currently only support rules created using the full path to the application(s).
> The use of wildcard patterns, such as *C:\*\\teams.exe* is not supported in application rules. You can only create rules using the full path to the application(s).
## Understand Group Policy Processing
## Understand group policy processing
The Windows Firewall settings configured via group policy are stored in the registry. By default, group policies are refreshed in the background every 90 minutes, with a random offset of 0 to 30 minutes.
The Windows Firewall settings configured via group policy or CSP are stored in the registry. By default, group policies are refreshed in the background every 90 minutes, with a random offset of 0 to 30 minutes.
Windows Firewall monitors the registry for changes, and if something is written to the registry it notifies the *Windows Filtering Platform (WFP)*, which performs the following actions:
@ -157,13 +137,13 @@ Windows Firewall monitors the registry for changes, and if something is written
> [!NOTE]
> The actions are triggered whenever something is written to, or deleted from the registry location the GPO settings are stored, regardless if there's really a configuration change. During the process, IPsec connections are disconnected.
Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a desired policy setting in case a user has changed it. To control the behavior of the registry group policy processing, you can use the policy `Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing`. The *Process even if the Group Policy objects have not changed* option updates and reapplies the policies even if the policies have not changed. This option is disabled by default.
Many policy implementations specify that they're updated only when changed. However, you might want to update unchanged policies, such as reapplying a desired policy setting in case a user has changed it. To control the behavior of the registry group policy processing, you can use the policy `Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing`. The *Process even if the Group Policy objects haven't changed* option updates and reapplies the policies even if the policies haven't changed. This option is disabled by default.
If you enable the option *Process even if the Group Policy objects have not changed*, the WFP filters get reapplied during **every** background refresh. In case you have ten group policies, the WFP filters get reapplied ten times during the refresh interval. If an error happens during policy processing, the applied settings may be incomplete, resulting in issues like:
If you enable the option *Process even if the Group Policy objects haven't changed*, the WFP filters get reapplied during **every** background refresh. In case you have 10 group policies, the WFP filters get reapplied 10 times during the refresh interval. If an error happens during policy processing, the applied settings might be incomplete, resulting in issues like:
- Windows Defender Firewall blocks inbound or outbound traffic allowed by group policies
- Windows Firewall blocks inbound or outbound traffic allowed by group policies
- Local Firewall settings are applied instead of group policy settings
- IPsec connections cannot establish
- IPsec connections can't establish
The temporary solution is to refresh the group policy settings, using the command `gpupdate.exe /force`, which requires connectivity to a domain controller.
@ -174,7 +154,7 @@ To avoid the issue, leave the policy `Computer Configuration > Administrative Te
>
> If there's a requirement to force registry deletion and rewrite, then disable background processing by checking the checkbox next to **Do not apply during periodic background processing**.
## Know how to use "shields up" mode for active attacks
## Know how to use *shields up* mode for active attacks
An important firewall feature you can use to mitigate damage during an active attack is the "shields up" mode. It's an informal term referring to an easy method a firewall administrator can use to temporarily increase security in the face of an active attack.
@ -189,7 +169,7 @@ incoming connections, including those in the list of allowed apps** setting foun
*Figure 7: Legacy firewall.cpl*
By default, the Windows Defender Firewall will block everything unless there's an exception rule created. This setting overrides the exceptions.
By default, the Windows Firewall blocks everything unless there's an exception rule created. This setting overrides the exceptions.
For example, the Remote Desktop feature automatically creates firewall rules when enabled. However, if there's an active exploit using multiple ports and services on a host, you can, instead of disabling individual rules, use the shields up mode to block all inbound connections, overriding previous exceptions, including the rules for Remote Desktop. The Remote Desktop rules remain intact but remote access won't work as long as shields up is activated.
@ -201,7 +181,7 @@ What follows are a few general guidelines for configuring outbound rules.
- The default configuration of Blocked for Outbound rules can be considered for certain highly secure environments. However, the Inbound rule configuration should never be changed in a way that Allows traffic by default
- It's recommended to Allow Outbound by default for most deployments for the sake of simplification around app deployments, unless the enterprise prefers tight security controls over ease-of-use
- In high security environments, an inventory of all enterprise-spanning apps must be taken and logged by the administrator or administrators. Records must include whether an app used requires network connectivity. Administrators will need to create new rules specific to each app that needs network connectivity and push those rules centrally, via group policy (GP), Mobile Device Management (MDM), or both (for hybrid or co-management environments)
- In high security environments, an inventory of all enterprise-spanning apps must be taken and logged by the administrator or administrators. Records must include whether an app used requires network connectivity. Administrators need to create new rules specific to each app that needs network connectivity and push those rules centrally, via group policy (GP), Mobile Device Management (MDM), or both (for hybrid or co-management environments)
For tasks related to creating outbound rules, see [Checklist: Creating Outbound Firewall Rules](checklist-creating-outbound-firewall-rules.md).
@ -211,21 +191,19 @@ When creating an inbound or outbound rule, you should specify details about the
## Configure Windows Firewall rules with WDAC tagging policies
Windows Firewall now supports the use of Windows Defender Application Control (WDAC) Application ID (AppID) tags in firewall rules. With this capability, Windows Firewall rules can now be scoped to an application or a group of applications by referencing process tags, without using absolute path or sacrificing security. There are two steps for this configuration:
Windows Firewall now supports the use of Windows Defender Application Control (WDAC) Application ID (AppID) tags in firewall rules. With this capability, Windows Firewall rules can now be scoped to an application or a group of applications by referencing process tags, without using absolute path or sacrificing security. There are two steps for this configuration:
### Step 1: Deploy WDAC AppId Tagging Policies
A Windows Defender Application Control (WDAC) policy needs to be deployed which specifies individual applications or groups of applications to apply a PolicyAppId tag to the process token(s). Then, the admin can define firewall rules which are scoped to all processes tagged with the matching PolicyAppId.  
A Windows Defender Application Control (WDAC) policy needs to be deployed which specifies individual applications or groups of applications to apply a PolicyAppId tag to the process token(s). Then, the admin can define firewall rules that are scoped to all processes tagged with the matching PolicyAppId.
Follow the detailed [WDAC Application ID (AppId) Tagging Guide](/windows/security/threat-protection/windows-defender-application-control/appidtagging/windows-defender-application-control-appid-tagging-guide) to create, deploy, and test an AppID (Application ID) policy to tag applications. 
Follow the detailed [WDAC Application ID (AppId) Tagging Guide](/windows/security/threat-protection/windows-defender-application-control/appidtagging/windows-defender-application-control-appid-tagging-guide) to create, deploy, and test an AppID (Application ID) policy to tag applications.
### Step 2: Configure Firewall Rules using PolicyAppId Tags
- **Deploy firewall rules with Intune:** When creating firewall rules with Intune Microsoft Defender Firewall Rules, provide the AppId tag in the Policy App ID setting. The properties come directly from the [Firewall configuration service provider ](/windows/client-management/mdm/firewall-csp)(CSP) and apply to the Windows platform.
You can do this through the Intune admin center under Endpoint security > Firewall. Policy templates can be found via Create policy > Windows 10, Windows 11, and Windows Server > Microsoft Defender Firewall or Microsoft Defender Firewall Rules.
- **Deploy firewall rules with Intune:** When creating firewall rules with Intune Microsoft Defender Firewall Rules, provide the AppId tag in the Policy App ID setting. The properties come directly from the [Firewall configuration service provider](/windows/client-management/mdm/firewall-csp)(CSP) and apply to the Windows platform.
You can do this through the Intune admin center under Endpoint security > Firewall. Policy templates can be found via Create policy > Windows 10, Windows 11, and Windows Server > Microsoft Defender Firewall or Microsoft Defender Firewall Rules.
OR
- **Create local firewall rules with PowerShell**: You can use PowerShell to configure by adding a Firewall rule using [New-NetFirewallRule](/powershell/module/netsecurity/new-netfirewallrule) and specify the `–PolicyAppId` tag. You can specify one tag at a time while creating firewall rules. Multiple User Ids are supported. 
- **Create local firewall rules with PowerShell**: You can use PowerShell to configure by adding a Firewall rule using [New-NetFirewallRule](/powershell/module/netsecurity/new-netfirewallrule) and specify the `-PolicyAppId` tag. You can specify one tag at a time while creating firewall rules. Multiple User Ids are supported.

2
windows/security/operating-system-security/network-security/windows-firewall/checklist-implementing-a-standalone-server-isolation-policy-design.md
View File

@ -18,7 +18,7 @@ This parent checklist includes cross-reference links to important concepts about
| Task | Reference |
| - | - |
| Review important concepts and examples for the server isolation policy design to determine if this design meets your implementation goals and the needs of your organization.| [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md)<br/>[Server Isolation Policy Design](server-isolation-policy-design.md)<br/>[Server Isolation Policy Design Example](server-isolation-policy-design-example.md)<br/>[Planning Server Isolation Zones](planning-server-isolation-zones.md) |
| Create the GPOs and connection security rules for isolated servers.| [Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone](checklist-configuring-rules-for-servers-in-a-standalone-isolated-server-zone.md)|
| Create the GPOs and connection security rules for isolated servers.| [Checklist: Configuring Rules for Servers in a Standalone Isolated Server Zone](checklist-configuring-rules-for-servers-in-a-standalone-isolated-server-zone.md)|
| Create the GPOs and connection security rules for the client devices that must connect to the isolated servers. | [Checklist: Creating Rules for Clients of a Standalone Isolated Server Zone](checklist-creating-rules-for-clients-of-a-standalone-isolated-server-zone.md)|
| Verify that the connection security rules are protecting network traffic on your test devices. | [Verify That Network Traffic Is Authenticated](verify-that-network-traffic-is-authenticated.md)|
| After you confirm that network traffic is authenticated by IPsec as expected, you can change authentication rules for the isolated server zone to require authentication instead of requesting it. | [Change Rules from Request to Require Mode](change-rules-from-request-to-require-mode.md)|