[Updated twice below.]
Check out Alex Bakman’s VMworld 2007 presentation here as well on Top 10 Recommendations for Improving VMware ESX Security.
- Use Firewall and Antivirus software for COS. Just as in any other operating system, this provides basic protection
- Use VLANs to segment the physical network so only machines that are required to see each other are able to do so
- When installing ESX, use security=high
- Do not allow root level access over SSH and use secure commands
- Disable all unnecessary services in console OS
- Use VirtualCenter to help you manage granular security access
- Stay current with ESX patches
- Harden Guest Operating Systems
- Control User Level Access using VirtualCenter
- Document and monitor configuration changes in your environment, especially changes in security settings
[Update: from Schley Andrew Kutz in the comments:
I disagree about installing an AV scanner in the COS. There should
be limited access to the COS to begin with, and an AV scanner provides
unnecessary overhead. Remember, most ESX installations do not allocate
the COS that much memory, and an AV scanner will just bog things down,
and honestly is not all that helpful.I appreciate Alex’s work on this, but I work very hard to encourage
people to think of VMs as physical machines. Hence, I think when
designing documents like this we, as public voices for ESX, should
separate guidelines and suggestions into 2 categories — 1) topics
related directly to VMs and 2) everything else. Steps 4, 5, 7, 8, 10
are all steps that should be applied to any server or operating system.
They are not specific to ESX, its VMs, or guest OSs.
See also the two new papers just published on VMTN: VMware Infrastructure 3 Security Hardening and Security Design of the VMware Infrastructure 3 Architecture.]
[Update 2: From one of our internal security gurus:
Also as a general recommendation we suggest putting the Service console or Console OS (COS) on a separate network or VLan. The COS should only be accessible people who administer ESX. This will significantly reduce the attack surface. In fact if you can you should have the COS on its own private physical nic card and virtual switch. Since you restrict permissions at the network layer the more common ‘privilege escalations’ are not possible.
As far as an anti-virus… If you have a physically separate COS and you don’t use the COS as a "general purpose" OS, you shouldn’t need an anti-virus. If your environment requires anti-virus, you need one that will work with our glibc version.]
