Summary: Microsoft senior technical writer, Yuri Diogenes, and knowledge engineer, Tom Shinder, talk about using Windows PowerShell to protect a Windows Server 2012-based cloud infrastructure.

Microsoft Scripting Guy, Ed Wilson, is here. Guest bloggers Yuri Diogenes and Tom Shinder are back with the exciting conclusion to their series about security. This series includes three blog posts where the authors describe examples about how you can leverage Windows PowerShell to automate security tasks.

Note  This is the third blog in Yuri and Tom’s Private Cloud Infrastructure security and Windows PowerShell series. Before you read today’s post, you should catch up on the first two parts of the series:

Take it away guys…

In Part 2 of our series about how to use Windows PowerShell to protect your private cloud infrastructure we discussed how to protect the private cloud infrastructure against rogue services. To address this security concern, we showed how to leverage the DHCP Guard feature. In this post, we will explain how to isolate and protect virtual machines that are part of the same tenant network by using the port access control list (ACL) feature.

Scenario 3: Isolating and protecting virtual machines

As described in the paper, Leveraging Windows Server 2012 Capabilities to Address Private Cloud Security Concerns – Part 2, you need to be concerned about protecting tenants and virtual machines that are part of the same tenant network against potential data leakage and service interruption. Although tenant isolation is a core part of Hyper-V virtual switch, and it can be easily accomplished by separating tenants in different virtual networks, the challenge remains for the tenant network. Internal threats can be very dangerous in most scenarios; however in a private cloud environment, the damage could be even higher. Although the target for the attack might be a host that is located on the same tenant network as the attacker, there could be scenarios where the attack might go against the cloud infrastructure hosts themselves. This can cause performance degradation or even cataclysmic failure of the cloud infrastructure, and therefore affect other tenants.

Tip  Internal threats could leverage social engineering techniques to gain access to resources. Make sure to read the document How to Protect Insiders from Social Engineering Threats to get more information about how to protect against that.

One feature in the Hyper-V virtual switch in Windows Server 2012 that can help block unwanted traffic and isolate virtual machines from one another is the port ACL. With this feature, you can block virtual machine A from communicating with virtual machine B, while keeping the communication flowing between virtual machine B and others.

To demonstrate this scenario, we will use the configuration shown in the following image:

Image of configuration

Scenario definition

Contoso, Ltd. has a cloud infrastructure with multiple tenants. Recently the private cloud administrator was investigating a network monitor capture that was showing a traffic pattern coming from a specific host within their network. The traffic pattern was looking like this:

 

10.30.30.35       10.30.30.30       TCP      TCP:[SynReTransmit #2]Flags=......S., SrcPort=1162, DstPort=28, PayloadLen=0, Seq=98689837, Ack=0, Win=65535 ( ) = 65535    {TCP:2, IPv4:1}

10.30.30.35       10.30.30.30       TCP      TCP:Flags=......S., SrcPort=1163, DstPort=MSG ICP(29), PayloadLen=0, Seq=193907566, Ack=0, Win=65535 ( ) = 65535  {TCP:3, IPv4:1}

10.30.30.35       10.30.30.30       TCP      TCP:Flags=......S., SrcPort=1164, DstPort=30, PayloadLen=0, Seq=3091433387, Ack=0, Win=65535 ( ) = 65535    {TCP:4, IPv4:1}

10.30.30.35       10.30.30.30       TCP      TCP:Flags=......S., SrcPort=1165, DstPort=MSG Authentication(31), PayloadLen=0, Seq=3947077525, Ack=0, Win=65535 ( ) = 65535            {TCP:5, IPv4:1}

10.30.30.35       10.30.30.30       TCP      TCP:[SynReTransmit #14]Flags=......S., SrcPort=1166, DstPort=32, PayloadLen=0, Seq=1503303803, Ack=0, Win=65535 ( ) = 65535            {TCP:6, IPv4:1}

 

This pattern raised a flag because it can be categorized as a port scan (syn on each sequential port over trying to find open ports).

Scenario constraint

Although the source (10.30.30.35) was a legitimate system within the private cloud infrastructure, it was clear from the pattern that something on that system was triggering the port scan on the target server (10.30.30.30). It was observed that this was the only server within the infrastructure that was affected by this issue. The private cloud administrator wanted to investigate the source system and collect live data (while the behavior was happening), but he wanted to avoid performance degradation on the target system (because it was under attack).

To accomplish this, the private cloud administrator leveraged a port ACL on the Hyper-V virtual switch. By using this feature it is possible to:

  • Block the communication from the possibly infected system (10.30.30.35).
  • Isolate the traffic at the switch level to prevent the target system from receiving the packets.
  • Not interrupt the possibly infected system because it is necessary to acquire data while the irregular behavior is in progress.

The first step in this case is to access Windows PowerShell on the host system and run the Get-VM cmdlet to obtain the list of the hosts.

Note   Running VM cmdlets requires Administrator permissions.

This is what returns:

Image of command output

Tip   In a multitenant environment, you might want to use a name suffix that can identify the tenant. For example, “[Finance] Windows 8.” This will help you query the virtual machine’s name by using the command Get-VM -Name *finance*.

After you identify the virtual machines, you can configure the isolation ACL as shown here:

Image of command output

To verify the configuration, run Get-VMNetworkAdapterAcl as shown here:

Image of command output

When the issue is resolved and the ACL is not necessary anymore, you can use the Remove-VMNetworkAdapterAcl to delete this entry.

Beyond the Hyper-V virtual switch

Usually when we describe a scenario like this in our presentations, the audience always asks, “Is it possible to make the Hyper-V switch automatically detect this attack and create a rule?”

The answer is, “Yes, but not natively.” You can leverage the Hyper-V extensible switch and install third-party add-ons that can add this layer of security for you. For more information about the Hyper-V extensible switch read, Overview of the Hyper-V Extensible Switch.

Note  To see if there is a Hyper-V extensible switch installed, run Get-VMSwitchExtension.

We hope you enjoyed the series, and we are looking forward to bringing you more blog posts about Windows PowerShell and security!

~Yuri Diogenes, senior technical writer, SCD iX Solutions Group
Twitter: @YuriDiogenes

~Tom Shinder, knowledge engineer, SCD iX Solutions Group
Twitter: @TomShinder

Photo of book cover

Thanks Yuri and Tom! Great stuff! Join me tomorrow as I present Part 2 of my series, I Found this Function—Now What?

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy