If you want to follow the Security Technical Implementation Guide (STIG) for Active Directory you will come across V-53727, AD.0015, stating that internet access should be restricted. If you ask Microsoft what you should do, they also state internet access should be restricted but provide no clear mechanism to do so.
(https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack#blocking-internet-access-for-domain-controllers)
What is the best way to turn off browsing the internet on Domain Controllers that doesn’t involve contacting your Information Security team? I’m glad you asked. I’m going to walk you through the process I’ve put forward to implement locked down Windows Firewall rules on the Domain Controllers.
There may be criticism here that things could be locked down even more, and I DO NOT disagree with you. This article is more about getting started on locking down your Domain Controllers not the solve-all be-all guide. This write-up is one of many I hope to include in a Domain Controller Hardening Series.
NOTE: These Firewall Rules May Not Work For Your Organization! We are not running DHCP, WINS, or Integrated AD DNS. We also have RPC dynamic ports locked to 1,000 ports.
For changing RPC ports on the Domain Controllers, I followed this article:
Create Group Policy and link it to Domain Controllers OU for Firewall Rules
(Set the scope to one DC if you are worried)
In this Group Policy, open it up and edit it and navigate to the following area:
- Computer Configuration
- Policies
- Windows Settings
- Security Settings
- Windows Firewall with Advanced Security
If you are implementing changes like this in a TEST environment which I highly recommend first and you happen to be connected to one of the DCs to do this work you will want to perform the following things first to prevent being disconnected.
These Domain Controllers should be behind a hardware firewall, so leaving all remote addresses set to ANY while you configure, you should still have protection from your hardware firewall until you can go through rule-by-rule and lock them down. I’m not providing any guidance here as all organizations are different.
Go to Inbound Rules and create your base ruleset.
| Rule Name | Protocol | Local Port |
| Active Directory Web Services | TCP | 9389 |
| NetBIOS Session Service | TCP | 139 |
| ICMPv4 | ICMPv4 | ANY |
| ICMPv6 | ICMPv6 | ANY |
| Kerberos | TCP | 88 |
| Kerberos | UDP | 88 |
| Kerberos Password Change | TCP | 464 |
| Kerberos Password Change | UDP | 464 |
| LDAP | TCP | 389 |
| LDAP | UDP | 389 |
| LDAP Global Catalog | TCP | 3268 |
| LDAPS | TCP | 636 |
| LDAPS Global Catalog | TCP | 3269 |
| NetBIOS Name Service | TCP | 137 |
| NetBIOS Name Service | UDP | 137 |
| NetBIOS Datagram Service | UDP | 138 |
| NTP | UDP | 123 |
| Remote Desktop Protocol | TCP | 3389 |
| Remote Desktop Protocol | UDP | 3389 |
| RPC Endpoint Mapper | TCP | 135 |
| RPC Dynamically Assigned Ports | TCP | Example: 50000-51000 |
| SMB | TCP | 445 |
| Windows Remote Management (WinRM) | TCP | 5985-5986 |
Go to Outbound Rules and create your base ruleset.
| Rule Name | Remote Address | Protocol | Local Port | Remote Port |
| Allow ICMPv4, ICMPv6 Outbound | Any | ICMPv4/ICMPv6 | ANY | ANY |
| Allow All Traffic Outbound (TCP) | Any | TCP | ANY | 1-79,81-442,444-65535 |
| Allow All Traffic Outbound (UDP) | Any | UDP | ANY | 1-79,81-442,444-65535 |
| Allow Outbound Web Traffic Exceptions | <IPs> Crowdstrike, PKI, etc. | TCP | ANY | 80, 443 |
| Allow Outbound Web Traffic Exceptions | <IPs> Crowdstrike, PKI, etc. | UDP | ANY | 80, 443 |
By default Windows Firewall will allow all traffic outbound. These outbound rules are needed because I’m going to change the behavior to block traffic outbound by default and then put in an exception to most traffic out.
This is done to stop web traffic outbound on ports 80/443, except for the IPs we know are OK (for example Crowdstrike, or PKI services). You could and should argue that outbound traffic should be limited to your workplace but I’m not covering that level of specifics in this guide.
Right-Click “Windows Firewall with Advanced Security – LDAP://…” and click Properties.
Make sure the Firewall State is “On”, and Inbound Connections are set to “Block (default)” and Outbound Connections are set to “Block”. Verify these settings for all three Domain Profiles (Domain, Private, Public).
Next, while still in this dialog box under “Domain Profile” click Customize under Settings. I have turned off displaying a notification when a program is blocked. I have also disallowed rule merging. By turning off Rule Merging you will remove a lot of the “garbage” Microsoft Firewall Rules that are created by default. This will allow you full control of the Windows Firewall.
Next, click “Customize” under Logging, on the Domain Profile tab. Here, I’m using the default log location:
%systemroot%\system32\logfiles\firewall\pfirewall.log
I’ve also maximized the firewall log to 32MB, and I’m logging dropped packets and successful connections, this is needed for troubleshooting later.
Once this is complete you should be able to to run “gpupdate /force” on one of your Domain Controllers and launch Windows Firewall. The Windows Firewall current rules that are being enforced are found under “Monitoring -> Firewall”
You should see all of the rules that you setup enforced and you can now begin to lock down things potentially even more-so than the hardware firewall depending on your IT Security team.
This should be enough to get you started on your journey. If you have a close relationship with your IT Security Team, it would also be good to reach out to them and get their rule-set for your Domain Controllers. You may find that you can help IT Security lock down the hardware firewall even more!