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

Merge branch 'main' into pm-20231121-freshness

Browse Source
This commit is contained in:
Paolo Matarazzo
2023-11-22 08:44:13 -05:00
committed by GitHub
parent c914df9c69 c787aac690
commit 2c04e32ba0
70 changed files with 1164 additions and 1817 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
.openpublishing.redirection.windows-security.json
View File

@ -6847,7 +6847,7 @@
},
{
"source_path": "windows/security/threat-protection/windows-firewall/configure-the-windows-firewall-log.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure-the-windows-firewall-log",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure-logging",
"redirect_document_id": false
},
{
@ -6930,11 +6930,6 @@
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/create-wmi-filters-for-the-gpo",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-firewall/designing-a-windows-firewall-with-advanced-security-strategy.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/designing-a-windows-firewall-with-advanced-security-strategy",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-firewall/determining-the-trusted-state-of-your-devices.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/determining-the-trusted-state-of-your-devices",
@ -7082,7 +7077,7 @@
},
{
"source_path": "windows/security/threat-protection/windows-firewall/isolating-apps-on-your-network.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/isolating-apps-on-your-network",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831418(v=ws.11)",
"redirect_document_id": false
},
{
@ -7959,6 +7954,91 @@
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/determining-the-trusted-state-of-your-devices.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc753540(v=ws.10)",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-inbound-rules-to-support-rpc.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-an-outbound-program-or-service-rule.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-an-outbound-port-rule.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-program-or-service-rule.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-port-rule.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-icmp-rule.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall-with-advanced-security-administration-with-windows-powershell.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-firewall/designing-a-windows-firewall-with-advanced-security-strategy.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/designing-a-windows-firewall-with-advanced-security-strategy.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security-administration-with-windows-powershell.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/securing-end-to-end-ipsec-connections-by-using-ikev2.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831807(v=ws.11)",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/isolating-apps-on-your-network.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831418(v=ws.11)",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/configure-the-windows-firewall-log.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure-logging",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/create-windows-firewall-rules-in-intune.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall/configure",
"redirect_document_id": false
},
{
"source_path": "windows/security/operating-system-security/network-security/windows-firewall/firewall-settings-lost-on-upgrade.md",
"redirect_url": "/windows/security/operating-system-security/network-security/windows-firewall",
"redirect_document_id": false
}
]
}

2
includes/configure/gpo-settings-1.md
View File

@ -6,4 +6,4 @@ ms.topic: include
ms.prod: windows-client
---
To configure a device using group policy, use the [Local Group Policy Editor](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc731745(v=ws.10)). To configure multiple devices joined to Active Directory, [create](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc754740(v=ws.11)) or [edit](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc730903(v=ws.10)) a group policy object (GPO) and use the following settings:
To configure a device with group policy, use the [Local Group Policy Editor](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc731745(v=ws.10)). To configure multiple devices joined to Active Directory, [create or edit](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc754740(v=ws.11)) a group policy object (GPO) and use the following settings:

2
includes/configure/intune-settings-catalog-1.md
View File

@ -6,4 +6,4 @@ ms.topic: include
ms.prod: windows-client
---
To configure devices using Microsoft Intune, [create a Settings catalog policy](/mem/intune/configuration/settings-catalog) and use the following settings:
To configure devices with Microsoft Intune, [create a Settings catalog policy](/mem/intune/configuration/settings-catalog) and use the following settings:

2
includes/configure/registry.md
View File

@ -6,4 +6,4 @@ ms.topic: include
ms.prod: windows-client
---
To configure devices using the [Registry Editor](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc755256(v=ws.11)), use the following settings:
To configure devices with the [Registry Editor](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc755256(v=ws.11)), use the following settings:

2
includes/licensing/_edition-requirements.md
View File

@ -81,7 +81,7 @@ ms.topic: include
|**[Windows Autopilot](/autopilot/)**|Yes|Yes|Yes|Yes|
|**[Windows Defender Application Control (WDAC)](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control)**|Yes|Yes|Yes|Yes|
|**[Windows Defender System Guard](/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows)**|Yes|Yes|Yes|Yes|
|**[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security)**|Yes|Yes|Yes|Yes|
|**[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall)**|Yes|Yes|Yes|Yes|
|**[Windows Hello for Business](/windows/security/identity-protection/hello-for-business/)**|Yes|Yes|Yes|Yes|
|**[Windows Hello for Business Enhanced Security Sign-in (ESS)](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security)**|Yes|Yes|Yes|Yes|
|**[Windows LAPS](/windows-server/identity/laps/laps-overview)**|Yes|Yes|Yes|Yes|

2
includes/licensing/_licensing-requirements.md
View File

@ -81,7 +81,7 @@ ms.topic: include
|**[Windows Autopilot](/autopilot/)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows Defender Application Control (WDAC)](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows Defender System Guard](/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows Hello for Business](/windows/security/identity-protection/hello-for-business/)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows Hello for Business Enhanced Security Sign-in (ESS)](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security)**|Yes|Yes|Yes|Yes|Yes|
|**[Windows LAPS](/windows-server/identity/laps/laps-overview)**|Yes|Yes|Yes|Yes|Yes|

5
windows/security/application-security/application-isolation/microsoft-defender-application-guard/faq-md-app-guard.yml
View File

@ -119,10 +119,7 @@ sections:
- question: |
Why am I getting the error message "ERR_NAME_NOT_RESOLVED" after not being able to reach the PAC file?
answer: |
This issue is a known one. To mitigate this issue, you need to create two firewall rules. For information about creating a firewall rule by using Group Policy, see the following resources:
- [Create an inbound icmp rule](../../../operating-system-security/network-security/windows-firewall/create-an-inbound-icmp-rule.md)
- [Open Group Policy management console for Microsoft Defender Firewall](../../../operating-system-security/network-security/windows-firewall/open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md)
This issue is a known one. To mitigate this issue, you need to create two firewall rules. For information about creating a firewall rule with Group Policy, see [Configure Windows Firewall rules with group policy](../../../operating-system-security/network-security/windows-firewall/configure.md)
### First rule (DHCP Server)
- Program path: `%SystemRoot%\System32\svchost.exe`

2
windows/security/identity-protection/toc.yml
View File

@ -24,7 +24,7 @@ items:
href: enterprise-certificate-pinning.md
- name: Web sign-in
href: web-sign-in/index.md
- name: Federated sign-in 🔗
- name: Federated sign-in (EDU) 🔗
href: /education/windows/federated-sign-in
- name: Advanced credential protection
items:

24
windows/security/includes/sections/operating-system-security.md
View File

@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 09/18/2023
ms.date: 11/21/2023
ms.topic: include
---
@ -10,8 +10,8 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
| **[Secure Boot and Trusted Boot](/windows/security/operating-system-security/system-security/trusted-boot)** | Secure Boot and Trusted Boot help to prevent malware and corrupted components from loading when a device starts. <br><br>Secure Boot starts with initial boot-up protection, and then Trusted Boot picks up the process. Together, Secure Boot and Trusted Boot help to ensure the system boots up safely and securely. |
| **[Measured boot](/windows/compatibility/measured-boot)** | Measured Boot measures all important code and configuration settings during the boot of Windows. This includes: the firmware, boot manager, hypervisor, kernel, secure kernel and operating system. Measured Boot stores the measurements in the TPM on the machine, and makes them available in a log that can be tested remotely to verify the boot state of the client.<br><br>The Measured Boot feature provides antimalware software with a trusted (resistant to spoofing and tampering) log of all boot components that started before it. The antimalware software can use the log to determine whether components that ran before it are trustworthy, or if they are infected with malware. The antimalware software on the local machine can send the log to a remote server for evaluation. The remote server may initiate remediation actions, either by interacting with software on the client, or through out-of-band mechanisms, as appropriate. |
| **[Device health attestation service](/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices)** | The Windows device health attestation process supports a zero-trust paradigm that shifts the focus from static, network-based perimeters, to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and have not been tampered with before they can access corporate resources. The determinations are made with data stored in the TPM, which provides a secure root of trust. The information is sent to an attestation service, such as Azure Attestation, to verify the device is in a trusted state. Then, an MDM tool like Microsoft Intune reviews device health and connects this information with Microsoft Entra ID for conditional access. |
| **[Measured boot](/windows/compatibility/measured-boot)** | Measured Boot measures all important code and configuration settings during the boot of Windows. This includes: the firmware, boot manager, hypervisor, kernel, secure kernel and operating system. Measured Boot stores the measurements in the TPM on the machine, and makes them available in a log that can be tested remotely to verify the boot state of the client.<br><br>The Measured Boot feature provides anti-malware software with a trusted (resistant to spoofing and tampering) log of all boot components that started before it. The anti-malware software can use the log to determine whether components that ran before it are trustworthy, or if they're infected with malware. The anti-malware software on the local machine can send the log to a remote server for evaluation. The remote server may initiate remediation actions, either by interacting with software on the client, or through out-of-band mechanisms, as appropriate. |
| **[Device health attestation service](/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices)** | The Windows device health attestation process supports a zero-trust paradigm that shifts the focus from static, network-based perimeters, to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and haven't been tampered with before they can access corporate resources. The determinations are made with data stored in the TPM, which provides a secure root of trust. The information is sent to an attestation service, such as Azure Attestation, to verify the device is in a trusted state. Then, an MDM tool like Microsoft Intune reviews device health and connects this information with Microsoft Entra ID for conditional access. |
| **[Windows security policy settings and auditing](/windows/security/threat-protection/security-policy-settings/security-policy-settings)** | Microsoft provides a robust set of security settings policies that IT administrators can use to protect Windows devices and other resources in their organization. |
| **[Assigned Access (kiosk mode)](/windows/configuration/kiosk-methods)** | Some desktop devices in an enterprise serve a special purpose. For example, a PC in the lobby that customers use to see your product catalog. Or, a PC displaying visual content as a digital sign. Windows client offers two different locked-down experiences for public or specialized use: A single-app kiosk that runs a single Universal Windows Platform (UWP) app in full screen above the lock screen, or A multi-app kiosk that runs one or more apps from the desktop.<br><br>Kiosk configurations are based on Assigned Access, a feature in Windows that allows an administrator to manage the user's experience by limiting the application entry points exposed to the user. |
@ -19,13 +19,13 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
| **[Microsoft Defender Antivirus](/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-windows)** | Microsoft Defender Antivirus is a protection solution included in all versions of Windows. From the moment you boot Windows, Microsoft Defender Antivirus continually monitors for malware, viruses, and security threats. Updates are downloaded automatically to help keep your device safe and protect it from threats. Microsoft Defender Antivirus includes real-time, behavior-based, and heuristic antivirus protection.<br><br>The combination of always-on content scanning, file and process behavior monitoring, and other heuristics effectively prevents security threats. Microsoft Defender Antivirus continually scans for malware and threats and also detects and blocks potentially unwanted applications (PUA) which are applications that are deemed to negatively impact your device but are not considered malware. |
| **[Microsoft Defender Antivirus](/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-windows)** | Microsoft Defender Antivirus is a protection solution included in all versions of Windows. From the moment you boot Windows, Microsoft Defender Antivirus continually monitors for malware, viruses, and security threats. Updates are downloaded automatically to help keep your device safe and protect it from threats. Microsoft Defender Antivirus includes real-time, behavior-based, and heuristic antivirus protection.<br><br>The combination of always-on content scanning, file and process behavior monitoring, and other heuristics effectively prevents security threats. Microsoft Defender Antivirus continually scans for malware and threats and also detects and blocks potentially unwanted applications (PUA) which are applications that are deemed to negatively impact your device but aren't considered malware. |
| **[Local Security Authority (LSA) Protection](/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)** | Windows has several critical processes to verify a user's identity. Verification processes include Local Security Authority (LSA), which is responsible for authenticating users and verifying Windows logins. LSA handles tokens and credentials such as passwords that are used for single sign-on to a Microsoft account and Azure services. To help protect these credentials, additional LSA protection only allows loading of trusted, signed code and provides significant protection against Credential theft.<br><br>LSA protection is enabled by default on new, enterprise joined Windows 11 devices with added support for non-UEFI lock and policy management controls via MDM and group policy. |
| **[Attack surface reduction (ASR)](/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction)** | Attack surface reduction (ASR) rules help to prevent software behaviors that are often abused to compromise your device or network. By reducing the number of attack surfaces, you can reduce the overall vulnerability of your organization.<br><br>Administrators can configure specific ASR rules to help block certain behaviors, such as launching executable files and scripts that attempt to download or run files, running obfuscated or otherwise suspicious scripts, performing behaviors that apps don't usually initiate during normal day-to-day work. |
| **[Tamper protection settings for MDE](/microsoft-365/security/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection)** | Tamper protection is a capability in Microsoft Defender for Endpoint that helps protect certain security settings, such as virus and threat protection, from being disabled or changed. During some kinds of cyber attacks, bad actors try to disable security features on devices. Disabling security features provides bad actors with easier access to your data, the ability to install malware, and the ability to exploit your data, identity, and devices. Tamper protection helps guard against these types of activities. |
| **[Controlled folder access](/microsoft-365/security/defender-endpoint/controlled-folders)** | You can protect your valuable information in specific folders by managing app access to specific folders. Only trusted apps can access protected folders, which are specified when controlled folder access is configured. Commonly used folders, such as those used for documents, pictures, downloads, are typically included in the list of controlled folders. Controlled folder access works with a list of trusted apps. Apps that are included in the list of trusted software work as expected. Apps that are not included in the trusted list are prevented from making any changes to files inside protected folders. <br><br>Controlled folder access helps to protect user's valuable data from malicious apps and threats, such as ransomware. |
| **[Controlled folder access](/microsoft-365/security/defender-endpoint/controlled-folders)** | You can protect your valuable information in specific folders by managing app access to specific folders. Only trusted apps can access protected folders, which are specified when controlled folder access is configured. Commonly used folders, such as those used for documents, pictures, downloads, are typically included in the list of controlled folders. Controlled folder access works with a list of trusted apps. Apps that are included in the list of trusted software work as expected. Apps that aren't included in the trusted list are prevented from making any changes to files inside protected folders. <br><br>Controlled folder access helps to protect user's valuable data from malicious apps and threats, such as ransomware. |
| **[Exploit protection](/microsoft-365/security/defender-endpoint/exploit-protection)** | Exploit protection automatically applies several exploit mitigation techniques to operating system processes and apps. Exploit protection works best with Microsoft Defender for Endpoint, which gives organizations detailed reporting into exploit protection events and blocks as part of typical alert investigation scenarios. You can enable exploit protection on an individual device, and then use MDM or group policy to distribute the configuration file to multiple devices. When a mitigation is encountered on the device, a notification will be displayed from the Action Center. You can customize the notification with your company details and contact information. You can also enable the rules individually to customize which techniques the feature monitors. |
| **[Microsoft Defender SmartScreen](/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/)** | Microsoft Defender SmartScreen protects against phishing, malware websites and applications, and the downloading of potentially malicious files. For enhanced phishing protection, SmartScreen also alerts people when they are entering their credentials into a potentially risky location. IT can customize which notifications appear via MDM or group policy. The protection runs in audit mode by default, giving IT admins full control to make decisions around policy creation and enforcement. |
| **[Microsoft Defender SmartScreen](/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/)** | Microsoft Defender SmartScreen protects against phishing, malware websites and applications, and the downloading of potentially malicious files. For enhanced phishing protection, SmartScreen also alerts people when they're entering their credentials into a potentially risky location. IT can customize which notifications appear via MDM or group policy. The protection runs in audit mode by default, giving IT admins full control to make decisions around policy creation and enforcement. |
| **[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint)** | Microsoft Defender for Endpoint is an enterprise endpoint detection and response solution that helps security teams to detect, investigate, and respond to advanced threats. Organizations can use the rich event data and attack insights Defender for Endpoint provides to investigate incidents. Defender for Endpoint brings together the following elements to provide a more complete picture of security incidents: endpoint behavioral sensors, cloud security analytics, threat intelligence and rich response capabilities. |
## Network security
@ -33,11 +33,11 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
| **[Transport Layer Security (TLS)](/windows-server/security/tls/tls-ssl-schannel-ssp-overview)** | Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a network. TLS 1.3 is the latest version of the protocol and is enabled by default in Windows 11. This version eliminates obsolete cryptographic algorithms, enhances security over older versions, and aims to encrypt as much of the TLS handshake as possible. The handshake is more performant with one fewer round trip per connection on average, and supports only five strong cipher suites which provide perfect forward secrecy and less operational risk. |
| **[Domain Name System (DNS) security](/windows-server/networking/dns/doh-client-support)** | Starting in Windows 11, the Windows DNS client supports DNS over HTTPS (DoH), an encrypted DNS protocol. This allows administrators to ensure their devices protect DNS queries from on-path attackers, whether they are passive observers logging browsing behavior or active attackers trying to redirect clients to malicious sites.<br><br>In a zero-trust model where there is no trust placed in a network boundary, having a secure connection to a trusted name resolver is required. |
| **Bluetooth pairing and connection protection** | The number of Bluetooth devices connected to Windows continues to increase. Windows supports all standard Bluetooth pairing protocols, including classic and LE Secure connections, secure simple pairing, and classic and LE legacy pairing. Windows also implements host based LE privacy. Windows updates help users stay current with OS and driver security features in accordance with the Bluetooth Special Interest Group (SIG), Standard Vulnerability Reports, as well as issues beyond those required by the Bluetooth core industry standards. Microsoft strongly recommends that users ensure their firmware and/ or software of their Bluetooth accessories are kept up to date. |
| **[WiFi Security](https://support.microsoft.com/windows/faster-and-more-secure-wi-fi-in-windows-26177a28-38ed-1a8e-7eca-66f24dc63f09)** | Wi-Fi Protected Access (WPA) is a security certification programs designed to secure wireless networks. WPA3 is the latest version of the certification and provides a more secure and reliable connection method as compared to WPA2 and older security protocols. Windows supports three WPA3 modes: WPA3 personal with the Hash-to-Element (H2E) protocol, WPA3 Enterprise, and WPA3 Enterprise 192-bit Suite B.<br><br>Windows 11 also supports WFA defined WPA3 Enterprise that includes enhanced Server Cert validation and TLS 1.3 for authentication using EAP-TLS Authentication. |
| **[Domain Name System (DNS) security](/windows-server/networking/dns/doh-client-support)** | Starting in Windows 11, the Windows DNS client supports DNS over HTTPS (DoH), an encrypted DNS protocol. This allows administrators to ensure their devices protect DNS queries from on-path attackers, whether they're passive observers logging browsing behavior or active attackers trying to redirect clients to malicious sites.<br><br>In a zero-trust model where there is no trust placed in a network boundary, having a secure connection to a trusted name resolver is required. |
| **Bluetooth pairing and connection protection** | The number of Bluetooth devices connected to Windows continues to increase. Windows supports all standard Bluetooth pairing protocols, including classic and LE Secure connections, secure simple pairing, and classic and LE legacy pairing. Windows also implements host based LE privacy. Windows updates help users stay current with OS and driver security features in accordance with the Bluetooth Special Interest Group (SIG), Standard Vulnerability Reports, and issues beyond those required by the Bluetooth core industry standards. Microsoft strongly recommends that users ensure their firmware and/ or software of their Bluetooth accessories are kept up to date. |
| **[WiFi Security](https://support.microsoft.com/windows/faster-and-more-secure-wi-fi-in-windows-26177a28-38ed-1a8e-7eca-66f24dc63f09)** | Wi-Fi Protected Access (WPA) is a security certification program designed to secure wireless networks. WPA3 is the latest version of the certification and provides a more secure and reliable connection method as compared to WPA2 and older security protocols. Windows supports three WPA3 modes: WPA3 personal with the Hash-to-Element (H2E) protocol, WPA3 Enterprise, and WPA3 Enterprise 192-bit Suite B.<br><br>Windows 11 also supports WFA defined WPA3 Enterprise that includes enhanced Server Cert validation and TLS 1.3 for authentication using EAP-TLS Authentication. |
| **Opportunistic Wireless Encryption (OWE)** | Opportunistic Wireless Encryption (OWE) is a technology that allows wireless devices to establish encrypted connections to public Wi-Fi hotspots. |
| **[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security)** | Windows Firewall with Advanced Securityprovides host-based, two-way network traffic filtering, blocking unauthorized traffic flowing into or out of the local device based on the types of networks to which the device is connected. Windows Firewall reduces the attack surface of a device with rules to restrict or allow traffic by many properties such as IP addresses, ports, or program paths. Reducing the attack surface of a device increases manageability and decreases the likelihood of a successful attack.<br><br>With its integration with Internet Protocol Security (IPsec), Windows 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. Windows Firewall is a host-based firewall that is included with the operating system, there is no additional hardware or software required. Windows Firewall is also designed to complement existing non-Microsoft network security solutions through a documented application programming interface (API). |
| **[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall)** | Windows Firewall provides host-based, two-way network traffic filtering, blocking unauthorized traffic flowing into or out of the local device based on the types of networks to which the device is connected. Windows Firewall reduces the attack surface of a device with rules to restrict or allow traffic by many properties such as IP addresses, ports, or program paths. Reducing the attack surface of a device increases manageability and decreases the likelihood of a successful attack.<br><br>With its integration with Internet Protocol Security (IPsec), Windows 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. Windows Firewall is a host-based firewall that is included with the operating system, there's no additional hardware or software required. Windows Firewall is also designed to complement existing non-Microsoft network security solutions through a documented application programming interface (API). |
| **[Virtual private network (VPN)](/windows/security/operating-system-security/network-security/vpn/vpn-guide)** | The Windows VPN client platform includes built in VPN protocols, configuration support, a common VPN user interface, and programming support for custom VPN protocols. VPN apps are available in the Microsoft Store for both enterprise and consumer VPNs, including apps for the most popular enterprise VPN gateways.<br><br>In Windows 11, the most commonly used VPN controls are integrated right into the Quick Actions pane. From the Quick Actions pane, users can see the status of their VPN, start and stop the VPN tunnels, and access the Settings app for more controls. |
| **[Always On VPN (device tunnel)](/Windows-server/remote/remote-access/overview-always-on-vpn)** | With Always On VPN, you can create a dedicated VPN profile for the device. Unlike User Tunnel, which only connects after a user logs on to the device, Device Tunnel allows the VPN to establish connectivity before a user sign-in. Both Device Tunnel and User Tunnel operate independently with their VPN profiles, can be connected at the same time, and can use different authentication methods and other VPN configuration settings as appropriate. |
| **[Direct Access](/windows-server/remote/remote-access/directaccess/directaccess)** | DirectAccess allows connectivity for remote users to organization network resources without the need for traditional Virtual Private Network (VPN) connections.<br><br>With DirectAccess connections, remote devices are always connected to the organization and there's no need for remote users to start and stop connections. |
@ -51,5 +51,5 @@ ms.topic: include
| **[BitLocker management](/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises)** | The BitLocker CSP allows an MDM solution, like Microsoft Intune, to manage the BitLocker encryption features on Windows devices. This includes OS volumes, fixed drives and removeable storage, and recovery key management into Microsoft Entra ID. |
| **[BitLocker enablement](/windows/security/operating-system-security/data-protection/bitlocker/)** | BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. BitLocker uses AES algorithm in XTS or CBC mode of operation with 128-bit or 256-bit key length to encrypt data on the volume. Cloud storage on Microsoft OneDrive or Azure can be used to save recovery key content. BitLocker can be managed by any MDM solution such as Microsoft Intune, using a configuration service provider (CSP).<br><br>BitLocker provides encryption for the OS, fixed data, and removable data drives leveraging technologies like hardware security test interface (HSTI), Modern Standby, UEFI Secure Boot and TPM. |
| **[Encrypted hard drive](/windows/security/operating-system-security/data-protection/encrypted-hard-drive)** | Encrypted hard drives are a class of hard drives that are self-encrypted at the hardware level and allow for full disk hardware encryption while being transparent to the device user. These drives combine the security and management benefits provided by BitLocker Drive Encryption with the power of self-encrypting drives.<br><br>By offloading the cryptographic operations to hardware, encrypted hard drives increase BitLocker performance and reduce CPU usage and power consumption. Because encrypted hard drives encrypt data quickly, BitLocker deployment can be expanded across enterprise devices with little to no impact on productivity. |
| **[Personal data encryption (PDE)](/windows/security/operating-system-security/data-protection/personal-data-encryption/)** | Personal data encryption (PDE) works with BitLocker and Windows Hello for Business to further protect user documents and other files, including when the device is turned on and locked. Files are encrypted automatically and seamlessly to give users more security without interrupting their workflow. <br><br>Windows Hello for Business is used to protect the container which houses the encryption keys used by PDE. When the user signs in, the container gets authenticated to release the keys in the container to decrypt user content. |
| **[Email Encryption (S/MIME)](/windows/security/operating-system-security/data-protection/configure-s-mime)** | Email encryption enables users to encrypt outgoing email messages and attachments, so only intended recipients with a digital ID (certificate) can read them. Users can digitally sign a message, which verifies the identity of the sender and confirms the message has not been tampered with. The encrypted messages can be sent by a user to other users within their organization or external contacts if they have proper encryption certificates. |
| **[Personal data encryption (PDE)](/windows/security/operating-system-security/data-protection/personal-data-encryption/)** | Personal data encryption (PDE) works with BitLocker and Windows Hello for Business to further protect user documents and other files, including when the device is turned on and locked. Files are encrypted automatically and seamlessly to give users more security without interrupting their workflow. <br><br>Windows Hello for Business is used to protect the container, which houses the encryption keys used by PDE. When the user signs in, the container gets authenticated to release the keys in the container to decrypt user content. |
| **[Email Encryption (S/MIME)](/windows/security/operating-system-security/data-protection/configure-s-mime)** | Email encryption enables users to encrypt outgoing email messages and attachments, so only intended recipients with a digital ID (certificate) can read them. Users can digitally sign a message, which verifies the identity of the sender and confirms the message hasn't been tampered with. The encrypted messages can be sent by a user to other users within their organization or external contacts if they have proper encryption certificates. |

2
windows/security/index.yml
View File

@ -63,7 +63,7 @@ productDirectory:
- url: /windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines
text: Windows security baselines
- url: /windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/
text: MMicrosoft Defender SmartScreen
text: Microsoft Defender SmartScreen
- url: /windows/security/operating-system-security
text: Learn more about OS security >

2
windows/security/operating-system-security/data-protection/bitlocker/configure.md
View File

@ -10,11 +10,9 @@ ms.date: 10/30/2023
To configure BitLocker, you can use one of the following options:
- Configuration Service Provider (CSP): this option is commonly used for devices managed by a Mobile Device Management (MDM) solution, like Microsoft Intune. The [BitLocker CSP][WIN-1] is used to configure BitLocker, and to report the status of different BitLocker functions to the MDM solution. With Microsoft Intune, you can use the BitLocker status in [compliance policies][INT-1], combining them with [Conditional Access][ENTRA-1]. Conditional Access can prevent or grant access to services like Exchange Online and SharePoint Online, based on the status of BitLocker. To learn more about the Intune options to configure and monitor BitLocker, check the following articles:
- [Manage BitLocker policy for Windows devices with Intune][INT-2]
- [Monitor device encryption with Intune][INT-3]
- [Use compliance policies to set rules for devices you manage with Intune][INT-4]
- Group policy (GPO): this option can be used for devices that are joined to an Active Directory domain and aren't managed by a device management solution. Group policy can also be used for devices that aren't joined to an Active Directory domain, using the local group policy editor
- Microsoft Configuration Manager: this option can be used for devices that are managed by Microsoft Configuration Manager using the BitLocker management agent. To learn more about options to configure BitLocker via Microsoft Configuration Manager, see [Deploy BitLocker management][MCM-1]

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

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

177
windows/security/operating-system-security/network-security/windows-firewall/configure-logging.md Normal file
View File

@ -0,0 +1,177 @@
---
title: Configure Windows Firewall logging
description: Learn how to configure Windows Firewall to log dropped packets or successful connections with CSP and group policy.
ms.topic: how-to
ms.date: 11/21/2023
---
# Configure Windows Firewall logging
To configure Windows Firewall to log dropped packets or successful connections, you can use:
- Configuration Service Provider (CSP), using an MDM solution like Microsoft Intune
- Group policy (GPO)
[!INCLUDE [tab-intro](../../../../../includes/configure/tab-intro.md)]
# [:::image type="icon" source="../../../images/icons/intune.svg" border="false"::: **Intune/CSP**](#tab/intune)
1. Sign into the [Microsoft Intune admin center][INT]
1. Go to **Endpoint security** > **Firewall** > **Create policy** > **Windows 10, Windows 11, and Windows Server** > **Windows Firewall** > **Create**
1. Enter a name and, optionally, a description > **Next**
1. Under **Configuration settings**, for each network location type (*Domain*, *Private*, *Public*), configure:
- **Log file path**
- **Enable log dropped packets**
- **Enable log success connections**
- **Log max file size**
1. Select **Next** > **Next**
1. Assign the policy to a group that contains as members the devices or users that you want to configure > **Next** > **Create**
> [!TIP]
> If you prefer you can also use a [Settings catalog policy][MEM-1] to configure Windows Firewall logging.
Alternatively, you can configure devices using a [custom policy][INT-1] with the [Firewall CSP][CSP-1].
| Network profile | Setting |
|--|--|
| *Domain* | Setting name: [EnableLogDroppedPackets][CSP-2]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/DomainProfile/EnableLogDroppedPackets` |
| *Domain* | Setting name: [LogFilePath][CSP-5]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/DomainProfile/LogFilePath` |
| *Domain* | Setting name: [EnableLogSuccessConnections][CSP-8]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/DomainProfile/EnableLogSuccessConnections` |
| *Domain* | Setting name: [LogMaxFileSize][CSP-11]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/DomainProfile/LogMaxFileSize` |
| *Private* | Setting name: [EnableLogDroppedPackets][CSP-3]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/EnableLogDroppedPackets` |
| *Private* | Setting name: [LogFilePath][CSP-6]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/LogFilePath`|
| *Private* | Setting name: [EnableLogSuccessConnections][CSP-9]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/EnableLogSuccessConnections` |
| *Private* | Setting name: [LogMaxFileSize][CSP-12]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/LogMaxFileSize` |
| *Public* | Setting name: [EnableLogDroppedPackets][CSP-4]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/EnableLogDroppedPackets` |
| *Public* | Setting name: [LogFilePath][CSP-7]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/LogFilePath`|
| *Public* | Setting name: [EnableLogSuccessConnections][CSP-10]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/EnableLogSuccessConnections` |
| *Public* | Setting name: [LogMaxFileSize][CSP-13]<br>OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/LogMaxFileSize` |
# [:::image type="icon" source="../../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
[!INCLUDE [gpo-settings-1](../../../../../includes/configure/gpo-settings-1.md)]
1. Expand the nodes **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Windows Firewall with Advanced Security**
1. In the details pane, in the **Overview** section, select **Windows Defender Firewall Properties**
1. For each network location type (*Domain*, *Private*, *Public*), perform the following steps
1. Select the tab that corresponds to the network location type
1. Under **Logging**, select **Customize**
1. The default path for the log is `%windir%\system32\logfiles\firewall\pfirewall.log`. If you want to change this path, clear the **Not configured** check box and enter the path to the new location, or select **Browse** to select a file location
1. The default maximum file size for the log is 4,096 kilobytes (KB). If you want to change this size, clear the **Not configured** check box, and enter the new size in KB, or use the up and down arrows to select a size. The file won't grow beyond this size; when the limit is reached, old log entries are deleted to make room for the newly created ones.
1. No logging occurs until you set one of following two options:
- To create a log entry when Windows Defender Firewall drops an incoming network packet, change **Log dropped packets** to **Yes**
- To create a log entry when Windows Defender Firewall allows an inbound connection, change **Log successful connections** to **Yes**
1. Select **OK** twice
[!INCLUDE [gpo-settings-2](../../../../../includes/configure/gpo-settings-2.md)]
---
> [!IMPORTANT]
> The location you specify must have permissions assigned that permit the Windows Firewall service to write to the log file.
## Recommendations
Here are some recommendations for configuring Windows Firewall logging:
- Change the logging size to at least **20,480 KB (20 MB)** to ensure that the log file doesn't fill up too quickly. The maximum log size is 32,768 KB (32 MB)
- For each profile (Domain, Private, and Public) change the default log file name from `%windir%\system32\logfiles\firewall\pfirewall.log` to:
- `%windir%\system32\logfiles\firewall\pfirewall_Domain.log`
- `%windir%\system32\logfiles\firewall\pfirewall_Private.log`
- `%windir%\system32\logfiles\firewall\pfirewall_Public.log`
- Log dropped packets to **Yes**
- Log successful connections to **Yes**
On a single system, you can use the following commands to configure logging:
```cmd
netsh advfirewall>set allprofiles logging allowedconnections enable
netsh advfirewall>set allprofiles logging droppedconnections enable
```
## Parsing methods
There are several methods to parse the Windows Firewall log files. For example:
- Enable *Windows Event Forwarding* (WEF) to a *Windows Event Collector* (WEC). To learn more, see [Use Windows Event Forwarding to help with intrusion detection][WIN-1]
- Forward the logs to your SIEM product such as our Azure Sentinel. To learn more, see [Windows Firewall connector for Microsoft Sentinel][AZ-1]
- Forward the logs to Azure Monitor and use KQL to parse the data. To learn more, see [Azure Monitor agent on Windows client devices][AZ-2]
> [!TIP]
> If logs are slow to appear in your SIEM solution, you can decrease the log file size. Just beware that the downsizing results in more resource usage due to the increased log rotation.
## Troubleshoot if the log file is not created or modified
Sometimes the Windows Firewall log files aren't created, or the events aren't written to the log files. Some examples when this condition might occur include:
- Missing permissions for the *Windows Defender Firewall Service* (`mpssvc`) on the folder or on the log files
- You want to store the log files in a different folder and the permissions are missing, or aren't set automatically
- if firewall logging is configured via policy settings, it can happen that
- the log folder in the default location `%windir%\System32\LogFiles\firewall` doesn't exist
- the log folder in a custom path doesn't exist
In both cases, you must create the folder manually or via script, and add the permissions for `mpssvc`.
```PowerShell
New-Item -ItemType Directory -Path $env:windir\System32\LogFiles\Firewall
```
Verify if `mpssvc` has *FullControl* on the folder and the files. From an elevated PowerShell session, use the following commands, ensuring to use the correct path:
```PowerShell
$LogPath = Join-Path -path $env:windir -ChildPath "System32\LogFiles\Firewall"
(Get-ACL -Path $LogPath).Access | Format-Table IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -AutoSize
```
The output should show `NT SERVICE\mpssvc` having *FullControl*:
```PowerShell
IdentityReference FileSystemRights AccessControlType IsInherited InheritanceFlags
----------------- ---------------- ----------------- ----------- ----------------
NT AUTHORITY\SYSTEM FullControl Allow False ObjectInherit
BUILTIN\Administrators FullControl Allow False ObjectInherit
NT SERVICE\mpssvc FullControl Allow False ObjectInherit
```
If not, add *FullControl* permissions for `mpssvc` to the folder, subfolders and files. Make sure to use the correct path.
```PowerShell
$LogPath = Join-Path -path $env:windir -ChildPath "System32\LogFiles\Firewall"
$NewAcl = Get-Acl -Path $LogPath
$identity = "NT SERVICE\mpssvc"
$fileSystemRights = "FullControl"
$inheritanceFlags = "ContainerInherit,ObjectInherit"
$propagationFlags = "None"
$type = "Allow"
$fileSystemAccessRuleArgumentList = $identity, $fileSystemRights, $inheritanceFlags, $propagationFlags, $type
$fileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $fileSystemAccessRuleArgumentList
$NewAcl.SetAccessRule($fileSystemAccessRule)
Set-Acl -Path $LogPath -AclObject $NewAcl
```
Restart the device to restart the *Windows Defender Firewall* service.
<!--links-->
[INT-1]: /mem/intune/configuration/custom-settings-windows-10
[CSP-1]: /windows/client-management/mdm/firewall-csp
[AZ-1]: /azure/sentinel/data-connectors/windows-firewall
[INT]: https://go.microsoft.com/fwlink/?linkid=2109431
[MEM-1]: /mem/intune/configuration/settings-catalog
[WIN-1]: /windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection
[AZ-2]: /azure/azure-monitor/agents/azure-monitor-agent-windows-client
[CSP-2]: /windows/client-management/mdm/firewall-csp#mdmstoredomainprofileenablelogdroppedpackets
[CSP-3]: /windows/client-management/mdm/firewall-csp#mdmstoreprivateprofileenablelogdroppedpackets
[CSP-4]: /windows/client-management/mdm/firewall-csp#mdmstorepublicprofileenablelogdroppedpackets
[CSP-5]: /windows/client-management/mdm/firewall-csp#mdmstoredomainprofilelogfilepath
[CSP-6]: /windows/client-management/mdm/firewall-csp#mdmstoreprivateprofilelogfilepath
[CSP-7]: /windows/client-management/mdm/firewall-csp#mdmstorepublicprofilelogfilepath
[CSP-8]: /windows/client-management/mdm/firewall-csp#mdmstoredomainprofileenablelogsuccessconnections
[CSP-9]: /windows/client-management/mdm/firewall-csp#mdmstoreprivateprofileenablelogsuccessconnections
[CSP-10]: /windows/client-management/mdm/firewall-csp#mdmstorepublicprofileenablelogsuccessconnections
[CSP-11]: /windows/client-management/mdm/firewall-csp#mdmstoredomainprofilelogmaxfilesize
[CSP-12]: /windows/client-management/mdm/firewall-csp#mdmstoreprivateprofilelogmaxfilesize
[CSP-13]: /windows/client-management/mdm/firewall-csp#mdmstorepublicprofilelogmaxfilesize

94
windows/security/operating-system-security/network-security/windows-firewall/configure-the-windows-firewall-log.md
View File

@ -1,94 +0,0 @@
---
title: Configure the Windows Defender Firewall Log
description: Learn how to configure Windows Defender Firewall with Advanced Security to log dropped packets or successful connections by using Group Policy Management MMC.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Configure the Windows Defender Firewall with Advanced Security Log
To configure Windows Defender Firewall with Advanced Security to log dropped packets or successful connections, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management MMC snap-in.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
## To configure the Windows Defender Firewall with Advanced Security log
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the details pane, in the **Overview** section, click **Windows Defender Firewall Properties**.
3. For each network location type (Domain, Private, Public), perform the following steps.
1. Click the tab that corresponds to the network location type.
2. Under **Logging**, click **Customize**.
3. The default path for the log is **%windir%\\system32\\logfiles\\firewall\\pfirewall.log**. If you want to change this path, clear the **Not configured** check box and type the path to the new location, or click **Browse** to select a file location.
> [!IMPORTANT]
> The location you specify must have permissions assigned that permit the Windows Defender Firewall service to write to the log file.
5. The default maximum file size for the log is 4,096 kilobytes (KB). If you want to change this size, clear the **Not configured** check box, and type in the new size in KB, or use the up and down arrows to select a size. The file won't grow beyond this size; when the limit is reached, old log entries are deleted to make room for the newly created ones.
6. No logging occurs until you set one of following two options:
- To create a log entry when Windows Defender Firewall drops an incoming network packet, change **Log dropped packets** to **Yes**.
- To create a log entry when Windows Defender Firewall allows an inbound connection, change **Log successful connections** to **Yes**.
7. Click **OK** twice.
### Troubleshoot if the log file is not created or modified
Sometimes the Windows Firewall log files aren't created, or the events aren't written to the log files. Some examples when this condition might occur include:
- missing permissions for the Windows Defender Firewall Service (MpsSvc) on the folder or on the log files
- you want to store the log files in a different folder and the permissions were removed, or haven't been set automatically
- if firewall logging is configured via policy settings, it can happen that
- the log folder in the default location `%windir%\System32\LogFiles\firewall` doesn't exist
- the log folder in a custom path doesn't exist
In both cases, you must create the folder manually or via script, and add the permissions for MpsSvc
If firewall logging is configured via Group Policy only, it also can happen that the `firewall` folder is not created in the default location `%windir%\System32\LogFiles\`. The same can happen if a custom path to a non-existent folder is configured via Group Policy. In this case, create the folder manually or via script and add the permissions for MPSSVC.
```PowerShell
New-Item -ItemType Directory -Path $env:windir\System32\LogFiles\Firewall
```
Verify if MpsSvc has *FullControl* on the folder and the files.
From an elevated PowerShell session, use the following commands, ensuring to use the correct path:
```PowerShell
$LogPath = Join-Path -path $env:windir -ChildPath "System32\LogFiles\Firewall"
(Get-ACL -Path $LogPath).Access | Format-Table IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -AutoSize
```
The output should show `NT SERVICE\mpssvc` having *FullControl*:
```PowerShell
IdentityReference FileSystemRights AccessControlType IsInherited InheritanceFlags
----------------- ---------------- ----------------- ----------- ----------------
NT AUTHORITY\SYSTEM FullControl Allow False ObjectInherit
BUILTIN\Administrators FullControl Allow False ObjectInherit
NT SERVICE\mpssvc FullControl Allow False ObjectInherit
```
If not, add *FullControl* permissions for mpssvc to the folder, subfolders and files. Make sure to use the correct path.
```PowerShell
$LogPath = Join-Path -path $env:windir -ChildPath "System32\LogFiles\Firewall"
$ACL = get-acl -Path $LogPath
$ACL.SetAccessRuleProtection($true, $false)
$RULE = New-Object System.Security.AccessControl.FileSystemAccessRule ("NT SERVICE\mpssvc","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$ACL.AddAccessRule($RULE)
```
Restart the device to restart the Windows Defender Firewall Service.
### Troubleshoot Slow Log Ingestion
If logs are slow to appear in Sentinel, you can turn down the log file size. Just beware that this downsizing will result in more resource usage due to the increased resource usage for log rotation.

581
windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security-administration-with-windows-powershell.md → windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line.md
View File

@ -1,114 +1,86 @@
---
title: Windows Defender Firewall with Advanced Security Administration with Windows PowerShell
description: Windows Defender Firewall with Advanced Security Administration with Windows PowerShell
ms.prod: windows-client
title: Manage Windows Firewall with the command line
description: Learn how to manage Windows Firewall from the command line. This guide provides examples how to manage Windows Firewall with PowerShell and Netsh.
ms.topic: conceptual
ms.date: 09/08/2021
ms.date: 11/21/2023
---
# Windows Defender Firewall with Advanced Security Administration with Windows PowerShell
# Manage Windows Firewall with the command line
This article provides examples how to manage Windows Firewall with PowerShell and `netsh.exe`, which can be used to automate the management of Windows Firewall.
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.
## Set profile global defaults
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.
Global defaults set the device behavior in a per-profile basis. Windows Firewall supports Domain, Private, and Public profiles.
In future versions of Windows, Microsoft might remove the netsh functionality for Windows Defender Firewall. Microsoft recommends that you transition to Windows PowerShell if you currently use netsh to configure and manage Windows Defender 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:
Windows PowerShell and netsh command references are at the following locations.
- [Netsh Commands for Windows Defender Firewall](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc771920(v=ws.10))
## Scope
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're familiar with Windows Defender Firewall, the Windows PowerShell language, and the basic concepts of Windows PowerShell.
## In this topic
| Section | Description |
| - | - |
| [Set profile global defaults](#bkmk-profileglobaldefaults) | Enable and control firewall behavior|
| [Deploy basic firewall rules](#deploy-basic-firewall-rules)| How to create, modify, and delete firewall rules|
| [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|
| [Other resources](#other-resources) | More information about Windows PowerShell|
## <a href="" id="bkmk-profileglobaldefaults"></a>Set profile global defaults
Global defaults set the device behavior in a per-profile basis. Windows Defender Firewall supports Domain, Private, and Public profiles.
### Enable Windows Defender Firewall with Advanced Security
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**
``` syntax
netsh advfirewall set allprofiles state on
```
**Windows PowerShell**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
```powershell
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
```
### Control Windows Defender Firewall with Advanced Security behavior
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
The global default settings can be defined through the command-line interface. These modifications are also available through the Windows Defender Firewall with Advanced Security console.
``` cmd
netsh.exe advfirewall set allprofiles state on
```
---
### Control Windows Firewall behavior
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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```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)
```cmd
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound
netsh advfirewall set allprofiles settings inboundusernotification enable
netsh advfirewall set allprofiles settings unicastresponsetomulticast enable
netsh advfirewall set allprofiles logging filename %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
```
Windows PowerShell
---
```powershell
Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow –NotifyOnListen True -AllowUnicastResponseToMulticast True –LogFileName %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
```
### Disable Windows Firewall
### Disable Windows Defender Firewall with Advanced Security
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:
Microsoft recommends that you don't disable Windows 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 Firewall can also cause problems, including:
- Start menu can stop working
- Modern applications can fail to install or update
- Activation of Windows via phone fails
- Application or OS incompatibilities that depend on Windows Defender Firewall
- Application or OS incompatibilities that depend on Windows Firewall
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, 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.
Microsoft recommends disabling Windows Firewall only when installing a third-party firewall, and resetting Windows Firewall back to defaults when the third-party software is disabled or removed.
If disabling Windows Firewall is required, don't disable it by stopping the Windows Firewall service (in the **Services** snap-in, the display name is Windows Firewall and the service name is MpsSvc).
Stopping the Windows Firewall service isn't supported by Microsoft.
Non-Microsoft firewall software can programmatically disable only the parts of Windows Firewall that need to be disabled for compatibility.
You shouldn't disable the firewall yourself for this purpose.
The proper method to disable the Windows Firewall is to disable the Windows Firewall Profiles and leave the service running.
Use the following procedure to turn off the firewall, or disable the Group Policy setting **Computer Configuration|Administrative Templates|Network|Network Connections|Windows Firewall|Domain Prolfile|Windows Firewall:Protect all network connections**.
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.
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 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.
# [:::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)
---
## Deploy basic firewall rules
This section provides scriptlet examples for creating, modifying, and deleting firewall rules.
@ -116,50 +88,49 @@ This section provides scriptlet examples for creating, modifying, and deleting f
### Create firewall rules
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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```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)
``` cmd
netsh advfirewall firewall add rule name="Allow Inbound Telnet" dir=in program= %SystemRoot%\System32\tlntsvr.exe remoteip=localsubnet action=allow
```
Windows PowerShell
```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 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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```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)
``` cmd
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
netsh advfirewall firewall add rule name="Block Outbound Telnet" dir=out program=%SystemRoot%\System32\telnet.exe protocol=tcp localport=23 action=block
```
Windows 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
```
---
### GPO Caching
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 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
```powershell
$gpo = Open-NetGPO –PolicyStore domain.contoso.com\gpo_name
New-NetFirewallRule -DisplayName “Block Outbound Telnet” -Direction Outbound -Program %SystemRoot%\System32\telnet.exe –Protocol TCP –LocalPort 23 -Action Block –GPOSession $gpo
Save-NetGPO –GPOSession $gpo
$gpo = Open-NetGPO -PolicyStore domain.contoso.com\gpo_name
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\telnet.exe -Protocol TCP -LocalPort 23 -Action Block -GPOSession $gpo
Save-NetGPO -GPOSession $gpo
```
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.
@ -167,120 +138,105 @@ This command doesn't batch your individual changes, it loads and saves the entir
### 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 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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```powershell
Set-NetFirewallRule -DisplayName "Allow Web 80" -RemoteAddress 192.168.0.2
```
# [:::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
```
Windows PowerShell
```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 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 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 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.
Windows PowerShell
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.
```powershell
Get-NetFirewallPortFilter | ?{$_.LocalPort -eq 80} | Get-NetFirewallRule | ?{ $_.Direction –eq “Inbound” -and $_.Action –eq “Allow”} | Set-NetFirewallRule -RemoteAddress 192.168.0.2
Get-NetFirewallPortFilter | ?{$_.LocalPort -eq 80} | Get-NetFirewallRule | ?{ $_.Direction -eq "Inbound" -and $_.Action -eq "Allow"} | Set-NetFirewallRule -RemoteAddress 192.168.0.2
```
You can also query for rules using the wildcard character. The following example returns an array of firewall rules associated with a particular program. The elements of the array can be modified in subsequent `Set-NetFirewallRule` cmdlets.
Windows PowerShell
```powershell
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 isn't possible in Netsh.
Windows PowerShell
```powershell
New-NetFirewallRule -DisplayName “Allow Inbound Telnet” -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow –Group “Telnet Management”
New-NetFirewallRule -DisplayName “Block Outbound Telnet” -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow –Group “Telnet Management”
New-NetFirewallRule -DisplayName "Allow Inbound Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow -Group "Telnet Management"
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow -Group "Telnet Management"
```
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
```powershell
$rule = Get-NetFirewallRule -DisplayName “Allow Inbound Telnet”
$rule.Group = “Telnet Management”
$rule = Get-NetFirewallRule -DisplayName "Allow Inbound Telnet"
$rule.Group = "Telnet Management"
$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.
**Netsh**
``` syntax
netsh advfirewall firewall set rule group="Windows Defender Firewall remote management" new enable=yes
```
Windows PowerShell
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
```powershell
Set-NetFirewallRule -DisplayGroup “Windows Defender Firewall Remote Management” –Enabled True
Set-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Enabled True
```
# [:::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
```
---
There's also a separate `Enable-NetFirewallRule` cmdlet for enabling rules by group or by other properties of the rule.
Windows PowerShell
```powershell
Enable-NetFirewallRule -DisplayGroup “Windows Defender Firewall Remote Management” -Verbose
Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Verbose
```
### Delete a firewall rule
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.
**Netsh**
``` syntax
netsh advfirewall firewall delete rule name=“Allow Web 80”
```
Windows PowerShell
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
```powershell
Remove-NetFirewallRule –DisplayName “Allow Web 80”
Remove-NetFirewallRule -DisplayName "Allow Web 80"
```
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
``` cmd
netsh advfirewall firewall delete rule name="Allow Web 80"
```
---
Like with other cmdlets, you can also query for rules to be removed. Here, all blocking firewall rules are deleted from the device.
Windows PowerShell
```powershell
Remove-NetFirewallRule –Action Block
Remove-NetFirewallRule -Action Block
```
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
```powershell
$x = Get-NetFirewallRule –Action Block
$x = Get-NetFirewallRule -Action Block
$x
$x[0-3] | Remove-NetFirewallRule
```
@ -288,86 +244,76 @@ $x[0-3] | Remove-NetFirewallRule
## Manage remotely
Remote management using WinRM is enabled by default. The cmdlets that support the *CimSession* parameter use WinRM and can be managed remotely by default.
The following example returns all firewall rules of the persistent store on a device named **RemoteDevice**.
Windows PowerShell
```powershell
Get-NetFirewallRule –CimSession RemoteDevice
Get-NetFirewallRule -CimSession RemoteDevice
```
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
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.
```powershell
$RemoteSession = New-CimSession –ComputerName RemoteDevice
Remove-NetFirewallRule –DisplayName “AllowWeb80” –CimSession $RemoteSession -Confirm
$RemoteSession = New-CimSession -ComputerName RemoteDevice
Remove-NetFirewallRule -DisplayName "AllowWeb80" -CimSession $RemoteSession -Confirm
```
## Deploy basic IPsec rule settings
An Internet Protocol security (IPsec) policy consists of rules that determine IPsec behavior. IPsec supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Windows PowerShell can create powerful, complex IPsec policies like in Netsh and the Windows Defender Firewall with Advanced Security console. However, because Windows PowerShell is object-based rather than string token-based, configuration in Windows PowerShell offers greater control and flexibility.
Windows PowerShell can create powerful, complex IPsec policies like in Netsh and the Windows Firewall console. However, because Windows PowerShell is object-based rather than string token-based, configuration in Windows PowerShell offers greater control and flexibility.
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.
![object model for creating a single ipsec rule.](images/createipsecrule.gif)
### Create IPsec rules
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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```powershell
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -PolicyStore domain.contoso.com\gpo_name
```
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
``` cmd
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
netsh advfirewall consec add rule name="Require Inbound Authentication" endpoint1=any endpoint2=any action=requireinrequestout
```
Windows PowerShell
```powershell
New-NetIPsecRule -DisplayName “Require Inbound Authentication” -PolicyStore domain.contoso.com\gpo_name
```
---
### Add custom authentication methods to an IPsec rule
If you want to create a custom set of quick-mode proposals that includes both AH and ESP in an IPsec rule object, you create the associated objects separately and link their associations. For more information about authentication methods, see [Choosing the IPsec Protocol](/previous-versions/windows/it-pro/windows-server-2003/cc757847(v=ws.10)) .
If you want to create a custom set of quick-mode proposals that includes both AH and ESP in an IPsec rule object, you create the associated objects separately and link their associations. For more information about authentication methods, see [Choosing the IPsec Protocol](/previous-versions/windows/it-pro/windows-server-2003/cc757847(v=ws.10)).
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.
![crypto set object.](images/qmcryptoset.gif)
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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```powershell
$AHandESPQM = New-NetIPsecQuickModeCryptoProposal -Encapsulation AH,ESP -AHHash SHA1 -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "ah:sha1+esp:sha1-des3" -Proposal $AHandESPQM -PolicyStore domain.contoso.com\gpo_name
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)
``` cmd
netsh advfirewall set store gpo=domain.contoso.com\gpo_name
netsh advfirewall consec add rule name="Require Outbound Authentication" endpoint1=any endpoint2=any action=requireinrequestout qmsecmethods=ah:sha1+esp:sha1-3des
```
Windows PowerShell
```powershell
$AHandESPQM = New-NetIPsecQuickModeCryptoProposal -Encapsulation AH,ESP –AHHash SHA1 -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet –DisplayName “ah:sha1+esp:sha1-des3” -Proposal $AHandESPQM –PolicyStore domain.contoso.com\gpo_name
New-NetIPsecRule -DisplayName “Require Inbound Authentication” -InboundSecurity Require -OutboundSecurity Request -QuickModeCryptoSet $QMCryptoSet.Name –PolicyStore domain.contoso.com\gpo_name
```
---
### IKEv2 IPsec transport rules
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 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
```powershell
New-NetIPsecRule -DisplayName “Require Inbound Authentication” -InboundSecurity Require -OutboundSecurity Request –Phase1AuthSet MyCertAuthSet -KeyModule IKEv2 –RemoteAddress $nonWindowsGateway
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -InboundSecurity Require -OutboundSecurity Request -Phase1AuthSet MyCertAuthSet -KeyModule IKEv2 -RemoteAddress $nonWindowsGateway
```
For more info about IKEv2, including scenarios, see [Securing End-to-End IPsec Connections by Using IKEv2](securing-end-to-end-ipsec-connections-by-using-ikev2.md).
@ -375,105 +321,90 @@ For more info about IKEv2, including scenarios, see [Securing End-to-End IPsec C
### Copy an IPsec rule from one policy to another
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 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 isn't possible through the Netsh interface. Here's how you can accomplish it with Windows PowerShell.
Windows PowerShell
```powershell
$Rule = Get-NetIPsecRule –DisplayName “Require Inbound Authentication”
$Rule | Copy-NetIPsecRule –NewPolicyStore domain.costoso.com\new_gpo_name
$Rule | Copy-NetPhase1AuthSet –NewPolicyStore domain.costoso.com\new_gpo_name
$Rule = Get-NetIPsecRule -DisplayName "Require Inbound Authentication"
$Rule | Copy-NetIPsecRule -NewPolicyStore domain.costoso.com\new_gpo_name
$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 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
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.
```powershell
Remove-NetFirewallRule –DisplayName “Contoso Messenger 98” –ErrorAction SilentlyContinue
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98" -ErrorAction SilentlyContinue
```
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
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.
```powershell
Remove-NetFirewallRule –DisplayName “Contoso Messenger 98*”
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*"
```
When using wildcards, if you want to double-check the set of rules that is matched, you can use the *–WhatIf* parameter.
Windows PowerShell
When using wildcards, if you want to double-check the set of rules that is matched, you can use the *-WhatIf* parameter.
```powershell
Remove-NetFirewallRule –DisplayName “Contoso Messenger 98*” –WhatIf
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -WhatIf
```
If you only want to delete some of the matched rules, you can use the *–Confirm* parameter to get a rule-by-rule confirmation prompt.
Windows PowerShell
If you only want to delete some of the matched rules, you can use the *-Confirm* parameter to get a rule-by-rule confirmation prompt.
```powershell
Remove-NetFirewallRule –DisplayName “Contoso Messenger 98*” –Confirm
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -Confirm
```
You can also just perform the whole operation, displaying the name of each rule as the operation is performed.
Windows PowerShell
```powershell
Remove-NetFirewallRule –DisplayName “Contoso Messenger 98*” –Verbose
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -Verbose
```
### Monitor
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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```powershell
Show-NetIPsecRule -PolicyStore ActiveStore
```
# [:::image type="icon" source="images/cmd.svg"::: **Command Prompt**](#tab/cmd)
``` cmd
netsh advfirewall consec show rule name=all
```
Windows PowerShell
```powershell
Show-NetIPsecRule –PolicyStore ActiveStore
```
---
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:
**Netsh**
``` syntax
netsh advfirewall monitor show mmsa all
```
Windows 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)
``` cmd
netsh advfirewall monitor show mmsa all
```
---
### 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 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.
Windows PowerShell
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.
```powershell
Get-NetIPsecRule –DisplayName “Require Inbound Authentication” –TracePolicyStore
Get-NetIPsecRule -DisplayName "Require Inbound Authentication" -TracePolicyStore
```
It's important to note that the revealed sources don't contain a domain name.
@ -481,146 +412,140 @@ 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 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**
``` syntax
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
netsh advfirewall consec add rule name=“Basic Domain Isolation Policy” profile=domain endpoint1=”any” endpoint2=”any” action=requireinrequestout auth1=”computerkerb”
```
Windows PowerShell
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
```powershell
$kerbprop = New-NetIPsecAuthProposal –Machine –Kerberos
$Phase1AuthSet = New-NetIPsecPhase1AuthSet -DisplayName "Kerberos Auth Phase1" -Proposal $kerbprop –PolicyStore domain.contoso.com\domain_isolation
New-NetIPsecRule –DisplayName “Basic Domain Isolation Policy” –Profile Domain –Phase1AuthSet $Phase1AuthSet.Name –InboundSecurity Require –OutboundSecurity Request –PolicyStore domain.contoso.com\domain_isolation
$kerbprop = New-NetIPsecAuthProposal -Machine -Kerberos
$Phase1AuthSet = New-NetIPsecPhase1AuthSet -DisplayName "Kerberos Auth Phase1" -Proposal $kerbprop -PolicyStore domain.contoso.com\domain_isolation
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)
``` cmd
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
netsh advfirewall consec add rule name="Basic Domain Isolation Policy" profile=domain endpoint1="any" endpoint2="any" action=requireinrequestout auth1="computerkerb"
```
---
### 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's encrypted by using ESP/DES3.
**Netsh**
``` syntax
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
```
Windows PowerShell
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
```powershell
$QMProposal = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet –DisplayName “esp:sha1-des3” -Proposal $QMProposal
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
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "esp:sha1-des3" -Proposal $QMProposal
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)
``` 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
```
---
## Deploy secure firewall rules with IPsec
In situations where only secure traffic can be allowed through the Windows Defender Firewall, a combination of manually configured firewall and IPsec rules are necessary. The firewall rules determine the level of security for allowed packets, and the underlying IPsec rules secure the traffic. The scenarios can be accomplished in Windows PowerShell and in Netsh, with many similarities in deployment.
In situations where only secure traffic can be allowed through the Windows Firewall, a combination of manually configured firewall and IPsec rules are necessary. The firewall rules determine the level of security for allowed packets, and the underlying IPsec rules secure the traffic. The scenarios can be accomplished in Windows PowerShell and in Netsh, with many similarities in deployment.
### Create a secure firewall rule (allow if secure)
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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```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)
``` cmd
netsh advfirewall firewall add rule name="Allow Authenticated Telnet" dir=in program=%SystemRoot%\System32\tlntsvr.exe security=authenticate action=allow
```
Windows PowerShell
```powershell
New-NetFirewallRule -DisplayName “Allow Authenticated Telnet” -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -Authentication Required -Action Allow
```
---
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.
**Netsh**
``` syntax
netsh advfirewall consec add rule name="Authenticate Both Computer and User" endpoint1=any endpoint2=any action=requireinrequireout auth1=computerkerb,computerntlm auth2=userkerb,userntlm,anonymous
```
Windows PowerShell
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
```powershell
$mkerbauthprop = New-NetIPsecAuthProposal -Machine –Kerberos
$mkerbauthprop = New-NetIPsecAuthProposal -Machine -Kerberos
$mntlmauthprop = New-NetIPsecAuthProposal -Machine -NTLM
$P1Auth = New-NetIPsecPhase1AuthSet -DisplayName “Machine Auth” –Proposal $mkerbauthprop,$mntlmauthprop
$P1Auth = New-NetIPsecPhase1AuthSet -DisplayName "Machine Auth" -Proposal $mkerbauthprop,$mntlmauthprop
$ukerbauthprop = New-NetIPsecAuthProposal -User -Kerberos
$unentlmauthprop = New-NetIPsecAuthProposal -User -NTLM
$anonyauthprop = New-NetIPsecAuthProposal -Anonymous
$P2Auth = New-NetIPsecPhase2AuthSet -DisplayName “User Auth” -Proposal $ukerbauthprop,$unentlmauthprop,$anonyauthprop
New-NetIPSecRule -DisplayName “Authenticate Both Computer and User” -InboundSecurity Require -OutboundSecurity Require -Phase1AuthSet $P1Auth.Name –Phase2AuthSet $P2Auth.Name
$P2Auth = New-NetIPsecPhase2AuthSet -DisplayName "User Auth" -Proposal $ukerbauthprop,$unentlmauthprop,$anonyauthprop
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)
``` 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
```
---
### Isolate a server by requiring encryption and group membership
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 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
To deploy server isolation, we layer a firewall rule that restricts traffic to authorized users or devices on the IPsec rule that enforces authentication.
The following firewall rule allows Telnet traffic from user accounts that are members of a custom group called “Authorized to Access Server.” This access can additionally be restricted based on the device, user, or both by specifying the restriction parameters.
A Security Descriptor Definition Language (SDDL) string is created by extending a user or group’s security identifier (SID). For more information about finding a group’s SID, see: [Finding the SID for a group account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)#bkmk_FINDSID).
Restricting access to a group allows administrations to extend strong authentication support through Windows Defender Firewall and/or IPsec policies.
The following firewall rule allows Telnet traffic from user accounts that are members of a custom group called "Authorized to Access Server." This access can additionally be restricted based on the device, user, or both by specifying the restriction parameters.
A Security Descriptor Definition Language (SDDL) string is created by extending a user or group's security identifier (SID). For more information about finding a group's SID, see: [Finding the SID for a group account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753463(v=ws.10)#bkmk_FINDSID).
Restricting access to a group allows administrations to extend strong authentication support through Windows Firewall and/or IPsec policies.
The following example shows you how to create an SDDL string that represents security groups.
Windows PowerShell
```powershell
$user = new-object System.Security.Principal.NTAccount (“corp.contoso.com\Administrators”)
$user = new-object System.Security.Principal.NTAccount ("corp.contoso.com\Administrators")
$SIDofSecureUserGroup = $user.Translate([System.Security.Principal.SecurityIdentifier]).Value
$secureUserGroup = "D:(A;;CC;;;$SIDofSecureUserGroup)"
```
By using the previous scriptlet, you can also get the SDDL string for a secure computer group as shown here:
Windows PowerShell
```powershell
$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 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.
**Netsh**
``` syntax
netsh advfirewall set store gpo=domain.contoso.com\Server_Isolation
netsh advfirewall firewall add rule name=“Allow Encrypted Inbound Telnet to Group Members Only” program=%SystemRoot%\System32\tlntsvr.exe protocol=TCP dir=in action=allow localport=23 security=authenc rmtusrgrp ="D:(A;;CC;;; S-1-5-21-2329867823-2610410949-1491576313-1735)"
```
Windows 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
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)
``` cmd
netsh advfirewall set store gpo=domain.contoso.com\Server_Isolation
netsh advfirewall firewall add rule name="Allow Encrypted Inbound Telnet to Group Members Only" program=%SystemRoot%\System32\tlntsvr.exe protocol=TCP dir=in action=allow localport=23 security=authenc rmtusrgrp ="D:(A;;CC;;; S-1-5-21-2329867823-2610410949-1491576313-1735)"
```
---
### Endpoint security enforcement
The previous example showed end to end security for a particular application. In situations where endpoint security is required for many applications, having a firewall rule per application can be cumbersome and difficult to manage. Authorization can override the per-rule basis and be done at the IPsec layer.
In this example, we set the global IPsec setting to only allow transport mode traffic to come from an authorized user group with the following cmdlet. Consult the previous examples for working with security groups.
Windows PowerShell
```powershell
Set-NetFirewallSetting -RemoteMachineTransportAuthorizationList $secureMachineGroup
```
@ -628,59 +553,19 @@ 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 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.
**Netsh**
# [:::image type="icon" source="images/powershell.svg"::: **PowerShell**](#tab/powershell)
``` syntax
```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)
``` cmd
netsh advfirewall set store gpo=domain.contoso.com\domain_isolation
netsh advfirewall firewall add rule name="Inbound Secure Bypass Rule" dir=in security=authenticate action="bypass" rmtcomputergrp="D:(A;;CC;;;S-1-5-21-2329867823-2610410949-1491576313-1114)" rmtusrgrp="D:(A;;CC;;; S-1-5-21-2329867823-2610410949-1491576313-1735)"
```
Windows 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
```
## Other resources
For more information about Windows PowerShell concepts, see the following topics.
- [Windows PowerShell Getting Started Guide](/powershell/scripting/overview)
- [Windows PowerShell User Guide](/powershell/scripting/overview)
- [Windows PowerShell About Help Topics](https://go.microsoft.com/fwlink/p/?linkid=113206)
- [about\_Functions](/powershell/module/microsoft.powershell.core/about/about_functions)
- [about\_Functions\_Advanced](/powershell/module/microsoft.powershell.core/about/about_functions_advanced)
- [about\_Execution\_Policies](/powershell/module/microsoft.powershell.core/about/about_execution_policies)
- [about\_Foreach](/powershell/module/microsoft.powershell.core/about/about_foreach)
- [about\_Objects](/powershell/module/microsoft.powershell.core/about/about_objects)
- [about\_Properties](/powershell/module/microsoft.powershell.core/about/about_properties)
- [about\_While](/powershell/module/microsoft.powershell.core/about/about_while)
- [about\_Scripts](/powershell/module/microsoft.powershell.core/about/about_scripts)
- [about\_Signing](/powershell/module/microsoft.powershell.core/about/about_signing)
- [about\_Throw](/powershell/module/microsoft.powershell.core/about/about_throw)
- [about\_PSSessions](/powershell/module/microsoft.powershell.core/about/about_pssessions)
- [about\_Modules](/powershell/module/microsoft.powershell.core/about/about_modules)
- [about\_Command\_Precedence](/powershell/module/microsoft.powershell.core/about/about_command_precedence)
 
 
---

178
windows/security/operating-system-security/network-security/windows-firewall/configure.md Normal file
View File

@ -0,0 +1,178 @@
---
title: Configure firewall rules with group policy
description: Learn how to configure firewall rules using group policy with the Windows Firewall with Advanced Security console.
ms.topic: how-to
ms.date: 11/21/2023
---
# Configure rules with group policy
This article contains examples how to configure Windows Firewall rules using the *Windows Firewall with Advanced Security* console.
## Access the Windows Firewall with Advanced Security console
If you're configuring devices joined to an Active Directory domain, to complete these procedures you must be a member of the Domain Administrators group, or otherwise have delegated permissions to modify the GPOs in the domain. To access the *Windows Firewall with Advanced Security* console, [create or edit](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc754740(v=ws.11)) a group policy object (GPO) and expand the nodes **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Windows Firewall with Advanced Security**.
If you are configuring a single device, you must have administrative rights on the device. In which case, to access the *Windows Firewall with Advanced Security* console, select <kbd>START</kbd>, type `wf.msc`, and press <kbd>ENTER</kbd>.
## Create an inbound ICMP rule
This type of rule allows ICMP requests and responses to be received by devices on the network. To create an inbound ICMP rule:
1. Open the *Windows Firewall with Advanced Security* console
1. In the navigation pane, select **Inbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Inbound Rule Wizard, select **Custom**, and then select **Next**
1. On the **Program** page, select **All programs**, and then select **Next**
1. On the **Protocol and Ports** page, select **ICMPv4** or **ICMPv6** from the **Protocol type** list. If you use both IPv4 and IPv6 on your network, you must create a separate ICMP rule for each
1. Select **Customize**
1. In the **Customize ICMP Settings** dialog box, do one of the following:
- To allow all ICMP network traffic, select **All ICMP types**, and then select **OK**
- To select one of the predefined ICMP types, select **Specific ICMP types**, and then select each type in the list that you want to allow. Select **OK**
- To select an ICMP type that does not appear in the list, select **Specific ICMP types**, select the **Type** number from the list, select the **Code** number from the list, select **Add**, and then select the newly created entry from the list. Select **OK**
1. Select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Allow the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
## Create an inbound port rule
This type of rule allows any program that listens on a specified TCP or UDP port to receive network traffic sent to that port. To create an inbound port rule:
1. Open the *Windows Firewall with Advanced Security* console
1. In the navigation pane, select **Inbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Inbound Rule Wizard, select **Custom**, and then select **Next**
> [!NOTE]
> Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
1. On the **Program** page, select **All programs**, and then select **Next**
> [!NOTE]
> This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The specified program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. If you choose to do this, follow the steps in the [Create an Inbound Program or Service Rule](#create-an-inbound-program-or-service-rule) procedure in addition to the steps in this procedure to create a single rule that filters network traffic using both program and port criteria.
1. On the **Protocol and Ports** page, select the protocol type that you want to allow. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this is an incoming rule, you typically configure only the local port number
If you select another protocol, then only packets whose protocol field in the IP header match this rule are permitted through the firewall.\
To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box.\
When you have configured the protocols and ports, select **Next**.
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Allow the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
> [!NOTE]
> If this GPO is targeted at server computers running Windows Server 2008 that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card's cable. A disconnected network card is automatically assigned to the Public network location type.
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
## Create an outbound port rule
By default, Windows Firewall allows all outbound network traffic, unless it matches a rule that prohibits the traffic. This type of rule blocks any outbound network traffic that matches the specified TCP or UDP port numbers. To create an outbound port rule:
1. Open the *Windows Firewall with Advanced Security* console
1. In the navigation pane, select **Outbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Outbound Rule wizard, select **Custom**, and then select **Next**
> [!NOTE]
> Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
1. On the **Program** page, select **All programs**, and then select **Next**
1. On the **Protocol and Ports** page, select the protocol type that you want to block. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this rule is an outbound rule, you typically configure only the remote port number
If you select another protocol, then only packets whose protocol field in the IP header matches this rule are blocked by Windows Defender Firewall. Network traffic for protocols is allowed as long as other rules that match don't block it. To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box. When you've configured the protocols and ports, select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Block the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
## Create an inbound program or service rule
This type of rule allows the program to listen and receive inbound network traffic on any port.
> [!NOTE]
> This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. To combine the program and port rule types into a single rule, follow the steps in the [Create an Inbound Port Rule](#create-an-inbound-port-rule) procedure in addition to the steps in this procedure.
To create an inbound firewall rule for a program or service:
1. Open the *Windows Firewall with Advanced Security* console
1. In the navigation pane, select **Inbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Inbound Rule Wizard, select **Custom**, and then select **Next**
> [!NOTE]
> Information the user should notice even if skimmingAlthough you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
1. On the **Program** page, select **This program path**
1. Type the path to the program in the text box. Use environment variables, where applicable, to ensure that programs installed in different locations on different computers work correctly.
1. Do one of the following:
- If the executable file contains a single program, select **Next**
- If the executable file is a container for multiple services that must all be allowed to receive inbound network traffic, select **Customize**, select **Apply to services only**, select **OK**, and then select **Next**
- If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, select **Customize**, select **Apply to this service**, and then select the service from the list. If the service does not appear in the list, select **Apply to service with this service short name**, and then type the short name for the service in the text box. Select **OK**, and then select **Next**
> [!IMPORTANT]
> To use the **Apply to this service** or **Apply to service with this service short name** options, the service must be configured with a security identifier (SID) with a type of **RESTRICTED** or **UNRESTRICTED**. To check the SID type of a service, run the following command: `sc qsidtype <ServiceName>`
>
> If the result is `NONE`, then a firewall rule cannot be applied to that service.
To set a SID type on a service, run the following command: `sc sidtype <ServiceName> <Type>`
In the preceding command, the value of `<Type>` can be `UNRESTRICTED` or `RESTRICTED`. Although the command also permits the value of `NONE`, that setting means the service cannot be used in a firewall rule as described here. By default, most services in Windows are configured as `UNRESTRICTED`. If you change the SID type to `RESTRICTED`, the service might fail to start. We recommend that you change the SID type only on services that you want to use in firewall rules, and that you change the SID type to `UNRESTRICTED`.
1. It is a best practice to restrict the firewall rule for the program to only the ports it needs to operate. On the **Protocols and Ports** page, you can specify the port numbers for the allowed traffic. If the program tries to listen on a port different from the one specified here, it is blocked. For more information about protocol and port options, see [Create an Inbound Port Rule](#create-an-inbound-port-rule). After you have configured the protocol and port options, select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Allow the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
## Create an outbound program or service rule
By default, Windows Defender Firewall allows all outbound network traffic unless it matches a rule that prohibits the traffic. This type of rule prevents the program from sending any outbound network traffic on any port. To create an outbound firewall rule for a program or service:
1. Open the *Windows Firewall with Advanced Security* console
1. In the navigation pane, select **Outbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Outbound Rule Wizard, select **Custom**, and then select **Next**
> [!NOTE]
> Although you can create many rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
1. On the **Program** page, select **This program path**
1. Type the path to the program in the text box. Use environment variables as appropriate to ensure that programs installed in different locations on different computers work correctly
1. Do one of the following:
- If the executable file contains a single program, select **Next**
- If the executable file is a container for multiple services that must all be blocked from sending outbound network traffic, select **Customize**, select **Apply to services only**, select **OK**, and then select **Next**
- If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, select **Customize**, select **Apply to this service**, and then select the service from the list. If the service does not appear in the list, then select **Apply to service with this service short name**, and type the short name for the service in the text box. Select **OK**, and then select **Next**
1. If you want the program to be allowed to send on some ports, but blocked from sending on others, then you can restrict the firewall rule to block only the specified ports or protocols. On the **Protocols and Ports** page, you can specify the port numbers or protocol numbers for the blocked traffic. If the program tries to send to or from a port number different from the one specified here, or by using a protocol number different from the one specified here, then the default outbound firewall behavior allows the traffic. For more information about the protocol and port options, see [Create an Outbound Port Rule](#create-an-outbound-port-rule). When you have configured the protocol and port options, select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Block the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
## Create inbound rules to support RPC
To allow inbound remote procedure call (RPC) network traffic, you must create two firewall rules:
- the first rule allows incoming network packets on TCP port 135 to the RPC Endpoint Mapper service. The incoming traffic consists of requests to communicate with a specified network service. The RPC Endpoint Mapper replies with a dynamically assigned port number that the client must use to communicate with the service
- the second rule allows the network traffic that is sent to the dynamically assigned port number
Using the two rules configured as described in this topic helps to protect your device by allowing network traffic only from devices that have received RPC dynamic port redirection and to only those TCP port numbers assigned by the RPC Endpoint Mapper.
### RPC Endpoint Mapper service
1. Open the *Windows Firewall with Advanced Security* console
1. In the navigation pane, select **Inbound Rules**
1. Select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Inbound Rule Wizard, select **Custom**, and then select **Next**
1. On the **Program** page, select **This Program Path**, and then type `%systemroot%\system32\svchost.exe`
1. Select **Customize**.
1. In the **Customize Service Settings** dialog box, select **Apply to this service**, select **Remote Procedure Call (RPC)** with a short name of **RpcSs**, select **OK**, and then select **Next**
1. On the warning about Windows service-hardening rules, select **Yes**
1. On the **Protocol and Ports** dialog box, for **Protocol type**, select **TCP**
1. For **Local port**, select **RPC Endpoint Mapper**, and then select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Allow the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**
### RPC-enabled network services
1. On the same GPO you edited in the preceding procedure, select **Action**, and then select **New rule**
1. On the **Rule Type** page of the New Inbound Rule Wizard, select **Custom**, and then select **Next**
1. On the **Program** page, select **This Program Path**, and then type the path to the executable file that hosts the network service. Select **Customize**
1. In the **Customize Service Settings** dialog box, select **Apply to this service**, and then select the service that you want to allow. If the service doesn't appear in the list, then select **Apply to service with this service short name**, and then type the short name of the service in the text box
1. Select **OK**, and then select **Next**
1. On the **Protocol and Ports** dialog box, for **Protocol type**, select **TCP**
1. For **Local port**, select **RPC Dynamic Ports**, and then select **Next**
1. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then select **Next**
1. On the **Action** page, select **Allow the connection**, and then select **Next**
1. On the **Profile** page, select the network location types to which this rule applies, and then select **Next**
1. On the **Name** page, type a name and description for your rule, and then select **Finish**

56
windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-icmp-rule.md
View File

@ -1,56 +0,0 @@
---
title: Create an Inbound ICMP Rule
description: Learn how to allow inbound ICMP traffic by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Inbound ICMP Rule
To allow inbound Internet Control Message Protocol (ICMP) network traffic, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows ICMP requests and responses to be sent and received by computers on the network.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
This topic describes how to create a port rule that allows inbound ICMP network traffic. For other inbound port rule types, see:
- [Create an Inbound Port Rule](create-an-inbound-port-rule.md)
- [Create Inbound Rules to Support RPC](create-inbound-rules-to-support-rpc.md)
To create an inbound ICMP rule
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Inbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
5. On the **Program** page, click **All programs**, and then click **Next**.
6. On the **Protocol and Ports** page, select **ICMPv4** or **ICMPv6** from the **Protocol type** list. If you use both IPv4 and IPv6 on your network, you must create a separate ICMP rule for each.
7. Click **Customize**.
8. In the **Customize ICMP Settings** dialog box, do one of the following:
- To allow all ICMP network traffic, click **All ICMP types**, and then click **OK**.
- To select one of the predefined ICMP types, click **Specific ICMP types**, and then select each type in the list that you want to allow. Click **OK**.
- To select an ICMP type that does not appear in the list, click **Specific ICMP types**, select the **Type** number from the list, select the **Code** number from the list, click **Add**, and then select the newly created entry from the list. Click **OK**
9. Click **Next**.
10. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
11. On the **Action** page, select **Allow the connection**, and then click **Next**.
12. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
13. On the **Name** page, type a name and description for your rule, and then click **Finish**.

64
windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-port-rule.md
View File

@ -1,64 +0,0 @@
---
title: Create an Inbound Port Rule
description: Learn to allow traffic on specific ports by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Inbound Port Rule
To allow inbound network traffic on only a specified TCP or UDP port number, use the Windows Defender Firewall
with Advanced Security node in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows any program that listens on a specified TCP or UDP port to receive network traffic sent to that port.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
This topic describes how to create a standard port rule for a specified protocol or TCP or UDP port number. For other inbound port rule types, see:
- [Create an Inbound ICMP Rule](create-an-inbound-icmp-rule.md)
- [Create Inbound Rules to Support RPC](create-inbound-rules-to-support-rpc.md)
**To create an inbound port rule**
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Inbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
> [!Note]
> Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
5. On the **Program** page, click **All programs**, and then click **Next**.
> [!Note]
> This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The specified program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. If you choose to do this, follow the steps in the [Create an Inbound Program or Service Rule](create-an-inbound-program-or-service-rule.md) procedure in addition to the steps in this procedure to create a single rule that filters network traffic using both program and port criteria.
6. On the **Protocol and Ports** page, select the protocol type that you want to allow. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this is an incoming rule, you typically configure only the local port number.
If you select another protocol, then only packets whose protocol field in the IP header match this rule are permitted through the firewall.
To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box.
When you have configured the protocols and ports, click **Next**.
7. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
8. On the **Action** page, select **Allow the connection**, and then click **Next**.
9. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
> [!Note]
> If this GPO is targeted at server computers running Windows Server 2008 that never move, consider modifying the rules to apply to all network location type profiles. This prevents an unexpected change in the applied rules if the network location type changes due to the installation of a new network card or the disconnection of an existing network card's cable. A disconnected network card is automatically assigned to the Public network location type.
10. On the **Name** page, type a name and description for your rule, and then click **Finish**.

65
windows/security/operating-system-security/network-security/windows-firewall/create-an-inbound-program-or-service-rule.md
View File

@ -1,65 +0,0 @@
---
title: Create an Inbound Program or Service Rule
description: Learn how to allow inbound traffic to a program or service by using the Group Policy Management MMC snap-in to create firewall rules.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Inbound Program or Service Rule
To allow inbound network traffic to a specified program or service, use the Windows Defender Firewall with Advanced Securitynode in the Group Policy Management MMC snap-in to create firewall rules. This type of rule allows the program to listen and receive inbound network traffic on any port.
>**Note:**  This type of rule is often combined with a program or service rule. If you combine the rule types, you get a firewall rule that limits traffic to a specified port and allows the traffic only when the specified program is running. The program cannot receive network traffic on other ports, and other programs cannot receive network traffic on the specified port. To combine the program and port rule types into a single rule, follow the steps in the [Create an Inbound Port Rule](create-an-inbound-port-rule.md) procedure in addition to the steps in this procedure.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To create an inbound firewall rule for a program or service
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Inbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
>**Note:**  Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
5. On the **Program** page, click **This program path**.
6. Type the path to the program in the text box. Use environment variables, where applicable, to ensure that programs installed in different locations on different computers work correctly.
7. Do one of the following:
- If the executable file contains a single program, click **Next**.
- If the executable file is a container for multiple services that must all be allowed to receive inbound network traffic, click **Customize**, select **Apply to services only**, click **OK**, and then click **Next**.
- If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, click **Customize**, select **Apply to this service**, and then select the service from the list. If the service does not appear in the list, click **Apply to service with this service short name**, and then type the short name for the service in the text box. Click **OK**, and then click **Next**.
**Important**  
To use the **Apply to this service** or **Apply to service with this service short name** options, the service must be configured with a security identifier (SID) with a type of **RESTRICTED** or **UNRESTRICTED**. To check the SID type of a service, run the following command:
**sc** **qsidtype** *&lt;ServiceName&gt;*
If the result is **NONE**, then a firewall rule cannot be applied to that service.
To set a SID type on a service, run the following command:
**sc** **sidtype** *&lt;ServiceName&gt; &lt;Type&gt;*
In the preceding command, the value of *&lt;Type&gt;* can be **UNRESTRICTED** or **RESTRICTED**. Although the command also permits the value of **NONE**, that setting means the service cannot be used in a firewall rule as described here. By default, most services in Windows are configured as **UNRESTRICTED**. If you change the SID type to **RESTRICTED**, the service might fail to start. We recommend that you change the SID type only on services that you want to use in firewall rules, and that you change the SID type to **UNRESTRICTED**.
8. It is a best practice to restrict the firewall rule for the program to only the ports it needs to operate. On the **Protocols and Ports** page, you can specify the port numbers for the allowed traffic. If the program tries to listen on a port different from the one specified here, it is blocked. For more information about protocol and port options, see [Create an Inbound Port Rule](create-an-inbound-port-rule.md). After you have configured the protocol and port options, click **Next**.
9. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
10. On the **Action** page, select **Allow the connection**, and then click **Next**.
11. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
12. On the **Name** page, type a name and description for your rule, and then click **Finish**.

46
windows/security/operating-system-security/network-security/windows-firewall/create-an-outbound-port-rule.md
View File

@ -1,46 +0,0 @@
---
title: Create an Outbound Port Rule
description: Learn to block outbound traffic on a port by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Outbound Port Rule
By default, Windows Defender Firewall allows all outbound network traffic unless it matches a rule that prohibits the traffic. To block outbound network traffic on a specified TCP or UDP port number, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create firewall rules. This type of rule blocks any outbound network traffic that matches the specified TCP or UDP port numbers.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To create an outbound port rule
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Outbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Outbound Rule wizard, click **Custom**, and then click **Next**.
>**Note:**  Although you can create rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
5. On the **Program** page, click **All programs**, and then click **Next**.
6. On the **Protocol and Ports** page, select the protocol type that you want to block. To restrict the rule to a specified port number, you must select either **TCP** or **UDP**. Because this rule is an outbound rule, you typically configure only the remote port number.
If you select another protocol, then only packets whose protocol field in the IP header matches this rule are blocked by Windows Defender Firewall. Network traffic for protocols is allowed as long as other rules that match don't block it.
To select a protocol by its number, select **Custom** from the list, and then type the number in the **Protocol number** box.
When you've configured the protocols and ports, click **Next**.
7. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
8. On the **Action** page, select **Block the connection**, and then click **Next**.
9. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
10. On the **Name** page, type a name and description for your rule, and then click **Finish**.

50
windows/security/operating-system-security/network-security/windows-firewall/create-an-outbound-program-or-service-rule.md
View File

@ -1,50 +0,0 @@
---
title: Create an Outbound Program or Service Rule
description: Use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create firewall rules.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create an Outbound Program or Service Rule
By default, Windows Defender Firewall allows all outbound network traffic unless it matches a rule that prohibits the traffic. To block outbound network traffic for a specified program or service, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create firewall rules. This type of rule prevents the program from sending any outbound network traffic on any port.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
To create an outbound firewall rule for a program or service
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Outbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Outbound Rule Wizard, click **Custom**, and then click **Next**.
>**Note:**  Although you can create many rules by selecting **Program** or **Port**, those choices limit the number of pages presented by the wizard. If you select **Custom**, you see all of the pages, and have the most flexibility in creating your rules.
5. On the **Program** page, click **This program path**.
6. Type the path to the program in the text box. Use environment variables as appropriate to ensure that programs installed in different locations on different computers work correctly.
7. Do one of the following:
- If the executable file contains a single program, click **Next**.
- If the executable file is a container for multiple services that must all be blocked from sending outbound network traffic, click **Customize**, select **Apply to services only**, click **OK**, and then click **Next**.
- If the executable file is a container for a single service or contains multiple services but the rule only applies to one of them, click **Customize**, select **Apply to this service**, and then select the service from the list. If the service does not appear in the list, then click **Apply to service with this service short name**, and type the short name for the service in the text box. Click **OK**, and then click **Next**.
8. If you want the program to be allowed to send on some ports, but blocked from sending on others, then you can restrict the firewall rule to block only the specified ports or protocols. On the **Protocols and Ports** page, you can specify the port numbers or protocol numbers for the blocked traffic. If the program tries to send to or from a port number different from the one specified here, or by using a protocol number different from the one specified here, then the default outbound firewall behavior allows the traffic. For more information about the protocol and port options, see [Create an Outbound Port Rule](create-an-outbound-port-rule.md). When you have configured the protocol and port options, click **Next**.
9. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
10. On the **Action** page, select **Block the connection**, and then click **Next**.
11. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
12. On the **Name** page, type a name and description for your rule, and then click **Finish**.

83
windows/security/operating-system-security/network-security/windows-firewall/create-inbound-rules-to-support-rpc.md
View File

@ -1,83 +0,0 @@
---
title: Create Inbound Rules to Support RPC
description: Learn how to allow RPC network traffic by using the Group Policy Management MMC snap-in to create rules in Windows Defender Firewall with Advanced Security.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Create Inbound Rules to Support RPC
To allow inbound remote procedure call (RPC) network traffic, use the Windows Defender Firewall with Advanced Security node in the Group Policy Management console to create two firewall rules. The first rule allows incoming network packets on TCP port 135 to the RPC Endpoint Mapper service. The incoming traffic consists of requests to communicate with a specified network service. The RPC Endpoint Mapper replies with a dynamically assigned port number that the client must use to communicate with the service. The second rule allows the network traffic that is sent to the dynamically assigned port number. Using the two rules configured as described in this topic helps to protect your device by allowing network traffic only from devices that have received RPC dynamic port redirection and to only those TCP port numbers assigned by the RPC Endpoint Mapper.
**Administrative credentials**
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.
This topic describes how to create rules that allow inbound RPC network traffic. For other inbound port rule types, see:
- [Create an Inbound Port Rule](create-an-inbound-port-rule.md)
- [Create an Inbound ICMP Rule](create-an-inbound-icmp-rule.md)
In this topic:
- [To create a rule to allow inbound network traffic to the RPC Endpoint Mapper service](#to-create-a-rule-to-allow-inbound-network-traffic-to-the-rpc-endpoint-mapper-service)
- [To create a rule to allow inbound network traffic to RPC-enabled network services](#to-create-a-rule-to-allow-inbound-network-traffic-to-rpc-enabled-network-services)
## To create a rule to allow inbound network traffic to the RPC Endpoint Mapper service
1. Open the Group Policy Management Console to [Windows Defender Firewall with Advanced Security](open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md).
2. In the navigation pane, click **Inbound Rules**.
3. Click **Action**, and then click **New rule**.
4. On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
5. On the **Program** page, click **This Program Path**, and then type **%systemroot%\\system32\\svchost.exe**.
6. Click **Customize**.
7. In the **Customize Service Settings** dialog box, click **Apply to this service**, select **Remote Procedure Call (RPC)** with a short name of **RpcSs**, click **OK**, and then click **Next**.
8. On the warning about Windows service-hardening rules, click **Yes**.
9. On the **Protocol and Ports** dialog box, for **Protocol type**, select **TCP**.
10. For **Local port**, select **RPC Endpoint Mapper**, and then click **Next**.
11. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
12. On the **Action** page, select **Allow the connection**, and then click **Next**.
13. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.  
14. On the **Name** page, type a name and description for your rule, and then click **Finish**.
## To create a rule to allow inbound network traffic to RPC-enabled network services
1. On the same GPO you edited in the preceding procedure, click **Action**, and then click **New rule**.
2. On the **Rule Type** page of the New Inbound Rule Wizard, click **Custom**, and then click **Next**.
3. On the **Program** page, click **This Program Path**, and then type the path to the executable file that hosts the network service. Click **Customize**.
4. In the **Customize Service Settings** dialog box, click **Apply to this service**, and then select the service that you want to allow. If the service doesn't appear in the list, then click **Apply to service with this service short name**, and then type the short name of the service in the text box.
5. Click **OK**, and then click **Next**.
6. On the **Protocol and Ports** dialog box, for **Protocol type**, select **TCP**.
7. For **Local port**, select **RPC Dynamic Ports**, and then click **Next**.
8. On the **Scope** page, you can specify that the rule applies only to network traffic to or from the IP addresses entered on this page. Configure as appropriate for your design, and then click **Next**.
9. On the **Action** page, select **Allow the connection**, and then click **Next**.
10. On the **Profile** page, select the network location types to which this rule applies, and then click **Next**.
11. On the **Name** page, type a name and description for your rule, and then click **Finish**.

110
windows/security/operating-system-security/network-security/windows-firewall/create-windows-firewall-rules-in-intune.md
View File

@ -1,110 +0,0 @@
---
title: Create Windows Firewall rules in Intune
description: Learn how to use Intune to create rules in Windows Defender Firewall with Advanced Security. Start by creating a profile in Device Configuration in Intune.
ms.topic: conceptual
ms.date: 11/07/2023
---
# Create Windows Firewall rules in Intune
>[!IMPORTANT]
>This information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
To get started, Open the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), and then go to **Devices** > **Windows** > **Configuration profiles** > **Create profile** > Choose **Windows 10 and later** as the platform, Choose **Templates**, then **Endpoint protection** as the profile type.
Select Windows Defender Firewall.
:::image type="content" source="images/windows-firewall-intune.png" alt-text="Example of a Windows Defender Firewall policy in Microsoft Intune and the Intune admin center.":::
>[!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.
## Firewall rule components
The firewall rule configurations in Intune use the Windows CSP for Firewall. For more information, see [Firewall CSP](/windows/client-management/mdm/firewall-csp).
## Application
Control connections for an app or program.
Apps and programs can be specified either file path, package family name, or Windows service short name.
The file path of an app is its location on the client device.
For example, C:\Windows\System\Notepad.exe.
[Learn more](/windows/client-management/mdm/firewall-csp#filepath)
Package family names can be retrieved by running the Get-AppxPackage command from PowerShell.
[Learn more](https://aka.ms/intunefirewallPackageNameFromPowerShell)
Windows service short names are used in cases when a service, not an application, is sending or receiving traffic.
Default is All.
[Learn more](/windows/client-management/mdm/firewall-csp#servicename)
## Protocol
Select the protocol for this port rule. Transport layer protocols—TCP and UDP—allow you to specify ports or port ranges. For custom protocols, enter a number between 0 and 255 representing the IP protocol.
Default is Any.
[Learn more](/windows/client-management/mdm/firewall-csp#protocol)
## Local ports
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
[Learn more](/windows/client-management/mdm/firewall-csp#localportranges)
## Remote ports
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
[Learn more](/windows/client-management/mdm/firewall-csp#remoteportranges)
## Local addresses
Comma-separated list of local addresses covered by the rule. Valid tokens include:
- `*` indicates any local address. If present, this token must be the only one included
- A subnet can be specified using either the subnet mask or network prefix notation. If a subnet mask or a network prefix isn't specified, the subnet mask default is 255.255.255.255
- A valid IPv6 address
- An IPv4 address range in the format of "start address-end address" with no spaces included
- An IPv6 address range in the format of "start address-end address" with no spaces included. Default is Any address
[Learn more](/windows/client-management/mdm/firewall-csp#localaddressranges)
## Remote addresses
List of comma separated tokens specifying the remote addresses covered by the rule. Tokens are case insensitive. Valid tokens include:
- `*` indicates any remote address. If present, this token must be the only one included
- Defaultgateway
- DHCP
- DNS
- WINS
- Intranet
- RmtIntranet
- Internet
- Ply2Renders
- LocalSubnet indicates any local address on the local subnet
- A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255
- A valid IPv6 address
- An IPv4 address range in the format of "start address-end address" with no spaces included
- An IPv6 address range in the format of "start address-end address" with no spaces included
Default is Any address
[Learn more](https://aka.ms/intunefirewallremotaddressrule)
## Edge traversal (UI coming soon)
Indicates whether edge traversal is enabled or disabled for this rule. The EdgeTraversal setting indicates that specific inbound traffic is allowed to tunnel through NATs and other edge devices using the Teredo tunneling technology. In order for this setting to work correctly, the application or service with the inbound firewall rule needs to support IPv6. The primary application of this setting allows listeners on the host to be globally addressable through a Teredo IPv6 address. New rules have the EdgeTraversal property disabled by default. This setting can only be configured via Intune Graph at this time.
[Learn more](/windows/client-management/mdm/firewall-csp#edgetraversal)
## Authorized users
Specifies the list of authorized local users for this rule. A list of authorized users can't be specified if the rule being authored is targeting a Windows service. Default is all users.
[Learn more](/windows/client-management/mdm/firewall-csp#localuserauthorizedlist)
## Configuring firewall rules programmatically
Coming soon.

41
windows/security/operating-system-security/network-security/windows-firewall/designing-a-windows-firewall-with-advanced-security-strategy.md
View File

@ -1,41 +0,0 @@
---
title: Designing a Windows Defender Firewall Strategy
description: Answer the question in this article to design an effective Windows Defender Firewall with Advanced Security Strategy.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/07/2021
---
# Designing a Windows Defender Firewall with Advanced Security Strategy
To select the most effective design for helping to protect the network, you must spend time collecting key information about your current computer environment. You must have a good understanding of what tasks the devices on the network perform, and how they use the network to accomplish those tasks. You must understand the network traffic generated by the programs running on the devices.
- [Gathering the Information You Need](gathering-the-information-you-need.md)
- [Determining the Trusted State of Your Devices](determining-the-trusted-state-of-your-devices.md)
The information that you gather will help you answer the following questions. The answers will help you understand your security requirements and select the design that best matches those requirements. The information will also help you when it comes time to deploy your design, by helping you to build a deployment strategy that is cost effective and resource efficient. It will help you project and justify the expected costs associated with implementing the design.
- What traffic must always be allowed? What are characteristics of the network traffic generated and consumed by the business programs?
- What traffic must always be blocked? Does your organization have policies that prohibit the use of specific programs? If so, what are the characteristics of the network traffic generated and consumed by the prohibited programs?
- What traffic on the network can't be protected by IPsec because the devices or devices sending or receiving the traffic don't support IPsec?
- For each type of network traffic, does the default configuration of the firewall (block all unsolicited inbound network traffic, allow all outbound traffic) allow or block the traffic as required?
- Do you have an Active Directory domain (or forest of trusted domains) to which all your devices are joined? If you don't, then you can't use Group Policy for easy mass deployment of your firewall and connection security rules. You also can't easily take advantage of Kerberos V5 authentication that all domain clients can use.
- Which devices must be able to accept unsolicited inbound connections from devices that aren't part of the domain?
- Which devices contain data that must be encrypted when exchanged with another computer?
- Which devices contain sensitive data to which access must be restricted to authorized users and devices?
- Does your organization have specific network troubleshooting devices or devices (such as protocol analyzers) that must be granted unlimited access to the devices on the network, essentially bypassing the firewall?
This guide describes how to plan your groups and GPOs for an environment with a mix of operating systems. Details can be found in the section [Planning Group Policy Deployment for Your Isolation Zones](planning-group-policy-deployment-for-your-isolation-zones.md) later in this guide.
**Next:** [Gathering the Information You Need](gathering-the-information-you-need.md)

51
windows/security/operating-system-security/network-security/windows-firewall/filter-origin-documentation.md
View File

@ -1,21 +1,19 @@
---
title: Filter origin audit log improvements
description: Filter origin documentation audit log improvements
title: Filter origin audit log
description: Learn about Windows Firewall and filter origin audit log to troubleshoot packet drops.
ms.topic: troubleshooting
ms.date: 11/07/2023
ms.date: 11/21/2023
---
# Filter origin audit log improvements
# Filter origin audit log
Debugging packet drops is a continuous issue to Windows customers. In the past, customers had limited information about packet drops.
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.
When investigating packet drop events, you can use the field `Filter Run-Time ID` from Windows Filtering Platform (WFP) audits `5157` or `5152`.
![Event properties.](images/event-properties-5157.png)
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. However, the filter ID isn't a reliable source for tracing back to the filter or the rule, as the filter ID can change for many reasons despite the rule not changing at all. This change in ID makes the diagnosis process error-prone and difficult.
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. However, the filter ID isn't a reliable source for tracing back to the filter or the rule, as the filter ID can change for many reasons despite the rule not changing at all. The change in ID makes the diagnosis process error-prone and difficult.
For customers to debug packet drop events correctly and efficiently, they would need more context about the blocking filter such as its origin. The blocking filters can be categorized under these filter origins:
To debug packet drop events correctly and efficiently, you need more context about the blocking filter, such as its origin. The blocking filters can be categorized under these filter origins:
1. Firewall rules
1. Firewall default block filters
@ -27,17 +25,14 @@ For customers to debug packet drop events correctly and efficiently, they would
1. Universal Windows Platform (UWP) default
1. Windows Service Hardening (WSH) default
The next section describes the improvements made to audits 5157 and 5152, and how the above filter origins are used in these events. These improvements were added in the Windows Server 2022 and Windows 11 releases.
The next section describes the improvements made to audits `5157` and `5152` in Windows 11 and Windows Server 2022, and how the filter origins are used in these events.
## Improved firewall audit
The two new fields added to the audit 5157 and 5152 events are `Filter Origin` and `Interface Index`.
Starting in Windows 11 and Windows Server 2022, two new fields added to the audit `5157` and `5152` events are *Filter Origin* and *Interface Index*:
The `Filter Origin` field helps identify the cause of the drop. Packet drops from firewall are explicitly dropped by default block filters created by the Windows Firewall service or a firewall rule that may be created by users, policies, services, apps, etc.
`Filter Origin` specifies either the rule ID (a unique identifier of a Firewall rule) or the name of one of the default block filters.
The `Interface Index` field specifies the network interface in which the packet was dropped. This field helps to identify which interface was quarantined, if the `Filter Origin` is a `Quarantine Default`.
- The *Filter Origin* field helps identify the cause of the drop. Packet drops from firewall are explicitly dropped by default block filters created by the Windows Firewall service or a firewall rule that may be created by users, policies, services, apps, etc. Filter Origin` specifies either the *rule ID* (a unique identifier of a Firewall rule) or the name of one of the default block filters
- The *Interface Index* field specifies the network interface in which the packet was dropped. This field helps to identify which interface was quarantined, if the *Filter Origin* is a *Quarantine Default*
To enable a specific audit event, run the corresponding command in an administrator command prompt:
@ -48,11 +43,11 @@ To enable a specific audit event, run the corresponding command in an administra
## Example flow of debugging packet drops with filter origin
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.
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.
![Event audit.](images/event-audit-5157.png)
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**.
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](#firewall-default-block-filters).
## Firewall rules
@ -65,20 +60,19 @@ Get-NetFirewallRule -Name " {A549B7CF-0542-4B67-93F9-EEBCDD584377} "
![Firewall rule.](images/firewallrule.png)
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`.
After identifying the rule that caused the drop, the network admin can modify or disable the rule to allow the traffic they want through one of the available [tools](tools.md). The network admin can find the rule in the UI with the rule's *DisplayName*.
>[!NOTE]
> Firewall rules from Mobile Device Management (MDM) store cannot be searched using the Windows Defender UI. Additionally, the above method will not work when the `Filter Origin` is one of the default block filters, as they do not correspond to any firewall rules.
> Firewall rules from Mobile Device Management (MDM) store cannot be searched using the Windows Firewall UI. Additionally, the above method doesn't work when the *Filter Origin* is one of the default block filters, as they don't correspond to any firewall rules.
## Firewall default block filters
### AppContainer loopback
Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn't enabled properly for the Universal Windows Platform (UWP) app.
Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn't enabled properly for the Universal Windows Platform (UWP) app:
To enable localhost loopback in a local debugging environment, see [Communicating with localhost](/windows/iot-core/develop-your-app/loopback).
To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged Win32 app, see [uap4:LoopbackAccessRules](/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules).
- To enable localhost loopback in a local debugging environment, see [Communicating with localhost](/windows/iot-core/develop-your-app/loopback)
- To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged Win32 app, see [uap4:LoopbackAccessRules](/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules)
### Boot time default
@ -92,11 +86,8 @@ Run the following PowerShell command to generate more information about the inte
```Powershell
Get-NetIPInterface -InterfaceIndex <Interface Index>
Get-NetIPInterface -InterfaceIndex 5
```
![Quarantine default block filter.](images/quarantine-default-block-filter.png)
To learn more about the quarantine feature, see [Quarantine behavior](quarantine.md).
>[!NOTE]
@ -115,11 +106,7 @@ To generate a list of all the query user block rules, you can run the following
Get-NetFirewallRule | Where {$_.Name -like "*Query User*"}
```
![Query user default block filter.](images/query-user-default-block-filters.png)
The query user pop-up feature is enabled by default.
To disable the query user pop-up, you can run the following command in administrative command prompt:
The query user pop-up feature is enabled by default. To disable the query user pop-up, you can run the following command in administrative command prompt:
```cmd
Netsh set allprofiles inboundusernotification disable

31
windows/security/operating-system-security/network-security/windows-firewall/firewall-settings-lost-on-upgrade.md
View File

@ -1,31 +0,0 @@
---
title: Troubleshooting Windows Firewall settings after a Windows upgrade
description: Firewall settings lost on upgrade
ms.topic: troubleshooting
ms.date: 11/07/2023
---
# Troubleshooting Windows Firewall settings after a Windows upgrade
Use this article to troubleshoot firewall settings that are turned off after upgrading to a new version of Windows.
## Rule groups
To help you organize your list, individual built-in firewall rules are categorized within a group. For example, the following rules form part of the Remote Desktop group.
- Remote Desktop - Shadow (TCP-In)
- Remote Desktop - User Mode (TCP-In)
- Remote Desktop - User-Mode (UDP-In)
Other group examples include **core networking**, **file and print sharing**, and **network discovery**. Grouping allows administrators to manage sets of similar rules by filtering on categories in the firewall interface (wf.msc). Do this filtering by right-clicking on either **Inbound** or **Outbound Rules** and selecting **Filter by Group**. Optionally, you can use PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch.
```Powershell
Get-NetFirewallRule -Group <groupName>
```
> [!NOTE]
> Microsoft recommends to enable or disable an entire group instead of individual rules.
Microsoft recommends that you enable/disable all of the rules within a group instead of one or two individual rules. This recommendation is because groups aren't only used to organize rules and allow batch rule modification by type, but they also represent a 'unit' by which rule state is maintained across a Windows upgrade. Rule groups, as opposed to individual rules, are the unit by which the update process determines what should be enabled/disabled when the upgrade is complete.
For example, the Remote Desktop group consists of three rules. To ensure that the rule set is properly migrated during an upgrade, all three rules must be enabled. If only one rule is enabled, the upgrade process will see that two of three rules are disabled and then disable the entire group to maintain a clean, out-of-the-box configuration. This scenario has the unintended consequence of breaking Remote Desktop Protocol (RDP) connectivity to the host.

8
windows/security/operating-system-security/network-security/windows-firewall/hyper-v-firewall.md
View File

@ -2,9 +2,7 @@
title: Hyper-V firewall
description: Learn how to configure Hyper-V firewall rules and settings using PowerShell or Configuration Service Provider (CSP).
ms.topic: how-to
ms.date: 11/08/2023
author: paolomatarazzo
ms.author: paoloma
ms.date: 11/21/2023
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
---
@ -57,8 +55,8 @@ The output contains the following values:
|--|--|
| `Enabled` (True/False) | True if Hyper-V Firewall is enabled for WSL VMs. |
| `DefaultInboundAction`, `DefaultOutboundAction` | These are default rule policies applied to packets entering or leaving the WSL container. The rule policies can be modified, as described in this article. |
| `LoopbackEnabled` | Tracks if loopback traffic between the host and the container is allowed, without requiring any Hyper-V Firewall rules. WSL enables it by default, to allow the Windows Host to talk to WSL, and WSL to talk to the Windows Host. |
| `AllowHostPolicyMerge` | Determines how Windows Host Firewall Enterprise Settings (GPO), Hyper-V Firewall Enterprise Settings (CSP), Windows Host Firewall Enterprise Settings (CSP), local Hyper-V Firewall settings, and local Host Firewall settings interact.<br>This setting is detailed with the [Set-NetFirewallHyperVVMSetting][PS-2] cmdlet. |
| `LoopbackEnabled` | Tracks if loopback traffic between the host and the container is allowed, without requiring any Hyper-V Firewall rules. WSL enables it by default, to allow the Windows Host to talk to WSL, and WSL to talk to the Windows Host.|
| `AllowHostPolicyMerge` | Determines how Windows Host Firewall Enterprise Settings (GPO), Hyper-V Firewall Enterprise Settings (CSP), Windows Host Firewall Enterprise Settings (CSP), local Hyper-V Firewall settings, and local Host Firewall settings interact.<br>This setting is detailed with the [Set-NetFirewallHyperVVMSetting][PS-2] cmdlet.|
### Configure Hyper-V firewall settings

9
windows/security/operating-system-security/network-security/windows-firewall/images/cmd.svg Normal file
View File

@ -0,0 +1,9 @@
<svg width="20" height="17" viewBox="0 0 20 17" fill="none" xmlns="http://www.w3.org/2000/svg">
<rect x="0.90909" y="1.88889" width="18.1818" height="14.1667" fill="black"/>
<path d="M4.45117 6.87549C4.30957 6.93245 4.17204 6.97477 4.03857 7.00244C3.90674 7.03011 3.76921 7.04395 3.62598 7.04395C3.39648 7.04395 3.19303 7.01058 3.01562 6.94385C2.83984 6.87549 2.69092 6.77458 2.56885 6.64111C2.4484 6.50765 2.35645 6.34245 2.29297 6.14551C2.23112 5.94694 2.2002 5.71663 2.2002 5.45459C2.2002 5.18604 2.23438 4.94759 2.30273 4.73926C2.37109 4.5293 2.46875 4.3527 2.5957 4.20947C2.72266 4.06462 2.87646 3.95475 3.05713 3.87988C3.23942 3.80339 3.44368 3.76514 3.66992 3.76514C3.74316 3.76514 3.81152 3.76676 3.875 3.77002C3.9401 3.77327 4.00358 3.77979 4.06543 3.78955C4.12728 3.79769 4.18994 3.80908 4.25342 3.82373C4.31689 3.83838 4.38281 3.8571 4.45117 3.87988V4.47559C4.31283 4.41048 4.18099 4.3641 4.05566 4.33643C3.93034 4.30876 3.81641 4.29492 3.71387 4.29492C3.5625 4.29492 3.43311 4.32259 3.32568 4.37793C3.21826 4.43164 3.12956 4.50814 3.05957 4.60742C2.99121 4.70508 2.94076 4.82227 2.9082 4.95898C2.87565 5.09408 2.85938 5.243 2.85938 5.40576C2.85938 5.57829 2.87565 5.73291 2.9082 5.86963C2.94238 6.00472 2.99447 6.11947 3.06445 6.21387C3.13444 6.30827 3.22396 6.3807 3.33301 6.43115C3.44206 6.47998 3.57145 6.50439 3.72119 6.50439C3.7749 6.50439 3.83268 6.49951 3.89453 6.48975C3.95801 6.47835 4.02148 6.46452 4.08496 6.44824C4.15007 6.43034 4.21354 6.40999 4.27539 6.38721C4.33887 6.36279 4.39746 6.33838 4.45117 6.31396V6.87549ZM6.12354 4.49512C6.18538 4.49512 6.24316 4.50651 6.29688 4.5293C6.35059 4.55208 6.39697 4.58382 6.43604 4.62451C6.4751 4.66357 6.50602 4.70996 6.52881 4.76367C6.5516 4.81738 6.56299 4.87435 6.56299 4.93457C6.56299 4.99642 6.5516 5.0542 6.52881 5.10791C6.50602 5.16162 6.4751 5.20801 6.43604 5.24707C6.39697 5.28613 6.35059 5.31706 6.29688 5.33984C6.24316 5.36263 6.18538 5.37402 6.12354 5.37402C6.06169 5.37402 6.00391 5.36263 5.9502 5.33984C5.89811 5.31706 5.85173 5.28613 5.81104 5.24707C5.77197 5.20801 5.74105 5.16162 5.71826 5.10791C5.69548 5.0542 5.68408 4.99642 5.68408 4.93457C5.68408 4.87435 5.69548 4.81738 5.71826 4.76367C5.74105 4.70996 5.77197 4.66357 5.81104 4.62451C5.85173 4.58382 5.89811 4.55208 5.9502 4.5293C6.00391 4.50651 6.06169 4.49512 6.12354 4.49512ZM6.12354 6.17725C6.18538 6.17725 6.24316 6.18864 6.29688 6.21143C6.35059 6.23421 6.39697 6.26514 6.43604 6.3042C6.4751 6.34326 6.50602 6.38965 6.52881 6.44336C6.5516 6.49707 6.56299 6.55404 6.56299 6.61426C6.56299 6.67611 6.5516 6.73389 6.52881 6.7876C6.50602 6.84131 6.4751 6.88851 6.43604 6.9292C6.39697 6.96826 6.35059 6.99919 6.29688 7.02197C6.24316 7.04476 6.18538 7.05615 6.12354 7.05615C6.06169 7.05615 6.00391 7.04476 5.9502 7.02197C5.89811 6.99919 5.85173 6.96826 5.81104 6.9292C5.77197 6.88851 5.74105 6.84131 5.71826 6.7876C5.69548 6.73389 5.68408 6.67611 5.68408 6.61426C5.68408 6.55404 5.69548 6.49707 5.71826 6.44336C5.74105 6.38965 5.77197 6.34326 5.81104 6.3042C5.85173 6.26514 5.89811 6.23421 5.9502 6.21143C6.00391 6.18864 6.06169 6.17725 6.12354 6.17725ZM8.36719 3.55029L10.0737 7.5249H9.49268L7.78857 3.55029H8.36719ZM10.2471 8.00098V7.52979H12.9961V8.00098H10.2471ZM12.9961 8.00098V7.52979H15.7451V8.00098H12.9961Z" fill="white"/>
<rect x="0.90909" y="0.944443" width="18.1818" height="1.88889" fill="#D9D9D9"/>
<rect x="17.2727" y="0.944443" width="0.909091" height="0.944444" fill="#605E5C"/>
<rect x="15.4545" y="0.944443" width="0.909091" height="0.944444" fill="#605E5C"/>
<rect x="13.6364" y="0.944443" width="0.909091" height="0.944444" fill="#605E5C"/>
<rect x="0.5" y="0.5" width="19" height="16" stroke="#CDCDCD"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 3.6 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/control-panel.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/corpnet.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.0 KiB

3
windows/security/operating-system-security/network-security/windows-firewall/images/domain-network.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="14" height="19" viewBox="0 0 14 19" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M0.583311 19C0.425331 19 0.288617 18.9412 0.17317 18.8237C0.0577235 18.7062 0 18.5671 0 18.4063V1.78174C0 1.54054 0.0455712 1.31171 0.136714 1.09524C0.227856 0.878776 0.352417 0.690142 0.510397 0.529339C0.668377 0.368536 0.856738 0.238657 1.07548 0.139702C1.29422 0.0407464 1.51904 -0.00563901 1.74993 0.000545711H8.74966C8.98663 0.000545711 9.21145 0.0469311 9.42412 0.139702C9.63678 0.232473 9.82211 0.359259 9.98009 0.520062C10.1381 0.680865 10.2657 0.872591 10.3629 1.09524C10.4601 1.31789 10.5057 1.54673 10.4996 1.78174V7.12534H12.2495C12.4865 7.12534 12.7113 7.17173 12.924 7.2645C13.1366 7.35727 13.322 7.48405 13.48 7.64486C13.6379 7.80566 13.7655 7.99739 13.8627 8.22004C13.96 8.44269 14.0055 8.67152 13.9995 8.90654V18.4063C13.9995 18.5671 13.9417 18.7062 13.8263 18.8237C13.7108 18.9412 13.5741 19 13.4162 19H0.583311ZM1.16662 17.8125H3.49987V14.8439C3.49987 14.6831 3.55759 14.5439 3.67304 14.4264C3.78848 14.3089 3.9252 14.2501 4.08318 14.2501H9.91629C10.0743 14.2501 10.211 14.3089 10.3264 14.4264C10.4419 14.5439 10.4996 14.6831 10.4996 14.8439V17.8125H12.8328V8.90654C12.8328 8.74574 12.7751 8.60658 12.6597 8.48907C12.5442 8.37156 12.4075 8.31281 12.2495 8.31281H9.91629C9.75831 8.31281 9.62159 8.25405 9.50615 8.13654C9.3907 8.01903 9.33298 7.87988 9.33298 7.71907V1.78174C9.33298 1.62094 9.27525 1.48179 9.1598 1.36428C9.04436 1.24677 8.90764 1.18801 8.74966 1.18801H1.74993C1.59195 1.18801 1.45524 1.24677 1.33979 1.36428C1.22435 1.48179 1.16662 1.62094 1.16662 1.78174V17.8125ZM2.33324 4.45354C2.33324 4.20615 2.41831 3.99587 2.58844 3.8227C2.75857 3.64953 2.96516 3.56294 3.20821 3.56294C3.45126 3.56294 3.65785 3.64953 3.82798 3.8227C3.99811 3.99587 4.08318 4.20615 4.08318 4.45354C4.08318 4.70093 3.99811 4.91121 3.82798 5.08438C3.65785 5.25756 3.45126 5.34414 3.20821 5.34414C2.96516 5.34414 2.75857 5.25756 2.58844 5.08438C2.41831 4.91121 2.33324 4.70093 2.33324 4.45354ZM5.83311 4.45354C5.83311 4.20615 5.91818 3.99587 6.08831 3.8227C6.25844 3.64953 6.46503 3.56294 6.70808 3.56294C6.95112 3.56294 7.15771 3.64953 7.32784 3.8227C7.49798 3.99587 7.58304 4.20615 7.58304 4.45354C7.58304 4.70093 7.49798 4.91121 7.32784 5.08438C7.15771 5.25756 6.95112 5.34414 6.70808 5.34414C6.46503 5.34414 6.25844 5.25756 6.08831 5.08438C5.91818 4.91121 5.83311 4.70093 5.83311 4.45354ZM2.33324 8.01594C2.33324 7.76855 2.41831 7.55827 2.58844 7.3851C2.75857 7.21193 2.96516 7.12534 3.20821 7.12534C3.45126 7.12534 3.65785 7.21193 3.82798 7.3851C3.99811 7.55827 4.08318 7.76855 4.08318 8.01594C4.08318 8.26333 3.99811 8.47361 3.82798 8.64678C3.65785 8.81995 3.45126 8.90654 3.20821 8.90654C2.96516 8.90654 2.75857 8.81995 2.58844 8.64678C2.41831 8.47361 2.33324 8.26333 2.33324 8.01594ZM5.83311 8.01594C5.83311 7.76855 5.91818 7.55827 6.08831 7.3851C6.25844 7.21193 6.46503 7.12534 6.70808 7.12534C6.95112 7.12534 7.15771 7.21193 7.32784 7.3851C7.49798 7.55827 7.58304 7.76855 7.58304 8.01594C7.58304 8.26333 7.49798 8.47361 7.32784 8.64678C7.15771 8.81995 6.95112 8.90654 6.70808 8.90654C6.46503 8.90654 6.25844 8.81995 6.08831 8.64678C5.91818 8.47361 5.83311 8.26333 5.83311 8.01594ZM2.33324 11.5783C2.33324 11.3309 2.41831 11.1207 2.58844 10.9475C2.75857 10.7743 2.96516 10.6877 3.20821 10.6877C3.45126 10.6877 3.65785 10.7743 3.82798 10.9475C3.99811 11.1207 4.08318 11.3309 4.08318 11.5783C4.08318 11.8257 3.99811 12.036 3.82798 12.2092C3.65785 12.3824 3.45126 12.4689 3.20821 12.4689C2.96516 12.4689 2.75857 12.3824 2.58844 12.2092C2.41831 12.036 2.33324 11.8257 2.33324 11.5783ZM5.83311 11.5783C5.83311 11.3309 5.91818 11.1207 6.08831 10.9475C6.25844 10.7743 6.46503 10.6877 6.70808 10.6877C6.95112 10.6877 7.15771 10.7743 7.32784 10.9475C7.49798 11.1207 7.58304 11.3309 7.58304 11.5783C7.58304 11.8257 7.49798 12.036 7.32784 12.2092C7.15771 12.3824 6.95112 12.4689 6.70808 12.4689C6.46503 12.4689 6.25844 12.3824 6.08831 12.2092C5.91818 12.036 5.83311 11.8257 5.83311 11.5783ZM9.33298 11.5783C9.33298 11.3309 9.41804 11.1207 9.58817 10.9475C9.75831 10.7743 9.9649 10.6877 10.2079 10.6877C10.451 10.6877 10.6576 10.7743 10.8277 10.9475C10.9978 11.1207 11.0829 11.3309 11.0829 11.5783C11.0829 11.8257 10.9978 12.036 10.8277 12.2092C10.6576 12.3824 10.451 12.4689 10.2079 12.4689C9.9649 12.4689 9.75831 12.3824 9.58817 12.2092C9.41804 12.036 9.33298 11.8257 9.33298 11.5783ZM4.66649 15.4376V17.8125H6.41642V15.4376H4.66649ZM7.58304 15.4376V17.8125H9.33298V15.4376H7.58304Z" fill="#5489d7"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 4.4 KiB

3
windows/security/operating-system-security/network-security/windows-firewall/images/feedback.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="42" height="40" viewBox="0 0 42 40" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M27.27 21C27.03 21 26.78 20.96 26.54 20.88C25.6 20.57 25 19.73 25 18.75V15.94C22.74 15.58 21 13.61 21 11.25V4.75C21 2.13 23.13 0 25.75 0H37.25C39.87 0 42 2.13 42 4.75V11.25C42 13.87 39.87 16 37.25 16H32.13L29.05 20.1C28.61 20.68 27.96 21 27.27 21ZM13 23.5C8.86 23.5 5.5 20.14 5.5 16C5.5 11.86 8.86 8.5 13 8.5C17.14 8.5 20.5 11.86 20.5 16C20.5 20.14 17.14 23.5 13 23.5ZM0 30.79C0 30.88 0.15 40 13 40C25.85 40 26 30.88 26 30.79V29.75C26 27.68 24.32 26 22.25 26H3.75C1.68 26 0 27.68 0 29.75V30.79Z" fill="#0078D4"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 625 B

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/fw01-profiles.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 65 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/fw02-createrule.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 162 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/fw03-defaults.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 28 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/fw04-userquery.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 243 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/fw05-rulemerge.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 25 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/grouppolicy-paste.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 12 KiB

9
windows/security/operating-system-security/network-security/windows-firewall/images/powershell.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/powershelllogosmall.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.4 KiB

3
windows/security/operating-system-security/network-security/windows-firewall/images/private-network.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="18" height="14" viewBox="0 0 18 14" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M2.25 10.5V5.77865C1.91602 5.70573 1.61133 5.57812 1.33594 5.39583C1.06055 5.21354 0.823242 4.99479 0.624023 4.73958C0.424805 4.48437 0.272461 4.19271 0.166992 3.86458C0.0615234 3.53646 0.00585938 3.19922 0 2.85286C0 2.4579 0.0761719 2.08724 0.228516 1.74089C0.380859 1.39453 0.585937 1.09375 0.84375 0.838542C1.10156 0.583333 1.40039 0.379774 1.74023 0.227865C2.08008 0.0759549 2.4375 0 2.8125 0C3.1875 0 3.54492 0.0729167 3.88477 0.21875C4.22461 0.364583 4.52344 0.568142 4.78125 0.829427C5.03906 1.09071 5.24414 1.39453 5.39648 1.74089C5.54883 2.08724 5.625 2.4579 5.625 2.85286C5.625 3.2053 5.57227 3.54253 5.4668 3.86458C5.36133 4.18663 5.20898 4.47526 5.00977 4.73047C4.81055 4.98568 4.57324 5.20747 4.29785 5.39583C4.02246 5.5842 3.71484 5.71181 3.375 5.77865V10.5H6.75V5.25C6.75 5.06771 6.81445 4.91884 6.94336 4.80339L10.8809 1.30339C10.9863 1.21224 11.1094 1.16667 11.25 1.16667C11.3906 1.16667 11.5137 1.21224 11.6191 1.30339L15.5566 4.80339C15.6855 4.91884 15.75 5.06771 15.75 5.25V10.5H17.4375C17.5898 10.5 17.7217 10.5577 17.833 10.6732C17.9443 10.7886 18 10.9253 18 11.0833C18 11.2413 17.9443 11.378 17.833 11.4935C17.7217 11.6089 17.5898 11.6667 17.4375 11.6667H0.5625C0.410156 11.6667 0.27832 11.6089 0.166992 11.4935C0.0556641 11.378 0 11.2413 0 11.0833C0 10.9253 0.0556641 10.7886 0.166992 10.6732C0.27832 10.5577 0.410156 10.5 0.5625 10.5H2.25ZM2.8125 4.66667C3.04102 4.66667 3.25781 4.62109 3.46289 4.52995C3.66797 4.4388 3.84668 4.31424 3.99902 4.15625C4.15137 3.99826 4.27441 3.8099 4.36816 3.59115C4.46191 3.3724 4.50586 3.14757 4.5 2.91667C4.5 2.67969 4.45605 2.45486 4.36816 2.24219C4.28027 2.02951 4.16016 1.84418 4.00781 1.6862C3.85547 1.52821 3.67383 1.40061 3.46289 1.30339C3.25195 1.20616 3.03516 1.16059 2.8125 1.16667C2.58398 1.16667 2.36719 1.21224 2.16211 1.30339C1.95703 1.39453 1.77832 1.5191 1.62598 1.67708C1.47363 1.83507 1.35059 2.02344 1.25684 2.24219C1.16309 2.46094 1.11914 2.68576 1.125 2.91667C1.125 3.15365 1.16895 3.37847 1.25684 3.59115C1.34473 3.80382 1.46484 3.98915 1.61719 4.14714C1.76953 4.30512 1.95117 4.43273 2.16211 4.52995C2.37305 4.62717 2.58984 4.67274 2.8125 4.66667ZM11.25 2.51562L7.875 5.51432V10.5H14.625V5.51432L11.25 2.51562ZM17.4375 12.8333C17.5898 12.8333 17.7217 12.8911 17.833 13.0065C17.9443 13.122 18 13.2587 18 13.4167C18 13.5747 17.9443 13.7114 17.833 13.8268C17.7217 13.9423 17.5898 14 17.4375 14H0.5625C0.410156 14 0.27832 13.9423 0.166992 13.8268C0.0556641 13.7114 0 13.5747 0 13.4167C0 13.2587 0.0556641 13.122 0.166992 13.0065C0.27832 12.8911 0.410156 12.8333 0.5625 12.8333H17.4375Z" fill="#5489d7"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.6 KiB

3
windows/security/operating-system-security/network-security/windows-firewall/images/public-network.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="19" height="14" viewBox="0 0 19 14" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M0 7.01818V1.36364C0 1.17576 0.0371094 1 0.111328 0.836364C0.185547 0.672727 0.284505 0.527273 0.408203 0.4C0.531901 0.272727 0.677246 0.175758 0.844238 0.109091C1.01123 0.0424242 1.19368 0.00606061 1.3916 0H12.8584C13.0316 0 13.1955 0.030303 13.3501 0.0909091C13.5047 0.151515 13.647 0.236364 13.7769 0.345455C13.9067 0.454545 14.0088 0.581818 14.083 0.727273C14.1572 0.872727 14.2098 1.0303 14.2407 1.2H15.5117C15.9941 1.2 16.4456 1.29394 16.8662 1.48182C17.2868 1.6697 17.6579 1.92424 17.9795 2.24545C18.3011 2.56667 18.5485 2.93636 18.7217 3.35455C18.8949 3.77273 18.9876 4.21818 19 4.69091C19 5.15758 18.9103 5.6 18.731 6.01818C18.5516 6.43636 18.3011 6.80909 17.9795 7.13636C17.6579 7.46364 17.2899 7.71818 16.8755 7.9C16.4611 8.08182 16.0065 8.17576 15.5117 8.18182H14.1479C14.049 8.73939 13.8882 9.2697 13.6655 9.77273C13.4429 10.2758 13.1676 10.7455 12.8398 11.1818C12.512 11.6182 12.141 12.0061 11.7266 12.3455C11.3122 12.6848 10.8576 12.9818 10.3628 13.2364C9.868 13.4909 9.35156 13.6788 8.81348 13.8C8.27539 13.9212 7.71257 13.9879 7.125 14C6.4694 14 5.83854 13.9182 5.23242 13.7545C4.6263 13.5909 4.05729 13.3545 3.52539 13.0455C2.99349 12.7364 2.51416 12.3727 2.0874 11.9545C1.66064 11.5364 1.28955 11.0667 0.974121 10.5455C0.658691 10.0242 0.420573 9.4697 0.259766 8.88182C0.0989583 8.29394 0.0123698 7.67273 0 7.01818ZM13.0625 7.01818V1.36364C13.0625 1.30909 13.0439 1.26364 13.0068 1.22727C12.9697 1.19091 12.9202 1.1697 12.8584 1.16364H1.3916C1.33594 1.16364 1.28955 1.18182 1.25244 1.21818C1.21533 1.25455 1.19368 1.30303 1.1875 1.36364V7.01818C1.1875 7.82424 1.34212 8.57879 1.65137 9.28182C1.96061 9.98485 2.38428 10.603 2.92236 11.1364C3.46045 11.6697 4.08822 12.0848 4.80566 12.3818C5.52311 12.6788 6.29622 12.8303 7.125 12.8364C7.94759 12.8364 8.71761 12.6848 9.43506 12.3818C10.1525 12.0788 10.7834 11.6636 11.3276 11.1364C11.8719 10.6091 12.2956 9.99394 12.5986 9.29091C12.9017 8.58788 13.0563 7.8303 13.0625 7.01818ZM15.4839 7.01818C15.8055 7.01818 16.1055 6.95455 16.3838 6.82727C16.6621 6.7 16.9095 6.5303 17.126 6.31818C17.3424 6.10606 17.5094 5.86061 17.627 5.58182C17.7445 5.30303 17.8063 5.00606 17.8125 4.69091C17.8125 4.38182 17.7507 4.08788 17.627 3.80909C17.5033 3.5303 17.3363 3.28182 17.126 3.06364C16.9157 2.84545 16.6714 2.67576 16.3931 2.55455C16.1147 2.43333 15.8117 2.3697 15.4839 2.36364H14.25V7.01818H15.4839Z" fill="#5489d7"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.4 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/quarantine-default-block-filter.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 50 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/quarantine-interfaceindex1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 78 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/query-user-default-block-filters.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 182 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/uac.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-design2example1.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-design3example1.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 22 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-designexample1.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-designflowchart1.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-domainiso.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-domainisoencrypt.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-domainisohighsec.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 21 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-domainnag.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas-implement.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 36 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfas.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/wfasdomainisoboundary.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/windows-firewall-intune.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 140 KiB

BIN
windows/security/operating-system-security/network-security/windows-firewall/images/windows-security.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 521 KiB

91
windows/security/operating-system-security/network-security/windows-firewall/index.md Normal file
View File

@ -0,0 +1,91 @@
---
title: Windows Firewall overview
description: Learn overview information about the Windows Firewall security feature.
ms.topic: conceptual
ms.date: 11/21/2023
---
# Windows Firewall overview
Windows Firewall is a security feature that helps to protect your device by filtering network traffic that enters and exits your device. This traffic can be filtered based on several criteria, including source and destination IP address, IP protocol, or source and destination port number. Windows Firewall can be configured to block or allow network traffic based on the services and applications that are installed on your device. This allows you to restrict network traffic to only those applications and services that are explicitly allowed to communicate on the network.
Windows Firewall is a host-based firewall that is included with the operating system and enabled by default on all Windows editions.
Windows Firewall 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 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.
:::row:::
:::column span="2":::
Windows Firewall also works with [Network Location Awareness][NLA] so that it can apply security settings appropriate to the types of networks to which the device is connected. For example, Windows Firewall can apply the *public network* profile when the device is connected a coffee shop wi-fi, and the *private network* profile when the device is connected to the home network. This allows you to apply more restrictive settings to public networks to help keep your device secure.
:::column-end:::
:::column span="2":::
:::image type="content" source="images/windows-security.png" alt-text="Screenshot showing the Windows Security app." lightbox="images/windows-security.png" border="false":::
:::column-end:::
:::row-end:::
## Practical applications
Windows Firewall offers several benefits to address your organization's network security challenges:
- Reduced risk of network security threats: By reducing the attack surface of a device, Windows Firewall provides an additional layer of defense to the defense-in-depth model. This increases manageability and decreases the likelihood of a successful attack
- Protection of sensitive data and intellectual property: Windows Firewall integrates with IPsec to provide a simple way to enforce authenticated, end-to-end network communications. This allows for scalable, tiered access to trusted network resources, helping to enforce data integrity and, if necessary, protect data confidentiality
- Extended value of existing investments: Windows Firewall is a host-based firewall included with the operating system, so no additional hardware or software is required. It's also designed to complement existing non-Microsoft network security solutions through a documented API
[!INCLUDE [windows-firewall](../../../../../includes/licensing/windows-firewall.md)]
## Concepts
The default behavior of Windows Firewall is to:
- block all incoming traffic, unless solicited or matching a *rule*
- allow all outgoing traffic, unless matching a *rule*
### Firewall rules
*Firewall rules* identify allowed or blocked network traffic, and the conditions for this to happen. The rules offer an extensive selection of conditions to identify traffic, including:
- Application, service or program name
- Source and destination IP addresses
- Can make use dynamic values, like default gateway, DHCP servers, DNS servers and local subnets
- Protocol name or type. For transport layer protocols, TCP and UDP, you can specify ports or port ranges. For custom protocols, you can use a number between 0 and 255 representing the IP protocol
- Interface type
- ICMP/ICMPv6 traffic type and code
### Firewall profiles
Windows Firewall offers three network profiles: domain, private and public. The network profiles are used to assign rules. For example, you can allow a specific application to communicate on a private network, but not on a public network.
#### :::image type="icon" source="images/domain-network.svg" border="false"::: Domain network
The *domain network* profile is automatically applied to a device that is joined to an Active Directory domain, when it detects the availability of a domain controller. This network profile cannot be set manually.
> [!TIP]
> Another option to detect the *domain network* is to configure the policy settings in the [NetworkListManager Policy CSP][CSP-1], which applies to Microsoft Entra joined devices too.
#### :::image type="icon" source="images/private-network.svg" border="false"::: Private network
The *private network* profile is designed for private networks such as a home network. It can be set manually on a network interface by an administrator.
#### :::image type="icon" source="images/public-network.svg" border="false"::: Public network
The *public network* profile is designed with higher security in mind for public networks, like Wi-Fi hotspots, coffee shops, airports, hotels, etc. It's the default profile for unidentified networks.
> [!TIP]
> Use the PowerShell cmdlet `Get-NetConnectionProfile` to retrieve the active network category (`NetworkCategory`). Use the PowerShell cmdlet `Set-NetConnectionProfile` to switch the category between *private* and *public*.
## Next steps
> [!div class="nextstepaction"]
> Learn about Windows Firewall rules and design recommendations:
>
> [Windows Firewall rules >](rules.md)
## :::image type="icon" source="images/feedback.svg" border="false"::: Provide feedback
To provide feedback for Windows Firewall, open [**Feedback Hub**][FHUB] (<kbd>WIN</kbd>+<kbd>F</kbd>) and use the category **Security and Privacy** > **Network protection**.
<!--links-->
[FHUB]: feedback-hub:?tabid=2&newFeedback=true
[NLA]: /windows/win32/winsock/network-location-awareness-service-provider-nla--2
[CSP-1]: /windows/client-management/mdm/policy-csp-networklistmanager

244
windows/security/operating-system-security/network-security/windows-firewall/isolating-apps-on-your-network.md
View File

@ -1,244 +0,0 @@
---
title: Isolating Microsoft Store Apps on Your Network
description: Learn how to customize your firewall configuration to isolate the network access of the new Microsoft Store apps that run on devices added to your network.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Isolating Microsoft Store Apps on Your Network
When you add new devices to your network, you may want to customize your Windows Defender Firewall with Advanced Security configuration to isolate the network access of the new Microsoft Store apps that run on them. Developers who build Microsoft Store apps can declare certain app capabilities that enable different classes of network access. A developer can decide what kind of network access the app requires and configure this capability for the app. When the app is installed on a device, appropriate firewall rules are automatically created to enable access. You can then customize the firewall configuration to further fine-tune this access if they desire more control over the network access for the app.
For example, a developer can decide that their app should only connect to trusted local networks (such as at home or work), and not to the Internet. In this way, developers can define the scope of network access for their app. This network isolation prevents an app from accessing a network and a connection type (inbound or outbound) if the connection has not been configured for the app. Then the network administrator can customize the firewall to further restrict the resources that the app can access.
The ability to set and enforce these network boundaries ensures that apps that get compromised can only access networks where they have been explicitly granted access. This significantly reduces the scope of their impact on other apps, the device, and the network. In addition, apps can be isolated and protected from malicious access from the network.
When creating new Microsoft Store apps, a developer can define the following network capabilities for their app:
- **Home\\Work Networking**
Provides inbound and outbound access to intranet networks that the user has designated as a home or a work network, or if the network has an authenticated domain controller.
- **Internet (Client)**
Provides outbound access to the Internet and untrusted networks, such as airports and coffee shops (for example, intranet networks where the user has designated the network as Public). Most apps that require Internet access should use this capability.
- **Internet (Client and Server)**
Provides inbound and outbound access to the Internet and untrusted networks, such as airports and coffee shops. This capability is a superset of the **Internet (Client)** capability, and **Internet (Client)** does not need to be enabled if this capability is enabled.
- **Proximity**
Provides near-field communication (NFC) with devices that are in close proximity to the device. Proximity may be used to send files or connect with an application on a proximate device.
**In this topic**
To isolate Microsoft Store apps on your network, you need to use Group Policy to define your network isolation settings and create custom Microsoft Store app firewall rules.
- [Prerequisites](#prerequisites)
- [Step 1: Define your network](#step-1-define-your-network)
- [Step 2: Create custom firewall rules](#step-2-create-custom-firewall-rules)
## Prerequisites
- A domain controller is installed on your network, and your devices are joined to the Windows domain.
- Your Microsoft Store app is installed on the client device.
- The Remote Server Administration Tools (RSAT) are installed on your client device. When you perform the following steps from your client device, you can select your Microsoft Store app when you create Windows Defender Firewall rules.
>**Note:**  You can install the RSAT on your device running Windows from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520).
 
## Step 1: Define your network
The **Home\\Work Networking** capability enables access to intranet resources. Administrators can use Group Policy settings to define the scope of the intranet. This ensures that Microsoft Store apps can access intranet resources appropriately.
A network endpoint is considered part of the **Home\\Work Network** if:
- It is part of the local subnet of a trusted network.
For example, home users generally flag their network as Trusted. Local devices will be designated as such.
- A device is on a network, and it is authenticated to a domain controller.
- Endpoints within the intranet address space are considered private.
- Endpoints within the local subnet are considered private.
- The device is configured for DirectAccess, and the endpoint is part of the intranet address space.
The intranet address space is composed of configured Active Directory sites and subnets, and it is configured for Windows network isolation specifically by using Group Policy. You can disable the usage of Active Directory sites and subnets by using Group Policy by declaring that your subnet definitions are authoritative.
Any proxies that you configure or that are automatically configured with proxy autoconfiguration (by using Web Proxy Auto-Discovery (WPAD) protocol) are exempt from the intranet zone. You can add proxy addresses by using Group Policy.
All other endpoints that do not meet the previously stated criteria are considered endpoints on the Internet.
**To configure a GPO that defines your intranet address space**
1. Open the Group Policy Management snap-in (gpmc.msc), right click on the Group Policy you want to use to define your address space, and select **Edit**.
2. From the Group Policy Management Editor, expand **Computer Configuration**, expand **Policies**, expand **Administrative Templates**, expand **Network**, and click **Network Isolation**.
3. In the right pane, double-click **Private network ranges for apps**.
4. In the **Private network ranges for apps** dialog box, click **Enabled**. In the **Private subnets** text box, type the private subnets for your intranet, separated by commas if necessary.
For example, if the Contoso intranet is defined as 10.0.0.0 with a subnet mask of 255.255.255.0, you would type 10.0.0.0/24 in the **Private subnets** text box.
5. Double-click **Subnet definitions are authoritative**.
If you want the subnet definitions that you previously created to be the single source for your subnet definition, click **Enabled**. Otherwise, leave the **Not Configured** default so that you can add additional subnets by using local settings or network isolation heuristics.
**To configure the proxy addresses for the intranet and Internet**
1. Double-click **Internet proxy servers for apps**. Click **Enabled**, and then in the **Domain Proxies** text box, type the IP addresses of your Internet proxy servers, separated by semicolons.
2. Double-click **Intranet proxy servers for apps**. Click **Enabled**, and then in the IP address text box, type the IP addresses of your intranet proxy servers, separated by semicolons.
3. Double-click **Proxy definitions are authoritative**.
If you want the proxy definitions that you previously created to be the single source for your proxy definition, click **Enabled**. Otherwise, leave the **Not Configured** default so that you can add additional proxies by using local settings or network isolation heuristics.
## Step 2: Create custom firewall rules
Microsoft Store apps can declare many capabilities in addition to the network capabilities discussed previously. For example, apps can declare capabilities to access user identity, the local file system, and certain hardware devices.
The following table provides a complete list of the possible app capabilities.
| Capability | Name | Description |
| - | - | - |
| **Internet (Client)** | internetClient | Your outgoing Internet connection.|
| **Internet (Client &amp; Server)** | internetClientServer| Your Internet connection, including incoming unsolicited connections from the Internet The app can send information to or from your device through a firewall. You do not need to declare **internetClient** if this capability is declared.
| **Home\Work Networking** |privateNetworkClientServer| A home or work network. The app can send information to or from your device and other devices on the same network.|
| **Document Library Access**| documentsLibrary| Your Documents library, including the capability to add, change, or delete files. The package can only access file types that are declared in the manifest.|
| **Picture Library Access**| picturesLibrary| Your Pictures library, including the capability to add, change, or delete files.|
| **Video Library Access**| videosLibrary| Your Videos library, including the capability to add, change, or delete files.|
| **Music Library Access**| musicLibrary|Your Music library, including the capability to add, change, or delete files.|
| **Default Windows Credentials**| defaultWindowsCredentials| Your Windows credentials for access to a corporate intranet. This application can impersonate you on the network.|
| **Removable Storage** | removableStorage| A removable storage device, such as an external hard disk, USB flash drive, or MTP portable device, including the capability to add, change, or delete specific files. This package can only access file types that are declared in the manifest.|
| **Shared User Certificates**| sharedUserCertificates| Software and hardware certificates or a smart card, which the app uses to identify you. This capability can be used by an employer, a bank, or government services to identify you.|
| **Location**| location| Provides access to the user's current location.|
| **Microphone** | microphone| Provides access to the microphone's audio feed.|
| **Near-field Proximity** | proximity| Required for near-field communication (NFC) between devices in close proximity. NFC can be used to send files or connect with an app on a proximate device.|
| **Text Messaging** | sms| Provides access to text messaging functionality.|
| **Webcam** | webcam| Provides access to the webcam's video feed.|
| **Other devices (represented by GUIDs)** | &lt;GUID&gt;| Includes specialized devices and Windows Portable Devices.|
You can create a Windows Defender Firewall policy that is scoped to a set of apps that use a specified capability or scoped to a specific Microsoft Store app.
For example, you could create a Windows Defender Firewall policy to block Internet access for any apps on your network that have the Documents Library capability.
**To block Internet access for any apps on your network that have the Documents Library capability**
1. Open the Group Policy Management snap-in (gpmc.msc).
2. In the left pane, right-click your domain name and click **Create a GPO in this domain, and link it here**.
3. Type a name for the GPO in the **Name** text box, and then click **OK**.
4. Right-click the new GPO, and then click **Edit**.
5. In the Group Policy Management Editor, expand **Computer Configuration**, expand **Policies**, expand **Windows Settings**, expand **Security Settings**, expand **Windows Defender Firewall with Advanced Security**, and click **Windows Defender Firewall – LDAP://…**
6. Right-click **Outbound Rules**, and then click **New Rule**.
7. Click **Custom**, and then click **Next**.
8. Click **Next** on the **Program** page, the **Protocols and Ports** page, and the **Scope** page.
9. On the **Action** page, ensure that **Block the Connection** is selected, and then click **Next**.
10. On the **Profile** page, click **Next**.
11. On the **Name** page, type a name for your rule, and then click **Finish**.
12. In the right pane, right-click your new rule and click **Properties**.
13. Click the **Local Principals** tab, select the **Only allow connections from these users** check box, and then click **Add**.
14. Click **Application Package Properties**, and then click **OK**.
15. In the **Choose Capabilities** dialog box, click **APPLICATION PACKAGE AUTHORITY\\Your documents library**, and then click **OK**.
16. Click the **Scope** tab under **Remote IP addresses**, and then click **Add**.
17. Click **Predefined set of computers**, select **Internet**, and click **OK**.
This scopes the rule to block traffic to Internet devices.
18. Click the **Programs and Services** tab, and in the **Application Packages** area, click **Settings**.
19. Click **Apply to application packages only**, and then click **OK**.
>**Important:**  You must do this to ensure that the rule applies only to Microsoft Store apps and not to other apps. Desktop apps declare all capabilities by default, and this rule would apply to them if you do not configure it this way.
20. Click **OK** to close the **Properties** dialog box.
21. Close the Group Policy Management Editor.
22. In the Group Policy Management snap-in, ensure that your new GPO is selected, and in the right pane under **Security Filtering**, select **Authenticated Users**. Click **Remove**, and then click **OK**.
23. Under **Security Filtering**, click **Add**.
24. Type **domain computers** in the text box, and then click **OK**.
25. Close the Group Policy Management snap-in.
Use the following procedure if you want to block intranet access for a specific media sharing app on your network.
**To block intranet access for a specific media sharing app on your network**
1. Open the Group Policy Management snap-in (gpmc.msc).
2. In the left pane, right-click your domain name, and then click **Create a GPO in this domain, and link it here**.
3. Type a name for your GPO in the **Name** text box, and then click **OK**.
4. Right-click your new GPO, and then click **Edit**.
5. From the Group Policy Management Editor, expand **Computer Configuration**, expand **Policies**, expand **Windows Settings**, expand **Security Settings**, expand **Windows Defender Firewall**, and then click **Windows Defender Firewall – LDAP://**…
6. Right-click **Outbound Rules**, and then click **New Rule**.
7. Click **Custom**, and then click **Next**.
8. Click **Next** on the **Program** page, the **Protocols and Ports** page, and the **Scope** page.
9. On the **Action** page, ensure **Block the Connection** is selected, and then click **Next**.
10. On the **Profile** page, click **Next**.
11. On the **Name** page, type a name for your rule, and then click **Finish**.
12. In the right pane, right-click your new rule, and then click **Properties**.
13. Click the **Local Principals** tab, select the **Only allow connections from these users** check box, and then click **Add**.
14. Click **Application Package Properties**, and then click **OK**.
15. In the **Choose Capabilities** dialog box, click **APPLICATION PACKAGE AUTHORITY\\A home or work network**, and then click **OK**.
16. Click the **Programs and Services** tab under **Application Packages**, and then click **Settings**.
17. Click **Apply to this application package**, select the app in the text box, and then click **OK**.
18. Click **OK** to close the **Properties** dialog box.
19. Close the Group Policy Management Editor.
20. In Group Policy Management, ensure that your new GPO is selected, and in the right pane under **Security Filtering**, select **Authenticated Users**, click **Remove**, and then click **OK**.
21. Under **Security Filtering**, click **Add**.
22. Type **domain computers** in the text box and click **OK**.
23. Close Group Policy Management.
## See also
- [Windows Defender Firewall with Advanced Security Overview](windows-firewall-with-advanced-security.md)

82
windows/security/operating-system-security/network-security/windows-firewall/quarantine.md
View File

@ -1,22 +1,19 @@
---
title: Quarantine behavior
description: Quarantine behavior is explained in detail.
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
description: Learn about Windows Firewall and the quarantine feature behavior.
ms.topic: concept-article
ms.date: 11/21/2023
---
# Quarantine behavior
One of the security challenges that network admins face is configuring a machine properly after a network change.
One of the security challenges that network admins face is configuring a device 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 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.
Network changes can happen frequently. The operations required to recategorize the network after a change, and apply the correct security policies on a device, are nontrivial and might require considerable CPU time. This requirement by operations is especially true for devices that are part of a domain. The delay in applying security policies during network recategorization can be 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 the potential exploitation, Windows Firewall quarantines an interface until the system successfully recategorizes 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.
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.
Ultimately, the goal of this document is to describe the quarantine feature at a high level and help network admins understand why the application traffic is sometimes blocked by quarantine.
This document describes the quarantine feature and explains why the application traffic could be blocked by quarantine.
## Quarantine filters
@ -24,50 +21,42 @@ The quarantine feature creates filters that can be split into three categories:
- Quarantine default inbound block filter
- Quarantine default exception filters
- Interface un-quarantine filters
- Interface unquarantine filters
These filters are added in the FWPM_SUBLAYER_MPSSVC_QUARANTINE sublayer and these layers are:
These filters are added in the `FWPM_SUBLAYER_MPSSVC_QUARANTINE` sublayer and these layers are:
1. FWPM_LAYER_ALE_AUTH_CONNECT_V4
2. FWPM_LAYER_ALE_AUTH_CONNECT_V6
3. FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
4. FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6
1. `FWPM_LAYER_ALE_AUTH_CONNECT_V4`
1. `FWPM_LAYER_ALE_AUTH_CONNECT_V6`
1. `FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4`
1. `FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6`
>[!NOTE]
> Any firewall rules added by the customers will not affect the filters in the quarantine sublayer as filters from Firewall rules are added in the FWPM_SUBLAYER_MPSSVC_WF sublayer. In other words, customers cannot add their own exception filters to prevent packets from being evaluated by quarantine filters.
> Any firewall rules added by policy settings don't affect the filters in the quarantine sublayer. Filters from firewall rules are added in the `FWPM_SUBLAYER_MPSSVC_WF` sublayer. In other words, you can't add your own exception filters to prevent packets from being evaluated by quarantine filters.
For more information about WFP layers and sublayers, see [WFP Operation](/windows/win32/fwp/basic-operation).
### Quarantine default inbound block filter
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.
The *quarantine default inbound block filter* blocks any new nonloopback inbound connections, unless the packet isn't explicitly permitted by another filter in the quarantine sublayer.
### Quarantine default exception filters
When the interface is in quarantine state, the quarantine default exception filters will permit new inbound connections given that they meet the conditions of an exception filter. One example of the exception filters is the quarantine default inbound loopback exception filter. This exception filter allows all loopback packets when the interface is in quarantine state.
When the interface is in quarantine state, the quarantine default exception filters permit new inbound connections given that they meet the conditions of an exception filter. One example of the exception filters is the quarantine default inbound loopback exception filter. This exception filter allows all loopback packets when the interface is in quarantine state.
### Interface un-quarantine filter
### Interface unquarantine filter
The interface un-quarantine filters allow all non-loopback packets if the interface is successfully categorized.
The interface unquarantine filters allow all nonloopback packets if the interface is successfully categorized.
## Quarantine flow
The following events describe the general flow of quarantine:
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.
3. All non-loopback inbound connections are either permitted by quarantine default exception filters or dropped by the quarantine default inbound block filter.
4. The WFP filters applicable to the old interface state are removed.
5. The WFP filters applicable to the new interface state are added, which include the un-quarantine filters for this interface. These filters are updated to match the interface's current state.
6. The interface has now exited quarantine state as the interface un-quarantine filters permit any new non-loopback packets.
1. There's some change on the current network interface
1. The interface unquarantine filters don't permit new inbound connections. The interface is now in quarantine state
1. All nonloopback inbound connections are either permitted by quarantine default exception filters or dropped by the quarantine default inbound block filter
1. The WFP filters applicable to the old interface state are removed
1. The WFP filters applicable to the new interface state are added, which include the unquarantine filters for this interface. These filters are updated to match the interface's current state
1. The interface has now exited quarantine state as the interface unquarantine filters permit any new nonloopback packets
## Quarantine diagnostics
@ -75,7 +64,7 @@ There are two methods of identifying packet drops from the quarantine default in
Given that the network connectivity issue is reproducible, diagnostic traces can be collected by running the following in an administrative command prompt:
```console
```cmd
Netsh wfp cap start
<Reproduce network connectivity issue>
Netsh wfp cap stop
@ -85,15 +74,15 @@ These commands generate a wfpdiag.cab. Inside the .cab exists a wfpdiag.xml, whi
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:
The characters in the application ID name are separated by periods:
```XML
<asString> \\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\\.w.i.n.d.o.w.s.\\.s.y.s.t.e.m.3.2.\\.s.v.c.h.o.s.t...e.x.e... </asString>
<asString> \\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\\.w.i.n.d.o.w.s.\\.s.y.s.t.e.m.3.2.\\.s.v.c.h.o.s.t...e.x.e... </asString>
```
The `netEvent` will have more information about the packet that was dropped including information about its capabilities, the filter that dropped the packet, and much more.
The `netEvent` contains more information about the dropped packet, including information about its capabilities, the filter that dropped the packet, and much more.
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`.
If the filter that dropped that packet was by the quarantine default inbound block filter, then the drop `netEvent` contains `filterOrigin` as `Quarantine Default`.
The following code is a sample `netEvent` with `filterOrigin` as `Quarantine Default`.
@ -171,14 +160,13 @@ The following code is a sample `netEvent` with `filterOrigin` as `Quarantine Def
<interfaceIndex>5</interfaceIndex>
</internalFields>
</netEvent>
```
Alternatively, If the Filtering Platform Connection failure auditing is enabled, the drop event will be logged in Windows Event Viewer.
Alternatively, If the Filtering Platform Connection failure auditing is enabled, the drop event is logged in Windows Event Viewer.
To enable Filtering Platform Connection audits, run the following command in an administrative command prompt:
```console
```cmd
Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable
```
@ -186,15 +174,13 @@ Sample drop audit with `filterOrigin` as `Quarantine Default`.
![Quarantine default.](images/quarantine-default1.png)
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:
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:
```Powershell
Get-NetIPInterface –InterfaceIndex <Interface Index>
Get-NetIPInterface –InterfaceIndex 5
Get-NetIPInterface -InterfaceIndex <Interface Index>
Get-NetIPInterface -InterfaceIndex 5
```
![Quarantine Interfaceindex.](images/quarantine-interfaceindex1.png)
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)).

119
windows/security/operating-system-security/network-security/windows-firewall/rules.md Normal file
View File

@ -0,0 +1,119 @@
---
title: Windows Firewall rules
description: Learn about Windows Firewall rules and design recommendations.
ms.date: 11/21/2023
ms.topic: concept-article
---
# Windows 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.
This article describes the concepts and recommendations for creating and managing firewall rules.
## 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 configuring 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
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.
> [!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.
## Applications rules
When first installed, network 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.
:::row:::
:::column span="2":::
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
:::column-end:::
:::column span="2":::
:::image type="content" source="images/uac.png" alt-text="Screenshot showing the User Account Control (UAC) prompt to allow Microsoft Teams." border="false":::
:::column-end:::
:::row-end:::
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.
### 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:
1. Deploy *WDAC AppId tagging policies*: a Windows Defender Application Control policy must be deployed, which specifies individual applications or groups of applications to apply a *PolicyAppId tag* to the process token(s). Then, the admin can define firewall rules that are scoped to all processes tagged with the matching *PolicyAppId*. For more information, see the [WDAC AppId tagging guide](../../../application-security/application-control/windows-defender-application-control/AppIdTagging/wdac-appid-tagging-guide.md) to create, deploy, and test an AppID policy to tag applications.
1. Configure firewall rules using *PolicyAppId tags* using one of the two methods:
- Using the [PolicyAppId node of the Firewall CSP](/windows/client-management/mdm/firewall-csp#mdmstorefirewallrulesfirewallrulenamepolicyappid) with an MDM solution like Microsoft Intune. If you use Microsoft Intune, you can deploy the rules from Microsoft Intune Admin center, under the path **Endpoint security** > **Firewall** > **Create policy** > **Windows 10, Windows 11, and Windows Server** > **Windows Firewall Rules**. When creating the rules, provide the *AppId tag* in the **Policy App ID** setting
- Create local firewall rules with PowerShell: use the [`New-NetFirewallRule`](/powershell/module/netsecurity/new-netfirewallrule) cmdlet and specify the `-PolicyAppId` parameter. You can specify one tag at a time while creating firewall rules. Multiple User Ids are supported
## Local policy merge and application rules
*Rule merging* policy settings control how rules from different policy sources can be combined. Administrators can configure different merge behaviors for *Domain*, *Private*, and *Public profiles*.
The rule-merging policy settings either allow or prevent local administrators from creating their own firewall rules in addition to those rules obtained from CSP or GPO.
| | Path |
|--|--|
| **CSP** | Domain Profile: `./Vendor/MSFT/Firewall/MdmStore/DomainProfile/`[AllowLocalPolicyMerge](/windows/client-management/mdm/firewall-csp#mdmstoredomainprofileallowlocalpolicymerge) <br> Private Profile`./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/`[AllowLocalPolicyMerge](/windows/client-management/mdm/firewall-csp#mdmstoreprivateprofileallowlocalpolicymerge) <br> Public Profile `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/`[AllowLocalPolicyMerge](/windows/client-management/mdm/firewall-csp#mdmstorepublicprofileallowlocalipsecpolicymerge) |
| **GPO** | **Computer Configuration** > **Windows Settings** > **Security Settings** > **Windows Defender Firewall with Advanced Security**|
Administrators may disable *LocalPolicyMerge* in high-security environments to maintain tighter control over endpoints. This setting can impact some applications and services that automatically generate a local firewall policy upon installation.
> [!IMPORTANT]
> If merging of local policies is disabled, centralized deployment of rules is required for any app that needs inbound connectivity.
It's important to create and maintain a list of 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 deployments, a thorough analysis might be needed using network packet capture tools.
In general, to maintain maximum security, admins should only deploy firewall exceptions for apps and services determined to serve legitimate purposes.
> [!NOTE]
> The use of wildcard patterns, such as `C:\*\teams.exe` isn't supported in application rules. You can only create rules using the full path to the application(s).
## Firewall rules recommendations
Here's a list of recommendations when designing your firewall rules:
- 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.
- 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.
- Configure 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.
- 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.
- 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.
- To maintain maximum security, admins should only deploy firewall exceptions for apps and services determined to serve legitimate purposes.
### 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](#local-policy-merge-and-application-rules) 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.
### Outbound rules considerations
What follows are a few general guidelines for configuring outbound rules.
- 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
> [!div class="nextstepaction"]
> Learn about the tools to configure Windows Firewall and firewall rules:
>
> [Configuration tools >](tools.md)

178
windows/security/operating-system-security/network-security/windows-firewall/securing-end-to-end-ipsec-connections-by-using-ikev2.md
View File

@ -1,178 +0,0 @@
---
title: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012
description: Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012
ms.prod: windows-client
ms.topic: conceptual
ms.date: 09/08/2021
---
# Securing End-to-End IPsec connections by using IKEv2
IKEv2 offers the following:
- Supports IPsec end-to-end transport mode connections
- Provides interoperability for Windows with other operating systems that use IKEv2 for end-to-end security
- Supports Suite B (RFC 4869) requirements
- Coexists with existing policies that deploy AuthIP/IKEv1
- Uses the Windows PowerShell interface exclusively for configuration. You cannot configure IKEv2 through the user interface.
- Uses certificates for the authentication mechanism
You can use IKEv2 as a virtual private network (VPN) tunneling protocol that supports automatic VPN reconnection. IKEv2 allows the security association to remain unchanged despite changes in the underlying connection.
**In this document**
- [Prerequisites](#prerequisites)
- [Devices joined to a domain](#devices-joined-to-a-domain)
- [Device not joined to a domain](#devices-not-joined-to-a-domain)
- [Troubleshooting](#troubleshooting)
>**Note:**  This topic includes sample Windows PowerShell cmdlets. For more info, see [How to Run a Windows PowerShell Cmdlet](/previous-versions//bb648607(v=vs.85)).
## Prerequisites
These procedures assume that you already have a public key infrastructure (PKI) in place for device authentication.
## Devices joined to a domain
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.
![the contoso corporate network.](images/corpnet.gif)
**Figure 1** The Contoso corporate network
This script does the following:
- Creates a security group called **IPsec client and servers** and adds CLIENT1 and SERVER1 as members.
- Creates a Group Policy Object (GPO) called **IPsecRequireInRequestOut** and links it to the corp.contoso.com domain.
- Sets the permissions to the GPO so that they apply only to the computers in **IPsec client and servers** and not to **Authenticated Users**.
- Indicates the certificate to use for authentication.
>**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.
- Creates the IKEv2 connection security rule called **My IKEv2 Rule**.
![powershell logo.](images/powershelllogosmall.gif)**Windows PowerShell commands**
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
```powershell
# Create a Security Group for the computers that will get the policy
$pathname = (Get-ADDomain).distinguishedname
New-ADGroup -name "IPsec client and servers" -SamAccountName "IPsec client and servers" `
-GroupCategory security -GroupScope Global -path $pathname
# Add test computers to the Security Group
$computer = Get-ADComputer -LDAPFilter "(name=client1)"
Add-ADGroupMember -Identity "IPsec client and servers" -Members $computer
$computer = Get-ADComputer -LDAPFilter "(name=server1)"
Add-ADGroupMember -Identity "IPsec client and servers" -Members $computer
# Create and link the GPO to the domain
$gpo = New-gpo IPsecRequireInRequestOut
$gpo | new-gplink -target "dc=corp,dc=contoso,dc=com" -LinkEnabled Yes
# Set permissions to security group for the GPO
$gpo | Set-GPPermissions -TargetName "IPsec client and servers" -TargetType Group -PermissionLevel GpoApply -Replace
$gpo | Set-GPPermissions -TargetName "Authenticated Users" -TargetType Group -PermissionLevel None -Replace
#Set up the certificate for authentication
$gponame = "corp.contoso.com\IPsecRequireInRequestOut"
$certprop = New-NetIPsecAuthProposal -machine -cert -Authority "DC=com, DC=contoso, DC=corp, CN=corp-APP1-CA"
$myauth = New-NetIPsecPhase1AuthSet -DisplayName "IKEv2TestPhase1AuthSet" -proposal $certprop –PolicyStore GPO:$gponame
#Create the IKEv2 Connection Security rule
New-NetIPsecRule -DisplayName "My IKEv2 Rule" -RemoteAddress any -Phase1AuthSet $myauth.InstanceID `
-InboundSecurity Require -OutboundSecurity Request -KeyModule IKEv2 -PolicyStore GPO:$gponame
```
## Devices not joined to a domain
Use a Windows PowerShell script similar to the following to create a local IPsec policy on the devices that you want to include in the secure connection.
>**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.
![powershell logo.](images/powershelllogosmall.gif)**Windows PowerShell commands**
Type each cmdlet on a single line, even though they may appear to wrap across several lines because of formatting constraints.
```powershell
#Set up the certificate
$certprop = New-NetIPsecAuthProposal -machine -cert -Authority "DC=com, DC=contoso, DC=corp, CN=corp-APP1-CA"
$myauth = New-NetIPsecPhase1AuthSet -DisplayName "IKEv2TestPhase1AuthSet" -proposal $certprop
#Create the IKEv2 Connection Security rule
New-NetIPsecRule -DisplayName "My IKEv2 Rule" -RemoteAddress any -Phase1AuthSet $myauth.InstanceID `
-InboundSecurity Require -OutboundSecurity Request -KeyModule IKEv2
```
Make sure that you install the required certificates on the participating computers.
> **Note:**
> - For local devices, you can import the certificates manually if you have administrator access to the computer. For more info, see [Import or export certificates and private keys](https://windows.microsoft.com/windows-vista/Import-or-export-certificates-and-private-keys).
> - You need a root certificate and a computer certificate on all devices that participate in the secure connection. Save the computer certificate in the **Personal/Certificates** folder.
> - For remote devices, you can create a secure website to facilitate access to the script and certificates.
## Troubleshooting
Follow these procedures to verify and troubleshoot your IKEv2 IPsec connections:
**Use the Windows Defender Firewall with Advanced Security snap-in to verify that a connection security rule is enabled.**
1. Open the Windows Defender Firewall with Advanced Security console.
2. In the left pane of the Windows Defender Firewall with Advanced Security snap-in, click **Connection Security Rules**, and then verify that there is an enabled connection security rule.
3. Expand **Monitoring**, and then click **Connection Security Rules** to verify that your IKEv2 rule is active for your currently active profile.
**Use Windows PowerShell cmdlets to display the security associations.**
1. Open a Windows PowerShell command prompt.
2. Type **get-NetIPsecQuickModeSA** to display the Quick Mode security associations.
3. Type **get-NetIPsecMainModeSA** to display the Main Mode security associations.
**Use netsh to capture IPsec events.**
1. Open an elevated command prompt.
2. At the command prompt, type **netsh wfp capture start**.
3. Reproduce the error event so that it can be captured.
4. At the command prompt, type **netsh wfp capture stop**.
A wfpdiag.cab file is created in the current folder.
5. Open the cab file, and then extract the wfpdiag.xml file.
6. Open the wfpdiag.xml file with your an XML viewer program or Notepad, and then examine the contents. There will be a lot of data in this file. One way to narrow down where to start looking is to search the last “errorFrequencyTable” at the end of the file. There might be many instances of this table, so make sure that you look at the last table in the file. For example, if you have a certificate problem, you might see the following entry in the last table at the end of the file:
```xml
<item>
<error>ERROR_IPSEC_IKE_NO_CERT</error>
<frequency>32</frequency>
</item>
```
In this example, there are 32 instances of the **ERROR\_IPSEC\_IKE\_NO\_CERT** error. So now you can search for **ERROR\_IPSEC\_IKE\_NO\_CERT** to get more details regarding this error.
You might not find the exact answer for the issue, but you can find good hints. For example, you might find that there seems to be an issue with the certificates, so you can look at your certificates and the related cmdlets for possible issues.
## See also
- [Windows Defender Firewall with Advanced Security](windows-firewall-with-advanced-security.md)

46
windows/security/operating-system-security/network-security/windows-firewall/toc.yml
View File

@ -1,41 +1,27 @@
items:
- name: Overview
href: windows-firewall-with-advanced-security.md
- name: Configure Windows Firewall
href: best-practices-configuring.md
- name: Configure Hyper-V firewall
href: hyper-v-firewall.md
- name: Configure the Windows Firewall log
href: configure-the-windows-firewall-log.md
- name: Secure connections with IPsec
href: securing-end-to-end-ipsec-connections-by-using-ikev2.md
- name: Configure Windows Firewall with PowerShell
href: windows-firewall-with-advanced-security-administration-with-windows-powershell.md
- name: Isolate Microsoft Store apps on your network
href: isolating-apps-on-your-network.md
- name: Firewall rules
href: index.md
- name: Firewall rules concepts
href: rules.md
- name: Configure and manage Windows Firewall
items:
- name: Create firewall rules with Microsoft Intune
href: create-windows-firewall-rules-in-intune.md
- name: Create an inbound ICMP rule
href: create-an-inbound-icmp-rule.md
- name: Create an inbound port rule
href: create-an-inbound-port-rule.md
- name: Create an inbound program or service rule
href: create-an-inbound-program-or-service-rule.md
- name: Create an outbound port rule
href: create-an-outbound-port-rule.md
- name: Create an outbound program or service rule
href: create-an-outbound-program-or-service-rule.md
- name: Create inbound rules to support RPC
href: create-inbound-rules-to-support-rpc.md
- name: Configuration tools
href: tools.md
- name: Configure with Microsoft Intune 🔗
href: /mem/intune/protect/endpoint-security-firewall-policy
- name: Configure with group policy
href: configure.md
- name: Configure with command line tools
href: configure-with-command-line.md
- name: Hyper-V firewall
href: hyper-v-firewall.md
- name: Troubleshoot
items:
- name: Configure Windows Firewall logging
href: configure-logging.md
- name: Troubleshoot UWP app connectivity issues in Windows Firewall
href: troubleshooting-uwp-firewall.md
- name: Filter origin audit log improvements
href: filter-origin-documentation.md
- name: Quarantine behavior
href: quarantine.md
- name: Firewall settings lost on upgrade
href: firewall-settings-lost-on-upgrade.md

146
windows/security/operating-system-security/network-security/windows-firewall/tools.md Normal file
View File

@ -0,0 +1,146 @@
---
title: Windows Firewall tools
description: Learn about the available tools to configure Windows Firewall and firewall rules.
ms.date: 11/20/2023
ms.topic: best-practice
---
# Windows Firewall tools
Windows offers different tools to view the status and configure Windows Firewall. All tools interact with the same underlying services, but provide different levels of control over those services:
- [Windows Security](#windows-security)
- [Control Panel](#control-panel)
- [Windows Defender Firewall with Advanced Security](#windows-defender-firewall-with-advanced-security) (WFAS)
- [Configuration Service Provider (CSP)](#configuration-service-provider-csp)
- [Command line tools](#command-line-tools)
> [!NOTE]
> To change the configuration of Windows Firewall on a device, you must have administative rights.
:::row:::
:::column span="4":::
#### Windows Security
:::column-end:::
:::row-end:::
:::row:::
:::column span="3":::
The *Windows Security* app can be used to view the Windows Firewall status and access advanced tools to configure it. Select <kbd>START</kbd>, type `Windows Security`, and press <kbd>ENTER</kbd>. Once Windows Security is open, select the tab **Firewall & network protection**. Or use the following shortcut:
> [!div class="nextstepaction"]
> [Open Firewall & network protection][SEC-1]
:::column-end:::
:::column span="1":::
:::image type="content" source="images/windows-security.png" alt-text="Screenshot showing the Windows Security app." lightbox="images/windows-security.png" border="false":::
:::column-end:::
:::row-end:::
:::row:::
:::column span="4":::
#### Control Panel
:::column-end:::
:::row-end:::
:::row:::
:::column span="3":::
The *Windows Defender Firewall* Control Panel applet provides basic functionalities to configure Windows Firewall. Select <kbd>START</kbd>, type `firewall.cpl`, and press <kbd>ENTER</kbd>.
:::column-end:::
:::column span="1":::
:::image type="content" source="images/control-panel.png" alt-text="Screenshot showing the Windows Defender Firewall control panel applet." lightbox="images/control-panel.png" border="false":::
:::column-end:::
:::row-end:::
:::row:::
:::column span="4":::
#### Windows Defender Firewall with Advanced Security
:::column-end:::
:::row-end:::
:::row:::
:::column span="3":::
The *Windows Defender Firewall with Advanced Security* (WFAS) is a Microsoft Management Console (MMC) snap-in that provides advanced configuration functionalities. It can be used locally and in group policy (GPO) implementations.
- If you are configuring a single device, select <kbd>START</kbd>, type `wf.msc`, and press <kbd>ENTER</kbd>
- If you're configuring devices joined to an Active Directory domain, [create or edit](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc754740(v=ws.11)) a group policy object (GPO) and expand the nodes **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Windows Firewall with Advanced Security**
:::column-end:::
:::column span="1":::
:::image type="content" source="images/wfas.png" alt-text="Screenshot of the Windows Defender Firewall with Advanced Security MMC snap-in." lightbox="images/wfas.png" border="false":::
:::column-end:::
:::row-end:::
:::row:::
:::column span="4":::
#### Configuration Service Provider (CSP)
:::column-end:::
:::row-end:::
:::row:::
:::column span="4":::
The [Firewall CSP][CSP] provides an interface to configure and query the status of Windows Firewall, which can be used with a mobile device management (MDM) solution like Microsoft Intune.
:::column-end:::
:::row-end:::
:::row:::
:::column span="4":::
#### Command line tools
:::column-end:::
:::row-end:::
:::row:::
:::column span="4":::
The `NetSecurity` PowerShell module and `Network Command Shell (netsh.exe)` are command line utilities that can be used to query the status and configure Windows Firewall.
:::column-end:::
:::row-end:::
## Group policy processing considerations
The Windows Firewall policy settings are stored in the registry. By default, group policies are refreshed in the background every 90 minutes, with a random offset between 0 and 30 minutes.
Windows Firewall monitors the registry for changes, and if something is written to the registry it notifies the *Windows Filtering Platform (WFP)*, which performs the following actions:
1. Reads all firewall rules and settings
1. Applies any new filters
1. Removes the old filters
> [!NOTE]
> The actions are triggered whenever something is written to, or deleted from the registry location the GPO settings are stored, regardless if there's really a configuration change. During the process, IPsec connections are disconnected.
Many policy implementations specify that they're updated only when changed. However, you might want to update unchanged policies, such as reapplying a desired policy setting in case a user has changed it. To control the behavior of the registry group policy processing, you can use the policy **Computer Configuration** > **Administrative Templates** > **System** > **Group Policy** > **Configure registry policy processing**. The **Process even if the Group Policy objects haven't changed** option updates and reapplies the policies even if the policies haven't changed. This option is disabled by default.
If you enable the option **Process even if the Group Policy objects haven't changed**, the WFP filters get reapplied at **every** background refresh. In case you have 10 group policies, the WFP filters get reapplied 10 times during the refresh interval. If an error happens during policy processing, the applied settings might be incomplete, resulting in issues like:
- Windows Firewall blocks inbound or outbound traffic allowed by group policies
- Local Firewall settings are applied instead of group policy settings
- IPsec connections can't establish
The temporary solution is to refresh the group policy settings, using the command `gpupdate.exe /force`, which requires connectivity to a domain controller.
To avoid the issue, leave the policy **Configure registry policy processing** to the default value of **Not Configured** or, if already configured, configure it **Disabled**.
> [!IMPORTANT]
> The checkbox next to **Process even if the Group Policy objects have not changed** must be unchecked. If you leave it unchecked, WFP filters are written only in case there's a configuration change.
>
> If there's a requirement to force registry deletion and rewrite, then disable background processing by checking the checkbox next to **Do not apply during periodic background processing**.
## *Shields up* mode for active attacks
An important Windows Firewall feature you can use to mitigate damage during an active attack is the *shields up* mode. It's an informal term referring to an easy method a firewall administrator can use to temporarily increase security in the face of an active attack.
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 Control Panel.
:::image type="content" alt-text="Screenshot of the Windows Security app showing incoming connections." source="images/fw06-block.png":::
:::image type="content" alt-text="Screenshot of the Control Panel Firewall applet." source="images/fw07-legacy.png":::
By default, the Windows Firewall blocks everything unless there's an exception rule created. The *shield up* option overrides the exceptions. For example, the Remote Desktop feature automatically creates firewall rules when enabled. However, if there's an active exploit using multiple ports and services on a host, you can, instead of disabling individual rules, use the shields up mode to block all inbound connections, overriding previous exceptions, including the rules for Remote Desktop. The Remote Desktop rules remain intact but remote access can't work as long as shields up is active.
Once the emergency is over, uncheck the setting to restore regular network traffic.
## Next steps
From the following dropdown, select one of tools to learn how to configure Windows Firewall:
> [!div class="op_single_selector"]
>
> - [Configure with Microsoft Intune 🔗][INT-1]
> - [Configure with group policy](configure.md)
> - [Configure with command line tools](configure-with-command-line.md)
<!--links-->
[SEC-1]: windowsdefender://network/
[CSP]: /windows/client-management/mdm/firewall-csp
[INT-1]: /mem/intune/protect/endpoint-security-firewall-policy

40
windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security.md
View File

@ -1,40 +0,0 @@
---
title: Windows Defender Firewall with Advanced Security
description: Learn overview information about the Windows Defender Firewall with Advanced Security (WFAS) and Internet Protocol security (IPsec) features.
ms.prod: windows-client
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.date: 09/08/2021
---
# Windows Defender Firewall with Advanced Security
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 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 doesn't provide enough centralized management or security features to help secure more complex network traffic found in a typical business enterprise environment.
[!INCLUDE [windows-firewall](../../../../../includes/licensing/windows-firewall.md)]
## Feature description
Windows Defender Firewall with Advanced Security is an important part of a layered security model. By providing host-based, two-way network traffic filtering for a device, Windows Defender Firewall blocks unauthorized network traffic flowing into or out of the local device. Windows Defender Firewall also works with Network Awareness so that it can apply security settings appropriate to the types of networks to which the device is connected. Windows Defender Firewall and Internet Protocol Security (IPsec) configuration settings are integrated into a single Microsoft Management Console (MMC) named Windows Defender Firewall, so Windows Defender Firewall is also an important part of your network's isolation strategy.
## Practical applications
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 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'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).

2
windows/security/operating-system-security/system-security/windows-defender-security-center/wdsc-firewall-network-protection.md
View File

@ -7,7 +7,7 @@ ms.topic: article
# Firewall and network protection
The **Firewall & network protection** section contains information about the firewalls and network connections used by the machine, including the status of Windows Defender Firewall and any other third-party firewalls. IT administrators and IT pros can get configuration guidance from the [Windows Defender Firewall with Advanced Security documentation library](../../network-security/windows-firewall/windows-firewall-with-advanced-security.md).
The **Firewall & network protection** section contains information about the firewalls and network connections used by the machine, including the status of Windows Defender Firewall and any other third-party firewalls. IT administrators and IT pros can get configuration guidance from the [Windows Defender Firewall with Advanced Security documentation library](../../network-security/windows-firewall/index.md).
This section can be hidden from users of the machine. This information is useful if you don't want employees in your organization to see or have access to user-configured options for the features shown in the section.

2
windows/security/operating-system-security/system-security/windows-defender-security-center/windows-defender-security-center.md
View File

@ -70,7 +70,7 @@ For more information about each section, options for configuring the sections, a
>
> Microsoft Defender Antivirus will be [disabled automatically when a third-party antivirus product is installed and kept up to date](/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-compatibility).
>
> Disabling the Windows Security Center Service won't disable Microsoft Defender Antivirus or [Windows Defender Firewall](../../network-security/windows-firewall/windows-firewall-with-advanced-security.md).
> Disabling the Windows Security Center Service won't disable Microsoft Defender Antivirus or [Windows Defender Firewall](../../network-security/windows-firewall/index.md).
> [!WARNING]
> If you disable the Windows Security Center Service, or configure its associated group policy settings to prevent it from starting or running, **Windows Security** may display stale or inaccurate information about any antivirus or firewall products you have installed on the device.

2
windows/security/threat-protection/index.md
View File

@ -26,7 +26,7 @@ See the following articles to learn more about the different areas of Windows th
- [Network Protection](/microsoft-365/security/defender-endpoint/network-protection)
- [Virtualization-Based Protection of Code Integrity](../hardware-security/enable-virtualization-based-protection-of-code-integrity.md)
- [Web Protection](/microsoft-365/security/defender-endpoint/web-protection-overview)
- [Windows Firewall](../operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security.md)
- [Windows Firewall](../operating-system-security/network-security/windows-firewall/index.md)
- [Windows Sandbox](../application-security/application-isolation/windows-sandbox/windows-sandbox-overview.md)
## Next-generation protection