Semi-Automate ConfigMgr Firewall Settings

jonasoh · ‎May 23 2022

Hi, Jonas here!

Or as we say in the north of Germany: "Moin Moin!"
I’m a Microsoft Senior Customer Engineer with a broad spectrum of interests.

Due to recent events multiple customers have questioned their infrastructure security concept and approached me with questions about possible improvements to their Microsoft Endpoint Configuration Manager (aka ConfigMgr or MECM) infrastructure.

One way of dealing with on-premises infrastructure challenges could be the move to a cloud service like Intune. But that might not be an option for everyone, or it might not be an immediate option.

TL;DR

This blog post is not a direct answer to every security measure possible and more dedicated to a script I wrote to semi-automate the ConfigMgr infrastructure firewall configuration based on the following documenation ConfigMgr Ports. So, it’s main purpose is to give other ConfigMgr admins the option to further harden their infrastructure firewall setup in an easy way.
It can either set rules directly, just show New-NetFirewallRule commands for a system, or add the rules to an existing Active Directory Group Policy.

Zero trust principles

As a Microsoft employee I’m trained to follow the three zero trust principles.
Those principles help to answer the question on how to strengthen ConfigMgr’s security setup.
Learn more about the topic via: https://aka.ms/zerotrust

#1 Verify explicitly

Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.

#2 Use least privileged access

Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive polices, and data protection to help secure both data and productivity.

#3 Assume breach

Minimize blast radius and segment access. Verify end-to-end encryption and use analytics to get visibility, drive threat detection, and improve defenses.

Semi-Automated ConfigMgr firewall rules

Since we have to assume breach and we want to minimize blast radius within a ConfigMgr infrastructure we should minimize options for lateral movement and limit service access by setting the correct firewall rules on each server.
Since I’m a PowerShell enthusiast and always like a good PowerShell challenge, I decided to write a script to set the required firewall rules on each site system in a semi-automated way.
The goal was to get the required inbound rule PowerShell commands for each ConfigMgr site system with a list of IP addresses like this example:

New-NetFirewallRule -DisplayName "MECM CAS to Primary Site" -Direction "Inbound" -RemoteAddress ("10.10.10.20") -Protocol "TCP" -LocalPort 445 -Profile "Any" -Action "Allow" -Group "MECM-v1" -LocalAddress ("10.10.10.15")

Before going into the inner workings of the script, let’s have a look at possible ConfigMgr environment setups.

ConfigMgr has many different roles and can be a simple setup with just one server hosting all required roles or a complex setup with many systems and all kinds of role configurations.
The following pictures show two examples of a simple and a complex ConfigMgr setup.
Important: Not all required connections are shown in the pictures and not all required roles are visible. It is just meant to show that creating firewall rules for each system and create “communication-bubbles” (green boxes) can be challenging when having a dispersed set of roles and servers.

ConfigMgr Infrastructure Example

SAW = Secure Admin Workstation

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implemen...

https://www.microsoft.com/en-us/insidetrack/protecting-high-risk-environments-with-secure-admin-work...

How to use the script

The script should be used in the following way.
(More details about each parameter can be found in section: “The script in more detail”)

Copy the script and the “Default-FirewallRuleConfig.json” file to a ConfigMgr SMS Provider machine. The file contains a list of almost all firewall rules from the official documentation

Start the script in an admin session with the following parameters:

.\New-ConfigMgrFirewallRuleDefinition.ps1 -ExportConfigMgrSystemRoleInformation -ProviderMachineName "your provider machinename" -SiteCode "your sitecode"

Now start the script without any parameter to open a GridView
NOTE: The script will not set anything on the system directly when used without any parameter!
Choose the newly created JSON file in the GridView and click “OK”
Choose a system you want local inbound rules for from the GridView and click “OK”
Validate the inbound rules for that system. Select the ones you want to have commands for and click “OK”
A new GridView should now open with the correct New-NetFirewallRule commands. Simply copy and paste the commands and run them in a PowerShell admin session if desired.
The whole process would look like this:Create rules process gif
Now play around with the other parameters and try to find the best matching setting for your environment. More details can be found in section: “The script in more detail”

Validate and set ConfigMgr firewall rules

The script might not take any possible ConfigMgr configuration into account and it is always a good idea to test settings before applying them. Here are some tips on how to validate the rules:

Start with the Primary Site or CAS server and work on site systems later
Make sure to change the JSON ServiceDefinition section in case you use custom ports for any role
Validate each rule shown in the GridView. The link to the documentation can be found in the description of each rule
If you want each rule to be applied to the “Domain” profile only, replace "Profile": "Any" with "Profile": "Domain" in the JSON definition file. Don’t just replace “Any”!
TIP: Use Visual Studio Code to work with JSON files. VSCode will tell you if the JSON is broken. Due to a missing comma for example.
Some rules have extra comments in the description. In case the rule is just required under certain circumstances for example. So, check the description and maybe validate the rule in the official documentation.
IMPORTANT: Make note of any extra systems or existing rules you require to manage the servers
1. Systems you use to connect via RDP or the ConfigMgr console for example.
2. Either add such external systems to the JSON definition file or manually create rules for them.
3. To add a system to the JSON file read section: “The “Default-FirewallRuleConfig.json” file in more detail”
Add all the rules you validated on the destination system either via the -AddRulesLocally parameter or by running the New-NetFirewallRule commands manually. (-ShowCommands)
NOTE: This should not break anything, since they only allow traffic and don’t block anything.
Enable Firewall logging for dropped packages
Firewall-Logging Settings
Now start to disable all other firewall rules except the ones you need for remote management (like RDP or Remote Management for Windows Admin Center for example) and monitor the firewall log for any dropped packages
In case of dropped packages validate the IP and port in question and either adjust the JSON definition file to create the correct rules or add rules manually.
If you think a rule is missing, consult the ConfigMgr ports documentation and maybe adjust the JSON definition file or leave a pull request or issue on my GitHub repository
IMPORTANT: The definition does not contain any rules for Distribution Point Multicast.
TIP: You can filter rules by group name via the “Filter by Group” action: Firewall Filter by Group
The script will use date and time as group suffix, but you could use your own suffix via parameter: -GroupSuffix

The script in more detail

The script has six different modes of operation and uses a file called “Default-FirewallRuleConfig.json” to work. The file contains a list of possible firewall rules based on the official ConfigMgr port documentation.
While the script is designed for ConfigMgr, with a few tweaks in the JSON file it should also be possible to use it for any other product.
(Note: The script works more like a module and might be slightly overengineered ;) )

Six main operational modes via parameter:

Export ConfigMgr site and hierarchy information and create new JSON file
- (-Export ConfigMgrSystemRoleInformation)
Show exported or example configuration from JSON file
- (-ShowConfig)
Show PowerShell commands to set firewall rules
- (-ShowCommands)
Show PowerShell commands to import firewall rules into a group policy
- (-ShowGPOCommands)
Add firewall rules locally
- (-AddRulesLocally)
Add firewall rules to group policy
- (-AddRulesToGPO)

Parameter -ExportConfigMgrSystemRoleInformation

Copy the script: “New-ConfigMgrFirewallRuleDefinition.ps1” and the file “Default-FirewallRuleConfig.json” to a machine with access to the SMS Provider.
(You need to be a ConfigMgr full admin to use the export parameter)
Run the following command:

.\New-ConfigMgrFirewallRuleDefinition.ps1 -ExportConfigMgrSystemRoleInformation -ProviderMachineName "your provider machinename" -SiteCode "your sitecode"

The script will then read the ConfigMgr hierarchy information as well as the “Default-FirewallRuleConfig.json” file and will create a new file in the same directory as the script itself.
The new file contains the same information as in “Default-FirewallRuleConfig.json” but with a list of systems of your ConfigMgr environment.

(You can add systems, rule entries or service definitions manually if needed)

Parameter -ShowConfig

ShowConfig will open a grid view with possible JSON definition files you can choose from.
If you pick a file and click “OK” It will open three other grid views showing the contents of the file.

Parameter -ShowCommands

This is the default parameter if no parameter has been used.
ShowCommands will open a grid view with possible JSON definition files you can choose from.
The script will then open another grid view with the list of systems of the selected file.
Choose a system and click “OK” to get a list of matching firewall rules based on roles installed of the system. The commands can be copied to the selected machine and run in PowerShell.

Parameter -ShowGPOCommands

The same as with ShowCommands but with additional commands to add the firewall rules to a group policy. You can then copy the commands to a system with access to the GPO or run them locally.
The following parameters are also required in that case:

-DomainName [Name of domain / Example: contoso.local]
-GPOName [Name of existing GPO / Example: Firewall-GPO]

Parameter -AddRulesLocally

The same as with ShowCommands but the firewall rules will be set directly on the system running the script.

Parameter -AddRulesToGPO

The same as with AddRulesLocally but instead of local rules, the rules will be added directly to a GPO.
This might require additional rights to be successful.
The following parameters are also required in that case:

-DomainName [Name of domain / Example: contoso.local]
-GPOName [Name of existing GPO / Example: Firewall-GPO]

The above parameters are the main ones, but there are some more to manipulate the output of the script no matter which main mode was chosen.

Parameter -GroupSuffix

Suffix to a firewall rule group. The group name is part of the JSON definition file.

Parameter -UseAnyAsLocalAddress

Will set the local address to ANY instead of the actual local IP address of a system
Helpful if a firewall GPO should work for multiple systems instead of just for one with a specific IP address

Parameter -ValidRulesOnly

Will only show rules with status OK

Parameter -MergeSimilarRules

When used, the script will merge similar rules based on direction, protocol, port and program. Can be used to minimize the required rules.
The list shown left will be merged to the list shown on the right side of the picture:

Merge Rule Example

Parameter -IPType

The script will lookup IP addresses for any system of the config file. The parameter can be used to either limit the results to IPv4 or IPv6 or to output both types of IP addresses. The script will try to lookup IPv4 IP addresses for each system by default.

Parameter -DefinitionFilePath

Path to a JSON definition file. If not used, a grid view will open from which a file can be chosen.
The parameter could be used in case you always work with just one file and don’t want to use the GridView selection.

Parameter -CreateOutboundRuleForeachInboundRule

To create an outbound rule for each calculated inbound rule. Not quite tested and more experimental

The “Default-FirewallRuleConfig.json” file in more detail

The file “Default-FirewallRuleConfig.json” consists of four sections:

Documentation
- The documentation and a description of each field baked into the config file

SystemAndRoleList

Contains a representation of a ConfigMgr hierarchy in the form of server objects with server properties like the IP Address, the ConfigMgr SiteCode and a list of present ConfigMgr roles. Each role is used to determine the required firewall rules. The SiteCode and ParentSiteCode are used to determine which site system belongs to which site.

The first example entry is a CAS with the SQL server on the same server. The second example is a non ConfigMgr terminal server for ConfigMgr console usage and RDP connections to the infrastructure:

{ 
            "FullQualifiedDomainName":  "CAS.contoso.local", 
            "IPAddress":  "10.11.12.13", 
            "SiteCode":  "CAS", 
            "ParentSiteCode":  "CAS", 
            "Description":  "Main central administration site in Europe", 
            "RoleList":  [ 
                             "CASSQLServerRole", 
                             "SQLServerRole", 
                             "CentralAdministrationSite", 
                             "SMSProvider", 
                             "PrimarySoftwareUpdatePoint", 
                             "CentralSoftwareUpdatePoint", 
                             "SoftwareUpdatePoint", 
                             "EndpointProtectionPoint" 
                         ] 
}, 
{ 
            "FullQualifiedDomainName": "ts01.contoso.local", 
            "IPAddress": "10.10.11.12", 
            "SiteCode":  "P01", 
            "ParentSiteCode":  "",             
            "Description": "Terminal Server 1", 
            "RoleList": [ 
                            "RDP", 
                            "MECMConsole" 
                        ] 
}

RuleDefinition

Contains an almost complete list of ConfigMgr firewall rules based on the official documentation https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/ports

The following example entry would allow the terminal server in the example above to connect to any SMS Provider Server of the site with sitecode P01 (Sitecode in the system definition):

{ 
            "RuleName": "MECM Console to SMS provider", 
            "Source": "MECMConsole", 
            "Destination": "SMSProvider", 
            "Direction": "Inbound", 
            "Action": "Allow", 
            "Profile": "Any", 
            "Group": "MECM", 
            "Description": "Console to WMI SMS provider connection. HTTPS for AdminService", 
            "IgnoreSiteCode": "", 
            "Services": [ 
                            "RPC", 
                            "RPCUDP", 
                            "RPCDynamic", 
                            "HTTPS" 
                        ] 
}

ServiceDefinition
- Contains a list of firewall services. Like the protocol, the port or a program.
  Each entry can be used for a rule definition as shown above. The description will not be part of the rule and is just meant to further describe the rule in the config file.
- Example entry:
```
{ 
            "Name": "HTTPS", 
            "Protocol": "TCP", 
            "Port": "443", 
            "Program": "", 
            "Description": "Https endpoint" 
}
```

Add systems, rules or services to JSON config

You can add as many systems, rules or services to the JSON config as you like. While this might not be necessary for ConfigMgr site systems, since those can be exported, it might be necessary for external systems with the need to access ConfigMgr.
Use the documentation which is part of the default JSON file and simply copy and paste existing entries and change them to your needs.
All possible values are part of the documentation in the JSON file, but you can also define your own roles or services.

Other security measures

Configuring the local firewall of a ConfigMgr site system is just one part of a security strategy.
Consult the ConfigMgr security documentation to read more about that topic: https://docs.microsoft.com/en-us/mem/configmgr/core/understand/fundamentals-of-security

Some general security tips

This is not a complete list and is mainly a summary of what is in the documentation already.

Configure the local firewall of each site system as described above.
By default, the Local System account and the user account that you used to install Configuration Manager can administer all objects in the site database.
So, take extra care of the system and user account and limit access.
Activate at least E-HTTP or configure your infrastructure to use PKI certificates
- E-HTTP is already part of the pre-req check.
- This can also help to get rid of the need for a network access account: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/accounts#network-access-ac...

Consider the use of IPSec for site system to site system communication. The following article might help: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/securing-dc-to-dc-communicat...
Consider to enable multi-factor authentication for SMS provider calls.
Consider the use of SAWs (Secure Admin Workstation) to manage the ConfigMgr infrastructure.
- https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implemen...
- https://www.microsoft.com/en-us/insidetrack/protecting-high-risk-environments-with-secure-admin-work...

Consider the use of service accounts instead of the site server computer account to install site systems.
Consider to activate the option: “Require the site server to initiate connections to this site system” to limit the inbound firewall rules for a Primary Site.
Consider the use of service accounts for management points (MP) to limit SQL database access for MPs to a minimum. This could even be a local SQL server account.
Consult the documentation for required rights: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/accounts#management-point-...

Use CMPivot, the Scripts feature and the “Collect Client Logs” feature rather then connecting to client machines with a privileged user.
Always set your WSUS server to use SSL
- https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy...
Enable F8 support in WinPE Images only for testing and in scenarios where you have full control over the deployment process. Because F8 support gives access to the whole task sequence environment.

Conclusion and GitHub link

I hope the article is written understandably and I hope the solution will help you further harden your ConfigMgr infrastructure.

Download or clone the solution here: https://github.com/jonasatgit/scriptrepo/tree/master/Firewall

Feel free to check out other blogs I wrote or co-authored:

https://aka.ms/jonasohmsenblogs

https://aka.ms/stefanroellblogs

Stay safe!

Jonas Ohmsen
Microsoft Germany

Disclaimer:

This posting is provided "AS IS" with no warranties, and confers no rights.

Products (52)

Special Topics (28)

Video Hub (447)

Most Active Hubs