mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-22 22:03:46 +00:00
Add periods to alt text
No other changes
This commit is contained in:
Gary Moore
@ -38,7 +38,7 @@ type **WF.msc**, and then select **OK**. See also [Open Windows Firewall](./op
|
||||
|
||||
When you open the Windows Defender Firewall for the first time, you can see the default settings applicable to the local computer. The Overview panel displays security settings for each type of network to which the device can connect.
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 1: Windows Defender Firewall*
|
||||
|
||||
@ -55,7 +55,7 @@ View detailed settings for each profile by right-clicking the top-level **Window
|
||||
Maintain the default settings in Windows Defender
|
||||
Firewall whenever possible. These settings have been designed to secure your device for use in most network scenarios. One key example is the default Block behavior for Inbound connections.
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 2: Default inbound/outbound settings*
|
||||
|
||||
@ -70,7 +70,7 @@ In many cases, a next step for administrators will be to customize these profile
|
||||
|
||||
This can be accomplished by right-clicking either **Inbound Rules** or **Outbound Rules**, and selecting **New Rule**. The interface for adding a new rule looks like this:
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 3: Rule Creation Wizard*
|
||||
|
||||
@ -131,7 +131,7 @@ To determine why some applications are blocked from communicating in the network
|
||||
|
||||
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 4: Dialog box to allow access*
|
||||
|
||||
@ -148,7 +148,7 @@ Rule merging settings control how rules from different policy sources can be com
|
||||
|
||||
The rule merging settings either allow or prevent local admins from creating their own firewall rules in addition to those obtained from Group Policy.
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 5: Rule merging setting*
|
||||
|
||||
@ -180,11 +180,11 @@ An important firewall feature you can use to mitigate damage during an active at
|
||||
Shields up can be achieved by checking **Block all
|
||||
incoming connections, including those in the list of allowed apps** setting found in either the Windows Settings app or the legacy file *firewall.cpl*.
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 6: Windows settings App/Windows Security/Firewall Protection/Network Type*
|
||||
|
||||
|
||||
|
||||
|
||||
*Figure 7: Legacy firewall.cpl*
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ The GPOs you build for the boundary zone include IPsec or connection security ru
|
||||
|
||||
Because these boundary zone devices can receive unsolicited inbound communications from untrusted devices that use plaintext, they must be carefully managed and secured in other ways. Mitigating this additional risk is an important part of deciding whether to add a device to the boundary zone. For example, completing a formal business justification process before adding each device to the boundary zone can help ensure that the additional risk is minimized. The following illustration shows a sample process that can help make such a decision.
|
||||
|
||||
|
||||
|
||||
|
||||
The goal of this process is to determine whether the risk of adding a device to a boundary zone can be mitigated to a level that makes it acceptable to the organization. Ultimately, if the risk cannot be mitigated, membership must be denied.
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ ms.technology: mde
|
||||
To get started, open Device Configuration in Intune, then create a new profile.
|
||||
Choose Windows 10 as the platform, and Endpoint Protection as the profile type.
|
||||
Select Windows Defender Firewall.
|
||||
|
||||
|
||||
|
||||
>[!IMPORTANT]
|
||||
>A single Endpoint Protection profile may contain up to a maximum of 150 firewall rules. If a client device requires more than 150 rules, then multiple profiles must be assigned to it.
|
||||
|
||||
@ -32,7 +32,7 @@ In addition to the basic protection provided by the firewall rules in the previo
|
||||
|
||||
The following illustration shows the traffic protection needed for this design example.
|
||||
|
||||
|
||||
|
||||
|
||||
1. All devices on the Woodgrove Bank corporate network that are Active Directory domain members must authenticate inbound network traffic as coming from another computer that is a member of the domain. Unless otherwise specified in this section, Woodgrove Bank's devices reject all unsolicited inbound network traffic that is not authenticated. If the basic firewall design is also implemented, even authenticated inbound network traffic is dropped unless it matches an inbound firewall rule.
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ By using connection security rules based on IPsec, you provide a logical barrier
|
||||
|
||||
The design is shown in the following illustration, with the arrows that show the permitted communication paths.
|
||||
|
||||
|
||||
|
||||
|
||||
Characteristics of this design, as shown in the diagram, include the following:
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ Debugging packet drops is a continuous issue to Windows customers. In the past,
|
||||
|
||||
Typically, when investigating packet drop events, a customer would use the field `Filter Run-Time ID` from Windows Filtering Platform (WFP) audits 5157 or 5152.
|
||||
|
||||
|
||||
|
||||
|
||||
The filter ID uniquely identifies the filter that caused the packet drop. The filter ID can be searched in the WFP state dump output to trace back to the Firewall rule where the filter originated from.
|
||||
|
||||
@ -73,7 +73,7 @@ To enable a specific audit event, run the corresponding command in an administra
|
||||
|
||||
As the audit surfaces `Filter Origin` and `Interface Index`, the network admin can determine the root cause of the network packet drop and the interface it happened on.
|
||||
|
||||
|
||||
|
||||
|
||||
The next sections are divided by `Filter Origin` type, the value is either a rule name or the name of one of the default block filters. If the filter origin is one of the default block filters, skip to the section, **Firewall default block filters**. Otherwise, continue to the section **Firewall rules**.
|
||||
|
||||
@ -86,7 +86,7 @@ Get-NetFirewallRule -Name “<Filter Origin>”
|
||||
Get-NetFirewallRule -Name " {A549B7CF-0542-4B67-93F9-EEBCDD584377} "
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
After identifying the rule that caused the drop, the network admin can now modify/disable the rule to allow the traffic they want through command prompt or using the Windows Defender UI. The network admin can find the rule in the UI with the rule’s `DisplayName`.
|
||||
|
||||
@ -118,7 +118,7 @@ Get-NetIPInterface –InterfaceIndex <Interface Index>
|
||||
Get-NetIPInterface –InterfaceIndex 5
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
To learn more about the quarantine feature, see [Quarantine behavior](quarantine.md).
|
||||
|
||||
@ -139,7 +139,7 @@ To generate a list of all the query user block rules, you can run the following
|
||||
Get-NetFirewallRule | Where {$_.Name -like "*Query User*"}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
The query user pop-up feature is enabled by default.
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ The network administrators want to implement Windows Defender Firewall with Adva
|
||||
|
||||
The following illustration shows the traffic protection needs for this design example.
|
||||
|
||||
|
||||
|
||||
|
||||
1. The network infrastructure servers that are running services, such as Active Directory, DNS, DHCP, or WINS, can receive unsolicited inbound requests from network clients. The network clients can receive the responses from the infrastructure servers.
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ The following are important factors in the implementation of your Windows Defend
|
||||
|
||||
The next step in implementing your design is to determine in what order each of the deployment steps must be performed. This guide uses checklists to help you accomplish the various deployment tasks that are required to implement your design plan. As the following diagram shows, checklists and subchecklists are used as necessary to provide the end-to-end procedure for deploying a design.
|
||||
|
||||
|
||||
|
||||
|
||||
Use the following parent checklists in this section of the guide to become familiar with the deployment tasks for implementing your organization's Windows Defender Firewall with Advanced Security design.
|
||||
|
||||
|
||||
@ -196,7 +196,7 @@ Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /s
|
||||
|
||||
Sample drop audit with `filterOrigin` as `Quarantine Default`.
|
||||
|
||||
|
||||
|
||||
|
||||
Once the drop’s filter origin has been identified as the quarantine default inbound block filter, the interface should be further investigated. To find the relevant interface, use the `InterfaceIndex` value from the `netEvent` or event audit in the following PowerShell command to generate more information about the interface:
|
||||
|
||||
@ -205,7 +205,7 @@ Get-NetIPInterface –InterfaceIndex <Interface Index>
|
||||
Get-NetIPInterface –InterfaceIndex 5
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
Using the interface name, event viewer can be searched for any interface related changes.
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ For devices that share sensitive information over the network, Windows Defender
|
||||
|
||||
The following illustration shows an encryption zone in an isolated domain. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory.
|
||||
|
||||
|
||||
|
||||
|
||||
This goal provides the following benefits:
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ 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.
|
||||
|
||||
|
||||
|
||||
|
||||
This goal, which corresponds to [Server Isolation Policy Design](server-isolation-policy-design.md), provides the following features:
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ The protection provided by domain isolation can help you comply with regulatory
|
||||
|
||||
The following illustration shows an isolated domain, with one of the zones that are optionally part of the design. The rules that implement both the isolated domain and the different zones are deployed by using Group Policy and Active Directory.
|
||||
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
|
||||
@ -59,7 +59,7 @@ These procedures assume that you already have a public key infrastructure (PKI)
|
||||
|
||||
The following Windows PowerShell script establishes a connection security rule that uses IKEv2 for communication between two computers (CLIENT1 and SERVER1) that are joined to the corp.contoso.com domain as shown in Figure 1.
|
||||
|
||||
|
||||
|
||||
|
||||
**Figure 1** The Contoso corporate network
|
||||
|
||||
@ -77,7 +77,7 @@ This script does the following:
|
||||
|
||||
- Creates the IKEv2 connection security rule called **My IKEv2 Rule**.
|
||||
|
||||
**Windows PowerShell commands**
|
||||
**Windows PowerShell commands**
|
||||
|
||||
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
|
||||
|
||||
@ -117,7 +117,7 @@ Use a Windows PowerShell script similar to the following to create a local IPsec
|
||||
|
||||
>**Important:** The certificate parameters that you specify for the certificate are case sensitive, so make sure that you type them exactly as specified in the certificate, and place the parameters in the exact order that you see in the following example. Failure to do so will result in connection errors.
|
||||
|
||||
**Windows PowerShell commands**
|
||||
**Windows PowerShell commands**
|
||||
|
||||
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ In addition to the protection provided by the firewall rules and domain isolatio
|
||||
|
||||
The following illustration shows the traffic protection needs for this design example.
|
||||
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ You can implement a server isolation design without using domain isolation. To d
|
||||
|
||||
The design is shown in the following illustration, with arrows that show the permitted communication paths.
|
||||
|
||||
|
||||
|
||||
|
||||
Characteristics of this design include the following:
|
||||
|
||||
|
||||
@ -328,7 +328,7 @@ Windows PowerShell can create powerful, complex IPsec policies like in Netsh and
|
||||
|
||||
In Netsh, the authentication and cryptographic sets were specified as a list of comma-separated tokens in a specific format. In Windows PowerShell, rather than using default settings, you first create your desired authentication or cryptographic proposal objects and bundle them into lists in your preferred order. Then, you create one or more IPsec rules that reference these sets. The benefit of this model is that programmatic access to the information in the rules is much easier. See the following sections for clarifying examples.
|
||||
|
||||
|
||||
|
||||
|
||||
### Create IPsec rules
|
||||
|
||||
@ -353,7 +353,7 @@ If you want to create a custom set of quick-mode proposals that includes both AH
|
||||
|
||||
You can then use the newly created custom quick-mode policies when you create IPsec rules. The cryptography set object is linked to an IPsec rule object.
|
||||
|
||||
|
||||
|
||||
|
||||
In this example, we build on the previously created IPsec rule by specifying a custom quick-mode crypto set. The final IPsec rule requires outbound traffic to be authenticated by the specified cryptography method.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user