Preventing Lateral Movement Using Network Access Groups

At least once a week I get on a rant about network segmentation. After all, it is one of the NSA Top Ten Cybersecurity Mitigation Strategies.

If you talk to any Security Engineer, Penetration Tester, your Uncle Bob, they always talk about “lateral movement.” Someone will penetrate your network and jump from device to device until they can use one of them to their advantage. Segmenting your network is one way to prevent this.

I often encounter networks that have little to no network segmentation. When I walk through the door, it is one of the first things I recommend. This strategy will improve the security posture of the network immediately. Clients love it when I tell them there is often no hardware to buy. They most likely already have everything we need to engineer the solution.

Problem is the labor. In order for us to pull this off with flawless execution, the amount of planning and discovery is pretty intense. We need to understand everything about your network. What devices do you have in your network? What applications, how do they communicate? What ports do they use, who do they need to talk to? etc, etc, etc. Like I said, I talk about this a lot.

Typically, this strategy is done by building VLANs within your switches and firewalls. Today, I am going to show you what I believe to be a much easier way.

One thing we do know about enterprise networks is, very rarely do workstations need to communicate directly to other workstations. The exception to the rule is IT Admins. Their workstations are the only workstations in the network that need to facilitate this kind of connection.

Using Active Directory, Group Policy, and Windows Firewall, I am going to provide a step by step instruction on how to prevent workstation to workstation communication while still allowing IT Admin Workstations and Domain Controllers to still have inbound communication to your client workstations.

A visual representation of what I’m blogging about.

Do not perform this in your production environment until you have fully validated the configuration in a lab environment.

Creating an Active Directory IT Admin Workstations Security Group

1. Open Active Directory Users and Computers
2. Create a Security Group for your IT Admin Workstation
3. Add you IT Admin Workstations

Creating a Windows Firewall Group Policy Object

1. Open Group Policy Management Edit.
2. Create a new GPO or modify an existing one. I simply named mine Workstation Firewall Policy
3. Edit policy and navigate to Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security

We are first going to enable the Windows Firewall for all profiles: Domain, Private, and Public.

1. Right Click Windows Firewall and choose properties. Configure the following Settings:

• Firewall State: On (recommended)
• Inbound Connections: Block (default)
• Outbound Connections: Allow (default)

Each profiles state should be configured as pictured below.

There are little to no unsolicited inbound connections required for the typical user’s workstation. There are obviously going to be exceptions to this, but for the most part, the theory will hold true. You may be asking, “What about my Softphone application? Well, most installed applications initiate outbound connections to establish connectivity to a given server/service. The Windows Firewall allows this solicited inbound traffic through the firewall because it was requested by the workstation.

Click Customize Under Settings. Apply the following Settings

• Display a notification: No
• Allow unicast response: Yes (default)
• Apply local firewall rules: Yes
• Apply location connection security rules: Yes
• Repeat for each profile

For the rules merging settings, you will want to set these to ‘Yes’ during testing and the initial phase of your deployment. If you screw anything up, you will be able to modify the firewall locally on the workstation to get your self out of a jam. Once you are confident that you have a solid configuration, I recommend the last step to set these rules to ‘No’.

• Click Customize Under Settings
• Log dropped packets: Yes
• Log successful connections: No (this will cause to much noise)
• Repeat for each profile

• Click ‘OK’ and save your settings.

Creating Connection Security Rules

Next, we’re going to skip to the Connection Security Rules. This is critical to pulling off this deployment. Connection Security Rules will ensure that authentication occurs between two computers before they begin to communicate. This is how your workstations will know to trust an IT Admin Workstation and drop all unsolicited inbound connects from all other devices.

Right click Connection Security Rules and select New rule

Rule Type

• Select Server-to-server
• Next

Endpoints

Since I want all windows devices to authentication to each other, I am leaving ‘Any IP Address’ selected.

• Next

Requirements

• Request authentication for inbound and outbound connections

It is important that you choose ‘Request’. Once you are confident all your Windows devices have a connection policy, I would suggest upgrading to ‘Require Authentication for inbound connections and request authentication for outbound connections’. ‘Require for inbound and outbound’ seemed like overkill and actually prevented my machine from reach the internet, so don’t do it.

Authentication Method

******This requires a Certificate Authority in your network.

• Computer Certificate

I chose my domain’s root certificate authority. If you don’t have one, you will need to create one. (A later blog article)

Profile

• Check Domain

Since we do not plan on having our IT Admins making inbound connections on anything other than our Domain. This security policy will only apply to the Domain Profile.

Name

I named this “Computer Authentication” because it will be used as the authentication mechanism when my domain connected workstations/servers connect to one another.

Final step for your Connection Security Rules

• Right Click Your new connection policy and choose properties
• Select the Authentication Tab
• Under Method choose Computer and user (Kerberos V5)

Creating Inbound Rules

Still working within your new Window Firewall Group Policy Object, we will create inbound firewall rules that only let IT Admin Workstations and Domain Controllers make inbound requests into your workstations and block everything else.

Create Block All Rule

Once we lock down a solid a solid firewall config, this rule will act as a cleanup rule to block everything we have not explicitly approved.

1. Right click Inbound Rules > New Rule
2. Rule Type: Custom
3. Program: All Programs
4. Protocols and Ports: Protocol Type: Any
5. Scope: Any, Any
6. Action: Block the Connection
7. Profile: Domain (For Now. When working on private or public networks you should not be allowing inbound connections)
8. Name: Block All

Create Allow Domain Controllers Rule

Our Domain Controllers are one of the few servers that will need inbound connectivity to our workstations. Active Directory relies on many ports for group policy, global catalogs, authentication, security tokens, kerberos and a bunch of other background noise no one really understands or gets. They just know it needs to happen. For this reason, we will allow Domain Controllers to have inbound access to our clients.

Create Allow IT Workstations Rule

1. Right Click: Inbound
2. Rule Type: Custom (I wanted to try to get away with using Predefined — File and Printer Sharing but Group Policy Editor kept crashing)
3. Programs: All Programs
4. Protocols and Ports: Protocol type: Any
5. Scope: Any, Any
6. Allow the connection if it is secure > Customize
7. Override Blow Rules > Check the box. It is critical that the option be selected or else your Block All rule will trump this rule. Windows firewall does not work off of precedence like most network firewalls do, it gives priority to all block rules before an allow rule
8. Users > Click Next
9. Computers > Authorized Computers > Check Only allow connections from these computers > Add > Domain Controllers
10. Profile: Domain
11. Name: Allow Domain Controllers

Create Allow IT Admin Workstations

IT Admin Workstations are another group of devices that will need inbound access to client workstations to efficiently support them remotely. For this reason, our new security group IT Admin Workstations will be granted the rights to facilitate unsolicited inbound connections to client workstations.

1. Repeat Steps 1–8.
2. When you get to step 9 chose the new security group you created IT Admin Workstations
3. Profile: Domain
4. Name: Allow IT Admin Workstations

Once all is said and done, your Windows Firewall Rules should look like the image below.

Final Steps

Apply your Windows Firewall Group Policy to all workstations. Before IT Admin workstations can being to make inbound requests to member workstations, you will need to reboot all workstations so they can update their Connection Security Rules.

Once your reboots are complete, try having a IT Admin Workstation ping a member workstation and vice versa.

(In order for your Domain Controllers to be able to make inbound connections, you will need to create Connection Security Rules on your DCs before they can make inbound connections to your member workstations).

Again, first implement this into a lab settings prior to production.

Summary

I could continue on and on about other mitigation steps but you just get to a point where people want you to stop talking.

What I can end with is that Penetration Testers will hate this. Their ping scans, port scans, nmap scans, any network footprinter tools will come up with minimal results when fully implementing this strategy.

Credits

• Windows Defender Firewall with Advanced Security
• Technet: Windows Firewall — Authorized Computers — Not Working