As a common best practice you should separate management, vMotion and Virtual SAN traffic from production traffic. This is not only a performance requirement, but also for security concerns. Compared to management traffic which is encrypted and requires authentication and vMotion traffic which is impracticable to eavesdrop, Virtual SAN traffic presents a large surface area to attacks.
This article explains why it is critical to keep Virtual SAN traffic in protected networks and what can happen when you ignore this guideline. I am also explaining how you can detect and monitor such attacks.
Read more »
This post explains how you can hide a VMware based Virtual Machine from designated users or the entire vCenter Server infrastructure. I’am explaining different scenarios where you can hide Virtual Machines including:
- Hide Virtual Machines from Groups or Users in vCenter
- Hide Virtual Machines from the entire vCenter Server
- Hide Virtual Machines from root on Single ESXi instances
- Find hidden Virtual Machines
To clarify, this post does not cover techniques to cloak that the Guest OS is running on a virtual machine, instead of bare metal.
Read more »
You might be aware of the 3 critical security issues that VMware has published and fixed a couple of days ago in VMSA-2015-0007. The information provided in the security advisory regarding the first issue, CVE-2015-5177 (ESXi OpenSLP Remote Code Execution), are:
VMware ESXi contains a double free flaw in OpenSLP’s SLPDProcessMessage() function. Exploitation of this issue may allow an unauthenticated attacker to remotely execute code on the ESXi host.
VMware ESXi 5.5 without patch ESXi550-201509101
VMware ESXi 5.1 without patch ESXi510-201510101
VMware ESXi 5.0 without patch ESXi500-201510101
In this post I am trying to give a better understanding of the vulnerability and its consequences. Please note that the information in this post are my personal opinions. I cannot guarantee that these information are accurate. The main fact is that VMware has published a fix and you should install the patch to be on the safe side. In the real world, you might have something like a “change process” where you can’t rollout the patch for hundreds of systems immediately. Or you have a single ESXi that you don’t want to reboot at the moment. In this situation, this post tries to help…
Read more »
[Last Update April 19, 2014 – Patches available]
There are a lot of news according to the recently published OpenSSL vulnerability. The bug, also known as “Heartbleed”, allows attackers to steal informations that are protected by the SSL/TLS encryption.
Is VMware ESXi and the vCenter affected?
There is currently no official statement from VMware regarding this issue. After some research I found affected versions im VMware products. Here are my findings:
The affected versions are OpenSSL 1.0.1 through 1.0.1f.
Read more »
VMware has publish a security fix for their current ESX Server. There is a vulnerability which might allow an attacker to manipulate the traffic from a remote virtual device to cause the virtual machine to crash. Another vulnerability might allow an attacker with the ability to load a specially crafted checkpoint file to execute arbitrary code on the host.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2012-3288 and CVE-2012-3289 to this issues. Please note that this is not the privilege escalation vulnerability which in everybody’s mouth at the moment. VMware products are not affected by this issue (CVE-2012-0217).
The latest ESXi 5.0.0 Build number is now: 721882
Also affected: ESX(i) 4.1, ESX(i) 4.0, ESX(i) 3.5
Updated: ESXi Release and Build Number History