Server virtualization has become commonplace over the past couple of years. Many organizations started out using VMWare and other virtualization products in lab environments and for utility type servers and workstations. Many virtual server deployments were implemented for internal web servers, ftp servers and other light use servers. As confidence increased in these deployments, more mainstream and business-critical applications have made their way into the virtual environment. Since this is a progression over time, many organizations have not really considered the security ramifications of this shift in paradigm.
When scouring the internet, you will find many different perspectives on virtualization and security. One perspective is that virtualization increases security. This is due to the fact that it allows organizations to more cost-effectively separate server roles. Another perspective is that virtualization decreases security because you basically have an added shim between the hardware and the network that could potentially be attacked. Attacks against this shim, also known as the hypervisor, are typically called hyperjacking. These types of attacks are basically root kits inserted into the host’s operating system. Another concern is guest to host leakage. Any process that can extend itself from the guest os to the host os is obviously a major concern.
My position on security and virtualization is a combination these concerns and is basically the same as my position on any other major shift in this industry. My belief that it is security in a virtual environment is different and should simply be understood. A virtual environment can be more or less secure than a traditional server farm model when cost is a factor based on how it is deployed. Virtualization is simply different, requiring the security to be addressed differently as well. Since this site is devoted to packets, I would like to examine these differences as it pertains to intrusion detection.
In a traditional network that does not include virtualization, the workstations, servers and routers connect to a switch. An IDS or Intrusion Detection System may be connected to a specially configured switch port that allows it to see all of the traffic passing through the switch. This port is usually called a monitor port or a span (Switched Port Analyzer) port. Traffic passing to or from anywhere to a device connected to the switch, will be copied to the span port. Thus the IDS very likely has “switch wide” visibility.
By collapsing the physical servers in a traditional network model to one or virtual guests on a physical host server, our IDS systems lose the visibility into server to server traffic. The exception to this is when server to server traffic is between to physical Virtual Host servers. In other words, if we install our web, database and file server, into a single physical host running some type of virtualization shim, we willl ose the ability to see the traffic between the servers installed on that hardware. If the file server were installed on a different physical host, then communication could be seen to and from the web and database server to the file server. Basically, with virtualization, you have an external physical switch and an internal virtual switch. The virtual switch is uplinked to the physical switch through the Ethernet interface in the virtual host. Each virtual guest links up to the virtual switch by utilizing the software that is built into the virtualization shim.
To remedy this problem, the possibility exists that IDS appliance could become virtualized and appear similar to a virtual guest operating system within the host. Although, it should be very simple to migrate to this model, I do not currently know of a commercial vendor that is taking this approach. It is, however, a perfect place to utilize an open source IDS product like Snort. I have found that VMWare server basically behaves as you would expect it to when placing virtual Ethernet interfaces into promiscuous mode. If you are connect a physical interface in the Virtual Host to a VMNet and subsequently place a guest host with an interface bound to that VMNet into promiscuous mode, you actually can see traffic from the physical interface. If a VMNet is virtual only network, connecting a guest to that VMNet and placing it in promiscuous mode will allow for visibility into everything on that virtual network.
Next generation IDS and even IPS mechanism may provide a more intelligent approach to this. Virtualization vendors and projects could work with IDS and even IPS, or Intrusion Prevention Systems, vendors in order to tailor products more specifically to these needs. For example, an IDS or IPS platform could be inserted into or hooked to the code within the hypervisor. This is an ideal perspective to analyze traffic patterns. Hopefully this will lend itself to the possibility of some very strong heuristic IPS approaches to security within the hypervisor itself. Another approach is to use traditional host intrusion detection software in each guest. This approach does not have as much visibility alone. However, it does not suffer from not being able to inspect encrypted traffic, like a network based or hypervisor based approach does. Additionally, external systems can correlate events from multiple hosts, thus creating a wider overall view.
Virtualization, like any other shift in methodology should be well understood prior to using in the enterprise. Virtualization does bring with it security concerns. One aspect of security that needs to be addressed is the traffic visibility for IDS systems. With proper planning, IDS can be deployed in a manner that adequately monitors guest to guest and external communication. It is crucial to understand how collapsing multiple servers into one physical host limits the traffic visibility. Once this is understood, solutions should be explored in order to maintain the traffic visibility that is describe in the security policies and is expected by the organization. In the future, I fully expect to see both commercial and open source projects that are specifically designed to fill the needs created by the virtual network. However, in the meantime we must make sure that we deploy our solutions without incurring increased risk and decreased traffic visibility.