Security is a never ending battle for us folks in the business of IT Infrastructure. There are always new threats that we need to consider from every layer of the network. Now that virtualization is becoming a huge part of the infrastructure, it’s a good idea to extend our security policy to include virtualization challenges.
I wanted to take a look at some of the common challenges to consider within VMware. Specifically the VI3 platform as I’m running into this platform %90 of the places I go versus vSphere which has a completely new model and API available for securing your virtual environment. I will take a separate look at Hyper-V, XenServer and vSphere at a later date. Since VI3 is so prevalent it’s the audience that I believe I could touch the most. It’s important to note that these principles could apply to the other platforms as well.
So, what are the security challenges with hypervisors? Out of the box the kernel and consol are pretty secure. There aren’t a lot of services that could be exploited running by default. There’s a firewall enabled by default. And communication is over SSH and SSL. These are all things we should expect but here are three areas of concern.
One of the first area’s to look at would be the guest OS and services. The vulnerabilities of the guest OS could easily become the not so obvious vulnerabilities of the hypervisor. I’m not going to pick on any one operating system as things issues are common amongst all OS’s that provide services. One thing to really consider is DoS attacks against the VMware host through a subject able guest OS or service.
An attacker could direct a DoS at a service running on one guest OS which could affect the performance of the physical hardware. This in turn could affect other guest operating systems. This is why it’s important to have system monitoring in place for your hardware and applications. This is where tools like vMotion could really pay for themselves as you can isolate servers that are experiencing high utilization or suspicious activity.
It’s extremely important to fully plan out your virtual network and physical network layout and the access lists governing control between the two. It’s been my experience that the team that manages the virtual switches and the team that manages the physical network are two separate teams. I personally think that this is a mistake.
I have experience as both a Network Engineer and a Server Administrator and have a strong understanding of routing, switching and access control. This is a critical skill when dealing with an extremely large virtual environment. I find that when I wear both hats I have conflicting agendas. The network engineer in me wants to think security first but the server administrator wants the course of least resistance.
This leads to shortcuts and poking holes in VLAN configurations by using static routes between Virtual Machines on different network segments. These shortcuts are normally undocumented and come to bite us in the rear sometime in the future when we least expect it. Worst case hopefully its internal audit doing a review of controls and not some bad guy taking advantage of our laziness.
Virtual Center Clients
This is an area that we may not give much thought to because the list of people allowed to access the console is limited. But it’s this area that we need to pay a great deal of attention. I’m very reluctant to give access to the Virtual Center Console to Jr. Level Administrators. Even when configured correctly by restricting rights to virtual machines through Directory Services it’s important to realize how big of a security risk it is giving access to someone who doesn’t have the appropriate training in Virtualization or even security.
This is an area that can lead to a great deal of damage if an administrator is lacks about securing their desktop. This is why it’s also importing to have the appropriate level of logging configured to re-enforce the security policy with accountability.
There are plenty of other area’s to look at like iSCSI security, Storage Network and device level challenges. I’ve provided a few links at the end where you can get much more detail on securing you virtual environment.
I found these useful links that give more detail in securing your virtual environment.
VMware Harding VI3
VMware vSphere Hardening Guide