diff --git a/windows/security/threat-protection/windows-firewall/identifying-your-windows-firewall-with-advanced-security-deployment-goals.md b/windows/security/threat-protection/windows-firewall/identifying-your-windows-firewall-with-advanced-security-deployment-goals.md index 5684e64a1e..da1df7152e 100644 --- a/windows/security/threat-protection/windows-firewall/identifying-your-windows-firewall-with-advanced-security-deployment-goals.md +++ b/windows/security/threat-protection/windows-firewall/identifying-your-windows-firewall-with-advanced-security-deployment-goals.md @@ -21,7 +21,7 @@ ms.technology: windows-sec Correctly identifying your Windows Defender Firewall with Advanced Security implementation goals is essential for the success of your Windows Defender Firewall design project. Form a project team that can clearly articulate deployment issues in a vision statement. When you write your vision statement, identify, clarify, and refine your implementation goals. Prioritize and, if possible, combine your implementation goals so that you can design and deploy Windows Defender Firewall by using an iterative approach. You can take advantage of the predefined Windows Defender Firewall implementation goals presented in this guide that are relevant to your scenarios. -The following table lists the three main tasks for articulating, refining, and subsequently documenting your Windows Defender Firewall implementation goals: +The following table lists the three main tasks for articulating, refining, and later documenting your Windows Defender Firewall implementation goals: | Deployment goal tasks | Reference links | diff --git a/windows/security/threat-protection/windows-firewall/implementing-your-windows-firewall-with-advanced-security-design-plan.md b/windows/security/threat-protection/windows-firewall/implementing-your-windows-firewall-with-advanced-security-design-plan.md index 19be53c930..e99fb5bdc3 100644 --- a/windows/security/threat-protection/windows-firewall/implementing-your-windows-firewall-with-advanced-security-design-plan.md +++ b/windows/security/threat-protection/windows-firewall/implementing-your-windows-firewall-with-advanced-security-design-plan.md @@ -26,11 +26,11 @@ The following are important factors in the implementation of your Windows Defend - **Perimeter firewall**. Most organizations use a perimeter firewall to help protect the devices on the network from potentially malicious network traffic from outside of the organization's network boundaries. If you plan a deployment that includes a boundary zone to enable external devices to connect to devices in that zone, then you must allow that traffic through the perimeter firewall to the devices in the boundary zone. -- **Devices running operating systems other than Windows**. If your network includes devices that are not running the Windows operating system, then you must make sure that required communication with those devices is not blocked by the restrictions put in place by your design. You must do one of the following: +- **Devices running operating systems other than Windows**. If your network includes devices that aren't running the Windows operating system, then you must make sure that required communication with those devices isn't blocked by the restrictions put in place by your design. You must implement one of the following steps: - Include those devices in the isolated domain or zone by adding certificate-based authentication to your design. Many other operating systems can participate in an isolated domain or isolated server scenario, as long as certificate-based authentication is used. - - Include the device in the authentication exemption list included in your design. You can choose this option if for any reason the device cannot participate in the isolated domain design. + - Include the device in the authentication exemption list included in your design. You can choose this option if for any reason the device can't participate in the isolated domain design. ## How to implement your Windows Defender Firewall with Advanced Security design using this guide diff --git a/windows/security/threat-protection/windows-firewall/isolated-domain-gpos.md b/windows/security/threat-protection/windows-firewall/isolated-domain-gpos.md index afdbbb4444..b2b51c8bed 100644 --- a/windows/security/threat-protection/windows-firewall/isolated-domain-gpos.md +++ b/windows/security/threat-protection/windows-firewall/isolated-domain-gpos.md @@ -24,7 +24,7 @@ All of the devices in the isolated domain are added to the group CG\_DOMISO\_Iso Each GPO has a security group filter that prevents the GPO from applying to members of the group GP\_DOMISO\_No\_IPsec. A WMI filter is attached to each GPO to ensure that the GPO is applied to only the specified version of Windows. For more information, see the [Planning GPO Deployment](planning-gpo-deployment.md) section. -The GPOs created for the Woodgrove Bank isolated domain include the following: +The GPOs created for the Woodgrove Bank isolated domain include: - [GPO\_DOMISO\_IsolatedDomain\_Clients](gpo-domiso-isolateddomain-clients.md) diff --git a/windows/security/threat-protection/windows-firewall/isolated-domain.md b/windows/security/threat-protection/windows-firewall/isolated-domain.md index 336af76b07..ab40a0617d 100644 --- a/windows/security/threat-protection/windows-firewall/isolated-domain.md +++ b/windows/security/threat-protection/windows-firewall/isolated-domain.md @@ -22,9 +22,9 @@ ms.technology: windows-sec The isolated domain is the primary zone for trusted devices. The devices in this zone use connection security and firewall rules to control the communications that can be sent between devices in the zone. -The term *domain* in this context means a boundary of communications trust instead of an Active Directory domain. In this solution the two constructs are very similar because Active Directory domain authentication (Kerberos V5) is required for accepting inbound connections from trusted devices. However, many Active Directory domains (or forests) can be linked with trust relationships to provide a single, logical, isolated domain. In addition, devices that authenticate by using certificates can also be included in an isolated domain without joining the Active Directory domain. +The term *domain* in this context means a boundary of communications trust instead of an Active Directory domain. In this solution, the two constructs are similar because Active Directory domain authentication (Kerberos V5) is required for accepting inbound connections from trusted devices. However, many Active Directory domains (or forests) can be linked with trust relationships to provide a single, logical, isolated domain. In addition, devices that authenticate by using certificates can also be included in an isolated domain without joining the Active Directory domain. -For most implementations, an isolated domain will contain the largest number of devices. Other isolation zones can be created for the solution if their communication requirements differ from those of the isolated domain. Examples of these differences are what result in the boundary and encryption zones described in this guide. Conceptually, the isolated domain is just the largest isolation zone, and a superset to the other zones. +For most implementations, an isolated domain will contain the largest number of devices. Other isolation zones can be created for the solution if their communication requirements differ from those requirements of the isolated domain. Examples of these differences are what result in the boundary and encryption zones described in this guide. Conceptually, the isolated domain is just the largest isolation zone, and a superset to the other zones. You must create a group in Active Directory to contain members of the isolated domain. You then apply one of several GPOs that contain connection security and firewall rules to the group so that authentication on all inbound network connections is enforced. Creation of the group and how to link the GPOs that apply the rules to its members are discussed in the [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section. @@ -33,7 +33,7 @@ The GPOs for the isolated domain should contain the following connection securit ## GPO settings for isolated domain members running at least Windows Vista and Windows Server 2008 -GPOs for devices running at least Windows Vista and Windows Server 2008 should include the following: +GPOs for devices running at least Windows Vista and Windows Server 2008 should include: - IPsec default settings that specify the following options: @@ -41,11 +41,11 @@ GPOs for devices running at least Windows Vista and Windows Server 2008 should 2. Key exchange (main mode) security methods and algorithm. We recommend that you use at least DH4, AES and SHA2 in your settings. Use the strongest algorithm combinations that are common to all your supported operating systems. - 3. Data protection (quick mode) algorithm combinations. We recommend that you do not include DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. + 3. Data protection (quick mode) algorithm combinations. We recommend that you don't include DES, or MD5 in any setting. They're included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. If any NAT devices are present on your networks, use ESP encapsulation. If isolated domain members must communicate with hosts in the encryption zone, ensure that you include algorithms that are compatible with the requirements of the encryption mode policies. - 4. Authentication methods. Include at least device-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then also include user-based Kerberos V5 as an optional authentication method. Likewise, if any of your isolated domain members cannot use Kerberos V5 authentication, then include certificate-based authentication as an optional authentication method. + 4. Authentication methods. Include at least device-based Kerberos V5 authentication. If you want to use user-based access to isolated servers, then also include user-based Kerberos V5 as an optional authentication method. Likewise, if any of your isolated domain members can't use Kerberos V5 authentication, then include certificate-based authentication as an optional authentication method. - The following connection security rules: diff --git a/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md b/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md index e0e0de7084..0e6eba3376 100644 --- a/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md +++ b/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md @@ -20,7 +20,7 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -Sometimes a device cannot join an Active Directory domain, and therefore cannot use Kerberos V5 authentication with domain credentials. However, the device can still participate in the isolated domain by using certificate-based authentication. +Sometimes a device can't join an Active Directory domain, and therefore can't use Kerberos V5 authentication with domain credentials. However, the device can still participate in the isolated domain by using certificate-based authentication. The non-domain member server, and the clients that must be able to communicate with it, must be configured to use cryptographic certificates based on the X.509 standard. These certificates can be used as an alternate set of credentials. During IKE negotiation, each device sends a copy of its certificate to the other device. Each device examines the received certificate, and then validates its authenticity. To be considered authentic, the received certificate must be validated by a certification authority certificate in the recipient's Trusted Root Certification Authorities store on the local device. @@ -48,12 +48,12 @@ You must also import the purchased certificate into a GPO that deploys it to the ### Using a commercially purchased certificate for devices running a non-Windows operating system -If you are installing the certificates on an operating system other than Windows, see the documentation for that operating system. +If you're installing the certificates on an operating system other than Windows, see the documentation for that operating system. ## Configuring IPsec to use the certificates When the clients and servers have the certificates available, you can configure the IPsec and connection security rules to include those certificates as a valid authentication method. The authentication method requires the subject name of the certificate, for example: **DC=com,DC=woodgrovebank,CN=CorporateCertServer**. Optionally, select **Enable certificate to account mapping** to support using these credentials for restricting access to users or devices that are members of authorized groups in a server isolation solution. -Starting in Windows Server 2012,you can configure certificate selection criteria so the desired certificate is selected and/or validated. Enhanced Key Usage (EKU) criteria can be configured, as well as name restrictions and certificate thumbprints. This is configured using the **Advanced** button when choosing certificates for the authentication method in the user interface, or through Windows PowerShell. +Starting in Windows Server 2012, you can configure certificate selection criteria so the desired certificate is selected and/or validated. Enhanced Key Usage (EKU) criteria can be configured, and name restrictions and certificate thumbprints. This EKU is configured using the **Advanced** button when choosing certificates for the authentication method in the user interface, or through Windows PowerShell. **Next:** [Documenting the Zones](documenting-the-zones.md) diff --git a/windows/security/threat-protection/windows-firewall/planning-domain-isolation-zones.md b/windows/security/threat-protection/windows-firewall/planning-domain-isolation-zones.md index 8732491e55..1df3ac69c7 100644 --- a/windows/security/threat-protection/windows-firewall/planning-domain-isolation-zones.md +++ b/windows/security/threat-protection/windows-firewall/planning-domain-isolation-zones.md @@ -1,6 +1,6 @@ --- title: Planning Domain Isolation Zones (Windows) -description: Learn how to use information you have gathered to make decisions about isolation zones for your environment in Windows Defender Firewall with Advanced Security. +description: Learn how to use information you've gathered to make decisions about isolation zones for your environment in Windows Defender Firewall with Advanced Security. ms.reviewer: ms.author: dansimp ms.prod: m365-security @@ -24,7 +24,7 @@ After you have the required information about your network, Active Directory, an The bulk of the work in planning server and domain isolation is determining which devices to assign to each isolation zone. Correctly choosing the zone for each device is important to providing the correct level of security without compromising performance or the ability for a device to send or receive required network traffic. -The zones described in this guide include the following: +The zones described in this guide include: - [Exemption List](exemption-list.md) diff --git a/windows/security/threat-protection/windows-firewall/planning-gpo-deployment.md b/windows/security/threat-protection/windows-firewall/planning-gpo-deployment.md index fcdef1ec8f..356ce2a71e 100644 --- a/windows/security/threat-protection/windows-firewall/planning-gpo-deployment.md +++ b/windows/security/threat-protection/windows-firewall/planning-gpo-deployment.md @@ -22,11 +22,11 @@ ms.technology: windows-sec You can control which GPOs are applied to devices in Active Directory in a combination of three ways: -- **Active Directory organizational unit hierarchy**. This involves linking the GPO to a specific OU in the Active Directory OU hierarchy. All devices in the OU and its subordinate containers receive and apply the GPO. +- **Active Directory organizational unit hierarchy**. This method involves linking the GPO to a specific OU in the Active Directory OU hierarchy. All devices in the OU and its subordinate containers receive and apply the GPO. Controlling GPO application through linking to OUs is typically used when you can organize the OU hierarchy according to your domain isolation zone requirements. GPOs can apply settings to devices based on their location within Active Directory. If a device is moved from one OU to another, the policy linked to the second OU will eventually take effect when Group Policy detects the change during polling. -- **Security group filtering**. This involves linking the GPOs to the domain level (or other parent OU) in the OU hierarchy, and then selecting which devices receive the GPO by using permissions that only allow correct group members to apply the GPO. +- **Security group filtering**. This method involves linking the GPOs to the domain level (or other parent OU) in the OU hierarchy, and then selecting which devices receive the GPO by using permissions that only allow correct group members to apply the GPO. The security group filters are attached to the GPOs themselves. A group is added to the security group filter of the GPO in Active Directory, and then assigned Read and Apply Group Policy permissions. Other groups can be explicitly denied Read and Apply Group Policy permissions. Only those devices whose group membership are granted Read and Apply Group Policy permissions without any explicit deny permissions can apply the GPO. @@ -42,7 +42,7 @@ This guide uses a combination of security group filtering and WMI filtering to p ## Test your deployed groups and GPOs -After you have deployed your GPOs and added some test devices to the groups, confirm the following before you continue with more group members: +After you've deployed your GPOs and added some test devices to the groups, confirm the following before you continue with more group members: - Examine the GPOs that are both assigned to and filtered from the device. Run the **gpresult** tool at a command prompt. @@ -54,17 +54,17 @@ After you have deployed your GPOs and added some test devices to the groups, con - Verify that your programs are unaffected. Run them and confirm that they still work as expected. -After you have confirmed that the GPOs have been correctly applied, and that the devices are now communicating by using IPsec network traffic in request mode, you can begin to add more devices to the group accounts, in manageable numbers at a time. Continue to monitor and confirm the correct application of the GPOs to the devices. +After you've confirmed that the GPOs have been correctly applied, and that the devices are now communicating by using IPsec network traffic in request mode, you can begin to add more devices to the group accounts, in manageable numbers at a time. Continue to monitor and confirm the correct application of the GPOs to the devices. -## Do not enable require mode until deployment is complete +## Don't enable require mode until deployment is complete If you deploy a GPO that requires authentication to a device before the other devices have a GPO deployed, communication between them might not be possible. Wait until you have all the zones and their GPOs deployed in request mode and confirm (as described in the previous section) that the devices are successfully communicating by using IPsec. If there are problems with GPO deployment, or errors in configuration of one or more of the IPsec GPOs, devices can continue to operate, because request mode enables any device to fall back to clear communications. -Only after you have added all of the devices to their zones, and you have confirmed that communications are working as expected, you can start changing the request mode rules to require mode rules where it is required in the zones. We recommend that you enable require mode in the zones one zone at a time, pausing to confirm that they are functioning properly before you continue. Turn the required mode setting on for the server isolation zones first, then the encryption zone, and then the isolated domain. +Only after you've added all of the devices to their zones, and you've confirmed that communications are working as expected, you can start changing the request mode rules to require mode rules where it's required in the zones. We recommend that you enable require mode in the zones one zone at a time, pausing to confirm that they're functioning properly before you continue. Turn the required mode setting on for the server isolation zones first, then the encryption zone, and then the isolated domain. -Do not change the boundary zone GPO, because it must stay in request mode for both inbound and outbound connections. +Don't change the boundary zone GPO, because it must stay in request mode for both inbound and outbound connections. If you create other zones that require either inbound or outbound require mode, make the setting change in a manner that applies the setting in stages from the smaller groups of devices to the larger groups. diff --git a/windows/security/threat-protection/windows-firewall/planning-group-policy-deployment-for-your-isolation-zones.md b/windows/security/threat-protection/windows-firewall/planning-group-policy-deployment-for-your-isolation-zones.md index 46f1ec18cd..a4b877a50f 100644 --- a/windows/security/threat-protection/windows-firewall/planning-group-policy-deployment-for-your-isolation-zones.md +++ b/windows/security/threat-protection/windows-firewall/planning-group-policy-deployment-for-your-isolation-zones.md @@ -20,9 +20,9 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -After you have decided on the best logical design of your isolation environment for the network and device security requirements, you can start the implementation plan. +After you've decided on the best logical design of your isolation environment for the network and device security requirements, you can start the implementation plan. -You have a list of isolation zones with the security requirements of each. For implementation, you must plan the groups that will hold the device accounts in each zone, the network access groups that will be used to determine who can access an isolated server, and the GPOs with the connection security and firewall rules to apply to corresponding groups. Finally you must determine how you will ensure that the policies will only apply to the correct devices within each group. +You have a list of isolation zones with the security requirements of each. For implementation, you must plan the groups that will hold the device accounts in each zone, the network access groups that will be used to determine who can access an isolated server, and the GPOs with the connection security and firewall rules to apply to corresponding groups. Finally you must determine how you'll ensure that the policies will only apply to the correct devices within each group. - [Planning Isolation Groups for the Zones](planning-isolation-groups-for-the-zones.md) diff --git a/windows/security/threat-protection/windows-firewall/planning-isolation-groups-for-the-zones.md b/windows/security/threat-protection/windows-firewall/planning-isolation-groups-for-the-zones.md index 703b785517..3b9d484653 100644 --- a/windows/security/threat-protection/windows-firewall/planning-isolation-groups-for-the-zones.md +++ b/windows/security/threat-protection/windows-firewall/planning-isolation-groups-for-the-zones.md @@ -20,7 +20,7 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -Isolation groups in Active Directory are how you implement the various domain and server isolation zones. A device is assigned to a zone by adding its device account to the group which represents that zone. +Isolation groups in Active Directory are how you implement the various domain and server isolation zones. A device is assigned to a zone by adding its device account to the group that represents that zone. > [!CAUTION] > Do not add devices to your groups yet. If a device is in a group when the GPO is activated then that GPO is applied to the device. If the GPO is one that requires authentication, and the other devices have not yet received their GPOs, the device that uses the new GPO might not be able to communicate with the others. @@ -31,15 +31,15 @@ The following table lists typical groups that can be used to manage the domain i | Group name | Description | | - | - | -| CG_DOMISO_No_IPsec | A universal group of device accounts that do not participate in the IPsec environment. Typically consists of infrastructure device accounts that will also be included in exemption lists.
This group is used in security group filters to ensure that GPOs with IPsec rules are not applied to group members.| -| CG_DOMISO_IsolatedDomain | A universal group of device accounts that contains the members of the isolated domain.
During the early days of testing, this group might contain only a very small number of devices. During production, it might contain the built-in **Domain Computers** group to ensure that every device in the domain participates.
Members of this group receive the domain isolation GPO that requires authentication for inbound connections.| +| CG_DOMISO_No_IPsec | A universal group of device accounts that don't participate in the IPsec environment. Typically consists of infrastructure device accounts that will also be included in exemption lists.
This group is used in security group filters to ensure that GPOs with IPsec rules aren't applied to group members.| +| CG_DOMISO_IsolatedDomain | A universal group of device accounts that contains the members of the isolated domain.
During the early days of testing, this group might contain only a small number of devices. During production, it might contain the built-in **Domain Computers** group to ensure that every device in the domain participates.
Members of this group receive the domain isolation GPO that requires authentication for inbound connections.| | CG_DOMISO_Boundary | A universal group of device accounts that contains the members of the boundary zone.

Members of this group receive a GPO that specifies that authentication is requested, but not required.| | CG_DOMISO_Encryption | A universal group of device accounts that contains the members of the encryption zone.
Members of this group receive a GPO that specifies that both authentication and encryption are required for all inbound connections. | CG_SRVISO_*ServerRole* | A universal group of device accounts that contains the members of the server isolation group.
Members of this group receive the server isolation GPO that requires membership in a network access group in order to connect.
There will be one group for each set of servers that have different user and device restriction requirements. | Multiple GPOs might be delivered to each group. Which one actually becomes applied depends on the security group filters assigned to the GPOs in addition to the results of any WMI filtering assigned to the GPOs. Details of the GPO layout are discussed in the section [Planning the GPOs](planning-the-gpos.md). -If multiple GPOs are assigned to a group, and similar rules are applied, the rule that most specifically matches the network traffic is the one that is used by the device. For example, if one IPsec rule says to request authentication for all IP traffic, and a second rule from a different GPO says to require authentication for IP traffic to and from a specific IP address, then the second rule takes precedence because it is more specific. +If multiple GPOs are assigned to a group, and similar rules are applied, the rule that most specifically matches the network traffic is the one that is used by the device. For example, if one IPsec rule says to request authentication for all IP traffic, and a second rule from a different GPO says to require authentication for IP traffic to and from a specific IP address, then the second rule takes precedence because it's more specific. **Next:** [Planning Network Access Groups](planning-network-access-groups.md) diff --git a/windows/security/threat-protection/windows-firewall/planning-network-access-groups.md b/windows/security/threat-protection/windows-firewall/planning-network-access-groups.md index 115c4bc0b4..a46279468a 100644 --- a/windows/security/threat-protection/windows-firewall/planning-network-access-groups.md +++ b/windows/security/threat-protection/windows-firewall/planning-network-access-groups.md @@ -26,7 +26,7 @@ Minimize the number of NAGs to limit the complexity of the solution. You need on The NAGs that you create and populate become active by referencing them in the **Users and Computers** tab of the firewall rules in the GPO assigned to the isolated servers. The GPO must also contain connection security rules that require authentication to supply the credentials checked for NAG membership. -For the Woodgrove Bank scenario, access to the devices running SQL Server that support the WGBank application are restricted to the WGBank front-end servers and to approved administrative users logged on to specific authorized administrative devices. They are also only accessed by the approved admin users and the service account that is used to the run the WGBank front end service. +For the Woodgrove Bank scenario, access to the devices running SQL Server which support the WGBank application are restricted to the WGBank front-end servers and to approved administrative users logged on to specific authorized administrative devices. They're also only accessed by the approved admin users and the service account that is used to the run the WGBank front end service. | NAG Name | NAG Member Users, Computers, or Groups | Description | | - | - | - | diff --git a/windows/security/threat-protection/windows-firewall/planning-server-isolation-zones.md b/windows/security/threat-protection/windows-firewall/planning-server-isolation-zones.md index 7c7ab8b78d..9e0486133d 100644 --- a/windows/security/threat-protection/windows-firewall/planning-server-isolation-zones.md +++ b/windows/security/threat-protection/windows-firewall/planning-server-isolation-zones.md @@ -24,13 +24,13 @@ Sometimes a server hosts data that is sensitive. If your servers host data that The second option is to additionally restrict access to the server, not just to members of the isolated domain, but to only those users or devices who have business reasons to access the resources on the server. You can specify only approved users, or you can additionally specify that the approved users can only access the server from approved devices. -To grant access, you add the approved user and device accounts to network access groups (NAGs) that are referenced in a firewall rule on this server. When the user sends a request to the server, the standard domain isolation rules are invoked. This causes IKE to use Kerberos V5 to exchange credentials with the server. The additional firewall rule on the server causes Windows to check the provided device and user accounts for group membership in the NAGs. If either the user or device is not a member of a required NAG then the network connection is refused. +To grant access, you add the approved user and device accounts to network access groups (NAGs) that are referenced in a firewall rule on this server. When the user sends a request to the server, the standard domain isolation rules are invoked. This invocation causes IKE to use Kerberos V5 to exchange credentials with the server. The other firewall rule on the server causes Windows to check the provided device and user accounts for group membership in the NAGs. If either the user or device isn't a member of a required NAG, then the network connection is refused. ## Isolated domains and isolated servers -If you are using an isolated domain, the client devices already have the IPsec rules to enable them to authenticate traffic when the server requires it. If you add an isolated server, it must have a GPO applied to its group with the appropriate connection security and firewall rules. The rules enforce authentication and restrict access to only connections that are authenticated as coming from an authorized device or user. +If you're using an isolated domain, the client devices already have the IPsec rules to enable them to authenticate traffic when the server requires it. If you add an isolated server, it must have a GPO applied to its group with the appropriate connection security and firewall rules. The rules enforce authentication and restrict access to only connections that are authenticated as coming from an authorized device or user. -If you are not using an isolated domain, but still want to isolate a server that uses IPsec, you must configure the client devices that you want to access the server to use the appropriate IPsec rules. If the client devices are members of an Active Directory domain, you can still use Group Policy to configure the clients. Instead of applying the GPO to the whole domain, you apply the GPO to only members of the NAG. +If you aren't using an isolated domain, but still want to isolate a server that uses IPsec, you must configure the client devices that you want to access the server to use the appropriate IPsec rules. If the client devices are members of an Active Directory domain, you can still use Group Policy to configure the clients. Instead of applying the GPO to the whole domain, you apply the GPO to only members of the NAG. ## Creating multiple isolated server zones @@ -44,7 +44,7 @@ An isolated server is often a member of the encryption zone. Therefore, copying ### GPO settings for isolated servers running at least Windows Server 2008 -GPOs for devices running at least Windows Server 2008 should include the following: +GPOs for devices running at least Windows Server 2008 should include: >**Note:**  The connection security rules described here are identical to the ones for the encryption zone. If you do not want to encrypt access and also restrict access to NAG members, you can use connection security rules identical to the main isolated domain. You must still add the firewall rule described at the end of this list to change it into an isolated server zone. @@ -52,16 +52,16 @@ GPOs for devices running at least Windows Server 2008 should include the follow 1. Exempt all ICMP traffic from IPsec. - 2. Key exchange (main mode) security methods and algorithm. We recommend that you do not include Diffie-Hellman Group 1, DES, or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. + 2. Key exchange (main mode) security methods and algorithm. We recommend that you don't include Diffie-Hellman Group 1, DES, or MD5 in any setting. They're included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. - 3. Data protection (quick mode) algorithm combinations. Check **Require encryption for all connection security rules that use these settings**, and then specify one or more integrity and encryption combinations. We recommend that you do not include DES or MD5 in any setting. They are included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. + 3. Data protection (quick mode) algorithm combinations. Check **Require encryption for all connection security rules that use these settings**, and then specify one or more integrity and encryption combinations. We recommend that you don't include DES or MD5 in any setting. They're included only for compatibility with previous versions of Windows. Use the strongest algorithm combinations that are common to all your supported operating systems. - If any NAT devices are present on your networks, do not use AH because it cannot traverse NAT devices. If isolated servers must communicate with hosts in the encryption zone, include an algorithm that is compatible with the requirements of the encryption zone GPOs. + If any NAT devices are present on your networks, don't use AH because it can't traverse NAT devices. If isolated servers must communicate with hosts in the encryption zone, include an algorithm that is compatible with the requirements of the encryption zone GPOs. - 4. Authentication methods. Include at least device-based Kerberos V5 authentication for compatibility with the rest of the isolated domain. If you want to restrict access to specific user accounts, also include user-based Kerberos V5 authentication as an optional authentication method. Do not make the user-based authentication method mandatory, or else devices that cannot use AuthIP instead of IKE, including Windows XP and Windows Server 2003, cannot communicate. Likewise, if any of your domain isolation members cannot use Kerberos V5, include certificate-based authentication as an optional authentication method. + 4. Authentication methods. Include at least device-based Kerberos V5 authentication for compatibility with the rest of the isolated domain. If you want to restrict access to specific user accounts, also include user-based Kerberos V5 authentication as an optional authentication method. Don't make the user-based authentication method mandatory, or else devices that can't use AuthIP instead of IKE, including Windows XP and Windows Server 2003, can't communicate. Likewise, if any of your domain isolation members can't use Kerberos V5, include certificate-based authentication as an optional authentication method. - The following connection security and firewall rules: - +s - A connection security rule that exempts all devices on the exemption list from authentication. Be sure to include all your Active Directory domain controllers on this list. Enter subnet addresses, if applicable in your environment. - A connection security rule, from **Any IP address** to **Any IP address**, that requires inbound and requests outbound authentication by using Kerberos V5 authentication. diff --git a/windows/security/threat-protection/windows-firewall/planning-settings-for-a-basic-firewall-policy.md b/windows/security/threat-protection/windows-firewall/planning-settings-for-a-basic-firewall-policy.md index 5aed4df804..6f5c67f5bd 100644 --- a/windows/security/threat-protection/windows-firewall/planning-settings-for-a-basic-firewall-policy.md +++ b/windows/security/threat-protection/windows-firewall/planning-settings-for-a-basic-firewall-policy.md @@ -20,11 +20,11 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -After you have identified your requirements, and have the information about the network layout and devices available, you can begin to design the GPO settings and rules that will enable you to enforce your requirements on the devices. +After you've identified your requirements, and have the information about the network layout and devices available, you can begin to design the GPO settings and rules that will enable you to enforce your requirements on the devices. -The following is a list of the firewall settings that you might consider for inclusion in a basic firewall design, together with recommendations to serve as a starting point for your analysis: +The following list is that of the firewall settings that you might consider for inclusion in a basic firewall design, together with recommendations to serve as a starting point for your analysis: -- **Profile selection**. The firewall rules can be configured for any of the network location profiles that you see in the Network and Sharing Center: **Domain**, **Public**, and **Private**. Most settings are enforced in the Domain profile, without an option for the user to change them. However, you might want to leave the profile settings configurable by the user on devices that can be taken from the organization's physical network and joined to a public or home network. If you lock down the public and private profiles, you might prevent a user from accessing a required network program or service. Because they are not on the organization's network, you cannot fix a connectivity problem by deploying rule changes in a GPO. For each section that follows, consider each profile and apply the rules to those profiles that make sense for your organization. +- **Profile selection**. The firewall rules can be configured for any of the network location profiles that you see in the Network and Sharing Center: **Domain**, **Public**, and **Private**. Most settings are enforced in the Domain profile, without an option for the user to change them. However, you might want to leave the profile settings configurable by the user on devices that can be taken from the organization's physical network and joined to a public or home network. If you lock down the public and private profiles, you might prevent a user from accessing a required network program or service. Because they aren't on the organization's network, you can't fix a connectivity problem by deploying rule changes in a GPO. For each section that follows, consider each profile and apply the rules to those profiles that make sense for your organization. >**Important:**  We recommend that on server devices that you set all rules for all profiles to prevent any unexpected profile switch from disrupting network connectivity. You might consider a similar practice for your desktop devices, and only support different profiles on portable devices. @@ -36,17 +36,17 @@ The following is a list of the firewall settings that you might consider for inc - **Allow unicast response: Yes**. We recommend that you use the default setting of **Yes** unless you have specific requirements to do otherwise. -- **Apply local firewall rules: Yes**. We recommend that you allow users to create and use local firewall rules. If you set this to **No**, then when a user clicks **Allow** on the notification message to allow traffic for a new program, Windows does not create a new firewall rule and the traffic remains blocked. +- **Apply local firewall rules: Yes**. We recommend that you allow users to create and use local firewall rules. If you set this setting to **No**, then when a user clicks **Allow** on the notification message to allow traffic for a new program, Windows doesn't create a new firewall rule and the traffic remains blocked. - If you and the IT staff can create and maintain the list of firewall rules for all permitted applications and deploy them by using GPOs then you can set this value to **No**. + If you and the IT staff can create and maintain the list of firewall rules for all permitted applications and deploy them by using GPOs, then you can set this value to **No**. - **Apply local connection security rules: No**. We recommend that you prevent users from creating and using their own connection security rules. Connection failures caused by conflicting rules can be difficult to troubleshoot. - **Logging**. We recommend that you enable logging to a file on the local hard disk. Be sure to limit the size, such as 4096 KB, to avoid causing performance problems by filling the user's hard disk. Be sure to specify a folder to which the Windows Defender Firewall with Advanced Security service account has write permissions. -- **Inbound rules**. Create inbound rules for programs that must be able to receive unsolicited inbound network packets from another device on the network. Make the rules as specific as possible to reduce the risk of malicious programs exploiting the rules. For example, specify both program and port numbers. Specifying a program ensures that the rule is only active when the program is actually running, and specifying the port number ensures that the program cannot receive unexpected traffic on a different port. +- **Inbound rules**. Create inbound rules for programs that must be able to receive unsolicited inbound network packets from another device on the network. Make the rules as specific as possible to reduce the risk of malicious programs exploiting the rules. For example, specify both program and port numbers. Specifying a program ensures that the rule is only active when the program is actually running, and specifying the port number ensures that the program can't receive unexpected traffic on a different port. - Inbound rules are common on servers, because they host services to which client devices connect. When you install programs and services on a server, the installation program typically creates and enables the rules for you. Examine the rules to ensure that they do not open up more ports than are required. + Inbound rules are common on servers, because they host services to which client devices connect. When you install programs and services on a server, the installation program typically creates and enables the rules for you. Examine the rules to ensure that they don't open up more ports than are required. >**Important:**  If you create inbound rules that permit RPC network traffic by using the **RPC Endpoint Mapper** and **Dynamic RPC** rule options, then all inbound RPC network traffic is permitted because the firewall cannot filter network traffic based on the UUID of the destination application. diff --git a/windows/security/threat-protection/windows-firewall/planning-the-gpos.md b/windows/security/threat-protection/windows-firewall/planning-the-gpos.md index 054cd6b4c9..c61cc01904 100644 --- a/windows/security/threat-protection/windows-firewall/planning-the-gpos.md +++ b/windows/security/threat-protection/windows-firewall/planning-the-gpos.md @@ -26,7 +26,7 @@ When you plan the GPOs for your different isolation zones, you must complete the A few things to consider as you plan the GPOs: -- Do not allow a device to be a member of more than one isolation zone. A device in more than one zone receives multiple and possibly contradictory GPOs. This can result in unexpected, and difficult to troubleshoot behavior. +- Don't allow a device to be a member of more than one isolation zone. A device in more than one zone receives multiple and possibly contradictory GPOs. This receipt of multiple GPOs can result in unexpected, and difficult to troubleshoot behavior. The examples in this guide show GPOs that are designed to prevent the requirement to belong to multiple zones. @@ -43,13 +43,13 @@ A few things to consider as you plan the GPOs: > [!NOTE] > Devices running Windows 7, Windows Server 2008 R2, and later support different network location types, and therefore profiles, for each network adapter at the same time. Each network adapter is assigned the network location appropriate for the network to which it is connected. Windows Defender Firewall then enforces only those rules that apply to that network type’s profile. So certain types of traffic are blocked when coming from a network adapter connected to a public network, but those same types might be permitted when coming from a private or domain network. -After considering these issues, document each GPO that you require, and the details about the connection security and firewall rules that it needs. +After you consider these issues, document each GPO that you require, and the details about the connection security and firewall rules that it needs. ## Woodgrove Bank example GPOs The Woodgrove Bank example uses the following set of GPOs to support its domain isolation requirements. This section only discusses the rules and settings for server and domain isolation. GPO settings that affect which devices receive the GPO, such as security group filtering and WMI filtering, are discussed in the [Planning GPO Deployment](planning-gpo-deployment.md) section. -In this section you can find information about the following: +In this section you can find information about: - [Firewall GPOs](firewall-gpos.md) diff --git a/windows/security/threat-protection/windows-firewall/planning-to-deploy-windows-firewall-with-advanced-security.md b/windows/security/threat-protection/windows-firewall/planning-to-deploy-windows-firewall-with-advanced-security.md index 1bb9e49550..b2922c2dd6 100644 --- a/windows/security/threat-protection/windows-firewall/planning-to-deploy-windows-firewall-with-advanced-security.md +++ b/windows/security/threat-protection/windows-firewall/planning-to-deploy-windows-firewall-with-advanced-security.md @@ -38,11 +38,11 @@ The design team's strategy for determining how WMI and security group filters at ### Configure communication between members and devices -Decide what communication is to be allowed between members of each of the zones in the isolated domain and devices that are not part of the isolated domain or members of the isolated domain's exemption list. +Decide what communication is to be allowed between members of each of the zones in the isolated domain and devices that aren't part of the isolated domain or members of the isolated domain's exemption list. ### Exempt domain controllers from IPsec authentication requirements -It is recommended that domain controllers are exempt from IPsec authentication requirements. If they are not exempt and authentication fails, then domain clients might not be able to receive Group Policy updates to the IPsec connection security rules from the domain controllers. +It's recommended that domain controllers are exempt from IPsec authentication requirements. If they aren't exempt and authentication fails, then domain clients might not be able to receive Group Policy updates to the IPsec connection security rules from the domain controllers. ### Configure IPsec authentication rules @@ -58,7 +58,7 @@ For all devices to communicate with each other, they must share a common set of: - Quick mode data integrity algorithms -If at least one set of each does not match between two devices, then the devices cannot successfully communicate. +If at least one set of each doesn't match between two devices, then the devices can't successfully communicate. ## Deploy your Windows Firewall Design Plan diff --git a/windows/security/threat-protection/windows-firewall/planning-your-windows-firewall-with-advanced-security-design.md b/windows/security/threat-protection/windows-firewall/planning-your-windows-firewall-with-advanced-security-design.md index c88257ead5..3c54199363 100644 --- a/windows/security/threat-protection/windows-firewall/planning-your-windows-firewall-with-advanced-security-design.md +++ b/windows/security/threat-protection/windows-firewall/planning-your-windows-firewall-with-advanced-security-design.md @@ -20,17 +20,17 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -After you have gathered the relevant information in the previous sections, and understand the basics of the designs as described earlier in this guide, you can select the design (or combination of designs) that meet your needs. +After you've gathered the relevant information in the previous sections, and understood the basics of the designs as described earlier in this guide, you can select the design (or combination of designs) that meet your needs. ## Basic firewall design We recommend that you deploy at least the basic firewall design. As discussed in the [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md) section, host-based firewalls are an important element in a defense-in-depth strategy and complement most other security measures you put in place in your organization. -When you are ready to examine the options for firewall policy settings, see the [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md) section. +When you're ready to examine the options for firewall policy settings, see the [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md) section. ## Algorithm and method support and selection -To create a domain isolation or server isolation design, you must understand the algorithms available in each version of Windows, as well as their relative strengths. +To create a domain isolation or server isolation design, you must understand the algorithms available in each version of Windows, and their relative strengths. ## IPsec performance considerations @@ -45,11 +45,11 @@ Include this design in your plans: - If you have an Active Directory domain of which most of the devices are members. -- If you want to prevent the devices in your organization from accepting any unsolicited network traffic from devices that are not part of the domain. +- If you want to prevent the devices in your organization from accepting any unsolicited network traffic from devices that aren't part of the domain. -If you plan on including the basic firewall design as part of your deployment, we recommend that you deploy the firewall policies first to confirm that they work properly. Also plan to enable your connection security rules in request mode at first, instead of the more restrictive require mode, until you are sure that the devices are all correctly protecting network traffic with IPsec. If something is wrong, request mode still allows communications to continue while you are troubleshooting. +If you plan on including the basic firewall design as part of your deployment, we recommend that you deploy the firewall policies first to confirm that they work properly. Also plan to enable your connection security rules in request mode at first, instead of the more restrictive require mode, until you're sure that the devices are all correctly protecting network traffic with IPsec. If something is wrong, request mode still allows communications to continue while you're troubleshooting. -When you are ready to examine the options for creating an isolated domain, see the [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) section. +When you're ready to examine the options for creating an isolated domain, see the [Planning Domain Isolation Zones](planning-domain-isolation-zones.md) section. ## Server isolation design @@ -58,38 +58,38 @@ Include this design in your plans: - If you have an isolated domain and you want to additionally restrict access to specific servers to only authorized users and devices. -- You are not deploying an isolated domain, but want to take advantage of similar benefits for a few specific servers. You can restrict access to the isolated servers to only authorized users and devices. +- You aren't deploying an isolated domain, but want to take advantage of similar benefits for a few specific servers. You can restrict access to the isolated servers to only authorized users and devices. -If you plan to include domain isolation in your deployment, we recommend that you complete that layer and confirm its correct operation before you implement the additional server isolation elements. +If you plan to include domain isolation in your deployment, we recommend that you complete that layer and confirm its correct operation before you implement the other server isolation elements. -When you are ready to examine the options for isolating servers, see the [Planning Server Isolation Zones](planning-server-isolation-zones.md) section. +When you're ready to examine the options for isolating servers, see the [Planning Server Isolation Zones](planning-server-isolation-zones.md) section. ## Certificate-based authentication design Include this design in your plans: -- If you want to implement some of the elements of domain or server isolation on devices that are not joined to an Active Directory domain, or do not want to use domain membership as an authentication mechanism. +- If you want to implement some of the elements of domain or server isolation on devices that aren't joined to an Active Directory domain, or don't want to use domain membership as an authentication mechanism. -- You have an isolated domain and want to include a server that is not a member of the Active Directory domain because the device is not running Windows, or for any other reason. +- You have an isolated domain and want to include a server that isn't a member of the Active Directory domain because the device isn't running Windows, or for any other reason. -- You must enable external devices that are not managed by your organization to access information on one of your servers, and want to do this in a secure way. +- You must enable external devices that aren't managed by your organization to access information on one of your servers in a secure way. If you plan to include domain or server isolation in your deployment, we recommend that you complete those elements and confirm their correct operation before you add certificate-based authentication to the devices that require it. -When you are ready to examine the options for using certificate-based authentication, see the [Planning Certificate-based Authentication](planning-certificate-based-authentication.md) section. +When you're ready to examine the options for using certificate-based authentication, see the [Planning Certificate-based Authentication](planning-certificate-based-authentication.md) section. ## Documenting your design -After you finish selecting the designs that you will use, you must assign each of your devices to the appropriate isolation zone and document the assignment for use by the deployment team. +After you finish selecting the designs that you'll use, you must assign each of your devices to the appropriate isolation zone and document the assignment for use by the deployment team. - [Documenting the Zones](documenting-the-zones.md) ## Designing groups and GPOs -After you have selected a design and assigned your devices to zones, you can begin laying out the isolation groups for each zone, the network access groups for isolated server access, and the GPOs that you will use to apply the settings and rules to your devices. +After you've selected a design and assigned your devices to zones, you can begin laying out the isolation groups for each zone, the network access groups for isolated server access, and the GPOs that you'll use to apply the settings and rules to your devices. -When you are ready to examine the options for the groups, filters, and GPOs, see the [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section. +When you're ready to examine the options for the groups, filters, and GPOs, see the [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) section. **Next:** [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md) diff --git a/windows/security/threat-protection/windows-firewall/protect-devices-from-unwanted-network-traffic.md b/windows/security/threat-protection/windows-firewall/protect-devices-from-unwanted-network-traffic.md index ba994c905e..0ae3e5785f 100644 --- a/windows/security/threat-protection/windows-firewall/protect-devices-from-unwanted-network-traffic.md +++ b/windows/security/threat-protection/windows-firewall/protect-devices-from-unwanted-network-traffic.md @@ -20,13 +20,13 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -Although network perimeter firewalls provide important protection to network resources from external threats, there are network threats that a perimeter firewall cannot protect against. Some attacks might successfully penetrate the perimeter firewall, and at that point what can stop it? Other attacks might originate from inside the network, such as malware that is brought in on portable media and run on a trusted device. Portable device are often taken outside the network and connected directly to the Internet, without adequate protection between the device and security threats. +Although network perimeter firewalls provide important protection to network resources from external threats, there are network threats that a perimeter firewall can't protect against. Some attacks might successfully penetrate the perimeter firewall, and at that point what can stop it? Other attacks might originate from inside the network, such as malware that is brought in on portable media and run on a trusted device. Portable devices are often taken outside the network and connected directly to the Internet, without adequate protection between the device and security threats. Reports of targeted attacks against organizations, governments, and individuals have become more widespread in recent years. For a general overview of these threats, also known as advanced persistent threats (APT), see the [Microsoft Security Intelligence Report](https://www.microsoft.com/security/business/security-intelligence-report). -Running a host-based firewall on every device that your organization manages is an important layer in a "defense-in-depth" security strategy. A host-based firewall can help protect against attacks that originate from inside the network and also provide additional protection against attacks from outside the network that manage to penetrate the perimeter firewall. It also travels with a portable device to provide protection when it is away from the organization's network. +Running a host-based firewall on every device that your organization manages is an important layer in a "defense-in-depth" security strategy. A host-based firewall can help protect against attacks that originate from inside the network and also provide extra protection against attacks from outside the network that manage to penetrate the perimeter firewall. It also travels with a portable device to provide protection when it's away from the organization's network. -A host-based firewall helps secure a device by dropping all network traffic that does not match the administrator-designed rule set for permitted network traffic. This design, which corresponds to [Basic Firewall Policy Design](basic-firewall-policy-design.md), provides the following benefits: +A host-based firewall helps secure a device by dropping all network traffic that doesn't match the administrator-designed rule set for permitted network traffic. This design, which corresponds to [Basic Firewall Policy Design](basic-firewall-policy-design.md), provides the following benefits: - Network traffic that is a reply to a request from the local device is permitted into the device from the network. @@ -34,7 +34,7 @@ A host-based firewall helps secure a device by dropping all network traffic that For example, Woodgrove Bank wants a device that is running SQL Server to be able to receive the SQL queries sent to it by client devices. The firewall policy deployed to the device that is running SQL Server includes firewall rules that specifically allow inbound network traffic for the SQL Server program. -- Outbound network traffic that is not specifically blocked is allowed on the network. +- Outbound network traffic that isn't blocked is allowed on the network. For example, Woodgrove Bank has a corporate policy that prohibits the use of certain peer-to-peer file sharing programs. The firewall policy deployed to the computers on the network includes firewall rules that block both inbound and outbound network traffic for the prohibited programs. All other outbound traffic is permitted. @@ -42,6 +42,6 @@ The following component is recommended for this deployment goal: - **Active Directory**: Active Directory supports centralized management of connection security rules by configuring the rules in one or more Group Policy objects (GPOs) that can be automatically applied to all relevant computers in the domain. -Other means of deploying a firewall policy are available, such as creating scripts that use the netsh command-line tool, and then running those scripts on each computer in the organization. This guide uses Active Directory as a recommended means of deployment because of its ability to scale to very large organizations. +Other means of deploying a firewall policy are available, such as creating scripts that use the netsh command-line tool, and then running those scripts on each computer in the organization. This guide uses Active Directory as a recommended means of deployment because of its ability to scale to large organizations. **Next:** [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md) diff --git a/windows/security/threat-protection/windows-firewall/quarantine.md b/windows/security/threat-protection/windows-firewall/quarantine.md index 42338ede59..debe26322b 100644 --- a/windows/security/threat-protection/windows-firewall/quarantine.md +++ b/windows/security/threat-protection/windows-firewall/quarantine.md @@ -17,9 +17,9 @@ ms.technology: windows-sec One of the security challenges that network admins face is configuring a machine properly after a network change. -Network changes can happen frequently. Additionally, the operations required to recategorize the network after a change and apply the correct security policies on a machine are non-trivial and may require considerable CPU time. This is especially true for machines that are part of the domain. In the past, the delay in applying security policies during network recategorization has been successfully exploited for vulnerabilities. +Network changes can happen frequently. Additionally, the operations required to recategorize the network after a change and apply the correct security policies on a machine are non-trivial and may require considerable CPU time. This requirement by operations is especially true for machines that are part of the domain. In the past, the delay in applying security policies during network recategorization has been successfully exploited for vulnerabilities. -To counter this potential exploitation, Windows Firewall will quarantine an interface until the system has successfully recategorized the network and Windows Filtering Platform (WFP) has the correct filters applied for the updated interface configuration. During quarantine, all new inbound connections without exceptions are blocked to the machine. +To counter this potential exploitation, Windows Firewall will quarantine an interface until the system has successfully recategorized the network, and Windows Filtering Platform (WFP) has the correct filters applied for the updated interface configuration. During quarantine, all new inbound connections without exceptions are blocked to the machine. While the quarantine feature has long been a part of Windows Firewall, the feature behavior has often caused confusion for customers unaware of quarantine and its motivations. @@ -50,7 +50,7 @@ For more information about WFP layers and sublayers, see [WFP Operation](/window ### Quarantine default inbound block filter -The quarantine default inbound block filter effectively blocks any new non-loopback inbound connections if the packet is not explicitly permitted by another filter in the quarantine sublayer. +The quarantine default inbound block filter effectively blocks any new non-loopback inbound connections if the packet isn't explicitly permitted by another filter in the quarantine sublayer. ### Quarantine default exception filters @@ -62,9 +62,9 @@ The interface un-quarantine filters allow all non-loopback packets if the interf ## Quarantine flow -The following describes the general flow of quarantine: +The following events describe the general flow of quarantine: -1. There is some change on the current network interface. +1. There's some change on the current network interface. 2. The interface un-quarantine filters will no longer permit new inbound connections. The interface is now in quarantine state. @@ -102,7 +102,7 @@ The `netEvent` will have more information about the packet that was dropped incl If the filter that dropped that packet was by the quarantine default inbound block filter, then the drop `netEvent` will have `filterOrigin` as `Quarantine Default`. -The following is a sample `netEvent` with `filterOrigin` as `Quarantine Default`. +The following code is a sample `netEvent` with `filterOrigin` as `Quarantine Default`. ```XML @@ -202,8 +202,8 @@ Get-NetIPInterface –InterfaceIndex 5 ![Quarantine Interfaceindex.](images/quarantine-interfaceindex1.png) -Using the interface name, event viewer can be searched for any interface related changes. +With the help of the interface name, event viewer can be searched for any interface related changes. To enable more networking audit events, see [Enable IPsec and Windows Firewall Audit Events](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754714(v=ws.10)). -Packet drops from the quarantine default inbound block filter are often transient and do not signify anything more than a network change on the interface. \ No newline at end of file +Packet drops from the quarantine default inbound block filter are often transient and don't signify anything more than a network change on the interface. \ No newline at end of file diff --git a/windows/security/threat-protection/windows-firewall/require-encryption-when-accessing-sensitive-network-resources.md b/windows/security/threat-protection/windows-firewall/require-encryption-when-accessing-sensitive-network-resources.md index 23025f1e50..92a170d7ef 100644 --- a/windows/security/threat-protection/windows-firewall/require-encryption-when-accessing-sensitive-network-resources.md +++ b/windows/security/threat-protection/windows-firewall/require-encryption-when-accessing-sensitive-network-resources.md @@ -20,7 +20,7 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -The use of authentication in the previously described goal ([Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)) enables a device in the isolated domain to block traffic from untrusted devices. However, it does not prevent an untrusted device from eavesdropping on the network traffic shared between two trusted devices, because by default network packets are not encrypted. +The use of authentication in the previously described goal ([Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)) enables a device in the isolated domain to block traffic from untrusted devices. However, it doesn't prevent an untrusted device from eavesdropping on the network traffic shared between two trusted devices, because by default network packets aren't encrypted. For devices that share sensitive information over the network, Windows Defender Firewall with Advanced Security allows you to require that all such network traffic be encrypted. Using encryption can help you comply with regulatory and legislative requirements such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. By creating connection security rules that apply to devices that host and exchange sensitive data, you can help protect the confidentiality of that data by encrypting it. @@ -30,7 +30,7 @@ The following illustration shows an encryption zone in an isolated domain. The r This goal provides the following benefits: -- Devices in the encryption zone require authentication to communicate with other devices. This works no differently from the domain isolation goal and design. For more info, see [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md). +- Devices in the encryption zone require authentication to communicate with other devices. This rule works no differently from the domain isolation goal and design. For more information, see [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md). - Devices in the encryption zone require that all inbound and outbound network traffic be encrypted. diff --git a/windows/security/threat-protection/windows-firewall/restrict-access-to-only-specified-users-or-devices.md b/windows/security/threat-protection/windows-firewall/restrict-access-to-only-specified-users-or-devices.md index b91f299c18..f9a9247b52 100644 --- a/windows/security/threat-protection/windows-firewall/restrict-access-to-only-specified-users-or-devices.md +++ b/windows/security/threat-protection/windows-firewall/restrict-access-to-only-specified-users-or-devices.md @@ -22,13 +22,13 @@ ms.technology: windows-sec Domain isolation (as described in the previous goal [Restrict Access to Only Trusted Devices](restrict-access-to-only-trusted-devices.md)) prevents devices that are members of the isolated domain from accepting network traffic from untrusted devices. However, some devices on the network might host sensitive data that must be additionally restricted to only those users and computers that have a business requirement to access the data. -Windows Defender Firewall with Advanced Security enables you to restrict access to devices and users that are members of domain groups authorized to access that device. These groups are called *network access groups (NAGs)*. When a device authenticates to a server, the server checks the group membership of the computer account and the user account, and grants access only if membership in the NAG is confirmed. Adding this check creates a virtual "secure zone" within the domain isolation zone. You can have multiple devices in a single secure zone, and it is likely that you will create a separate zone for each set of servers that have specific security access needs. Devices that are part of this server isolation zone are often also part of the encryption zone (see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)). +Windows Defender Firewall with Advanced Security enables you to restrict access to devices and users that are members of domain groups authorized to access that device. These groups are called *network access groups (NAGs)*. When a device authenticates to a server, the server checks the group membership of the computer account and the user account, and grants access only if membership in the NAG is confirmed. Adding this check creates a virtual "secure zone" within the domain isolation zone. You can have multiple devices in a single secure zone, and it's likely that you'll create a separate zone for each set of servers that have specific security access needs. Devices that are part of this server isolation zone are often also part of the encryption zone (see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md)). Restricting access to only users and devices that have a business requirement can help you comply with regulatory and legislative requirements, such as those found in the Federal Information Security Management Act of 2002 (FISMA), the Sarbanes-Oxley Act of 2002, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government and industry regulations. You can restrict access by specifying either computer or user credentials. -The following illustration shows an isolated server, and examples of devices that can and cannot communicate with it. Devices that are outside the Woodgrove corporate network, or computers that are in the isolated domain but are not members of the required NAG, cannot communicate with the isolated server. +The following illustration shows an isolated server, and examples of devices that can and can't communicate with it. Devices that are outside the Woodgrove corporate network, or computers that are in the isolated domain but aren't members of the required NAG, can't communicate with the isolated server. ![isolated domain with network access groups.](images/wfas-domainnag.gif) @@ -40,7 +40,7 @@ This goal, which corresponds to [Server Isolation Policy Design](server-isolatio - Server isolation can also be configured independently of an isolated domain. To do so, configure only the devices that must communicate with the isolated server with connection security rules to implement authentication and check NAG membership. -- A server isolation zone can be simultaneously configured as an encryption zone. To do this, configure the GPO with rules that force encryption in addition to requiring authentication and restricting access to NAG members. For more information, see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md). +- A server isolation zone can be simultaneously configured as an encryption zone. To do so, configure the GPO with rules that force encryption in addition to requiring authentication and restricting access to NAG members. For more information, see [Require Encryption When Accessing Sensitive Network Resources](require-encryption-when-accessing-sensitive-network-resources.md). The following components are required for this deployment goal: diff --git a/windows/security/threat-protection/windows-firewall/restrict-access-to-only-trusted-devices.md b/windows/security/threat-protection/windows-firewall/restrict-access-to-only-trusted-devices.md index cc78b7ceb7..6f48e70c2f 100644 --- a/windows/security/threat-protection/windows-firewall/restrict-access-to-only-trusted-devices.md +++ b/windows/security/threat-protection/windows-firewall/restrict-access-to-only-trusted-devices.md @@ -20,7 +20,7 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -Your organizational network likely has a connection to the Internet. You also likely have partners, vendors, or contractors who attach devices that are not owned by your organization to your network. Because you do not manage those devices, you cannot trust them to be free of malicious software, maintained with the latest security updates, or in any way in compliance with your organization's security policies. These untrustworthy devices both on and outside of your physical network must not be permitted to access your organization's devices except where it is truly required. +Your organizational network likely has a connection to the Internet. You also likely have partners, vendors, or contractors who attach devices that aren't owned by your organization to your network. Because you don't manage those devices, you can't trust them to be free of malicious software, maintained with the latest security updates, or in any way in compliance with your organization's security policies. These untrustworthy devices both on and outside of your physical network must not be permitted to access your organization's devices except where it's truly required. To mitigate this risk, you must be able to isolate the devices you trust, and restrict their ability to receive unsolicited network traffic from untrusted devices. By using connection security and firewall rules available in Windows Defender Firewall with Advanced Security, you can logically isolate the devices that you trust by requiring that all unsolicited inbound network traffic be authenticated. Authentication ensures that each device or user can positively identify itself by using credentials that are trusted by the other device. Connection security rules can be configured to use IPsec with the Kerberos V5 protocol available in Active Directory, or certificates issued by a trusted certification authority as the authentication method. @@ -35,21 +35,21 @@ The following illustration shows an isolated domain, with one of the zones that These goals, which correspond to [Domain Isolation Policy Design](domain-isolation-policy-design.md) and [Certificate-based Isolation Policy Design](certificate-based-isolation-policy-design.md), provide the following benefits: -- Devices in the isolated domain accept unsolicited inbound network traffic only when it can be authenticated as coming from another device in the isolated domain. Exemption rules can be defined to allow inbound traffic from trusted computers that for some reason cannot perform IPsec authentication. +- Devices in the isolated domain accept unsolicited inbound network traffic only when it can be authenticated as coming from another device in the isolated domain. Exemption rules can be defined to allow inbound traffic from trusted computers that for some reason can't perform IPsec authentication. - For example, Woodgrove Bank wants all of its devices to block all unsolicited inbound network traffic from any device that it does not manage. The connection security rules deployed to domain member devices require authentication as a domain member or by using a certificate before an unsolicited inbound network packet is accepted. + For example, Woodgrove Bank wants all of its devices to block all unsolicited inbound network traffic from any device that it doesn't manage. The connection security rules deployed to domain member devices require authentication as a domain member or by using a certificate before an unsolicited inbound network packet is accepted. - Devices in the isolated domain can still send outbound network traffic to untrusted devices and receive the responses to the outbound requests. - For example, Woodgrove Bank wants its users at client devices to be able to access Web sites on the Internet. The default Windows Defender Firewall settings for outbound network traffic allow this. No additional rules are required. + For example, Woodgrove Bank wants its users at client devices to be able to access Web sites on the Internet. The default Windows Defender Firewall settings for outbound network traffic allow this access. No other rules are required. These goals also support optional zones that can be created to add customized protection to meet the needs of subsets of an organization's devices: -- Devices in the "boundary zone" are configured to use connection security rules that request but do not require authentication. This enables them to receive unsolicited inbound network traffic from untrusted devices, and also to receive traffic from the other members of the isolated domain. +- Devices in the "boundary zone" are configured to use connection security rules that request but don't require authentication. This configuration enables them to receive unsolicited inbound network traffic from untrusted devices, and also to receive traffic from the other members of the isolated domain. - For example, Woodgrove Bank has a server that must be accessed by its partners' devices through the Internet. The rules applied to devices in the boundary zone use authentication when the client device can support it, but do not block the connection if the client device cannot authenticate. + For example, Woodgrove Bank has a server that must be accessed by its partners' devices through the Internet. The rules applied to devices in the boundary zone use authentication when the client device can support it, but don't block the connection if the client device can't authenticate. -- Devices in the "encryption zone" require that all network traffic in and out must be encrypted to secure potentially sensitive material when it is sent over the network. +- Devices in the "encryption zone" require that all network traffic in and out must be encrypted to secure potentially sensitive material when it's sent over the network. For example, Woodgrove Bank wants the devices running SQL Server to only transmit data that is encrypted to help protect the sensitive data stored on those devices. diff --git a/windows/security/threat-protection/windows-firewall/server-isolation-gpos.md b/windows/security/threat-protection/windows-firewall/server-isolation-gpos.md index 9f249ae1c5..6c2574d928 100644 --- a/windows/security/threat-protection/windows-firewall/server-isolation-gpos.md +++ b/windows/security/threat-protection/windows-firewall/server-isolation-gpos.md @@ -22,14 +22,14 @@ ms.technology: windows-sec Each set of devices that have different users or devices accessing them require a separate server isolation zone. Each zone requires one GPO for each version of Windows running on devices in the zone. The Woodgrove Bank example has an isolation zone for their devices that run SQL Server. The server isolation zone is logically considered part of the encryption zone. Therefore, server isolation zone GPOs must also include rules for encrypting all isolated server traffic. Woodgrove Bank copied the encryption zone GPOs to serve as a starting point, and renamed them to reflect their new purpose. -All of the device accounts for devices in the SQL Server server isolation zone are added to the group CG\_SRVISO\_WGBANK\_SQL. This group is granted Read and Apply Group Policy permissions in on the GPOs described in this section. The GPOs are only for server versions of Windows. Client devices are not expected to be members of the server isolation zone, although they can access the servers in the zone by being a member of a network access group (NAG) for the zone. +All of the device accounts for devices in the SQL Server server isolation zone are added to the group CG\_SRVISO\_WGBANK\_SQL. This group is granted Read and Apply Group Policy permissions in on the GPOs described in this section. The GPOs are only for server versions of Windows. Client devices aren't expected to be members of the server isolation zone, although they can access the servers in the zone by being a member of a network access group (NAG) for the zone. ## GPO\_SRVISO This GPO is identical to the GPO\_DOMISO\_Encryption GPO with the following changes: -- The firewall rule that enforces encryption is modified to include the NAGs on the **Users and Computers** tab of the rule. The NAGs granted permission include CG\_NAG\_SQL\_Users and CG\_NAG\_SQL\_Computers. +- The firewall rule that enforces encryption is modified to include the NAGs on the **Users and Computers** tab of the rule. The NAGs-granted permissions include CG\_NAG\_SQL\_Users and CG\_NAG\_SQL\_Computers. >**Important:**  Earlier versions of Windows support only device-based authentication. If you specify that user authentication is mandatory, only users on devices that are running at least Windows Vista or Windows Server 2008 can connect. diff --git a/windows/security/threat-protection/windows-firewall/server-isolation-policy-design-example.md b/windows/security/threat-protection/windows-firewall/server-isolation-policy-design-example.md index f5b9e6802b..bfade02b3c 100644 --- a/windows/security/threat-protection/windows-firewall/server-isolation-policy-design-example.md +++ b/windows/security/threat-protection/windows-firewall/server-isolation-policy-design-example.md @@ -22,9 +22,9 @@ ms.technology: windows-sec This design example continues to use the fictitious company Woodgrove Bank, as described in the [Firewall Policy Design Example](firewall-policy-design-example.md) section and the [Domain Isolation Policy Design Example](domain-isolation-policy-design-example.md) section. -In addition to the protections provided by the firewall and domain isolation, Woodgrove Bank wants to provide additional protection to the devices that are running Microsoft SQL Server for the WGBank program. They contain personal data, including each customer's financial history. Government and industry rules and regulations specify that access to this information must be restricted to only those users who have a legitimate business need. This includes a requirement to prevent interception of and access to the information when it is in transit over the network. +In addition to the protections provided by the firewall and domain isolation, Woodgrove Bank wants to provide extra protection to the devices that are running Microsoft SQL Server for the WGBank program. They contain personal data, including each customer's financial history. Government and industry rules and regulations specify that access to this information must be restricted to only those users who have a legitimate business need. These rules and regulations include a requirement to prevent interception of and access to the information when it is in transit over the network. -The information presented by the WGBank front-end servers to the client devices, and the information presented by the WGPartner servers to the remote partner devices, are not considered sensitive for the purposes of the government regulations, because they are processed to remove sensitive elements before transmitting the data to the client devices. +The information presented by the WGBank front-end servers to the client devices, and the information presented by the WGPartner servers to the remote partner devices, aren't considered sensitive for the purposes of the government regulations, because they're processed to remove sensitive elements before transmitting the data to the client devices. In this guide, the examples show server isolation layered on top of a domain isolation design. If you have an isolated domain, the client devices are already equipped with GPOs that require authentication. You only have to add settings to the isolated server(s) to require authentication on inbound connections, and to check for membership in the NAG. The connection attempt succeeds only if NAG membership is confirmed. @@ -34,7 +34,7 @@ Server isolation can also be deployed by itself, to only the devices that must p In short, instead of applying the client GPO to all clients in the domain, you apply the GPO to only the members of the NAG. -If you do not have an Active Directory domain, you can manually apply the connection security rules, use a netsh command-line script, or use a Windows PowerShell script to help automate the configuration of the rules on larger numbers of devices. If you do not have an Active Directory domain, you cannot use the Kerberos V5 protocol, but instead must provide the clients and the isolated servers with certificates that are referenced in the connection security rules. +If you don't have an Active Directory domain, you can manually apply the connection security rules, use a netsh command-line script, or use a Windows PowerShell script to help automate the configuration of the rules on larger numbers of devices. If you don't have an Active Directory domain, you can't use the Kerberos V5 protocol, but instead must provide the clients and the isolated servers with certificates that are referenced in the connection security rules. ## Design requirements @@ -44,11 +44,11 @@ The following illustration shows the traffic protection needs for this design ex ![isolated server example.](images/wfas-design3example1.gif) -1. Access to the SQL Server devices must be restricted to only those computer or user accounts that have a business requirement to access the data. This includes the service accounts that are used by the WGBank front-end servers, and administrators of the SQL Server devices. In addition, access is only granted when it is sent from an authorized computer. Authorization is determined by membership in a network access group (NAG). +1. Access to the SQL Server devices must be restricted to only those computer or user accounts that have a business requirement to access the data. These accounts include the service accounts that are used by the WGBank front-end servers, and administrators of the SQL Server devices. In addition, access is only granted when it's sent from an authorized computer. Authorization is determined by membership in a network access group (NAG). 2. All network traffic to and from the SQL Server devices must be encrypted. -3. Client devices or users whose accounts are not members of the NAG cannot access the isolated servers. +3. Client devices or users whose accounts aren't members of the NAG can't access the isolated servers. **Other traffic notes:** @@ -62,12 +62,12 @@ Woodgrove Bank uses Active Directory groups and GPOs to deploy the server isolat As in the previously described policy design examples, GPOs to implement the domain isolation environment are linked to the domain container in Active Directory, and then WMI filters and security group filters are attached to GPOs to ensure that the correct GPO is applied to each computer. The following groups were created by using the Active Directory Users and Computers snap-in, and all devices that run Windows were added to the correct groups. -- **CG\_SRVISO\_WGBANK\_SQL**. This group contains the computer accounts for the devices that run SQL Server. Members of this group receive a GPO with firewall and connections security rules that require that only users who are members of the group CG\_NAG\_SQL\_USERS can access the server, and only when they are using a computer that is a member of the group CG\_NAG\_SQL\_COMPUTERS. +- **CG\_SRVISO\_WGBANK\_SQL**. This group contains the computer accounts for the devices that run SQL Server. Members of this group receive a GPO with firewall and connections security rules that require that only users who are members of the group CG\_NAG\_SQL\_USERS can access the server, and only when they're using a computer that is a member of the group CG\_NAG\_SQL\_COMPUTERS. >**Note:**  You can design your GPOs in nested groups. For example, you can make the boundary group a member of the isolated domain group, so that it receives the firewall and basic isolated domain settings through that nested membership, with only the changes supplied by the boundary zone GPO. However, devices that are running older versions of Windows can only support a single IPsec policy being active at a time. The policies for each GPO must be complete (and to a great extent redundant with each other), because you cannot layer them as you can in the newer versions of Windows. For simplicity, this guide describes the techniques used to create the independent, non-layered policies. We recommend that you create and periodically run a script that compares the memberships of the groups that must be mutually exclusive and reports any devices that are incorrectly assigned to more than one group.   -Network access groups (NAGs) are not used to determine which GPOs are applied to a computer. Instead, these groups determine which users and devices can access the services on the isolated server. +Network access groups (NAGs) aren't used to determine which GPOs are applied to a computer. Instead, these groups determine which users and devices can access the services on the isolated server. - **CG\_NAG\_SQL\_COMPUTERS**. This network access group contains the computer accounts that are able to access the devices running SQL Server hosting the WGBank data. Members of this group include the WGBank front-end servers, and some client devices from which SQL Server administrators are permitted to work on the servers. @@ -75,8 +75,8 @@ Network access groups (NAGs) are not used to determine which GPOs are applied to >**Note:**  You can use a single group for both user and computer accounts. Woodgrove Bank chose to keep them separate for clarity. -If Woodgrove Bank wants to implement server isolation without domain isolation, the CG\_NAG\_SQL\_COMPUTERS group can also be attached as a security group filter on the GPOs that apply connection security rules to the client devices. By doing this, all the devices that are authorized to access the isolated server also have the required connection security rules. +If Woodgrove Bank wants to implement server isolation without domain isolation, the CG\_NAG\_SQL\_COMPUTERS group can also be attached as a security group filter on the GPOs that apply connection security rules to the client devices. By doing this task, all the devices that are authorized to access the isolated server also have the required connection security rules. -You do not have to include the encryption-capable rules on all devices. Instead, you can create GPOs that are applied only to members of the NAG, in addition to the standard domain isolation GPO, that contain connection security rules to support encryption. +You don't have to include the encryption-capable rules on all devices. Instead, you can create GPOs that are applied only to members of the NAG, in addition to the standard domain isolation GPO, that contains connection security rules to support encryption. **Next:** [Certificate-based Isolation Policy Design Example](certificate-based-isolation-policy-design-example.md) diff --git a/windows/security/threat-protection/windows-firewall/server-isolation-policy-design.md b/windows/security/threat-protection/windows-firewall/server-isolation-policy-design.md index c9a669692f..91160b8e0a 100644 --- a/windows/security/threat-protection/windows-firewall/server-isolation-policy-design.md +++ b/windows/security/threat-protection/windows-firewall/server-isolation-policy-design.md @@ -22,15 +22,15 @@ ms.technology: windows-sec In the server isolation policy design, you assign servers to a zone that allows access only to users and devices that authenticate as members of an approved network access group (NAG). -This design typically begins with a network configured as described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. For this design, you then create zones for servers that have additional security requirements. The zones can limit access to the server to only members of authorized groups, and can optionally require the encryption of all traffic in or out of these servers. This can be done on a per server basis, or for a group of servers that share common security requirements. +This design typically begins with a network configured as described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. For this design, you then create zones for servers that have more security requirements. The zones can limit access to the server to only members of authorized groups, and can optionally require the encryption of all traffic in or out of these servers. These restrictions and requirements can be done on a per-server basis, or for a group of servers that share common security requirements. -You can implement a server isolation design without using domain isolation. To do this, you use the same principles as domain isolation, but instead of applying them to an Active Directory domain, you apply them only to the devices that must be able to access the isolated servers. The GPO contains connection security and firewall rules that require authentication when communicating with the isolated servers. In this case, the NAGs that determine which users and devices can access the isolated server are also used to determine which devices receive the GPO. +You can implement a server isolation design without using domain isolation. To do this implementation, you use the same principles as domain isolation, but instead of applying them to an Active Directory domain, you apply them only to the devices that must be able to access the isolated servers. The GPO contains connection security and firewall rules that require authentication when communicating with the isolated servers. In this case, the NAGs that determine which users and devices can access the isolated server are also used to determine which devices receive the GPO. The design is shown in the following illustration, with arrows that show the permitted communication paths. ![isolated domain with isolated server.](images/wfas-domainisohighsec.gif) -Characteristics of this design include the following: +Characteristics of this design include: - Isolated domain (area A) - The same isolated domain described in the [Domain Isolation Policy Design](domain-isolation-policy-design.md) section. If the isolated domain includes a boundary zone, then devices in the boundary zone behave just like other members of the isolated domain in the way that they interact with devices in server isolation zones. diff --git a/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md b/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md index 2337344ccf..a0116d71eb 100644 --- a/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md +++ b/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md @@ -25,7 +25,7 @@ This document guides you through steps to debug Universal Windows Platform (UWP UWP app network connectivity issues are typically caused by: -1. The UWP app was not permitted to receive loopback traffic. This must be configured. By default, UWP apps are not allowed to receive loopback traffic. +1. The UWP applications not being permitted to receive loopback traffic. This permission must be configured. By default, UWP applications aren't allowed to receive loopback traffic. 2. The UWP app is missing the proper capability tokens. 3. The private range is configured incorrectly. For example, the private range is set incorrectly through GP/MDM policies, etc. @@ -34,8 +34,7 @@ To understand these causes more thoroughly, there are several concepts to review The traffic of network packets (what's permitted and what’s not) on Windows is determined by the Windows Filtering Platform (WFP). When a UWP app or the private range is configured incorrectly, it affects how the UWP app’s network traffic will be processed by WFP. -When a packet is processed by WFP, the characteristics of that packet must explicitly match all the conditions of a filter to either be permitted or dropped to its target address. Connectivity issues typically happen when the packet does not match any of the filter conditions, leading the packet to be dropped by a default block filter. The presence of the default block -filters ensures network isolation for UWP applications. Specifically, it guarantees a network drop for a packet that does not have the correct capabilities for the resource it is trying to reach. This ensures the application’s granular access to each resource type and preventing the application from escaping its environment. +When a packet is processed by WFP, the characteristics of that packet must explicitly match all the conditions of a filter to either be permitted or dropped to its target address. Connectivity issues typically happen when the packet doesn't match any of the filter conditions, leading the packet to be dropped by a default block filter. The presence of the default block filters ensures network isolation for UWP applications. Specifically, it guarantees a network drop for a packet that doesn't have the correct capabilities for the resource it's trying to reach. Such a packet drop ensures the application’s granular access to each resource type and preventing the application from escaping its environment. For more information on the filter arbitration algorithm and network isolation, see [Filter @@ -53,13 +52,13 @@ traces collected on previous releases of Windows. If you need to establish a TCP/IP connection between two processes on the same host where one of them is a UWP app, you must enable loopback. -To enable loopback for client outbound connections, run the following at a command prompt: +To enable loopback for client outbound connections, run the following command at a command prompt: ```console CheckNetIsolation.exe LoopbackExempt -a -n= ``` -To enable loopback for server inbound connections, run the following at a +To enable loopback for server inbound connections, run the following command at a command prompt: ```console CheckNetIsolation.exe LoopbackExempt -is -n= @@ -77,9 +76,9 @@ Also, see [How to enable loopback and troubleshoot network isolation (Windows Ru ## Debugging Live Drops -If the issue happened recently, but you find you are not able to reproduce the issue, go to Debugging Past Drops for the appropriate trace commands. +If the issue happened recently, but you find you aren't able to reproduce the issue, go to Debugging Past Drops for the appropriate trace commands. -If you can consistently reproduce the issue, then you can run the following in an admin command prompt to gather a fresh trace: +If you can consistently reproduce the issue, then you can run the following command in an admin command prompt to gather a fresh trace: ```console Netsh wfp capture start keywords=19 @@ -89,7 +88,7 @@ Netsh wfp capture stop These commands generate a wfpdiag.cab. Inside the .cab exists a wfpdiag.xml, which contains any allow or drop netEvents and filters that existed during that repro. Without “keywords=19”, the trace will only collect drop netEvents. -Inside the wfpdiag.xml, search for netEvents which have +Inside the wfpdiag.xml, search for netEvents that have FWPM_NET_EVENT_TYPE_CLASSIFY_DROP as the netEvent type. To find the relevant drop events, search for the drop events with matching destination IP address, package SID, or application ID name. The characters in the application ID name will be separated by periods: @@ -110,11 +109,11 @@ The netEvent will have more information about the packet that was dropped includ In this example, the UWP app successfully connects to bing.com [2620:1ec:c11::200]. -A packet from a UWP app needs the correct networking capability token for the resource it is trying to reach. +A packet from a UWP app needs the correct networking capability token for the resource it's trying to reach. In this scenario, the app could successfully send a packet to the Internet target because it had an Internet capability token. -The following shows the allow netEvent of the app connecting to the target IP. The netEvent contains information about the packet including its local address, +The following code shows the allow netEvent of the app connecting to the target IP. The netEvent contains information about the packet including its local address, remote address, capabilities, etc. **Classify Allow netEvent, Wfpdiag-Case-1.xml** @@ -285,7 +284,7 @@ allowed by Filter #125918, from the InternetClient Default Rule. ``` -This is the condition for checking capabilities in this filter. +This condition enables checking capabilities in this filter. The important part of this condition is **S-1-15-3-1**, which is the capability SID for **INTERNET_CLIENT** privileges. @@ -298,7 +297,7 @@ capabilities from netEvent, Wfpdiag-Case-1.xml. FWP_CAPABILITIES_FLAG_PRIVATE_NETWORK ``` -This shows the packet came from an app with an Internet client token (**FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**) which matches the capability SID in the +These capabilities show the packet came from an app with an Internet client token (**FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**) which matches the capability SID in the filter. All the other conditions are also met for the filter, so the packet is allowed. @@ -306,12 +305,12 @@ Something to note is that the only capability token required for the packet to reach bing.com was the Internet client token, even though this example showed the packet having all capabilities. -## Case 2: UWP APP cannot reach Internet target address and has no capabilities +## Case 2: UWP APP can't reach Internet target address and has no capabilities In this example, the UWP app is unable to connect to bing.com [2620:1ec:c11::200]. -The following is a drop netEvent that was captured in the trace. +The following example is that of a drop netEvent that was captured in the trace. **Classify Drop netEvent, Wfpdiag-Case-2.xml** ```xml @@ -384,7 +383,7 @@ The following is a drop netEvent that was captured in the trace. ``` The first thing that you should check in the **netEvent** is the capabilities field. In this example, the capabilities field is empty, indicating that the -UWP app was not configured with any capability tokens to allow it to connect to +UWP app wasn't configured with any capability tokens to allow it to connect to a network. **Internal Fields from netEvent, Wfpdiag-Case-2.xml** @@ -478,11 +477,11 @@ the same sublayer. If the packet had the correct capability token, **FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**, it would have matched a condition for a -non-default block filter and would have been permitted to reach bing.com. +non-default block filter, and would have been permitted to reach bing.com. Without the correct capability tokens, the packet will be explicitly dropped by a default block outbound filter. -## Case 3: UWP app cannot reach Internet target address without Internet Client capability +## Case 3: UWP app can't reach Internet target address without Internet Client capability In this example, the app is unable to connect to bing.com [2620:1ec:c11::200]. @@ -562,10 +561,10 @@ only has a private network token. Therefore, the packet will be dropped. ``` -## Case 4: UWP app cannot reach Intranet target address without Private Network capability +## Case 4: UWP app can't reach Intranet target address without Private Network capability In this example, the UWP app is unable to reach the Intranet target address, -10.50.50.50, because it does not have a Private Network capability. +10.50.50.50, because it doesn't have a Private Network capability. **Classify Drop netEvent, Wfpdiag-Case-4.xml** ```xml @@ -639,7 +638,7 @@ In this example, the UWP app is unable to reach the Intranet target address, ``` -## Case 5: UWP app cannot reach “Intranet” target address with Private Network capability +## Case 5: UWP app can't reach “Intranet” target address with Private Network capability In this example, the UWP app is unable to reach the Intranet target address, 10.1.1.1, even though it has a Private Network capability token. @@ -764,7 +763,7 @@ If the target was in the private range, then it should have been allowed by a PrivateNetwork Outbound Default Rule filter. The following PrivateNetwork Outbound Default Rule filters have conditions for matching Intranet IP addresses. Since the expected Intranet target address, -10.1.1.1, is not included in these filters it becomes clear that the address is not in the private range. Check the policies that configure the private range +10.1.1.1, isn't included in these filters it becomes clear that the address isn't in the private range. Check the policies that configure the private range on the device (MDM, Group Policy, etc.) and make sure it includes the private target address you wanted to reach. **PrivateNetwork Outbound Default Rule Filters, Wfpdiag-Case-5.xml** @@ -1003,13 +1002,13 @@ on the device (MDM, Group Policy, etc.) and make sure it includes the private ta ``` ## Debugging Past Drops -If you are debugging a network drop from the past or from a remote machine, you +If you're debugging a network drop from the past or from a remote machine, you may have traces already collected from Feedback Hub, such as nettrace.etl and wfpstate.xml. Once nettrace.etl is converted, nettrace.txt will have the netEvents of the reproduced event, and wfpstate.xml will contain the filters that were present on the machine at the time. -If you do not have a live repro or traces already collected, you can still +If you don't have a live repro or traces already collected, you can still collect traces after the UWP network connectivity issue has happened by running these commands in an admin command prompt @@ -1023,27 +1022,26 @@ these commands in an admin command prompt net events. **Netsh wfp show state** creates wfpstate.xml, which contains the current filters present on the machine. -Unfortunately, collecting traces after the UWP network connectivity issue is not -always reliable. +Unfortunately, collecting traces after the UWP network connectivity issue isn't always reliable. NetEvents on the device are stored in a buffer. Once that buffer has reached maximum capacity, the buffer will overwrite older net events. Due to the buffer -overwrite, it is possible that the collected netevents.xml will not contain the +overwrite, it's possible that the collected netevents.xml won't contain the net event associated with the UWP network connectivity issue. It could have been ov overwritten. Additionally, filters on the device can get deleted and re-added with different filterIds due to miscellaneous events on the device. Because of -this, a **filterId** from **netsh wfp show netevents** may not necessarily match any +these implications, a **filterId** from **netsh wfp show netevents** may not necessarily match any filter in **netsh wfp show state** because that **filterId** may be outdated. If you can reproduce the UWP network connectivity issue consistently, we recommend using the commands from Debugging Live Drops instead. Additionally, you can still follow the examples from Debugging Live Drops -section using the trace commands in this section, even if you do not have a live +section using the trace commands in this section, even if you don't have a live repro. The **netEvents** and filters are stored in one file in Debugging Live Drops as opposed to two separate files in the following Debugging Past Drops examples. -## Case 7: Debugging Past Drop - UWP app cannot reach Internet target address and has no capabilities +## Case 7: Debugging Past Drop - UWP app can't reach Internet target address and has no capabilities In this example, the UWP app is unable to connect to bing.com. @@ -1118,12 +1116,12 @@ Classify Drop Net Event, NetEvents-Case-7.xml ``` -The Internal fields lists no active capabilities, and the packet is dropped at +The Internal fields list no active capabilities, and the packet is dropped at filter 206064. -This is a default block rule filter, meaning the packet passed through every -filter that could have allowed it, but because conditions didn’t match for any -those filters, the packet fell to the filter which blocks any packet that the +This filter is a default block rule filter, meaning the packet passed through every +filter that could have allowed it, but because conditions didn’t match for any of +those filters, the packet fell to the filter that blocks any packet that the Security Descriptor doesn’t match. **Block Outbound Default Rule Filter \#206064, FilterState-Case-7.xml** diff --git a/windows/security/threat-protection/windows-firewall/verify-that-network-traffic-is-authenticated.md b/windows/security/threat-protection/windows-firewall/verify-that-network-traffic-is-authenticated.md index 0c11ed522b..3f49bc068c 100644 --- a/windows/security/threat-protection/windows-firewall/verify-that-network-traffic-is-authenticated.md +++ b/windows/security/threat-protection/windows-firewall/verify-that-network-traffic-is-authenticated.md @@ -20,13 +20,13 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -After you have configured your domain isolation rule to request, rather than require, authentication, you must confirm that the network traffic sent by the devices on the network is being protected by IPsec authentication as expected. If you switch your rules to require authentication before all of the devices have received and applied the correct GPOs, or if there are any errors in your rules, then communications on the network can fail. By first setting the rules to request authentication, any network connections that fail authentication can continue in clear text while you diagnose and troubleshoot. +After you've configured your domain isolation rule to request, rather than require, authentication, you must confirm that the network traffic sent by the devices on the network is being protected by IPsec authentication as expected. If you switch your rules to require authentication before all of the devices have received and applied the correct GPOs, or if there are any errors in your rules, then communications on the network can fail. By first setting the rules to request authentication, any network connections that fail authentication can continue in clear text while you diagnose and troubleshoot. -In these procedures, you confirm that the rules you deployed are working correctly. Your next steps depend on which zone you are working on: +In these procedures, you confirm that the rules you deployed are working correctly. Your next steps depend on which zone you're working on: -- **Main domain isolation zone.** Before you convert your main domain isolation IPsec rule from request mode to require mode, you must make sure that the network traffic is protected according to your design. By configuring your rules to request and not require authentication at the beginning of operations, devices on the network can continue to communicate even when the main mode authentication or quick mode integrity and encryption rules are not working correctly. For example, if your encryption zone contains rules that require a certain encryption algorithm, but that algorithm is not included in a security method combination on the clients, then those clients cannot successfully negotiate a quick mode security association, and the server refuses to accept network traffic from the client. By first using request mode only, you have the opportunity to deploy your rules and then examine the network traffic to see if they are working as expected without risking a loss of communications. +- **Main domain isolation zone.** Before you convert your main domain isolation IPsec rule from request mode to require mode, you must make sure that the network traffic is protected according to your design. By configuring your rules to request and not require authentication at the beginning of operations, devices on the network can continue to communicate even when the main mode authentication or quick mode integrity and encryption rules aren't working correctly. For example, if your encryption zone contains rules that require a certain encryption algorithm, but that algorithm isn't included in a security method combination on the clients, then those clients can't successfully negotiate a quick mode security association, and the server refuses to accept network traffic from the client. By first using request mode only, you have the opportunity to deploy your rules and then examine the network traffic to see if they're working as expected without risking a loss of communications. -- **Boundary zone.** Confirming correct operation of IPsec is the last step if you are working on the boundary zone GPO. You do not convert the GPO to require mode at any time. +- **Boundary zone.** Confirming correct operation of IPsec is the last step if you're working on the boundary zone GPO. You don't convert the GPO to require mode at any time. - **Encryption zone.** Similar to the main isolation zone, after you confirm that the network traffic to zone members is properly authenticated and encrypted, you must convert your zone rules from request mode to require mode. @@ -52,7 +52,7 @@ console. 2. In the **Available columns** list, select **Rule Source**, and then click **Add**. - 3. Use the **Move up** and **Move down** buttons to rearrange the order. Click **OK** when you are finished. + 3. Use the **Move up** and **Move down** buttons to rearrange the order. Click **OK** when you're finished. It can take a few moments for the list to be refreshed with the newly added column. @@ -63,7 +63,7 @@ console. The current list of main mode associations that have been negotiated with other devices appears in the details column. -6. Examine the list of main mode security associations for sessions between the local device and the remote device. Make sure that the **1st Authentication Method** and **2nd Authentication Method** columns contain expected values. If your rules specify only a first authentication method, then the **2nd Authentication Method** column displays **No authentication**. If you double-click the row, then the **Properties** dialog box appears with additional details about the security association. +6. Examine the list of main mode security associations for sessions between the local device and the remote device. Make sure that the **1st Authentication Method** and **2nd Authentication Method** columns contain expected values. If your rules specify only a first authentication method, then the **2nd Authentication Method** column displays **No authentication**. If you double-click the row, then the **Properties** dialog box appears with more details about the security association. 7. In the navigation pane, click **Quick mode**. diff --git a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-administration-with-windows-powershell.md b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-administration-with-windows-powershell.md index c89e65cba2..7173220848 100644 --- a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-administration-with-windows-powershell.md +++ b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-administration-with-windows-powershell.md @@ -20,7 +20,7 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -The Windows Defender Firewall with Advanced Security Administration with Windows PowerShell Guide provides essential scriptlets for automating Windows Defender Firewall management. It is designed for IT pros, system administrators, IT managers, and others who use and need to automate Windows Defender Firewall management in Windows. +The Windows Defender Firewall with Advanced Security Administration with Windows PowerShell Guide provides essential scriptlets for automating Windows Defender Firewall management. It's designed for IT pros, system administrators, IT managers, and others who use and need to automate Windows Defender Firewall management in Windows. You can use Windows PowerShell to manage your firewall and IPsec deployments. This object-oriented scripting environment will make it easier for you to manage policies and monitor network conditions than was possible in netsh. Windows PowerShell allows network settings to be self-discoverable through the syntax and parameters in each of the cmdlets. This guide demonstrates how common tasks were performed in netsh and how you can use Windows PowerShell to accomplish them. @@ -32,11 +32,11 @@ Windows PowerShell and netsh command references are at the following locations. ## Scope -This guide does not teach you the fundamentals of Windows Defender Firewall, which can be found in [Windows Defender Firewall](windows-firewall-with-advanced-security.md). It does not teach the fundamentals of Windows PowerShell, and it assumes that you are familiar with the Windows PowerShell language and the basic concepts of Windows PowerShell. For more info about Windows PowerShell concepts and usage, see the reference topics in the [Additional resources](#additional-resources) section of this guide. +This guide doesn't teach you the fundamentals of Windows Defender Firewall, which can be found in [Windows Defender Firewall](windows-firewall-with-advanced-security.md). It doesn't teach the fundamentals of Windows PowerShell, and it assumes that you're familiar with the Windows PowerShell language and the basic concepts of Windows PowerShell. For more info about Windows PowerShell concepts and usage, see the reference topics in the [Additional resources](#other-resources) section of this guide. ## Audience and user requirements -This guide is intended for IT pros, system administrators, and IT managers, and it assumes that you are familiar with Windows Defender Firewall, the Windows PowerShell language, and the basic concepts of Windows PowerShell. +This guide is intended for IT pros, system administrators, and IT managers, and it assumes that you're familiar with Windows Defender Firewall, the Windows PowerShell language, and the basic concepts of Windows PowerShell. ## In this topic @@ -47,7 +47,7 @@ This guide is intended for IT pros, system administrators, and IT managers, and | [Manage Remotely](#manage-remotely) | Remote management by using `-CimSession`| | [Deploy basic IPsec rule settings](#deploy-basic-ipsec-rule-settings) | IPsec rules and associated parameters| | [Deploy secure firewall rules with IPsec](#deploy-secure-firewall-rules-with-ipsec) | Domain and server isolation| -| [Additional resources](#additional-resources) | More information about Windows PowerShell| +| [Other resources](#other-resources) | More information about Windows PowerShell| ## Set profile global defaults @@ -55,7 +55,7 @@ Global defaults set the device behavior in a per-profile basis. Windows Defender ### Enable Windows Defender Firewall with Advanced Security -Windows Defender Firewall drops traffic that does not correspond to allowed unsolicited traffic, or traffic that is sent in response to a request by the device. If you find that the rules you create are not being enforced, you may need to enable Windows Defender Firewall. Here is how to do this on a local domain device: +Windows Defender Firewall drops traffic that doesn't correspond to allowed unsolicited traffic, or traffic that is sent in response to a request by the device. If you find that the rules you create aren't being enforced, you may need to enable Windows Defender Firewall. Here's how to enable Windows Defender Firewall on a local domain device: **Netsh** @@ -92,7 +92,7 @@ Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow ### Disable Windows Defender Firewall with Advanced Security -Microsoft recommends that you do not disable Windows Defender Firewall because you lose other benefits provided by the service, such as the ability to use Internet Protocol security (IPsec) connection security rules, network protection from attacks that employ network fingerprinting, [Windows Service Hardening](https://go.microsoft.com/fwlink/?linkid=104976), and [boot time filters](https://blogs.technet.microsoft.com/networking/2009/03/24/stopping-the-windows-authenticating-firewall-service-and-the-boot-time-policy/). +Microsoft recommends that you don't disable Windows Defender Firewall because you lose other benefits provided by the service, such as the ability to use Internet Protocol security (IPsec) connection security rules, network protection from attacks that employ network fingerprinting, [Windows Service Hardening](https://go.microsoft.com/fwlink/?linkid=104976), and [boot time filters](https://blogs.technet.microsoft.com/networking/2009/03/24/stopping-the-windows-authenticating-firewall-service-and-the-boot-time-policy/). Disabling Windows Defender Firewall with Advanced Security can also cause problems, including: @@ -103,15 +103,15 @@ Disabling Windows Defender Firewall with Advanced Security can also cause proble Microsoft recommends disabling Windows Defender Firewall only when installing a third-party firewall, and resetting Windows Defender Firewall back to defaults when the third-party software is disabled or removed. -If disabling Windows Defender Firewall is required, do not disable it by stopping the Windows Defender Firewall service (in the **Services** snap-in, the display name is Windows Defender Firewall and the service name is MpsSvc). -Stopping the Windows Defender Firewall service is not supported by Microsoft. +If disabling Windows Defender Firewall is required, don't disable it by stopping the Windows Defender Firewall service (in the **Services** snap-in, the display name is Windows Defender Firewall and the service name is MpsSvc). +Stopping the Windows Defender Firewall service isn't supported by Microsoft. Non-Microsoft firewall software can programmatically disable only the parts of Windows Defender Firewall that need to be disabled for compatibility. -You should not disable the firewall yourself for this purpose. +You shouldn't disable the firewall yourself for this purpose. The proper method to disable the Windows Defender Firewall is to disable the Windows Defender Firewall Profiles and leave the service running. -Use the following procedure to turn the firewall off, or disable the Group Policy setting **Computer Configuration|Administrative Templates|Network|Network Connections|Windows Defender Firewall|Domain Prolfile|Windows Defender Firewall:Protect all network connections**. +Use the following procedure to turn off the firewall, or disable the Group Policy setting **Computer Configuration|Administrative Templates|Network|Network Connections|Windows Defender Firewall|Domain Prolfile|Windows Defender Firewall:Protect all network connections**. For more information, see [Windows Defender Firewall with Advanced Security deployment guide](windows-firewall-with-advanced-security-deployment-guide.md). The following example disables Windows Defender Firewall for all profiles. @@ -128,7 +128,7 @@ This section provides scriptlet examples for creating, modifying, and deleting f Adding a firewall rule in Windows PowerShell looks a lot like it did in Netsh, but the parameters and values are specified differently. -Here is an example of how to allow the Telnet application to listen on the network. This firewall rule is scoped to the local subnet by using a keyword instead of an IP address. Just like in Netsh, the rule is created on the local device, and it becomes effective immediately. +Here's an example of how to allow the Telnet application to listen on the network. This firewall rule is scoped to the local subnet by using a keyword instead of an IP address. Just like in Netsh, the rule is created on the local device, and it becomes effective immediately. **Netsh** @@ -142,7 +142,7 @@ Windows PowerShell New-NetFirewallRule -DisplayName “Allow Inbound Telnet” -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow ``` -The following scriptlet shows how to add a basic firewall rule that blocks outbound traffic from a specific application and local port to a Group Policy Object (GPO) in Active Directory. In Windows PowerShell, the policy store is specified as a parameter within the **New-NetFirewall** cmdlet. In Netsh, you must first specify the GPO that the commands in a Netsh session should modify. The commands you enter are run against the contents of the GPO, and this remains in effect until the Netsh session is ended or until another set store command is executed. +The following scriptlet shows how to add a basic firewall rule that blocks outbound traffic from a specific application and local port to a Group Policy Object (GPO) in Active Directory. In Windows PowerShell, the policy store is specified as a parameter within the **New-NetFirewall** cmdlet. In Netsh, you must first specify the GPO that the commands in a Netsh session should modify. The commands you enter are run against the contents of the GPO, and the execution remains in effect until the Netsh session is ended or until another set store command is executed. Here, **domain.contoso.com** is the name of your Active Directory Domain Services (AD DS), and **gpo\_name** is the name of the GPO that you want to modify. Quotation marks are required if there are any spaces in the GPO name. @@ -163,7 +163,7 @@ New-NetFirewallRule -DisplayName “Block Outbound Telnet” -Direction Outbound To reduce the burden on busy domain controllers, Windows PowerShell allows you to load a GPO to your local session, make all your changes in that session, and then save it back at all once. -The following performs the same actions as the previous example (by adding a Telnet rule to a GPO), but we do so leveraging GPO caching in PowerShell. Changing the GPO by loading it onto your local session and using the *-GPOSession* parameter are not supported in Netsh +The following command performs the same actions as the previous example (by adding a Telnet rule to a GPO), but we do so by applying GPO caching in PowerShell. Changing the GPO by loading it onto your local session and using the *-GPOSession* parameter aren't supported in Netsh Windows PowerShell @@ -173,11 +173,11 @@ New-NetFirewallRule -DisplayName “Block Outbound Telnet” -Direction Outbound Save-NetGPO –GPOSession $gpo ``` -Note that this does not batch your individual changes, it loads and saves the entire GPO at once. So if any other changes are made by other administrators, or in a different Windows PowerShell window, saving the GPO overwrites those changes. +This command doesn't batch your individual changes, it loads and saves the entire GPO at once. So if any other changes are made by other administrators, or in a different Windows PowerShell window, saving the GPO overwrites those changes. ### Modify an existing firewall rule -When a rule is created, Netsh and Windows PowerShell allow you to change rule properties and influence, but the rule maintains its unique identifier (in Windows PowerShell this is specified with the *-Name* parameter). +When a rule is created, Netsh and Windows PowerShell allow you to change rule properties and influence, but the rule maintains its unique identifier (in Windows PowerShell, this identifier is specified with the *-Name* parameter). For example, you could have a rule **Allow Web 80** that enables TCP port 80 for inbound unsolicited traffic. You can change the rule to match a different remote IP address of a Web server whose traffic will be allowed by specifying the human-readable, localized name of the rule. @@ -193,11 +193,11 @@ Windows PowerShell Set-NetFirewallRule –DisplayName “Allow Web 80” -RemoteAddress 192.168.0.2 ``` -Netsh requires you to provide the name of the rule for it to be changed and we do not have an alternate way of getting the firewall rule. In Windows PowerShell, you can query for the rule using its known properties. +Netsh requires you to provide the name of the rule for it to be changed and we don't have an alternate way of getting the firewall rule. In Windows PowerShell, you can query for the rule using its known properties. -When you run `Get-NetFirewallRule`, you may notice that common conditions like addresses and ports do not appear. These conditions are represented in separate objects called Filters. As shown before, you can set all the conditions in New-NetFirewallRule and Set-NetFirewallRule. If you want to query for firewall rules based on these fields (ports, addresses, security, interfaces, services), you will need to get the filter objects themselves. +When you run `Get-NetFirewallRule`, you may notice that common conditions like addresses and ports don't appear. These conditions are represented in separate objects called Filters. As shown before, you can set all the conditions in New-NetFirewallRule and Set-NetFirewallRule. If you want to query for firewall rules based on these fields (ports, addresses, security, interfaces, services), you'll need to get the filter objects themselves. -You can change the remote endpoint of the **Allow Web 80** rule (as done previously) using filter objects. Using Windows PowerShell you query by port using the port filter, then assuming additional rules exist affecting the local port, you build with further queries until your desired rule is retrieved. +You can change the remote endpoint of the **Allow Web 80** rule (as done previously) using filter objects. Using Windows PowerShell, you query by port using the port filter, then assuming other rules exist affecting the local port, you build with further queries until your desired rule is retrieved. In the following example, we assume the query returns a single firewall rule, which is then piped to the `Set-NetFirewallRule` cmdlet utilizing Windows PowerShell’s ability to pipeline inputs. @@ -217,7 +217,7 @@ Get-NetFirewallApplicationFilter -Program "*svchost*" | Get-NetFirewallRule Multiple rules in a group can be simultaneously modified when the associated group name is specified in a Set command. You can add firewall rules to specified management groups in order to manage multiple rules that share the same influences. -In the following example, we add both inbound and outbound Telnet firewall rules to the group **Telnet Management**. In Windows PowerShell, group membership is specified when the rules are first created so we re-create the previous example rules. Adding rules to a custom rule group is not possible in Netsh. +In the following example, we add both inbound and outbound Telnet firewall rules to the group **Telnet Management**. In Windows PowerShell, group membership is specified when the rules are first created so we re-create the previous example rules. Adding rules to a custom rule group isn't possible in Netsh. Windows PowerShell @@ -226,7 +226,7 @@ New-NetFirewallRule -DisplayName “Allow Inbound Telnet” -Direction Inbound - New-NetFirewallRule -DisplayName “Block Outbound Telnet” -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow –Group “Telnet Management” ``` -If the group is not specified at rule creation time, the rule can be added to the rule group using dot notation in Windows PowerShell. You cannot specify the group using `Set-NetFirewallRule` since the command allows querying by rule group. +If the group isn't specified at rule creation time, the rule can be added to the rule group using dot notation in Windows PowerShell. You can't specify the group using `Set-NetFirewallRule` since the command allows querying by rule group. Windows PowerShell @@ -236,7 +236,7 @@ $rule.Group = “Telnet Management” $rule | Set-NetFirewallRule ``` -Using the `Set` command, if the rule group name is specified, the group membership is not modified but rather all rules of the group receive the same modifications indicated by the given parameters. +With the help of the `Set` command, if the rule group name is specified, the group membership isn't modified but rather all rules of the group receive the same modifications indicated by the given parameters. The following scriptlet enables all rules in a predefined group containing remote management influencing firewall rules. @@ -252,7 +252,7 @@ Windows PowerShell Set-NetFirewallRule -DisplayGroup “Windows Defender Firewall Remote Management” –Enabled True ``` -There is also a separate `Enable-NetFirewallRule` cmdlet for enabling rules by group or by other properties of the rule. +There's also a separate `Enable-NetFirewallRule` cmdlet for enabling rules by group or by other properties of the rule. Windows PowerShell @@ -262,7 +262,7 @@ Enable-NetFirewallRule -DisplayGroup “Windows Defender Firewall Remote Managem ### Delete a firewall rule -Rule objects can be disabled so that they are no longer active. In Windows PowerShell, the **Disable-NetFirewallRule** cmdlet will leave the rule on the system, but put it in a disabled state so the rule no longer is applied and impacts traffic. A disabled firewall rule can be re-enabled by **Enable-NetFirewallRule**. This is different from the **Remove-NetFirewallRule**, which permanently removes the rule definition from the device. +Rule objects can be disabled so that they're no longer active. In Windows PowerShell, the **Disable-NetFirewallRule** cmdlet will leave the rule on the system, but put it in a disabled state so the rule no longer is applied and impacts traffic. A disabled firewall rule can be re-enabled by **Enable-NetFirewallRule**. This cmdlet is different from the **Remove-NetFirewallRule**, which permanently removes the rule definition from the device. The following cmdlet deletes the specified existing firewall rule from the local policy store. @@ -286,7 +286,7 @@ Windows PowerShell Remove-NetFirewallRule –Action Block ``` -Note that it may be safer to query the rules with the **Get** command and save it in a variable, observe the rules to be affected, then pipe them to the **Remove** command, just as we did for the **Set** commands. The following example shows how you can view all the blocking firewall rules, and then delete the first four rules. +It may be safer to query the rules with the **Get** command and save it in a variable, observe the rules to be affected, then pipe them to the **Remove** command, just as we did for the **Set** commands. The following example shows how you can view all the blocking firewall rules, and then delete the first four rules. Windows PowerShell @@ -308,7 +308,7 @@ Windows PowerShell Get-NetFirewallRule –CimSession RemoteDevice ``` -We can perform any modifications or view rules on remote devices by simply using the *–CimSession* parameter. Here we remove a specific firewall rule from a remote device. +We can perform any modifications or view rules on remote devices by using the *–CimSession* parameter. Here we remove a specific firewall rule from a remote device. Windows PowerShell @@ -373,7 +373,7 @@ New-NetIPsecRule -DisplayName “Require Inbound Authentication” -InboundSecur A corporate network may need to secure communications with another agency. But, you discover the agency runs non-Windows operating systems and requires the use of the Internet Key Exchange Version 2 (IKEv2) standard. -You can leverage IKEv2 capabilities in Windows Server 2012 by simply specifying IKEv2 as the key module in an IPsec rule. This can only be done using computer certificate authentication and cannot be used with phase 2 authentication. +You can apply IKEv2 capabilities in Windows Server 2012 by specifying IKEv2 as the key module in an IPsec rule. This capability specification can only be done using computer certificate authentication and can't be used with phase-2 authentication. Windows PowerShell @@ -387,9 +387,9 @@ For more info about IKEv2, including scenarios, see [Securing End-to-End IPsec C Firewall and IPsec rules with the same rule properties can be duplicated to simplify the task of re-creating them within different policy stores. -To copy the previously created rule from one policy store to another, the associated objects must be also be copied separately. Note that there is no need to copy associated firewall filters. You can query rules to be copied in the same way as other cmdlets. +To copy the previously created rule from one policy store to another, the associated objects must also be copied separately. There's no need to copy associated firewall filters. You can query rules to be copied in the same way as other cmdlets. -Copying individual rules is a task that is not possible through the Netsh interface. Here is how you can accomplish it with Windows PowerShell. +Copying individual rules is a task that isn't possible through the Netsh interface. Here's how you can accomplish it with Windows PowerShell. Windows PowerShell @@ -401,7 +401,7 @@ $Rule | Copy-NetPhase1AuthSet –NewPolicyStore domain.costoso.com\new_gpo_name ### Handling Windows PowerShell errors -To handle errors in your Windows PowerShell scripts, you can use the *–ErrorAction* parameter. This is especially useful with the **Remove** cmdlets. If you want to remove a particular rule, you will notice that it fails if the rule is not found. When removing rules, if the rule isn’t already there, it is generally acceptable to ignore that error. In this case, you can do the following to suppress any “rule not found” errors during the remove operation. +To handle errors in your Windows PowerShell scripts, you can use the *–ErrorAction* parameter. This parameter is especially useful with the **Remove** cmdlets. If you want to remove a particular rule, you'll notice that it fails if the rule isn't found. When rules are being removed, if the rule isn’t already there, it's acceptable to ignore that error. In this case, you can do the following to suppress any “rule not found” errors during the remove operation. Windows PowerShell @@ -409,7 +409,7 @@ Windows PowerShell Remove-NetFirewallRule –DisplayName “Contoso Messenger 98” –ErrorAction SilentlyContinue ``` -Note that the use of wildcards can also suppress errors, but they could potentially match rules that you did not intend to remove. This can be a useful shortcut, but should only be used if you know there aren’t any extra rules that will be accidentally deleted. So the following cmdlet will also remove the rule, suppressing any “not found” errors. +The use of wildcards can also suppress errors, but they could potentially match rules that you didn't intend to remove. These wildcards can be a useful shortcut, but should only be used if you know there aren’t any extra rules that will be accidentally deleted. So the following cmdlet will also remove the rule, suppressing any “not found” errors. Windows PowerShell @@ -445,7 +445,7 @@ Remove-NetFirewallRule –DisplayName “Contoso Messenger 98*” –Verbose The following Windows PowerShell commands are useful in the update cycle of a deployment phase. -To allow you to view all the IPsec rules in a particular store, you can use the following commands. In Netsh, this command does not show rules where profile=domain,public or profile=domain,private. It only shows rules that have the single entry domain that is included in the rule. The following command examples will show the IPsec rules in all profiles. +To allow you to view all the IPsec rules in a particular store, you can use the following commands. In Netsh, this command doesn't show rules where profile=domain,public or profile=domain,private. It only shows rules that have the single entry domain that is included in the rule. The following command examples will show the IPsec rules in all profiles. **Netsh** @@ -477,7 +477,7 @@ Get-NetIPsecMainModeSA ### Find the source GPO of a rule -To view the properties of a particular rule or group of rules, you query for the rule. When a query returns fields that are specified as **NotConfigured**, you can to determine which policy store a rule originates from. +To view the properties of a particular rule or group of rules, you query for the rule. When a query returns fields that are specified as **NotConfigured**, you can determine which policy store a rule originates from. For objects that come from a GPO (the *–PolicyStoreSourceType* parameter is specified as **GroupPolicy** in the **Show** command), if *–TracePolicyStore* is passed, the name of the GPO is found and returned in the **PolicyStoreSource** field. @@ -487,13 +487,13 @@ Windows PowerShell Get-NetIPsecRule –DisplayName “Require Inbound Authentication” –TracePolicyStore ``` -It is important to note that the revealed sources do not contain a domain name. +It's important to note that the revealed sources don't contain a domain name. ### Deploy a basic domain isolation policy IPsec can be used to isolate domain members from non-domain members. Domain isolation uses IPsec authentication to require that the domain-joined devices positively establish the identities of the communicating devices to improve security of an organization. One or more features of IPsec can be used to secure traffic with an IPsec rule object. -To implement domain isolation on your network, the devices in the domain receive IPsec rules that block unsolicited inbound network traffic that is not protected by IPsec. Here we create an IPsec rule that requires authentication by domain members. Through this, you can isolate domain-joined devices from devices that are not joined to a domain. In the following examples, Kerberos authentication is required for inbound traffic and requested for outbound traffic. +To implement domain isolation on your network, the devices in the domain receive IPsec rules that block unsolicited inbound network traffic that isn't protected by IPsec. Here we create an IPsec rule that requires authentication by domain members. Through this authentication, you can isolate domain-joined devices from devices that aren't joined to a domain. In the following examples, Kerberos authentication is required for inbound traffic and requested for outbound traffic. **Netsh** @@ -512,7 +512,7 @@ New-NetIPsecRule –DisplayName “Basic Domain Isolation Policy” –Profile D ### Configure IPsec tunnel mode -The following command creates an IPsec tunnel that routes traffic from a private network (192.168.0.0/16) through an interface on the local device (1.1.1.1) attached to a public network to a second device through its public interface (2.2.2.2) to another private network (192.157.0.0/16). All traffic through the tunnel is checked for integrity by using ESP/SHA1, and it is encrypted by using ESP/DES3. +The following command creates an IPsec tunnel that routes traffic from a private network (192.168.0.0/16) through an interface on the local device (1.1.1.1) attached to a public network to a second device through its public interface (2.2.2.2) to another private network (192.157.0.0/16). All traffic through the tunnel is checked for integrity by using ESP/SHA1, and it's encrypted by using ESP/DES3. **Netsh** @@ -534,7 +534,7 @@ In situations where only secure traffic can be allowed through the Windows Defen ### Create a secure firewall rule (allow if secure) -Configuring firewalls rule to allow connections if they are secure requires the corresponding traffic to be authenticated and integrity protected, and then optionally encrypted by IPsec. +Configuring firewalls rule to allow connections if they're secure requires the corresponding traffic to be authenticated and integrity protected, and then optionally encrypted by IPsec. The following example creates a firewall rule that requires traffic to be authenticated. The command permits inbound Telnet network traffic only if the connection from the remote device is authenticated by using a separate IPsec rule. @@ -575,7 +575,7 @@ New-NetIPSecRule -DisplayName “Authenticate Both Computer and User” -Inbound To improve the security of the devices in an organization, you can deploy domain isolation in which domain-members are restricted. They require authentication when communicating among each other and reject non-authenticated inbound connections. To improve the security of servers with sensitive data, this data must be protected by allowing access only to a subset of devices within the enterprise domain. -IPsec can provide this additional layer of protection by isolating the server. In server isolation, sensitive data access is restricted to users and devices with legitimate business need, and the data is additionally encrypted to prevent eavesdropping. +IPsec can provide this extra layer of protection by isolating the server. In server isolation, sensitive data access is restricted to users and devices with legitimate business need, and the data is additionally encrypted to prevent eavesdropping. ### Create a firewall rule that requires group membership and encryption @@ -607,7 +607,7 @@ $secureMachineGroup = "D:(A;;CC;;;$SIDofSecureMachineGroup)" For more information about how to create security groups or how to determine the SDDL string, see [Working with SIDs](/previous-versions/windows/it-pro/windows-powershell-1.0/ff730940(v=technet.10)). -Telnet is an application that does not provide encryption. This application can send data, such as names and passwords, over the network. This data can be intercepted by malicious users. If an administrator would like to allow the use of Telnet, but protect the traffic, a firewall rule that requires IPsec encryption can be created. This is necessary so that the administrator can be certain that when this application is used, all of the traffic sent or received by this port is encrypted. If IPsec fails to authorize the connection, no traffic is allowed from this application. +Telnet is an application that doesn't provide encryption. This application can send data, such as names and passwords, over the network. This data can be intercepted by malicious users. If an administrator would like to allow the use of Telnet, but protect the traffic, a firewall rule that requires IPsec encryption can be created. This firewall rule is necessary so that the administrator can be certain that when this application is used, all of the traffic sent or received by this port is encrypted. If IPsec fails to authorize the connection, no traffic is allowed from this application. In this example, we allow only authenticated and encrypted inbound Telnet traffic from a specified secure user group through the creation of the following firewall rule. @@ -638,7 +638,7 @@ Set-NetFirewallSetting -RemoteMachineTransportAuthorizationList $secureMachineGr ### Create firewall rules that allow IPsec-protected network traffic (authenticated bypass) -Authenticated bypass allows traffic from a specified trusted device or user to override firewall block rules. This is helpful when an administrator wants to use scanning servers to monitor and update devices without the need to use port-level exceptions. For more information, see [How to enable authenticated firewall bypass](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)). +Authenticated bypass allows traffic from a specified trusted device or user to override firewall block rules. This override is helpful when an administrator wants to use scanning servers to monitor and update devices without the need to use port-level exceptions. For more information, see [How to enable authenticated firewall bypass](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)). In this example, we assume that a blocking firewall rule exists. This example permits any network traffic on any port from any IP address to override the block rule, if the traffic is authenticated as originating from a device or user account that is a member of the specified device or user security group. @@ -655,7 +655,7 @@ Windows PowerShell New-NetFirewallRule –DisplayName “Inbound Secure Bypass Rule" –Direction Inbound –Authentication Required –OverrideBlockRules $true -RemoteMachine $secureMachineGroup –RemoteUser $secureUserGroup –PolicyStore domain.contoso.com\domain_isolation ``` -## Additional resources +## Other resources For more information about Windows PowerShell concepts, see the following topics. diff --git a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide.md b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide.md index fbb11692e8..f0ec1fb9dc 100644 --- a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide.md +++ b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide.md @@ -30,7 +30,7 @@ This guide is intended for use by system administrators and system engineers. It Begin by reviewing the information in [Planning to Deploy Windows Defender Firewall with Advanced Security](planning-to-deploy-windows-firewall-with-advanced-security.md). -If you have not yet selected a design, we recommend that you wait to follow the instructions in this guide until after you have reviewed the design options in the [Windows Defender Firewall with Advanced Security Design Guide](windows-firewall-with-advanced-security-design-guide.md) and selected the one most appropriate for your organization. +If you haven't yet selected a design, we recommend that you wait to follow the instructions in this guide until after you've reviewed the design options in the [Windows Defender Firewall with Advanced Security Design Guide](windows-firewall-with-advanced-security-design-guide.md) and selected the one most appropriate for your organization. After you select your design and gather the required information about the zones (isolation, boundary, and encryption), operating systems to support, and other details, you can then use this guide to deploy your Windows Defender Firewall with Advanced Security design in your production environment. This guide provides steps for deploying any of the following primary designs that are described in the Design Guide: @@ -46,11 +46,11 @@ Use the checklists in [Implementing Your Windows Defender Firewall with Advanced > [!CAUTION] > We recommend that you use the techniques documented in this guide only for GPOs that must be deployed to the majority of the devices in your organization, and only when the OU hierarchy in your Active Directory domain does not match the deployment needs of these GPOs. These characteristics are typical of GPOs for server and domain isolation scenarios, but are not typical of most other GPOs. When the OU hierarchy supports it, deploy a GPO by linking it to the lowest level OU that contains all of the accounts to which the GPO applies. -In a large enterprise environment with hundreds or thousands of GPOs, using this technique with too many GPOs can result in user or device accounts that are members of an excessive number of groups; this can result in network connectivity problems if network protocol limits are exceeded. +In a large enterprise environment with hundreds or thousands of GPOs, using this technique with too many GPOs can result in user or device accounts that are members of an excessive number of groups; this creation of accounts can result in network connectivity problems if network protocol limits are exceeded.   -## What this guide does not provide +## What this guide doesn't provide -This guide does not provide: +This guide doesn't provide: - Guidance for creating firewall rules for specific network applications. For this information, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md) in the Windows Defender Firewall with Advanced Security Design Guide. diff --git a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-design-guide.md b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-design-guide.md index 623503499e..791816f439 100644 --- a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-design-guide.md +++ b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-design-guide.md @@ -20,9 +20,9 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -Windows Defender Firewall with Advanced Security is a host firewall that helps secure the device in two ways. First, it can filter the network traffic permitted to enter the device from the network, and also control what network traffic the device is allowed to send to the network. Second, Windows Defender Firewall supports IPsec, which enables you to require authentication from any device that is attempting to communicate with your device. When authentication is required, devices that cannot authenticate cannot communicate with your device. By using IPsec, you can also require that specific network traffic be encrypted to prevent it from being read or intercepted while in transit between devices. +Windows Defender Firewall with Advanced Security is a host firewall that helps secure the device in two ways. First, it can filter the network traffic permitted to enter the device from the network, and also control what network traffic the device is allowed to send to the network. Second, Windows Defender Firewall supports IPsec, which enables you to require authentication from any device that is attempting to communicate with your device. When authentication is required, devices that can't authenticate can't communicate with your device. By using IPsec, you can also require that specific network traffic be encrypted to prevent it from being read or intercepted while in transit between devices. -The interface for Windows Defender Firewall is much more capable and flexible than the consumer-friendly interface found in the Windows Defender Firewall Control Panel. They both interact with the same underlying services, but provide different levels of control over those services. While the Windows Defender Firewall Control Panel meets the needs for protecting a single device in a home environment, it does not provide enough centralized management or security features to help secure more complex network traffic found in a typical business enterprise environment. +The interface for Windows Defender Firewall is much more capable and flexible than the consumer-friendly interface found in the Windows Defender Firewall Control Panel. They both interact with the same underlying services, but provide different levels of control over those services. While the Windows Defender Firewall Control Panel meets the needs for protecting a single device in a home environment, it doesn't provide enough centralized management or security features to help secure more complex network traffic found in a typical business enterprise environment. For more overview information, see [Windows Defender Firewall with Advanced Security](windows-firewall-with-advanced-security.md). @@ -32,25 +32,25 @@ This guide provides recommendations to help you to choose or create a design for This guide is intended for the IT professional who has been assigned the task of deploying firewall and IPsec technologies on an organization's network to help meet the organization's security goals. -Windows Defender Firewall should be part of a comprehensive security solution that implements a variety of security technologies, such as perimeter firewalls, intrusion detection systems, virtual private networking (VPN), IEEE 802.1X authentication for wireless and wired connections, and IPsec connection security rules. +Windows Defender Firewall should be part of a comprehensive security solution that implements various security technologies, such as perimeter firewalls, intrusion detection systems, virtual private networking (VPN), IEEE 802.1X authentication for wireless and wired connections, and IPsec connection security rules. To successfully use this guide, you need a good understanding of both the capabilities provided by Windows Defender Firewall, and how to deliver configuration settings to your managed devices by using Group Policy in Active Directory. -You can use the implementation goals to form one of these Windows Defender Firewall with Advanced Security designs, or a custom design that combines elements from those presented here: +You can use the implementation goals to form one of these Windows Defender Firewall with Advanced Security designs, or a custom design that combines elements from those goals presented here: - **Basic firewall policy design**. Restricts network traffic in and out of your devices to only that which is needed and authorized. -- **Domain isolation policy design**. Prevents devices that are domain members from receiving unsolicited network traffic from devices that are not domain members. Additional "zones" can be established to support the special requirements of some devices, such as: +- **Domain isolation policy design**. Prevents devices that are domain members from receiving unsolicited network traffic from devices that aren't domain members. More "zones" can be established to support the special requirements of some devices, such as: - A "boundary zone" for devices that must be able to receive requests from non-isolated devices. - An "encryption zone" for devices that store sensitive data that must be protected during network transmission. -- **Server isolation policy design**. Restricts access to a server to only a limited group of authorized users and devices. Commonly configured as a zone in a domain isolation design, but can also be configured as a stand-alone design, providing many of the benefits of domain isolation to a small set of devices. +- **Server isolation policy design**. Restricts access to a server to only a limited group of authorized users and devices. This server can be commonly configured as a zone in a domain isolation design, but can also be configured as a stand-alone design, providing many of the benefits of domain isolation to a small set of devices. -- **Certificate-based isolation policy design**. This design is a complement to either of the previous two designs, and supports any of their capabilities. It uses cryptographic certificates that are deployed to clients and servers for authentication, instead of the Kerberos V5 authentication used by default in Active Directory. This enables devices that are not part of an Active Directory domain, such as devices running operating systems other than Windows, to participate in your isolation solution. +- **Certificate-based isolation policy design**. This design is a complement to either of the previous two designs, and supports any of their capabilities. It uses cryptographic certificates that are deployed to clients and servers for authentication, instead of the Kerberos V5 authentication used by default in Active Directory. This design enables devices that aren't part of an Active Directory domain, such as devices running operating systems other than Windows, to participate in your isolation solution. -In addition to descriptions and example for each design, you will find guidelines for gathering required data about your environment. You can then use these guidelines to plan and design your Windows Defender Firewall with Advanced Security deployment. After you read this guide, and finish gathering, documenting, and mapping your organization's requirements, you have the information that you need to begin deploying Windows Defender Firewall using the guidance in the Windows Defender Firewall with Advanced Security Deployment Guide. +In addition to descriptions and example for each design, you'll find guidelines for gathering required data about your environment. You can then use these guidelines to plan and design your Windows Defender Firewall with Advanced Security deployment. After you read this guide, and finish gathering, documenting, and mapping your organization's requirements, you have the information that you need to begin deploying Windows Defender Firewall using the guidance in the Windows Defender Firewall with Advanced Security Deployment Guide. You can find the Windows Defender Firewall with Advanced Security Deployment Guide at these locations: @@ -67,7 +67,7 @@ Deployment Guide at these locations: | [Identifying Your Windows Defender Firewall with Advanced Security Deployment Goals](identifying-your-windows-firewall-with-advanced-security-deployment-goals.md) | Learn how to identify your Windows Defender Firewall with Advanced Security implementation goals. | | [Mapping Your Deployment Goals to a Windows Defender Firewall with Advanced Security Design](mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design.md) | After you finish reviewing the existing Windows Defender Firewall with Advanced Security implementation goals and you determine which goals are important to your specific deployment, you can map those goals to a specific Windows Defender Firewall with Advanced Security design. | | [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md) | To select the most effective design for helping to protect the network, you must spend time collecting key information about your current computer environment. | -| [Planning Your Windows Defender Firewall with Advanced Security Design](planning-your-windows-firewall-with-advanced-security-design.md) | After you have gathered the relevant information in the previous sections, and understand the basics of the designs as described earlier in this guide, you can select the design (or combination of designs) that meet your needs. | +| [Planning Your Windows Defender Firewall with Advanced Security Design](planning-your-windows-firewall-with-advanced-security-design.md) | After you've gathered the relevant information in the previous sections, and understand the basics of the designs as described earlier in this guide, you can select the design (or combination of designs) that meet your needs. | | [Appendix A: Sample GPO Template Files for Settings Used in this Guide](appendix-a-sample-gpo-template-files-for-settings-used-in-this-guide.md) | 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). | ## Terminology used in this guide @@ -78,19 +78,19 @@ The following table identifies and defines terms used throughout this guide. | - | - | | Active Directory domain | A group of devices and users managed by an administrator by using Active Directory Domain Services (AD DS). Devices in a domain share a common directory database and security policies. Multiple domains can co-exist in a "forest," with trust relationships that establish the forest as the security boundary. | | Authentication | A process that enables the sender of a message to prove its identity to the receiver. For connection security in Windows, authentication is implemented by the IPsec protocol suite.| -| Boundary zone | A subset of the devices in an isolated domain that must be able to receive unsolicited and non-authenticated network traffic from devices that are not members of the isolated domain. Devices in the boundary zone request but do not require authentication. They use IPsec to communicate with other devices in the isolated domain.| -| Connection security rule | A rule in Windows Defender Firewall that contains a set of conditions and an action to be applied to network packets that match the conditions. The action can allow the packet, block the packet, or require the packet to be protected by IPsec. In previous versions of Windows, this was called an *IPsec rule*.| -| Certificate-based isolation | A way to add devices that cannot use Kerberos V5 authentication to an isolated domain, by using an alternate authentication technique. Every device in the isolated domain and the devices that cannot use Kerberos V5 are provided with a device certificate that can be used to authenticate with each other. Certificate-based isolation requires a way to create and distribute an appropriate certificate (if you choose not to purchase one from a commercial certificate provider).| -| Domain isolation | A technique for helping protect the devices in an organization by requiring that the devices authenticate each other's identity before exchanging information, and refusing connection requests from devices that cannot authenticate. Domain isolation takes advantage of Active Directory domain membership and the Kerberos V5 authentication protocol available to all members of the domain. Also see "Isolated domain" in this table.| +| Boundary zone | A subset of the devices in an isolated domain that must be able to receive unsolicited and non-authenticated network traffic from devices that aren't members of the isolated domain. Devices in the boundary zone request but don't require authentication. They use IPsec to communicate with other devices in the isolated domain.| +| Connection security rule | A rule in Windows Defender Firewall that contains a set of conditions and an action to be applied to network packets that match the conditions. The action can allow the packet, block the packet, or require the packet to be protected by IPsec. In previous versions of Windows, this rule was called an *IPsec rule*.| +| Certificate-based isolation | A way to add devices that can't use Kerberos V5 authentication to an isolated domain, by using an alternate authentication technique. Every device in the isolated domain and the devices that can't use Kerberos V5 are provided with a device certificate that can be used to authenticate with each other. Certificate-based isolation requires a way to create and distribute an appropriate certificate (if you choose not to purchase one from a commercial certificate provider).| +| Domain isolation | A technique for helping protect the devices in an organization by requiring that the devices authenticate each other's identity before exchanging information, and refusing connection requests from devices that can't authenticate. Domain isolation takes advantage of Active Directory domain membership and the Kerberos V5 authentication protocol available to all members of the domain. Also see "Isolated domain" in this table.| | Encryption zone | A subset of the devices in an isolated domain that process sensitive data. Devices that are part of the encryption zone have all network traffic encrypted to prevent viewing by non-authorized users. Devices that are part of the encryption zone also typically are subject to the access control restrictions of server isolation.| | Firewall rule | A rule in Windows Defender Firewall that contains a set of conditions used to determine whether a network packet is allowed to pass through the firewall.
By default, the firewall rules in Windows Server 2016. Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 11, Windows 10, Windows 8, Windows 7, and Windows Vista block unsolicited inbound network traffic. Likewise, by default, all outbound network traffic is allowed. The firewall included in previous versions of Windows only filtered inbound network traffic. | | Internet Protocol security (IPsec) | A set of industry-standard, cryptography-based protection services and protocols. IPsec protects all protocols in the TCP/IP protocol suite except Address Resolution Protocol (ARP).| | IPsec policy | A collection of connection security rules that provide the required protection to network traffic entering and leaving the device. The protection includes authentication of both the sending and receiving device, integrity protection of the network traffic exchanged between them, and can include encryption.| | Isolated domain | An Active Directory domain (or an Active Directory forest, or set of domains with two-way trust relationships) that has Group Policy settings applied to help protect its member devices by using IPsec connection security rules. Members of the isolated domain require authentication on all unsolicited inbound connections (with exceptions handled by the other zones).
In this guide, the term *isolated domain* refers to the IPsec concept of a group of devices that can share authentication. The term *Active Directory domain* refers to the group of devices that share a security database by using Active Directory.| -| Server isolation | A technique for using group membership to restrict access to a server that is typically already a member of an isolated domain. The additional protection comes from using the authentication credentials of the requesting device to determine its group membership, and then only allowing access if the computer account (and optionally the user account) is a member of an authorized group.| +| Server isolation | A technique for using group membership to restrict access to a server that is typically already a member of an isolated domain. The extra protection comes from using the authentication credentials of the requesting device to determine its group membership, and then only allowing access if the computer account (and optionally the user account) is a member of an authorized group.| | Solicited network traffic | Network traffic that is sent in response to a request. By default, Windows Defender Firewall allows all solicited network traffic through.| -| Unsolicited network traffic | Network traffic that is not a response to an earlier request, and that the receiving device cannot necessarily anticipate. By default, Windows Defender Firewall blocks all unsolicited network traffic. | -| Zone | A zone is a logical grouping of devices that share common IPsec policies because of their communications requirements. For example, the boundary zone permits inbound connections from non-trusted devices. The encryption zone requires that all connections be encrypted.
This is not related to the term zone as used by Domain Name System (DNS). | +| Unsolicited network traffic | Network traffic that isn't a response to an earlier request, and that the receiving device can't necessarily anticipate. By default, Windows Defender Firewall blocks all unsolicited network traffic. | +| Zone | A zone is a logical grouping of devices that share common IPsec policies because of their communications requirements. For example, the boundary zone permits inbound connections from non-trusted devices. The encryption zone requires that all connections be encrypted.
This term zone isn't related to the one used by Domain Name System (DNS). | **Next:** [Understanding the Windows Defender Firewall with Advanced Security Design Process](understanding-the-windows-firewall-with-advanced-security-design-process.md) diff --git a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security.md b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security.md index 966c5e4a6a..297a720a7a 100644 --- a/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security.md +++ b/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security.md @@ -21,13 +21,13 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -This is an overview of the Windows Defender Firewall with Advanced Security (WFAS) and Internet Protocol security (IPsec) features. +This topic is an overview of the Windows Defender Firewall with Advanced Security (WFAS) and Internet Protocol security (IPsec) features. ## Overview of Windows Defender Firewall with Advanced Security -Windows Defender Firewall in Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 is a stateful host firewall that helps secure the device by allowing you to create rules that determine which network traffic is permitted to enter the device from the network and which network traffic the device is allowed to send to the network. Windows Defender Firewall also supports Internet Protocol security (IPsec), which you can use to require authentication from any device that is attempting to communicate with your device. When authentication is required, devices that cannot be authenticated as a trusted device cannot communicate with your device. You can also use IPsec to require that certain network traffic is encrypted to prevent it from being read by network packet analyzers that could be attached to the network by a malicious user. +Windows Defender Firewall in Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2 is a stateful host firewall that helps secure the device by allowing you to create rules that determine which network traffic is permitted to enter the device from the network and which network traffic the device is allowed to send to the network. Windows Defender Firewall also supports Internet Protocol security (IPsec), which you can use to require authentication from any device that is attempting to communicate with your device. When authentication is required, devices that can't be authenticated as a trusted device can't communicate with your device. You can also use IPsec to require that certain network traffic is encrypted to prevent it from being read by network packet analyzers that could be attached to the network by a malicious user. -The Windows Defender Firewall with Advanced Security MMC snap-in is more flexible and provides much more functionality than the consumer-friendly Windows Defender Firewall interface found in the Control Panel. Both interfaces interact with the same underlying services, but provide different levels of control over those services. While the Windows Defender Firewall Control Panel program can protect a single device in a home environment, it does not provide enough centralized management or security features to help secure more complex network traffic found in a typical business enterprise environment. +The Windows Defender Firewall with Advanced Security MMC snap-in is more flexible and provides much more functionality than the consumer-friendly Windows Defender Firewall interface found in the Control Panel. Both interfaces interact with the same underlying services, but provide different levels of control over those services. While the Windows Defender Firewall Control Panel program can protect a single device in a home environment, it doesn't provide enough centralized management or security features to help secure more complex network traffic found in a typical business enterprise environment. @@ -40,9 +40,9 @@ Windows Defender Firewall with Advanced Security is an important part of a layer To help address your organizational network security challenges, Windows Defender Firewall offers the following benefits: -- **Reduces the risk of network security threats.**  Windows Defender Firewall reduces the attack surface of a device, providing an additional layer to the defense-in-depth model. Reducing the attack surface of a device increases manageability and decreases the likelihood of a successful attack. +- **Reduces the risk of network security threats.**  Windows Defender Firewall reduces the attack surface of a device, providing an extra layer to the defense-in-depth model. Reducing the attack surface of a device increases manageability and decreases the likelihood of a successful attack. - **Safeguards sensitive data and intellectual property.**  With its integration with IPsec, Windows Defender Firewall provides a simple way to enforce authenticated, end-to-end network communications. It provides scalable, tiered access to trusted network resources, helping to enforce integrity of the data, and optionally helping to protect the confidentiality of the data. -- **Extends the value of existing investments.**  Because Windows Defender Firewall is a host-based firewall that is included with the operating system, there is no additional hardware or software required. Windows Defender Firewall is also designed to complement existing non-Microsoft network security solutions through a documented application programming interface (API). +- **Extends the value of existing investments.**  Because Windows Defender Firewall is a host-based firewall that is included with the operating system, there's no other hardware or software required. Windows Defender Firewall is also designed to complement existing non-Microsoft network security solutions through a documented application programming interface (API). diff --git a/windows/security/threat-protection/windows-sandbox/windows-sandbox-architecture.md b/windows/security/threat-protection/windows-sandbox/windows-sandbox-architecture.md index be77c53fd5..7d809b3599 100644 --- a/windows/security/threat-protection/windows-sandbox/windows-sandbox-architecture.md +++ b/windows/security/threat-protection/windows-sandbox/windows-sandbox-architecture.md @@ -19,9 +19,9 @@ Windows Sandbox benefits from new container technology in Windows to achieve a c ## Dynamically generated image -Rather than requiring a separate copy of Windows to boot the sandbox, Dynamic Base Image technology leverages the copy of Windows already installed on the host. +Rather than requiring a separate copy of Windows to boot the sandbox, Dynamic Base Image technology uses the copy of Windows already installed on the host. -Most OS files are immutable and can be freely shared with Windows Sandbox. A small subset of operating system files are mutable and cannot be shared, so the sandbox base image contains pristine copies of them. A complete Windows image can be constructed from a combination of the sharable immutable files on the host and the pristine copies of the mutable files. By using this scheme, Windows Sandbox has a full Windows installation to boot from without needing to download or store an additional copy of Windows. +Most OS files are immutable and can be freely shared with Windows Sandbox. A small subset of operating system files are mutable and can't be shared, so the sandbox base image contains pristine copies of them. A complete Windows image can be constructed from a combination of the sharable immutable files on the host and the pristine copies of the mutable files. With the help of this scheme, Windows Sandbox has a full Windows installation to boot from without needing to download or store an extra copy of Windows. Before Windows Sandbox is installed, the dynamic base image package is stored as a compressed 30-MB package. Once it's installed, the dynamic base image occupies about 500 MB of disk space. @@ -35,7 +35,7 @@ Traditional VMs apportion statically sized allocations of host memory. When reso ## Memory sharing -Because Windows Sandbox runs the same operating system image as the host, it has been enhanced to use the same physical memory pages as the host for operating system binaries via a technology referred to as "direct map." For example, when *ntdll.dll* is loaded into memory in the sandbox, it uses the same physical pages as those of the binary when loaded on the host. Memory sharing between the host and the sandbox results in a smaller memory footprint when compared to traditional VMs, without compromising valuable host secrets. +Because Windows Sandbox runs the same operating system image as the host, it has been enhanced to use the same physical memory pages as the host for operating system binaries via a technology referred to as "direct map." For example, when *ntdll.dll* is loaded into memory in the sandbox, it uses the same physical pages as those pages of the binary when loaded on the host. Memory sharing between the host and the sandbox results in a smaller memory footprint when compared to traditional VMs, without compromising valuable host secrets. ![A chart compares the memory footprint in Windows Sandbox versus a traditional VM.](images/3-memory-sharing.png) @@ -45,7 +45,7 @@ With ordinary virtual machines, the Microsoft hypervisor controls the scheduling ![A chart compares the scheduling in Windows Sandbox versus a traditional VM.](images/4-integrated-kernal.png) -Windows Sandbox employs a unique policy that allows the virtual processors of the Sandbox to be scheduled like host threads. Under this scheme, high-priority tasks on the host can preempt less important work in the Sandbox. This means that the most important work will be prioritized, whether it's on the host or in the container. +Windows Sandbox employs a unique policy that allows the virtual processors of the Sandbox to be scheduled like host threads. Under this scheme, high-priority tasks on the host can preempt less important work in the Sandbox. This preemption means that the most important work will be prioritized, whether it's on the host or in the container. ## WDDM GPU virtualization