October 29, 2012 | Written by: Chenta Lee
Share this post:
Virtualization not only brings new threats to your infrastructure but also brings new ways to protect it. Theoretically, virtual machines (VMs) are just some software running on the physical machine. Therefore, everything on the VMs is transparent to the hypervisor, including the CPU registries, memory content and network packets. This advantage introduces new opportunities to secure your VMs.
Here are four unique technologies that we could use to protect our virtual infrastructure:
1. VM traffic inspection
The hypervisor literally “owns” every virtual NIC on virtual machines. Consequently, every packet that flows into VMs must go through the hypervisor first (using direct device mapping is another story). Therefore, the hypervisor could use this benefit to provide firewall, network access control, or IPC to every VM running on it. Why is it a unique technology? First, it is agentless. From the VM’s point of view, there is no agent running on it, hence there is no way to stop it or uninstall it. It is how the hypervisor could enforce the network security using the way we couldn’t do before. Second, it is OS independent. No matter which operating system is running on the VM, we could always inspect the traffic and provide protection. Why don’t we just put a physical network IPS in front of the hosts to provide network security? Isn’t it also agentless? Yes, it is agentless but it is also an incomplete solution. Anything outside of the hosts are not able to see the inter-VM traffic. However, inter-VM traffic plays an important role in virtual infrastructure because we usually run more than one VM on a single host. VMs on the same host might attack each other and even form a botnet. If you underestimate the importance of the protection to the inter-VM traffic. Your security solution is incomplete.
2. VM life cycle monitoring and control
Could you be 100% sure about how many machines are powered on in your environment? Could you be 100% sure that you could remotely power on and power off your machines to save energy? No, I don’t think so. A well designed firewall rule could bypass all kinds of checking and remote power management rely on special NIC model and BIOS support. Fortunately, the characteristics of virtual machines give us the ability to precisely get the status of each VM. Moreover, we could even control their life cycle. For instance, we could suspend any VMs at anytime and there is no way of escaping it. Administrator could now suspend every VM at night and bring them back in the morning to save energy. What’s more, we could turn off or suspend the infected VMs to mitigate the security risk as soon as possible. Could you do that before? Imagining how much time you need to spend on physically locating the machine and go there to turn it off.
3. Virtual CPU/memory introspection
None of the software running on the guest VM could see the CPU and memory in the same way as the hypervisor does. The hypervisor uses an agentless approach to transparently introspect the virtual CPU/memory. For example, there are many softwares doing rootkits detection by monitoring the SSDT and IDT table in memory. There are two problems in this approach. First, a software running on the operating system could be terminated by rootkits. Second, monitoring SSDT and IDT table somehow interfering with the system kernel and it is likely to make the entire system becomes unstable. In contrast to the software agent, the hypervisor could just monitor those two tables without installing any software on the guest VMs and the guest VMs do not even know that they are being watched. In the other word, the guest VM could not stop this monitoring mechanism, hence there is no place for rootkits to hide. We could do much more by leveraging virtual CPU/memory introspection. For instance, we could do process monitoring, windows registry monitoring and even process injection. I will address this part more in my upcoming blog posts.
4. Virtual IPS
On the hypervisor, we have virtual NICs on guest VMs and we use virtual switches to connect them together. How about virtual IPS? It turns out that it is easy to use a virtual IPS to bridge two virtual switches to do inline traffic inspection. The virtual IPS could be a service running on the hypervisor or a virtual machine having IPS capability. Since everything is virtual, there is no port number limitation in virtual IPS. We could dynamically create new port to bridge new virtual switches created by users. Furthermore, administrators could now have a flexible network topology that could be adjust anytime. Remember how hard it is to change the network topology in your server room? You need to reconnect all the cables to different switches and different IPSs. That would definitely ruin your day.
When we study the security solution in the cloud, we need to know what technologies they are using. Is it an old wine in new bottle? Do they leverage the technologies I mentioned above? Could they provide the functionalities that we couldn’t have before? Using an incomplete solution could only make hackers happier and make your life a debacle.