split firewall rules article

windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line.md

@@ -2,7 +2,7 @@
 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: 11/15/2023
+ms.date: 11/20/2023
 ---
 
 # Manage Windows Firewall with the command line
@@ -285,7 +285,7 @@ netsh advfirewall consec add rule name="Require Inbound Authentication" endpoint
 
 ### 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.

windows/security/operating-system-security/network-security/windows-firewall/index.md

@@ -2,7 +2,7 @@
 title: Windows Firewall overview 
 description: Learn overview information about the Windows Firewall security feature.
 ms.topic: conceptual
-ms.date: 11/14/2023
+ms.date: 11/20/2023
 ---
 
 # Windows Firewall overview
@@ -61,18 +61,21 @@ The *domain network* profile is automatically applied to a device that is joined
 
 #### :::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 on a network interface by an administrator.
+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 the tools to configure Windows Firewall, firewall rules, and some recommended practices:
 >
-> [Configure Windows Firewall >](configure.md)
+> [Windows Firewall rules >](rules.md)
 
 ## :::image type="icon" source="images/feedback.svg" border="false"::: Provide feedback
 

windows/security/operating-system-security/network-security/windows-firewall/rules.md

@@ -0,0 +1,79 @@
+---
+title: Windows Firewall rules
+description: Learn about Windows Firewall rules and best practices for creating and managing them.
+ms.date: 11/15/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 best practices 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.
+
+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.
+
+## 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* 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.
+
+- The default configuration of Blocked for Outbound rules can be considered for certain highly secure environments. However, the Inbound rule configuration should never be changed in a way that allows traffic by default
+- It's recommended to Allow Outbound by default for most deployments for the sake of simplification around app deployments, unless the organization prefers tight security controls over ease-of-use
+- In high security environments, an inventory of all apps should be logged and maintained. Records must include whether an app used requires network connectivity. Administrators need to create new rules specific to each app that needs network connectivity and push those rules centrally, via GPO or CSP.
+
+## Next steps
+
+> [!div class="nextstepaction"]
+> Learn about the tools to configure Windows Firewall and firewall rules:
+>
+> [Configure Windows Firewall >](configure.md)

windows/security/operating-system-security/network-security/windows-firewall/toc.yml

@@ -1,6 +1,8 @@
 items:
   - name: Overview
     href: index.md
+  - name: Firewall rules
+    href: rules.md
   - name: Configure and manage Windows Firewall
     items: 
     - name: Configure Windows Firewall