Links: Windows (2021-03)

This commit is contained in:
David Coulter
2021-03-25 10:07:47 -07:00
parent b820895b06
commit e967b61aa9
995 changed files with 5433 additions and 6267 deletions

View File

@ -32,7 +32,7 @@ network. These recommendations cover a wide range of deployments including home
networks and enterprise desktop/server systems.
To open Windows Firewall, go to the **Start** menu, select **Run**,
type **WF.msc**, and then select **OK**. See also [Open Windows Firewall](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/open-windows-firewall-with-advanced-security).
type **WF.msc**, and then select **OK**. See also [Open Windows Firewall](./open-windows-firewall-with-advanced-security.md).
## Keep default settings
@ -62,7 +62,7 @@ Firewall whenever possible. These settings have been designed to secure your dev
> [!IMPORTANT]
> To maintain maximum security, do not change the default Block setting for inbound connections.
For more on configuring basic firewall settings, see [Turn on Windows Firewall and Configure Default Behavior](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/turn-on-windows-firewall-and-configure-default-behavior) and [Checklist: Configuring Basic Firewall Settings](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/checklist-configuring-basic-firewall-settings).
For more on configuring basic firewall settings, see [Turn on Windows Firewall and Configure Default Behavior](./turn-on-windows-firewall-and-configure-default-behavior.md) and [Checklist: Configuring Basic Firewall Settings](./checklist-configuring-basic-firewall-settings.md).
## Understand rule precedence for inbound rules
@ -77,7 +77,7 @@ This can be accomplished by right-clicking either **Inbound Rules** or **Outboun
> [!NOTE]
>This article does not cover step-by-step rule
configuration. See the [Windows Firewall with Advanced Security Deployment
Guide](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide)
Guide](./windows-firewall-with-advanced-security-deployment-guide.md)
for general guidance on policy creation.
In many cases, allowing specific types of inbound traffic will be required for
@ -133,7 +133,7 @@ To determine why some applications are blocked from communicating in the network
*Figure 4: Dialog box to allow access*
See also [Checklist: Creating Inbound Firewall Rules](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/checklist-creating-inbound-firewall-rules).
See also [Checklist: Creating Inbound Firewall Rules](./checklist-creating-inbound-firewall-rules.md).
## Establish local policy merge and application rules
@ -151,7 +151,7 @@ The rule merging settings either allow or prevent local admins from creating the
*Figure 5: Rule merging setting*
> [!TIP]
> In the firewall [configuration service provider](https://docs.microsoft.com/windows/client-management/mdm/firewall-csp), the
> In the firewall [configuration service provider](/windows/client-management/mdm/firewall-csp), the
equivalent setting is *AllowLocalPolicyMerge*. This setting can be found under each respective profile node, *DomainProfile*, *PrivateProfile*, and *PublicProfile*.
If merging of local policies is disabled, centralized deployment of rules is required for any app that needs inbound connectivity.
@ -159,7 +159,7 @@ If merging of local policies is disabled, centralized deployment of rules is req
Admins may disable *LocalPolicyMerge* in high security environments to maintain tighter control over endpoints. This can impact some apps and services that automatically generate a local firewall policy upon installation as discussed above. For these types of apps and services to work, admins should push rules centrally via group policy (GP), Mobile Device
Management (MDM), or both (for hybrid or co-management environments).
[Firewall CSP](https://docs.microsoft.com/windows/client-management/mdm/firewall-csp) and [Policy CSP](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider) also have settings that can affect rule merging.
[Firewall CSP](/windows/client-management/mdm/firewall-csp) and [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider) also have settings that can affect rule merging.
As a best practice, it is important to list and log such apps, including the network ports used for communications. Typically, you can find what ports must be open for a given service on the app's website. For more complex or customer application deployments, a more thorough analysis may be needed using network packet capture tools.
@ -203,8 +203,8 @@ What follows are a few general guidelines for configuring outbound rules.
- In high security environments, an inventory of all enterprise-spanning apps must be taken and logged by the administrator or administrators. Records must include whether an app used requires network connectivity. Administrators will need to create new rules specific to each app that needs network connectivity and push those rules centrally, via group policy (GP), Mobile Device Management (MDM), or both (for hybrid or co-management environments).
For tasks related to creating outbound rules, see [Checklist: Creating Outbound Firewall Rules](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/checklist-creating-outbound-firewall-rules).
For tasks related to creating outbound rules, see [Checklist: Creating Outbound Firewall Rules](./checklist-creating-outbound-firewall-rules.md).
## Document your changes
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.