Change your vSphere Management Network now!
As part of the goals that I have set for myself, my home lab environment, and the production environments I work with, becoming more security conscious is on that list. I have found for myself personally that approaching my home lab environment as a production environment helps the overall thinking as I walk into production environments. Practicing in your home lab what you preach in production environments is a great way to keep best practices and other key ideas in mind. As part of my lab and “practice what I preach” goals entering into 2022, I have undertaken a redesign of the home network. Let’s talk about why you should change your vSphere management network now.
Threats affecting VMware vSphere
Do I think a malicious attacker or ransomware group is after my small home lab environment? No. However, as I am wanting to more closely emulate security best practices in production, redesigning the home lab environment for much better network security from a management perspective helps to keep these design principles front and center.
For years we have known that it is not best practice and introduces security risks by having your “management” IP addresses on the same network as virtual workloads, physical workstations, and other network resources. Separating out your management network, especially for vSphere is a great way to minimize the risk associated with intermingling these devices.
When it comes to vSphere, and especially vCenter Server, if an attacker compromises your vCenter Server, they have you, no questions asked. This is probably the worst-case scenario that can happen with organizations running on top of vSphere with now running 95% or more of their production workloads running as virtual machines.
New threats and, in particular, ransomware are now targeting VMware vSphere, vCenter Server, and ESXi. Attackers realize the amount of damage that can be done in vSphere environments by gaining management access to your VMware vSphere environment. Take a look at my post from a while back on ESXi ransomware:
Attackers are looking to compromise privileged credentials on the network using any means possible. Once they obtain the holy grail privileged administrator account, they can easily start doing real damage to the network and “owning” your environment.
The Initial Access Broker (IAB) criminal market is now known to be listing real vSphere credentials along with other compromised logins on the dark web. It helps to underscore that now is the time for securing your vSphere environments with proper password hygiene and network access safeguards.
Recommendations for increased vSphere security
Decoupling your vSphere environment from Active Directory helps to minimize the risk associated with compromised AD accounts leading to compromising your vSphere environment, especially in the case of ransomware. Often administrators simply wanting to make things easy will add their domain administrator accounts in the vSphere administrators role to use the same privileged account.
However, this is a dangerous practice that can lead to the compromise of your entire environment. Using separate credentials to administrate your vSphere environment helps to keep these “blast zones” separated. Now, on to the topic of the blog post, the vSphere management network.
Change your vSphere mangement network now!
In many environments that I have worked in, the management IP addresses for ESXi hosts and vCenter Server live in the same subnet as production workload subnets. I have even seen SMB and even larger environments with all vSphere management resources running in a large Layer 2 network containing servers and workstations with end-users and everyday Internet browsing – wildly dangerous!
In my home lab environment, prior to the decision to redesign, for the sake of ease and time initially, while I had other segments in place, I also was running a combined subnet housing management and lab server resources. I didn’t plan it that way but it was just something that grew from quickly spinning up labs, etc. Amazing that we get caught up in the same practices when not thinking through network designs, even in the home lab.
However, moving into 2022, I have carved out the proper management network for administering vSphere resources that is air-gapped from the other subnets/VLANs running my network resources. Using a privileged access workstation (PAW) provides a secure “jump box” environment that allows securely accessing your vSphere management interfaces.
The privileged access workstation is never used for dangerous activities such as browsing or for any other general-purpose use cases. Instead, its sole purpose is to provide access to privileged resources, such as your vSphere management network and is filtered from Internet traffic, etc.
The advantage of the PAW is that you are further reducing the attack surface. Consider this. Even if an attacker gains the credentials for your vSphere environment, they have the additional hurdle of gaining access to the PAW to use the credentials. Is this possible? Yes. No security measure is 100% failsafe. However, the main rule of security that I have observed that is most effective is to provide as many roadblocks as possible to compromise to make the end goal of compromising the environment less attractive from a time and effort standpoint.
Wait! I didn’t design my management network correctly. How hard is it to move my vSphere management IPs? I just posted a blog post covering the process from the ESXi perspective. Take note of the post here:
Look for a new post on changing the vCenter IP as well.
Be sure to check out the vSphere security best practices and resources:
Wrapping Up
Make 2022 a year to increase your cybersecurity posture, even in the home lab environment. This translates to a more security-conscious posture overall. As ransomware attacks and other threats to vSphere and all other technology resources continue to escalate, implementing best practices and other security measures has never been more important.
