Hello Folks,
In today’s post, we will deep dive into Extended Port Access Lists in Hyper-V 2012 R2 and later versions.
Table of Contents
Introduction
For those who are new to this feature, Port ACL is a rule that you can apply to a Hyper-V virtual switch (Per VM or Per Virtual Network Adapter).
The rule specifies whether a packet is allowed or denied on the way into or out of the VM. ACLs in Hyper-V 2012 have three elements only with the following structure: Local or Remote Address | Direction | Action. This allows controlling traffic between VMs or between VMs and the physical world.
Starting in Hyper-V 2012 R2 and later versions, the Hyper-V team extended that feature and now you can configure port ACLs for a VM based on five attributes in a packet – Source IP, Destination IP, Protocol, Source Port, and Destination Port.
For example, you can configure port ACLs for a VM to allow all incoming and outgoing HTTP traffic on port 80 while blocking the network traffic of all other protocols on all ports.
Hyper-V Extended Port ACLs
Let’s see how to configure the Hyper-V Virtual Switch Extended Port ACLs feature in Action.
Here is our scenario environment for this demo:
To configure port ACL, we need to use PowerShell folks, NO GUI :)
Related: Deploy Hyper-V Extended Port ACLs in System Center Virtual Machine Manager (SCVMM).
Let’s get started…
First, we need to check the connectivity from all users’ machines (Between VM and the External World) using the new SuperPing cmdlet…
#From Account Users:
Connection is succeeded to both Virtual Machines as expected, the Account Server is a Web Server listening on port 80 and the RemoteApp Server is an RDS Session Host listening on port 3389…
#From Front Desk Users:
The connection is good as well as from the Front Desk users subnet, sure enough, the RDS-RemoteAppSRV VM is failing to connect on port 80 since it’s not a Web Server.
Second, we need to check the connectivity between Virtual Machines on the same physical host…
#From Account-AppSRV:
#From RDS-RemoteAppSRV:
As you can see the connectivity is True between the two VMs as well.
Based on our scenario described above, here are our security policies that we need to enforce:
Rule #1:
- The Account Users must be able to access the Account WebServer using HTTP only
- The Account Users must not able to access the RemoteApp Server at all
Rule #2:
- The Front Desk Users must be able to access the RemoteApp Server using RDP only
- The Front Desk Users must not able to access the Account WebServer at all
Rule #3:
- The Account Server must not able to access the RemoteApp Server using RDP Protocol and vice versa
- The RemoteApp Server must not be able to access the Account WebServer using HTTP
So let’s start applying those security policies and see the results…
Here we are on our Hyper-V box:
First, we need to check if we have any pre-existing Access Rule applied:
No Rules….
If you are a networking or Cisco guy, this might look familiar to you, like a kind of PowerShell version of an ACL command line :)
1- Add-VMNetworkAdapterExtendedAcl –VMName "ACCOUNT-APPSRV" –Action "Deny" –Direction "Inbound" –Weight 1
2- Add-VMNetworkAdapterExtendedAcl –VMName "RDS-RemoteAppSRV" –Action "Deny" –Direction "Inbound" –Weight 1
3- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.9 –Weight 20
4- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.2 –Weight 30
5- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.40 –Weight 40
6- Add-VMNetworkAdapterExtendedAcl –VMName “RDS-RemoteAppSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.9 –Weight 20
7- Add-VMNetworkAdapterExtendedAcl –VMName “RDS-RemoteAppSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.2 –Weight 30
8- Add-VMNetworkAdapterExtendedAcl –VMName “RDS-RemoteAppSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.40 –Weight 40
9- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress 172.16.20.207 –LocalPort 80 –Protocol "TCP" –Weight 100 -Stateful $True
10- Add-VMNetworkAdapterExtendedAcl –VMName "RDS-RemoteAppSRV" –Action "Allow" –Direction "Inbound" –RemoteIPAddress 172.16.28.10 –LocalPort 3389 –Protocol "TCP" –Weight 100 -Stateful $TrueLet’s explain the above commands in a nutshell.
The Add-VMNetworkAdapterExtendedAcl cmdlet creates an extended access control list (ACL) for a VM virtual network adapter. The ACL allows or denies access to a virtual machine network adapter for network packets based on source IP address, destination IP address, protocol, source port, and destination port.
The first two commands deny all inbound traffic for both VMs. The third to the eighth rule allows traffic between the Virtual Machines and our DNS Server/Gateway in order to communicate with our Active Directory and to route between different subnets as well.
Notice that all commands have a weight number and the last command has a weight of 100. Commands with higher weight take precedence (weight of 100 takes precedence over a weight of 40, 30, 20, and 1).
The last two rules are to allow the Account Users subnet to connect to the Account-AppSRV VM using HTTP protocol and to allow the Front Desk Users to connect to the RDS-RemoteAppSRV VM using RDP protocol.
Note: If we are applying the rule in the Outbound direction, we need to use RemotePort instead of LocalPort.
Let’s check now the connectivity after applying the above rules:
#From Account Users:
As you can see, the Account Users are able to access the Account Web Server using HTTP, but nothing else and they cannot reach the RDS RemoteApp server too.
#From Front Desk Users:
Here the Front Desk users are not able to reach the Account Web Server, but they can connect to the RDS RemoteApp server only.
#From Account-AppSRV:
No connectivity between the Account-AppSRV and the RDS-RemoteAppSRV as expected :)
#From RDS-RemoteAppSRV:
No connectivity as well from the RDS-RemoteAppSRV and the Account-AppSRV… Bingo!
The other piece that we have with Extended ACL is Stateful support, like a stateful firewall.
We can say, when we see an inbound connection coming on port 80, it will watch that inbound connection and automatically open the source port on the other side just for a period of time that’s needed to communicate through that inbound session.
We can associate timeouts with that Stateful session as well, so after a certain period of time, we can close that Stateful connection using the -Timeout flag value defined in seconds.
Read more on Microsoft Learn about Extended Port Access Control Lists in Hyper-V.
Until this point in time, the Hyper-V Extensible switch cannot do a traffic inspection of the payload, but that’s why the big role of the Extensible Virtual Switch comes into play with Cisco NEXUS 1000V, NEC, or Five9 partners, etc.
Until next time… Enjoy your Day!
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
