Part 2 of this series will go over the configuration of the Windows Firewall via Group Policy on servers and Domain Controllers. Servers and Domain Controllers are only just slightly more complicated than clients; since these provide unique services to clients, they will all require unique policies per server/group of servers. However, they can all still benefit from inheriting a top-level policy containing a few basic rules for remote management purposes.
Top Level Server Policy
Starting similarly to clients, create a new GPO linked to all servers to configure a default firewall policy, and include some base rules for remote management purposes.
The above is an example of what a top-level server firewall policy can look like. It includes a number of builtin rules related to remote management of different services, all restricted to a single remote IP address. Similarly to the client configuration, the firewall options are also configured to block inbound/allow outbound traffic by default for all profiles, and to prevent local rules from applying.
NOTE: In a production environment, I would recommend not disabling local rules right away, as you most likely have local rules driving your services currently. Instead, that can be tackled one by one as new server specific policies are created.
This policy also contains one custom rule, at the top of this list, for remote SMB access. A custom rule was created for this, as the builtin rule may be used in later policies, and when policies merge together during application, all rule names must be unique.
Server-specific Policies
Next, create a new policy for for a specific server. In a new GPO, linked to the the server-specific OU, add builtin and custom rules as necessary.
The above policy is an example of a server-specific firewall policy, in this case, for a ConfigMgr server. It contains rules to allow access to the various ConfigMgr services from anywhere, a scoped rule for SMB access from my local subnet, and specific rules for RPC, WMI, and SQL, for local management access.
If any installed applications created their own local firewall rules, these can easily by copy/pasted from the local firewall management console (wf.msc) to a GPO. I’ve done this in the above GPO for the “ConfigMgr PXE Responder Service” rules.
Pro-tip: you can even copy/paste these across an RDP session!
Once this policy has applied, and confirmed functional, go back and disable local rules from applying, and again confirm that everything still works as expected.
This process should continue, across each server/group of servers, until all have been converted to only having firewall rules applied via policy. This work will involve inventorying all servers and what ports need to be open on them, including between servers, such as a group of application servers that need to access a group of SQL servers.
Once this has been completed, and all servers have firewall policies defined, local firewall rule application can be disabled from the top down, ensuring that all existing servers only apply firewall rules defined in Group Policy, and that new servers added later must have an associated firewall policy configured from the start.
Domain Controller Policy
Domain Controllers are mostly just specialized servers, which require their own set of policies to configure the Windows Firewall.
In a new GPO linked to the Domain Controllers OU, start by adding all of the builtin rules necessary for Active Directory and related services to function.
In the above policy, I have added builtin rules for the various AD-related services that clients need to access. I’ve also added rules for DHCP, as I am running DHCP on my lab DCs (this would normally be on separate servers in a production environment).
I’ll now create a second policy for inter-DC traffic.
In the above policy, I have added a number of rules for services such as DFS-R, DHCP, and DNS, for replication and management purposes. All of these rules have been scoped to the IP addresses of my DCs under local and remote addresses. When DCs are later added/removed, this policy must be revisited and updated to ensure functionality.
After all of the above is complete, and functionality verified, go back and block local rules from applying, necessitating that all firewall rules must be defined in policy.
Summary
After accomplishing the above, all servers and Domain Controllers are now also in a much more secure state, similar to the result of clients in the previous post. Firewall policy creation must now be built into the new server build process to ensure any installed applications function as expected.
Hi, I don’t suppose there is an export of these rules anywhere so we can see the path to executables etc? Thanks
I don’t have an export handy, but all of the DC related rules are all builtin and can easily be added via the add rule wizard, and selecting from the various rule groups (ADDS, DNS Server, etc.).