In our first blog of this series, Using PowerShell to Protect Your Private Cloud Infrastructure, we defined the essential characteristics of cloud computing, briefly discussed some cloud security challenges, and started exploring network protection by using platform capabilities in Windows Server 2012. The first network security scenario we described covered protection against eavesdropping attacks by leveraging the SMB Encryption feature available in Windows Server 2012. In this blog, we will discuss how to protect a private cloud infrastructure against rogue services.
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 against rogue services that could interrupt their workload. Because network isolation is a fundamental requirement for a private cloud, many times this concern is already mitigated for cross-tenant communication; however, traffic within the same tenant network is still vulnerable to this type of attack if nothing is done.
Traffic that belongs to the same tenant network can initially be viewed as “trusted”; however, as a security professional you should never trust any traffic, even if it comes from the your own corporate network. The risk that an internal threat will provision a service that will affect the entire tenant’s network is something that should be addressed from the private cloud infrastructure perspective. One classic example of potential network disruption is a rogue DHCP server that sends leases for bogus IP addresses on the tenant’s network.
One great new feature in Windows Server 2012 that can be used to mitigate this scenario is DHCP Guard. The Hyper-V Virtual Switch can use this feature to block DHCP offers from virtual machines that were not authorized to distribute IP addresses.
Note This is a feature of the Hyper-V Virtual Switch, so don’t get confused when we say “authorized.” This is not the same as DHCP Authorization in Active Directory. DHCP Guard does not need Active Directory, and it is implemented on the virtual switch level.
To demonstrate this scenario, we will use the configuration that follows.
Scenario definition: Contoso, Ltd. has a cloud infrastructure, and as part of the security policy for their private cloud they need to prevent rogue DHCP servers from distributing IP addresses on their network.
Scenario constraint: The plan is to implement this capability throughout the entire cloud infrastructure, but for now they are going to deploy only on the Financial Tenant virtual machine (the Red virtual machine in the previous image).
To use DHCP Guard, you need to select the virtual machines that must have this feature enabled. You can use the Get-VM command to visualize all your virtual machiness as shown here:
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 *finance*.
It is important to note that the DHCP Guard feature is disabled by default, which means that every virtual machine you create will have this functionality disabled. You can use the command Get-VMNetworkAdapter to obtain this information shown here:
You can retrieve information about only this setting by using Get-VMNetworkAdapter –VMName RogueDHCP | Format-List DHCPGuard. The result of this command is shown here.
In a private cloud infrastructure, you (as an administrator) should be aware of which virtual machines will be provisioned to be a DHCP server (which in almost all cases is likely to be none of them because tenants should not be providing infrastructure services). Therefore, the correct assumption is that all virtual machines should have this feature on except the ones that will act as a DHCP server.
Unfortunately, it is not possible to change the default setting in Hyper-V to force all virtual machines that you create to have DHCP Guard enabled. You need to create the virtual machine and then use the following command to enable it.
In this blog of a three-part series, we discussed a scenario where the private cloud administrator wants to protect his cloud infrastructure against rogue DHCP attacks. The next blog in this series will discuss protection against MAC Spoofing and Router Advertisement attacks.
See you next time!
~Yuri Diogenes, senior technical writer, SCD iX Solutions Group