Join us for the upcoming North Carolina Triad VMUG meeting taking place on Friday, July 13, 2012.

Registration is now open and available to all VMUG members. This is a great opportunity to meet with your peers to discuss virtualization trends, best practices, and the latest technology! Read more >>

Welcome to our last discussion on the VMware vSphere 5.0 Hardening Guide of the week. Here are links to the past articles from the week: one, two, three, and four.

• Guideline Title: Verify contents of exposed configuration files
  • Title: verify-config-files
  • Discussion: Certain configuration files exist on ESXi hosts that govern host behavior and operations. These files should be logged and monitored for both authorized and unauthorized configuration changes. These files can be retrieved over HTTPS via http://<hostname>/host if the Managed Object Browser (MOB) is enabled. However, a separate VMware hardening recommendation we’ve previously covered advises that the MOB be disabled. If your organization chooses not to accept the risk of leaving the MOB enabled, these configuration files can also be retrieved via vCLI or PowerCLI.
  • Official VMware documentation
• Guideline Title: Keep ESXi system properly patched
  • Title: apply-patches
  • Discussion: ESXi is designed from the ground up to be a powerful but secure hypervisor with minimal attack surface area. A complete install disc is less than 300MB. ESXi needs patches much less frequently than ESX used to, but it does still need them. VMware Update Manager is a free tool included with vCenter to help automate the patching of ESXi hosts during production hours with no VM downtime. To stay on top of the latest VMware Security Advisories by email you can also subscribe here.
  • Official VMware documentation

Note: I’m collapsing the next three hardening guide checks into a single entry since they are almost identical. I will point out in the discussion section where they differ.

• Guideline Title: Verify Image Profile and VIB Acceptance Levels
  • Title(s): (1) verify-acceptance-level-certified, (2) verify-acceptance-level-accepted, (3) verify-acceptance-level-supported
  • Discussion: vSphere Installation Bundles (VIBs) are files that can be used to extend ESXi functionality. They might perform functions such as enabling hardware status monitoring, adding new hardware drivers, or enabling third-party security virtual appliances. These VIBs can have one of four available acceptance levels: VMwareCertified, VMwareAccepted, PartnerSupported, and CommunitySupported. As their names imply, these four levels relate to the entity that tested and possibly certified the VIBs for use. When you configure the VIB Acceptance Level, you are instructing your ESXi hosts to only install VIBs that meet or exceed the specified level of support and testing.
    • -VMwareCertified – these VIBs are created, tested, and signed by VMware. This is the recommended setting for environments hosting extremely sensitive data, including military environments authorized to handle classified data.
    • -VMwareAccepted – These VIBs are created by a VMware Partner but are tested and signed by VMware. This is the recommended setting for environments hosting sensitive data or those subject to stricter compliance requirements.
    • -PartnerSupported – These VIBs are created, tested, and signed by a certified VMware Partner. This is the recommended setting for all vSphere environments.
    • -CommunitySupported – These VIBs are neither supported nor digitally signed. CommunitySupported VIBs should not be installed on production vSphere environments.
  • Official VMware documentation

So for the guys out there who have read a few of my blogs, they know that before I came to eGroup I spent 11 years on the customer facing side of IT, administering storage, VMware, Citrix, etc.. One of my roles during that time period was also managing antivirus on desktops and servers, a fairly critical task because no one wants to have a major virus outbreak. It was never a fun task though, DATs were a pain, so was versioning, and hoping that it was working and that it was actually updating never made you feel good! Well, as I made the jump to my new career at eGroup I had my eyes opened to a new world of technology that I had not been exposed to previously, one of those was Trend Micro’s Deep Security. As a VMware administrator I played around with different antivirus solutions trying to find one that didn’t impact CPU utilization on my hosts and virtual machines severely, if it was an antivirus solution I tried it at least once and yet all of them seemed to impact my VM’s CPU ranging from about 10% to sometimes closer to 30%. I always thought this was ridiculous and that there had to be a better way, well apparently the guys at Trend thought so as well and came up with a solution. Read more after the bump to see how it works! Read more >>

• Guideline Title: Disable SSH
  • Title: disable-ssh
  • Discussion: We all know and love SSH. It’s an encrypted way to access a command line on a remote system. But the truth is that a stopped service is infinitely harder to exploit than a running service. SSH should only be enabled as necessary for troubleshooting and then should be stopped again.
  • Official VMware documentation Read more >>

If you’re just joining us, I’m blogging my way through the VMware vSphere 5.0 Hardening Guide. The preceding posts, one and two, are also available. Today’s post discusses self-signed certificates, the DCUI console, and the memorable ESXi shell. Let’s dive in!

• Guideline Title: Enable SSL for NFC
  • Title: enable-nfc-ssl
  • Discussion: NFC (Network File Copy) is used to copy or migrate VMs between ESXi hosts. The vulnerability being addressed here is network traffic sniffing. If an attacker sniffed NFC traffic as it was being used to ship an entire VM, they would get an effective duplicate of your entire virtual server. Normally turning SSL on here would be an easy decision to recommend, but in this case, VMware’s guidance on this issue is that NFC over SSL between ESXi hosts “has … not been extensively tested and so may cause HA and other operations to fail in certain circumstances.” Ouch. We’ll keep our eye on this one and hope that NFC over SSL gets more testing in the future. In the meantime, make sure your vSphere management networks and VLANs are sufficiently isolated as a partial mitigation.
  • Official VMware documentation
• Guideline Title:  Do not use default self-signed certificates for ESXi communication
  • Title: esxi-no-self-signed-certs
  • Discussion: This hardening guidance is written towards vSphere, but it’s always good guidance for any system that uses encryption, even plain ol’ Windows Remote Desktop! Wikipedia has a detailed explanation of man-in-the-middle attacks, but here’s the gist: whenever you choose to connect to a server with an unverified SSL certificate, you have no certainty that your encrypted SSL tunnel reaches all the way to the server you’re talking to. It’s possible that your traffic is being intercepted, decrypted, stored, re-encrypted, and sent to its destination – all without you or the server you’re connecting to being aware your traffic was intercepted. Self-signed SSL certs are generic and hard to distinguish from each other. They also lose the benefit of having a Certificate Authority confirm the validity of the cert. The solution is always replace default/vendor certificates on all network endpoints with certs issued by a commercial or organizational Certificate Authority.
  • VMware Official documentation
• Guideline Title: Prevent unintended use of dvfilter network APIs
  • Title: verify-dvfilter-bind
  • Discussion: The dvfilter network APIs are part of the larger VMsafe API and they allow VMware partners to develop virtual security appliances to control the behavior of guest virtual machines. These virtual appliances have the benefit of simplifying guest VM configuration while increasing the overall security of your environment. Some great examples of this include Trend Micro Deep Security, the Cisco Virtual Security Gateway, and the Juniper Virtual Gateway. These appliances allow you to manage firewalls around your VMs as easily as dragging and dropping VMs in vCenter, enabling secure VM isolation (e.g. “DEV servers can’t talk to PROD servers”) but without sacrificing any ease of management (one of the reasons we virtualized everything in the first place, right?) These virtual security appliances using the dvfilter APIs receive privileged access to other guest VM network traffic. If you’re not using any security appliances that leverage these APIs, you’ll want to confirm they’re not in use to prevent a malicious VM from receiving the data instead.
  • Official VMware documentation is still TBD
• Guideline Title: Disable DCUI to prevent local administrative control
  • Title: disable-dcui
  • Discussion: NOTE: This is only recommended by VMware for the most secure environments. The DCUI is the name of the service that runs the gray and yellow console screen we all see when we first install ESXi and then promptly forget exists. This service can be stopped (and configured to not auto-start) which prevents any operations from occurring at the console or over a KVM. Be very careful and know the impact of this change. If you misconfigure a vSwitch and knock your host management kernel port offline, there’s no parachute to reset the host vSwitch and you might be reaching for an ESXi install disk.
  • Official VMware documentation is still TBD
• Guideline Title: Disable ESXi Shell unless needed for diagnostics or troubleshooting
  • Title: disable-esxi-shell
  • Discussion: This is known by some as the ESXi command line, formerly known as Tech Support Mode. From an ESXi console, you can press Alt+F1 and login as root to access a BusyBox environment that looks and acts a bit like Linux but has full control over host operations. The ESXi Shell should be started as necessary through the vSphere console for troubleshooting purposes and remain stopped the rest of the time.
  • Official VMware documentation