Here's how to configure your ESX Servers for optimal security.
There should be no surprise that virtualization has grown so popular. The ability to run multiple applications, servers, or even entire networks on a single hardware-based server promises much more than consolidating the number of boxes needed in the data center.
When done correctly, virtualization IT manageability cuts the amount of energy needed to power the data center, saves space, and makes businesses more agile than ever. Virtualization is growing so fast that research firm IDC expects the virtualization services market to grow from $5.5 billion in 2006 to $11.7 billion by 2011.
As security professionals, we have to ask: what are the potential security implications of virtualization?
The answer is: they are considerable. Consider the VMware share folder vulnerability that surfaced recently, and could allow a virus or Trojan to jump from a virtual machine to its host. Or the fact that a single misconfigured virtual machine could jeopardize the security of not only the host, but of all the other virtual machines on that system. Just the sheer number of patches – roughly 60 last year for ESX 3.0.1 – warrants attention.
While there are a number of virtualizations solutions on the market for x86 systems, this column focuses on securing one of the most common, which is VMware's ESX Server configuration.
To keep your ESX Servers in good shape, you'll want to have in place a number of important controls and settings. These include:
Avoid Default Port Groups. A default port group creates a virtual machine port group on the same network interface as the system's service console. By enabling this option, virtual machines possibly could detect sensitive and often unencrypted information. That means it's a good idea to avoid default port groups whenever possible.
Dedicate Networks for VMotion and iSCSI. iSCSI and VMotion, which make it possible to move live, running virtual machines from one host to another, are not encrypted. This means that the entire state of a virtual machine could be exposed. The answer is to use a dedicated and isolated network for VMotion and iSCSI.
Secure MAC Addresses. In the ESX Server, set the MAC address option to “reject” so that the ESX Server does not honor requests to change the effective MAC address. Also set the “forged transmissions” option to “reject.” This way, the ESX Server compares the source MAC address being transmitted by the operating system to the effective MAC address for its adapter, to see if they match. If the addresses do not match, the ESX Server makes the wise choice, and drops the packet.
Do not use promiscuous mode. When promiscuous mode is enabled for a VMnic switch, all virtual machines connected to the virtual switch have the potential to read all packets sent across that network, from other virtual machines as well as any networked physical machines or other networked devices. Turn promiscuous mode off.
Secure the ESX Server Console: Even if you have locked down the ESX Server to protect it from network attacks, anyone with access to the console of the host still might cause problems. You secure an ESX Server Console much the same way you secure a Linux system: set proper firewall rules, control access to root privileges, limit access to “su” using sudo, and employ password management best practices.
Securing Virtual Center: Secure the Windows Host for Virtual Center by limiting administration access and securing the Virtual Center database.
These are good suggestions to help keep your ESX Servers secure. Recently, VMware announced an initiative, VMsafe, which will help the company to foster a more secure virtualization platform. VMsafe will enable security vendors to build their applications so they can integrate closely with the Hypervisor. Essentially, the hypervisor is a layer of software that runs independent of the primary operating system and manages virtual machines. VMsafe will provide security software makers access to the memory, CPU, and I/O systems of the virtual machine. So far, about 20 security vendors have signed up, including Check Point Software, F5, Fortinet, IBM and Symantec.
These APIs definitely are a step in the right direction, and will provide for more security options when it comes to locking down virtual machines. The catch, however, is that the more APIs that are created, the more potential attack points there are. The devil, as always, will be in the details, and the quality of your implementation and configuration.
There should be no surprise that virtualization has grown so popular. The ability to run multiple applications, servers, or even entire networks on a single hardware-based server promises much more than consolidating the number of boxes needed in the data center.
When done correctly, virtualization IT manageability cuts the amount of energy needed to power the data center, saves space, and makes businesses more agile than ever. Virtualization is growing so fast that research firm IDC expects the virtualization services market to grow from $5.5 billion in 2006 to $11.7 billion by 2011.
As security professionals, we have to ask: what are the potential security implications of virtualization?
The answer is: they are considerable. Consider the VMware share folder vulnerability that surfaced recently, and could allow a virus or Trojan to jump from a virtual machine to its host. Or the fact that a single misconfigured virtual machine could jeopardize the security of not only the host, but of all the other virtual machines on that system. Just the sheer number of patches – roughly 60 last year for ESX 3.0.1 – warrants attention.
While there are a number of virtualizations solutions on the market for x86 systems, this column focuses on securing one of the most common, which is VMware's ESX Server configuration.
To keep your ESX Servers in good shape, you'll want to have in place a number of important controls and settings. These include:
Avoid Default Port Groups. A default port group creates a virtual machine port group on the same network interface as the system's service console. By enabling this option, virtual machines possibly could detect sensitive and often unencrypted information. That means it's a good idea to avoid default port groups whenever possible.
Dedicate Networks for VMotion and iSCSI. iSCSI and VMotion, which make it possible to move live, running virtual machines from one host to another, are not encrypted. This means that the entire state of a virtual machine could be exposed. The answer is to use a dedicated and isolated network for VMotion and iSCSI.
Secure MAC Addresses. In the ESX Server, set the MAC address option to “reject” so that the ESX Server does not honor requests to change the effective MAC address. Also set the “forged transmissions” option to “reject.” This way, the ESX Server compares the source MAC address being transmitted by the operating system to the effective MAC address for its adapter, to see if they match. If the addresses do not match, the ESX Server makes the wise choice, and drops the packet.
Do not use promiscuous mode. When promiscuous mode is enabled for a VMnic switch, all virtual machines connected to the virtual switch have the potential to read all packets sent across that network, from other virtual machines as well as any networked physical machines or other networked devices. Turn promiscuous mode off.
Secure the ESX Server Console: Even if you have locked down the ESX Server to protect it from network attacks, anyone with access to the console of the host still might cause problems. You secure an ESX Server Console much the same way you secure a Linux system: set proper firewall rules, control access to root privileges, limit access to “su” using sudo, and employ password management best practices.
Securing Virtual Center: Secure the Windows Host for Virtual Center by limiting administration access and securing the Virtual Center database.
These are good suggestions to help keep your ESX Servers secure. Recently, VMware announced an initiative, VMsafe, which will help the company to foster a more secure virtualization platform. VMsafe will enable security vendors to build their applications so they can integrate closely with the Hypervisor. Essentially, the hypervisor is a layer of software that runs independent of the primary operating system and manages virtual machines. VMsafe will provide security software makers access to the memory, CPU, and I/O systems of the virtual machine. So far, about 20 security vendors have signed up, including Check Point Software, F5, Fortinet, IBM and Symantec.
These APIs definitely are a step in the right direction, and will provide for more security options when it comes to locking down virtual machines. The catch, however, is that the more APIs that are created, the more potential attack points there are. The devil, as always, will be in the details, and the quality of your implementation and configuration.
