by Rich Johnson
on April 6, 2023

Domain Isolation with Windows Firewall (ZTNA for free!)

Foreword:

This engaging and informative article was thoughtfully crafted by Rich Johnson, an accomplished and highly knowledgeable leader in the field of cybersecurity who boasts more than 15 years of invaluable experience. Throughout his illustrious career, Rich has authored numerous articles for a variety of prestigious cybersecurity publications, cementing his reputation as a respected and sought-after authority in the industry. We extend our deepest gratitude to Rich for sharing his valuable insights and expertise with us. To stay up-to-date on the latest developments in cybersecurity and continue learning from Rich, we encourage you to connect with him on LinkedIn at https://www.linkedin.com/in/utsecnet/.

(This article has been edited for clarity)

Target audience: IT admins of small/medium businesses, predominantly Windows with on-prem Active Directory. Assumes basic understanding of IPSec and common IT terms like network segmentation and VLANs.

Scope: Domain and non-Domain joined Windows endpoints (Server & Workstation)

Cost to implement: Free (your time, and lots of it!)

Time to implement: Several hours to several months (depending on size and cleanliness of AD/GPOs)

đź’ˇ Managing Domain Isolation policies is fully supported via Group Policy Management Console (GPMC) within an Active Directory environment. It is not yet fully supported to create and manage these rules within the Intune Management Console to the extent it is within the GPMC.

WARNING! Some configurations in this article could severely damage your production environment if applied carelessly and without understanding the configuration. I will attempt to warn you of these when we discuss these settings.

What is Domain Isolation and what does it do?

Domain Isolation is a logical preventative control. It enables the capability of the native Windows Defender Firewall to require traffic to be authenticated (and may even require encryption via IPSec) from the requesting user and endpoint device. In other words, if you want to talk to my computer from your computer, your user account and/or your computer itself must authenticate before I open the port. Domain Isolation logically segments a flat network into authentication domains. This means that you could have a single large (but flat) network with many devices, but enforce communication boundaries such that only authenticated traffic can be received by the target endpoint. It helps enforce least privilege and can help prevent many TTPs across the MITRE ATT&CK framework, primarily:

  • Scanning/sniffing (recon)
  • Lateral movement
  • Remote execution
  • Remote privilege elevation
  • Remote vulnerability exploitation

Source: https://mitre-attack.github.io/attack-navigator/

Common use cases

  1. Segment traffic on the same network segment or VLAN
    Scenario details:
    A. All servers reside on the same VLAN (green box)
    B. Some servers are joined to the domain (dashed line)
    C. A sensitive database server exists (A) that provides DB access to 3 domain joined web servers (B)
    D. The three web servers are members of the AD machine group “www_computers”
    E. The three web servers use the domain account “www_user” to authenticate and transact to the DB server.
    F. The remaining domain joined servers are also members of various AD groups, but not “www_computers”
    G. An attacker has exploited a publicly exposed web server vulnerability and fully compromised and gained privileged access on Web_04 (a non-domain joined server). They have also exploited a vulnerability on Web_01 and have performed a lateral movement attack, gaining access to a non-privileged domain account that is not the “www_user” account. In this situation, Domain Isolation will mitigate many common man-in-the-middle (MitM) attacks the attacker may attempt between the web servers and the DB server because IPSec enforces strong authentication and integrity checking. It will also reduce the risk of the attacker exploiting any known vulnerability on the DB server since all ports are closed to any user but the www_user. This would not be possible if you were using standard host based firewall rules without IPSec. Hopefully by now, your SOC team has been alerted to the situation!
  2. Encrypting a non-encrypted protocol (Telnet)
    You have often heard it said that Telnet is a bad protocol and you should never use it. I disagree! I love Telnet! I recall a time when a particular vendor’s management app only communicated over telnet. Domain Isolation policies can be configured to encapsulate and encrypt non-encrypted communication, such as Telnet. But seriously, don’t use Telnet if you can avoid it.
  3. Allow traffic from Domain Admins, block everyone else
    Let’s assume the whole IT department is on a single VLAN. Let’s also assume this VLAN shares a Terminal Server between all IT personnel for use as a DR system in the event a user’s workstation crashes or where we want to enable remote workers to only access this given Terminal Server. In this example we wish to decrease our attack surface to sensitive services by simultaneously enabling our Domain Admins to access sensitive services (e.g., RDP, MMC, PAM) over the network and deny the rest of the IT team access to the same services, even when accessing from the shared Terminal Server. Because Domain Isolation works at layer 3 (Network Layer), to an unauthenticated user all remote ports appear closed. To an authenticated user, the ports are open. Yes, this is essentially the same as scenario 1, but also a very common setup used by organizations.
  4. Protecting your home computers when a friend joins their laptop to your WiFi (of course, why not have a separate SSID?)
    My home network does not use Active Directory. When on my home network, the firewall defaults to a Private profile. I wish to permit my personal desktop and laptop computers (which have DHCP addresses) to have full access to any other family member’s computer. I also want to allow certain protocols to work between computers on the network (e.g., local LAN gaming). But if I (or any family members) ever join one of our laptops to any other network and set the profile to Private or Public I want to block any and all access. Further, if friends bring their computers on to my network, I want to ensure they are unable to potentially infect any of my owned computers. Domain Isolation enables me to do both.

Regulatory Requirements

Many regulatory frameworks and standards require things like strict access control, firewall audit logging, logical or physical segmentation, and centralized configuration of security controls. Here are a few example control objectives from common security frameworks where Domain Isolation may be a good option:

  • PCI-DSS v4
    • Control 1: Install and maintain a firewall configuration to protect cardholder data
    • Control 3: Protect stored cardholder data
    • Control 7: Restrict access to cardholder data by business need to know
    • Control 10: Track and monitor all access to network resources and cardholder data
  • CIS Critical Security Controls (CSC) v8
    • Control 3: Data Protection (Specifically 3.12)
    • Control 4: Secure configuration of enterprise assets and software (Specifically 4.4 & 5)
    • Control 6: Access control management (Specifically 6.7)
    • Control 13: Network monitoring and defense (Specifically 6.4,5,9, & 10)
  • NIST 800-171 – Protecting Controlled Unclassified Information in Nonfederal Systems
    • Control 3.1 – Access control
    • Control 3.13 – System and communications protection
  • HIPAA § 164.312 Technical safeguards
    • all sub-controls deal with authenticating and limiting access to ePHI systems

đź’ˇ It should be noted that Domain Isolation does not meet any specific requirement within these and other frameworks. In other words, no framework that I am aware of specifically requires Domain Isolation policies to be enabled in order to achieve compliance. Domain Isolation is an additional control that works together with the basic host based firewall that can give additional assurances for granting access to your sensitive data.

Configuring Domain Isolation on a Home Network

Let’s start with a very simple use case, then build upon this to see how we can implement Domain Isolation in the enterprise. First, let’s configure policies to protect my home network. At home, I do not use AD or Group Policy so we will build a rule that could allow a small number of machines to authenticate and communicate with each other.

  1. On Computer1, open the Windows Defender Firewall (You may be prompted for administrator rights depending on your current account’s privilege level)
  2. Click on Connection Security Rules (in the left pane)
  3. Click New Rule… (in the right pane)
  4. Select Isolation (Default) and click Next
  5. Select Require authentication for inbound connections and request authentication for outbound connections and click Next > (See Warning #1 below!)
  6. Select Advanced and click Customize …
  7. For the First authentication method, click Add …
  8. Select Preshared key (not recommended) then click OK
  9. Type out a Preshared Key (PSK). Each computer on your network will use this key to authenticate to each other. Click OK
  10. Verify that the key is displayed in the First Authentication window. (This is one reason it is not recommended, because any local administrator can view this key! For home use, you may chose to accept this risk). Click OK
  11. Click Next
  12. Select which profile to which this rule applies (See Warning #2 below)
  13. Name the rule. I will name it Home Network for this example. Click Finish
  14. Confirm the rule was created.
  15. Click Inbound Rules in the left pane
  16. Click New Rule … in the right pane
  17. Select Custom and click Next
  18. Select All programs and click Next
  19. Select Allow the connection if it is secure and click Customize …
  20. Note your different options. We will select Allow the connection if it is authenticated and integrity-protected to only force inbound traffic to authenticate but not encrypt. If you wanted to encrypt the connection, you could select Require the connections to be encrypted. Click OK
  21. Click Next
  22. The Users pane will be a very important to us in a Domain environment as here we can select which users or groups we wish to permit. Since we are using a PSK, we cannot select users in this example. Click Next
  23. The same goes for the Computers pane. Useful on a Domain, but not in this example. Click Next
  24. Select the same Profiles you selected in step 12. Click Next
  25. Name the rule. For this example I will name it Allow all – Authenticated Traffic. Click Finish
  26. Notice the newly created rule has a lock icon next to it. This indicates that traffic allowed by this rule is protected (either integrity protected or encrypted depending on what you selected in step 20).
  27. Repeat all the above steps on your other home computers.
  28. COMPLETE!

Warning #1: If you select Require authentication for inbound, and request authentication for outbound in a production environment, you will halt Domain traffic and break many things! Do not do this. Always start with Request authentication for inbound and outbound when working in production!

Warning #2: If you are configuring this on a work laptop that is joined to a Domain, consider only checking the Private and Public profiles. If you select Domain, all domain traffic into your laptop will cease since it cannot authenticate!

Verify Configuration

Attempt to ping each of your computers. Assuming it succeeds, we can now view the list of computers that have authenticated to each other in the Windows Firewall. This will be an excellent first step for troubleshooting issues.

  1. Navigate to Monitoring > Security Associations > Main Mode in the left pane
  2. You should see a single association for each remote computer that has correctly authenticated to your current computer. On my home network of 6 Windows devices, my Security Associations on Computer1 (10.0.0.103) look like so:

Configuring Domain Isolation to Encrypt a single Protocol (Telnet)

Here we will walk through the steps to enforce any telnet traffic detected to be authenticated and encrypted with IPSec. All other traffic will remain unchanged. Again, we are doing this on a non-Domain network, but the steps would be exactly the same on a Domain using Group Policy. This time, we will not be building the rules directly within the Windows Firewall, but rather from within the Local Group Policy MMC snap-in.

  1. On the telnet server, As a local admin, launch mmc.exe from the start menu or a cmd prompt
  2. Navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > IP Security Policies on Local Computer
  3. Right click it and select Manage IP filter lists and filter actions …
  4. Click Add …
    1. Name: Telnet Traffic Click Add (The IP filter wizard appears)
    2. Description: Telnet
    3. check: Mirrored.(This will detect all inbound and outbound targeting TCP port 23 Telnet)
    4. Source: Consider your options, but for this example we will leave it on Any IP Address
    5. Destination: Consider your options, but for this example we will leave it on Any IP Address
    6. Select a protocol type: TCP
    7. From Any port (leave default)
    8. To any port: 23
    9. Finish
  5. Click OK on the IP Filter List window
  6. Select the Manage Filter Actions tab
  7. Click Add …, click Next
    1. Name: Secure Only, click Next
    2. Select Negotiate security, click Next
    3. Select: Do not allow unsecured communication, click **Next (**Note that if you allow unsecured communication it acts as a fallback method if IPSec could not be established. You may consider doing this and monitor for any unencrypted TCP port 23 on your network for a time before setting to Do not allow…). Click Next
    4. Select: Integrity and encryption, select Next
    5. Click Finish
  8. Click OK on the Manage IP filter lists and filter actions window
  9. Right Click the new Policy > Assign
  10. Repeat the steps on all Telnet clients that will connect to this Telnet server. If you are doing this from a Domain, assign the GPO to the scope of clients and servers
  11. Run gpupdate /force on all telnet servers and clients. No need to reboot.

Verify Configuration

You can again verify by connecting to your telnet server, and viewing any Security associations within the Windows Firewall. Here is what our Telnet session looked on in Wireshark before we secured the protocol:

Notice you can see the username (admin) and password (superpassword1) in clear text!

Here is what Wireshark saw after we secured Telnet:

The client and server negotiated an IPSec ESP (encryption) tunnel and all traffic is now passing through that tunnel encrypted. Note that when you view the Security Associations in the Windows Firewall, the IPSec connection is secured with 3DES encryption and SHA-1 hashing. These are not the most secure algorithms by today’s standards. These can be changed

Implementing Domain Isolation in a Windows Domain based environment

In our example above, we configured several devices to authenticate to each other. In a Domain environment there are many considerations and planning phases that should be considered when doing a Domain Isolation implementation. Covering all the necessary Group Policies to enable a full Domain Isolation deployment is beyond the scope of this article. However, I have shared an example deployment including group policy configuration on my GitHub.

Here are some things to consider:

  1. Are you wanting to configure your entire domain with Isolation rules or just a small subset of servers & workstations? Both are totally doable, but the former will require extensive planning.
  2. Do you have Linux and MacOS devices on your network? These can be configured successfully using IPSec configuration tools, but is outside the scope of this article.
  3. You do not have to require authentication to all ports and protocols as we did in the home network example above.
  4. Always configure your Connection Security Rules to Request authentication for inbound and outbound first! Never require! Once you have validated that everything is connecting as expected, then you may carefully set everything to require inbound and request outbound.
  5. Be extremely careful configuring Domain Isolation rules on Certificate Servers, DHCP Servers, Domain Controllers, and NPS servers as these are commonly used by devices that are not joined to the domain.
  6. Consider starting small with only Isolating the most critical of network services (e.g., RDP, SMB File Shares, RPC snapper services for MMC console connections)

Troubleshoot common Domain Isolation problems

Essential Services

For Windows Firewall with Advanced Security to operate correctly, the following services must be started:

  • Base Filtering Engine
  • Group Policy
  • Client IKE and AuthIP IPsec Keying Modules
  • IP Helper IPsec Policy Agent
  • Network Location Awareness
  • Network List Service
  • Windows Firewall

Uh oh, you configured an IPSEc policy via GPO and completely locked yourself out!

  1. Open regedit.exe
  2. Navigate to HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\ConSecRules
  3. Find the value that is causing issues and delete
  4. reboot

How to find what rule is blocking traffic?

(Note this was tested way back in the day on Windows 7 devices. Your mileage may vary).

  1. Open a Windows console (with Administration rights) to enter commands
  2. Enable the audit for Windows Filtering Platform (WFP):• run command:
    auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
  3. Run command:
    auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
    (This may drown you in Event Log data – enabling only failure audits, and possibly only connection failures will reduce the number of log entries. Be selective about what you actually need)
  4. Reproduce the issue
  5. Run command:
    netsh wfp show state
    (this creates a XML file in the current folder)
  6. Open the event viewer: Run (Windows+R) > eventvwr.msc
  7. Go to “Windows logs” > “Security”
  8. In the list, identify the dropping packet log (hint: use the Search feature on the right menu, searching for items (source IP, destination port, etc.) specific to your issue)
  9. In the log details, scroll down and note the filter ID used to block the packet
  10. Open the generated XML file
  11. Search for the noted filterID, and check out the rule name (element “displayData > name” on the corresponding XML node)This will give you a good start to find the blocking rule. When you’re done, don’t forget to turn off the audit:
  12. Run command:
    auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable
  13. Run command:
    auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable
    Note: depending on your Windows language setting, the auditing service might use different non-English names. To find the subcategory names, run command:
    auditpol /get /category:*
    Find subcategories which correspond to “Filtering Platform Packet Drop” and “Filtering Platform Connection” in the system language.

You have configured IPsec in the Windows Firewall, but you cannot authenticate to a remote server

  1. On the remote server, enable audit logs on IPsec events:
    auditpol.exe /set /SubCategory:"MPSSVC rule-level Policy Change","Filtering Platform policy change","IPsec Main Mode","IPsec Quick Mode","IPsec Extended Mode","IPsec Driver","Other System Events","Filtering Platform Packet Drop" /success:enable /failure:enable
  2. Review the events in the Windows Security Event Log

To view events for Windows Firewall with Advanced Security in Event Viewer

  1. Event Viewer is available as part of Computer Management. Right-click the Start charm, and then click Computer Management..
  2. In the navigation tree, expand Event Viewer, expand Applications and Services, expand Microsoft, expand Windows, and then expand Windows Firewall with Advanced Security.
  3. There are five views of operational events provided:
  • ConnectionSecurity – This log maintains events that relate to the configuration of IPsec rules and settings. For example, when a connection security rule is added or removed or the settings of IPsec are modified, an event is added here.
  • ConnectionSecurityVerbose – This log maintains events that relate to the operational state of the IPsec engine. For example, when a connection security rule become active or when crypto sets are added or removed, an event is added here. This log is disabled by default. To enable this log, right-click ConnectionSecurityVerbose, and then click Enable Log.
  • Firewall – This log maintains events that relate to the configuration of Windows Firewall. For example, when a rule is added, removed, or modified, or when a network interface changes its profile, an event is added here.
  • FirewallVerbose – This log maintains events that relate to the operational state of the firewall. For example, when a firewall rule become active, or when the settings of a profile are changed, an event is added here. This log is disabled by default. To enable this log, right-click FirewallVerbose, and then click Enable Log.
  • Network isolation operational – not sure what this one is!

Limitations and Alternatives to Domain Isolation with IPSec

Domain Isolation with IPSec has been a native function of the Windows Defender Firewall since Windows 7 (yes, it was there in XP…but it was bad!). It’s free. It works. But as with many thing’s legacy Microsoft, it has its limitations. Management via GPMC may be clunky compared to modern standards. GPMC hasn’t received a management console or UI update since it was implemented in 2003 Server and until Azure/Intune can has parity in what GPMC can do, we’re limited to on prem-AD and GPMC.

The second big limitation, is its integration capabilities into non-Windows OSes. Yes you can authenticate MacOS and Linux with IPSec, but not without heavy configuration and in some cases commercial tools to push centralized configuration to your endpoints. You would also be relying on non-group based rules (Certificates).

If Microsoft doesn’t become more inclusive with MacOS and Linux with Domain Isolation policies, and incorporating management parity in to Intune, it may soon be totally overshadowed by Zero Trust platforms. Zero Trust is showing promising progress in allowing all OS platforms, applications, cloud, on-prem, and everything between complete isolation and least privilege. Zero Trust is fast becoming the standard to replace “Least Privilege”. But it’s expensive. Domain Isolation? Free.

Additional Resources

Conclusion

In conclusion, Domain Isolation with Windows Firewall can provide an additional layer of security for your network by allowing you to control access to sensitive data and resources. It can be especially useful for meeting regulatory requirements and protecting against potential threats from untrusted devices. By following the steps outlined in this article, you can configure Domain Isolation on your home network or in an enterprise environment. However, it’s important to keep in mind the limitations of Domain Isolation, including its lack of integration with non-Windows operating systems, and to consider alternatives such as Zero Trust platforms (We love Cato and Extrahop!).

If you have questions around the deployment, or you get stuck reach out to professionalservices@tridentstack.com to get some immediate assistance from talented engineers that have done this before! For a POC of the Tridentstack SIEM SAAS platform email sales@tridentstack.com.

Categories:

Administrator Best PracticesSmall/Medium EnterpriseWindows Best Practices

Tags:

Best PracticeGroup PolicyMedium EnterpriseNetworkingSmall Enterprise

Comments are closed