mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-21 21:33:38 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -15,13 +15,13 @@ Global defaults set the device behavior in a per-profile basis. Windows Firewall
|
||||
|
||||
Windows 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 enforced, you might need to enable Windows Firewall. Here's how to enable Windows Firewall on a local device:
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh.exe advfirewall set allprofiles state on
|
||||
@ -34,13 +34,13 @@ netsh.exe advfirewall set allprofiles state on
|
||||
The global default settings can be defined through the command-line interface. These modifications are also available through the Windows Firewall console.
|
||||
The following scriptlets set the default inbound and outbound actions, specifies protected network connections, and allows notifications to be displayed to the user when a program is blocked from receiving inbound connections. It allows unicast response to multicast or broadcast network traffic, and it specifies logging settings for troubleshooting.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyOnListen True -AllowUnicastResponseToMulticast True -LogFileName %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
```cmd
|
||||
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound
|
||||
@ -71,13 +71,13 @@ Use the following procedure to turn off the firewall, or disable the Group Polic
|
||||
For more information, see [Windows Firewall deployment guide](windows-firewall-with-advanced-security-deployment-guide.md).
|
||||
The following example disables Windows Firewall for all profiles.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
---
|
||||
|
||||
@ -90,13 +90,13 @@ 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'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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
New-NetFirewallRule -DisplayName "Allow Inbound Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall firewall add rule name="Allow Inbound Telnet" dir=in program= %SystemRoot%\System32\tlntsvr.exe remoteip=localsubnet action=allow
|
||||
@ -107,13 +107,13 @@ netsh advfirewall firewall add rule name="Allow Inbound Telnet" dir=in program=
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -LocalPort 23 -Action Block -PolicyStore domain.contoso.com\gpo_name
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
|
||||
@ -140,13 +140,13 @@ This command doesn't batch your individual changes, it loads and saves the entir
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Set-NetFirewallRule -DisplayName "Allow Web 80" -RemoteAddress 192.168.0.2
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall firewall set rule name="Allow Web 80" new remoteip=192.168.0.2
|
||||
@ -188,13 +188,13 @@ $rule | Set-NetFirewallRule
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Set-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Enabled True
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall firewall set rule group="Windows Firewall remote management" new enable=yes
|
||||
@ -213,13 +213,13 @@ Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Verbo
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Remove-NetFirewallRule -DisplayName "Allow Web 80"
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall firewall delete rule name="Allow Web 80"
|
||||
@ -268,13 +268,13 @@ In Netsh, the authentication and cryptographic sets were specified as a list of
|
||||
|
||||
The following cmdlet creates basic IPsec transport mode rule in a Group Policy Object. An IPsec rule is simple to create; all that is required is the display name, and the remaining properties use default values. Inbound traffic is authenticated and integrity checked using the default quick mode and main mode settings. These default settings can be found in the console under Customize IPsec Defaults.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -PolicyStore domain.contoso.com\gpo_name
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
|
||||
@ -290,7 +290,7 @@ You can then use the newly created custom quick-mode policies when you create IP
|
||||
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
$AHandESPQM = New-NetIPsecQuickModeCryptoProposal -Encapsulation AH,ESP -AHHash SHA1 -ESPHash SHA1 -Encryption DES3
|
||||
@ -298,7 +298,7 @@ $QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "ah:sha1+esp:sha1-des
|
||||
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -InboundSecurity Require -OutboundSecurity Request -QuickModeCryptoSet $QMCryptoSet.Name -PolicyStore domain.contoso.com\gpo_name
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
|
||||
@ -367,13 +367,13 @@ 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 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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Show-NetIPsecRule -PolicyStore ActiveStore
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall consec show rule name=all
|
||||
@ -384,13 +384,13 @@ netsh advfirewall consec show rule name=all
|
||||
You can monitor main mode security associations for information such as which peers are currently connected to the device and which protection suite is used to form the security associations.
|
||||
Use the following cmdlet to view existing main mode rules and their security associations:
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
Get-NetIPsecMainModeSA
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall monitor show mmsa all
|
||||
@ -414,7 +414,7 @@ It's important to note that the revealed sources don't contain a domain name.
|
||||
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 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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
$kerbprop = New-NetIPsecAuthProposal -Machine -Kerberos
|
||||
@ -422,7 +422,7 @@ $Phase1AuthSet = New-NetIPsecPhase1AuthSet -DisplayName "Kerberos Auth Phase1" -
|
||||
New-NetIPsecRule -DisplayName "Basic Domain Isolation Policy" -Profile Domain -Phase1AuthSet $Phase1AuthSet.Name -InboundSecurity Require -OutboundSecurity Request -PolicyStore domain.contoso.com\domain_isolation
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
|
||||
@ -435,7 +435,7 @@ netsh advfirewall consec add rule name="Basic Domain Isolation Policy" profile=d
|
||||
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
$QMProposal = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA1 -Encryption DES3
|
||||
@ -443,7 +443,7 @@ $QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "esp:sha1-des3" -Prop
|
||||
New-NetIPSecRule -DisplayName "Tunnel from HQ to Dallas Branch" -Mode Tunnel -LocalAddress 192.168.0.0/16 -RemoteAddress 192.157.0.0/16 -LocalTunnelEndpoint 1.1.1.1 -RemoteTunnelEndpoint 2.2.2.2 -InboundSecurity Require -OutboundSecurity Require -QuickModeCryptoSet $QMCryptoSet.Name
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall consec add rule name="Tunnel from 192.168.0.0/16 to 192.157.0.0/16" mode=tunnel endpoint1=192.168.0.0/16 endpoint2=192.157.0.0/16 localtunnelendpoint=1.1.1.1 remotetunnelendpoint=2.2.2.2 action=requireinrequireout qmsecmethods=esp:sha1-3des
|
||||
@ -460,13 +460,13 @@ In situations where only secure traffic can be allowed through the Windows Firew
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
New-NetFirewallRule -DisplayName "Allow Authenticated Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -Authentication Required -Action Allow
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall firewall add rule name="Allow Authenticated Telnet" dir=in program=%SystemRoot%\System32\tlntsvr.exe security=authenticate action=allow
|
||||
@ -476,7 +476,7 @@ netsh advfirewall firewall add rule name="Allow Authenticated Telnet" dir=in pro
|
||||
|
||||
The following command creates an IPsec rule that requires a first (computer) authentication and then attempts an optional second (user) authentication. Creating this rule secures and allows the traffic through the firewall rule requirements for the messenger program.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
$mkerbauthprop = New-NetIPsecAuthProposal -Machine -Kerberos
|
||||
@ -489,7 +489,7 @@ $P2Auth = New-NetIPsecPhase2AuthSet -DisplayName "User Auth" -Proposal $ukerbaut
|
||||
New-NetIPSecRule -DisplayName "Authenticate Both Computer and User" -InboundSecurity Require -OutboundSecurity Require -Phase1AuthSet $P1Auth.Name -Phase2AuthSet $P2Auth.Name
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall consec add rule name="Authenticate Both Computer and User" endpoint1=any endpoint2=any action=requireinrequireout auth1=computerkerb,computerntlm auth2=userkerb,userntlm,anonymous
|
||||
@ -526,13 +526,13 @@ For more information about how to create security groups or how to determine the
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
New-NetFirewallRule -DisplayName "Allow Encrypted Inbound Telnet to Group Members Only" -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -Direction Inbound -Action Allow -LocalPort 23 -Authentication Required -Encryption Required -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\Server_Isolation
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall set store gpo=domain.contoso.com\Server_Isolation
|
||||
@ -555,13 +555,13 @@ Set-NetFirewallSetting -RemoteMachineTransportAuthorizationList $secureMachineGr
|
||||
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.
|
||||
|
||||
#### [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
|
||||
|
||||
```powershell
|
||||
New-NetFirewallRule -DisplayName "Inbound Secure Bypass Rule" -Direction Inbound -Authentication Required -OverrideBlockRules $true -RemoteMachine $secureMachineGroup -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\domain_isolation
|
||||
```
|
||||
|
||||
#### [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
|
||||
|
||||
``` cmd
|
||||
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
title: Configure Windows Firewall
|
||||
description: Learn about the available tools to configure Windows Firewall and best practices.
|
||||
description: Learn about the available tools to configure Windows Firewall and firewall rules.
|
||||
ms.date: 11/15/2023
|
||||
ms.topic: best-practice
|
||||
---
|
||||
|
||||
# Configure Windows Firewall
|
||||
|
||||
This article describes the available tools to configure Windows Firewall, firewall rules, and some recommended practices.
|
||||
This article describes the available tools to configure Windows Firewall and firewall rules.
|
||||
|
||||
## Configuration tools
|
||||
|
||||
@ -85,65 +85,6 @@ Windows offers different tools to view the status and configure Windows Firewall
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
|
||||
## Firewall rules
|
||||
|
||||
In many cases, a first step for administrators is to customize the firewall profiles using *firewall rules*, so that they can work with applications or other types of software. For example, an administrator or user may choose to add a rule to accommodate a program, open a port or protocol, or allow a predefined type of traffic.
|
||||
|
||||
It's recommended to maintain the default Windows Firewall settings whenever possible. The settings are designed to secure your device for use in most network scenarios. One key example is the default Block behavior for Inbound connections.
|
||||
|
||||
> [!TIP]
|
||||
> Create your rules in all three profiles, but only enable the firewall rule group on the profiles that suit your scenarios. For example, if you are installing a sharing application that is only used on a private network, then it would be best to create firewall rules in all three profiles, but only enable the firewall rule group containing your rules on the private profile.
|
||||
|
||||
### Restrictions per profile
|
||||
|
||||
You may need to modify the restrictions on your firewall rules depending on which profile the rules are applied to. For applications and services that are designed to only be accessed by devices within a home or small business network, it's best to modify the remote address restriction to specify *Local Subnet* only. The same application or service wouldn't have this restriction when used in an enterprise environment. This can be done by adding the remote address restriction to rules that are added to the private and public profiles, while leaving them unrestricted in the domain profile. This remote address restriction shouldn't apply to applications or services that require global Internet connectivity.
|
||||
|
||||
### Rule precedence for inbound rules
|
||||
|
||||
In many cases, allowing specific types of inbound traffic is required for applications to function in the network. Administrators should keep the following rule precedence behaviors in mind when allowing these inbound exceptions:
|
||||
|
||||
1. Explicitly defined allow rules take precedence over the default block setting
|
||||
1. Explicit block rules take precedence over any conflicting allow rules
|
||||
1. More specific rules take precedence over less specific rules, except if there are explicit block rules as mentioned in 2. For example, if the parameters of rule 1 include an IP address range, while the parameters of rule 2 include a single IP host address, rule 2 takes precedence.
|
||||
|
||||
> [!TIP]
|
||||
> Because of 1 and 2, when designing a set of policies you should make sure that there are no other explicit block rules that could inadvertently overlap, thus preventing the traffic flow you wish to allow.
|
||||
|
||||
A general security recommended practice when creating inbound rules is to be as specific as possible. However, when new rules must be made that use ports or IP addresses, consider using consecutive ranges or subnets instead of individual addresses or ports where possible. This approach avoids creation of multiple filters under the hood, reduces complexity, and helps to avoid performance degradation.
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Firewall doesn't support weighted, administrator-assigned rule ordering. An effective policy set with expected behaviors can be created by keeping in mind the few, consistent, and logical rule behaviors as described.
|
||||
|
||||
### Create rules for new applications
|
||||
|
||||
When first installed, networked applications and services issue a *listen call* specifying the protocol/port information required for them to function properly. Since there's a default *block* action in Windows Firewall, you must create inbound exception rules to allow the traffic. It's common for the app or the app installer itself to add this firewall rule. Otherwise, the user (or firewall admin on behalf of the user) needs to manually create a rule.
|
||||
|
||||
If there's no active application or administrator-defined allow rule(s), a dialog box prompts the user to either allow or block an application's packets the first time the app is launched or tries to communicate in the network:
|
||||
|
||||
- If the user has admin permissions, they're prompted. If they respond *No* or cancel the prompt, block rules are created. Two rules are typically created, one each for TCP and UDP traffic
|
||||
- If the user isn't a local admin, they won't be prompted. In most cases, block rules are created
|
||||
|
||||
In either of these scenarios, once the rules are added, they must be deleted to generate the prompt again. If not, the traffic continues to be blocked.
|
||||
|
||||
> [!NOTE]
|
||||
> The firewall's default settings are designed for security. Allowing all inbound connections by default introduces the network to various threats. Therefore, creating exceptions for inbound connections from third-party software should be determined by trusted app developers, the user, or the admin on behalf of the user.
|
||||
|
||||
### Known issues with automatic rule creation
|
||||
|
||||
When designing a set of firewall policies for your network, it's a recommended practice to configure *allow rules* for any networked applications deployed on the host. Having the rules in place before the user first launches the application helps to ensure a seamless experience.
|
||||
|
||||
The absence of these staged rules doesn't necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime require user interaction and administrative privilege. If the device is expected to be used by non-administrative users, you should follow best practices and provide these rules before the application's first launch to avoid unexpected networking issues.
|
||||
|
||||
To determine why some applications are blocked from communicating in the network, check for the following instances:
|
||||
|
||||
1. A user with sufficient privileges receives a query notification advising them that the application needs to make a change to the firewall policy. Not fully understanding the prompt, the user cancels or dismisses the prompt
|
||||
1. A user lacks sufficient privileges and is therefore not prompted to allow the application to make the appropriate policy changes
|
||||
1. *Local Policy Merge* is disabled, preventing the application or network service from creating local rules
|
||||
|
||||
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or policy settings.
|
||||
|
||||
:::image type="content" alt-text="Windows Firewall prompt." source="images/fw04-userquery.png":::
|
||||
|
||||
## Local policy merge and application rules
|
||||
|
||||
Firewall rules can be deployed:
|
||||
@ -218,18 +159,6 @@ By default, the Windows Firewall blocks everything unless there's an exception r
|
||||
|
||||
Once the emergency is over, uncheck the setting to restore regular network traffic.
|
||||
|
||||
## Outbound rules considerations
|
||||
|
||||
What follows are a few general guidelines for configuring outbound rules.
|
||||
|
||||
- The default configuration of Blocked for Outbound rules can be considered for certain highly secure environments. However, the Inbound rule configuration should never be changed in a way that allows traffic by default
|
||||
- It's recommended to Allow Outbound by default for most deployments for the sake of simplification around app deployments, unless the organization prefers tight security controls over ease-of-use
|
||||
- In high security environments, an inventory of all apps should be logged and maintained. Records must include whether an app used requires network connectivity. Administrators need to create new rules specific to each app that needs network connectivity and push those rules centrally, via GPO or CSP.
|
||||
|
||||
## 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.
|
||||
|
||||
## WDAC tagging policies
|
||||
|
||||
Windows Firewall supports the use of Windows Defender Application Control (WDAC) Application ID (AppID) tags in firewall rules. With this capability, Windows Firewall rules can be scoped to an application or a group of applications by referencing process tags, without using absolute path or sacrificing security. There are two steps for this configuration:
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 200 KiB After Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 140 KiB |
@ -73,7 +73,7 @@ The *public network* profile is designed with higher security in mind for public
|
||||
## Next steps
|
||||
|
||||
> [!div class="nextstepaction"]
|
||||
> Learn about the tools to configure Windows Firewall, firewall rules, and some recommended practices:
|
||||
> Learn about Windows Firewall rules and design recommendations:
|
||||
>
|
||||
> [Windows Firewall rules >](rules.md)
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Windows Firewall rules
|
||||
description: Learn about Windows Firewall rules and best practices for creating and managing them.
|
||||
description: Learn about Windows Firewall rules and design recommendations.
|
||||
ms.date: 11/15/2023
|
||||
ms.topic: concept-article
|
||||
---
|
||||
@ -9,7 +9,7 @@ ms.topic: concept-article
|
||||
|
||||
In many cases, a first step for administrators is to customize the firewall profiles using *firewall rules*, so that they can work with applications or other types of software. For example, an administrator or user may choose to add a rule to accommodate a program, open a port or protocol, or allow a predefined type of traffic.
|
||||
|
||||
This article describes the concepts and best practices for creating and managing firewall rules.
|
||||
This article describes the concepts and recommendations for creating and managing firewall rules.
|
||||
|
||||
## Rule precedence for inbound rules
|
||||
|
||||
@ -43,7 +43,6 @@ When first installed, network applications and services issue a *listen call* sp
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> The firewall's default settings are designed for security. Allowing all inbound connections by default introduces the network to various threats. Therefore, creating exceptions for inbound connections from third-party software should be determined by trusted app developers, the user, or the admin on behalf of the user.
|
||||
|
||||
@ -76,9 +75,9 @@ Creation of application rules at runtime can also be prohibited by administrator
|
||||
|
||||
What follows are a few general guidelines for configuring outbound rules.
|
||||
|
||||
- The default configuration of Blocked for Outbound rules can be considered for certain highly secure environments. However, the Inbound rule configuration should never be changed in a way that allows traffic by default
|
||||
- It's recommended to Allow Outbound by default for most deployments for the sake of simplification around app deployments, unless the organization prefers tight security controls over ease-of-use
|
||||
- In high security environments, an inventory of all apps should be logged and maintained. Records must include whether an app used requires network connectivity. Administrators need to create new rules specific to each app that needs network connectivity and push those rules centrally, via GPO or CSP.
|
||||
- Changing the outbound rules to *blocked* can be considered for certain highly secure environments. However, the inbound rule configuration should never be changed in a way that allows all traffic by default
|
||||
- It's recommended to *allow outbound* by default for most deployments for the sake of simplification with app deployments, unless the organization prefers tight security controls over ease-of-use
|
||||
- In high security environments, an inventory of all apps should be logged and maintained. Records must include whether an app used requires network connectivity. Administrators need to create new rules specific to each app that needs network connectivity and push those rules centrally, via GPO or CSP
|
||||
|
||||
## Next steps
|
||||
|
||||
|
||||
Reference in New Issue
Block a user