VSAN Deployment Guidelines - Part 1

In this post, I want to emphasize some of the important points of VSAN design by reviewing most primary VMware VSAN documentaries. Some of them included:

1. vSAN 7.0 Planning and Deployment
2. VMware VSAN Design Guide
   

I tried to cover all aspects of planning and design however, maybe I forget to mention some of them. Of course, it makes me happy if you find and remind me as a reply.

1. Don't ignore utilizing the same server configuration in the VSAN cluster, that is included identical hardware resources, such as processor model, total memory, and identical disk devices. Unbalancing the cluster can lead to storage performance reduction and different maintenance duration for each ESXi host. a uniform setup of the hosts also increases the rate of stability.
   
2. Consider some extra/spare components like disk devices, network adapters for VSAN cluster's member or even a physical server with enough capacity for rebuilding operations in the cases of disk device or host failure.
3. Try to keep always storage's used space less than rate of 70%. In the case of multiple VSAN cluster rebalancing operations (higher than 80% usage) it will affect on the line of business performance (Apps on VMs).
   
4. Don't forget to use VSAN sizing tools and check your server platform and storage device model on the VMware Compatibility Guide (VCG) as a pre-requirement step of VSAN setup.
5. Construct All-Flash architecture for the VSAN cluster, if you have any plan for VDI Deployment based on VMware Horizon View solutions even in the future, especially in the scenarios you will deploy Instant Clone. Enabling Deduplication and Compression options are highly recommended for this type of Desktop Pool to save storage space.
6. Enable VSAN Encryption preferably before deploying VMs on VSAN Datastores to reduce the required time for this operation. Although it's possible to enable Encryption for both layers of Capacity and Cache, Compression can be done just for Capacity.
7. Preparing more disk groups with a few members of the disk device can break the fault domain originated by any disk failures. However, in your VSAN planning phase, you should attend to these triple metrics carefully and choose whatever has a higher priority in your infrastructure: Required total capacity, better performance, and higher fault tolerance.
8. Using the Passthrough mode for the setup of the VSAN disk devices has better performance than using RAID0 mode which is configured via server local array configuration tools. Also, RAID0 required more configuration and maintenance actions. At last, if you have some non-VSAN disks, do not assign them as the RDM for your VMs.

In this post, I focused on server and storage considerations of VSAN deployment. In the next part of this series, I will discuss with respect to the networking section.

Horizon View: Investigation of all states of a virtual desktop

In this video, I discussed and review all types of virtual machine status related to a virtual desktop belonging to a Horizon View desktop pool. I tried to analyze most of them and also the circumstances of their occurrence.

  

A simple review on "Exposing Malware in Linux-Based Multi-Cloud Environments" document

Thanks to VMware TAU (Threat Analysis Unit) for publishing a technical report about the ransomware, cryptominers, and RAT attacks and techniques. This document focused on all recent critical threats against the Linux-based multi-cloud environment, like REvil and Defray777. 

I asked one of my technical staff (TW:alirahimi681) to review this very useful document. After his deeply reading, he summarized an easy-to-read draft about two categories of threats in this document: Ransomware and Cryptominer. Then I decided to publish this briefing on my blog for whom that may not read the whole original document. 

Ransomware families:

VMware TAU analyzed nine ransomware families and characterized their evolution. They started analyzing the different characteristics of the ransomware samples of each of these by looking at the static information extracted from their ELF files. While threats can be a combination of shell scripts, Python scripts, and binaries, this report focuses on the binaries. Binaries are usually the components that carry out the file system encryption in a ransomware attack.

REvil: Also known as Sodinokibi, originally targeted Windows hosts but released a Linux version in spring 2021. Interestingly, this threat relies on the esxcli tools to stop the current ESXi virtual machines. It then encrypts their on-disk images to prevent the recovery of running VMs. Recently, REvil actors have been targeted by a coordinated take-down operation that may impact future variants.

DarkSide: The actors behind DarkSide initially distributed REvil. Usually, they are using REvil as a service they called ransomware as a service (RaaS) operator. This ransomware has been used to target a wide variety of organizations and initially targeted Windows but quickly evolved to include Linux targets and in particular, those running on ESXi servers. These servers are usually targeted after the threat actors gain access to a VMware vCenter deployment, often by means of stolen credentials.

BlackMatter: The actors behind BlackMatter made sure to publicly announce that they were not targeting specific verticals, such as healthcare, oil and gas, government, and critical infrastructure companies possibly following the backlash that the Colonial Pipeline attack created, and the unwanted attention that the DarkSide operators received.

Defray777: Defray ransomware is another Linux-based threat that targets ESXi VMs. An interesting property of some of its samples is that it doesn’t strip or tamper with ELF binaries, which makes them easier to analyze. This ransomware family is closely related to RansomEXX to the point that sometimes the two families are considered to be variations of the same threat.

HelloKitty: The actors behind HelloKitty ransomware have achieved notoriety after successfully attacking CD Projekt Red, the makers of the Cyberpunk 2077 video game. It’s a Windows-based threat that evolved and expanded into the Linux world, targeting Linux-based systems and ESXi servers. Like other samples that target ESXi VMs, HelloKitty uses the esxcli tool to stop the VMs currently running before encrypting their files.

ViceSociety: Their malware shows substantial similarities with the HelloKitty ransomware. This ransomware family was responsible for attacking the United Health Centers in the San Joaquin Valley in California, among other targets, which resulted in the leaking of sensitive patient record

EreBus: This is a relatively older ransomware family. It initially targeted Windows hosts but evolved in 2016 to include a Linux variant. This threat is unique because of its multilingual nature. While the actors behind the ransomware have stopped their activity, it is still an interesting sample that shares some behaviors with other ransomware families.

GonnaCry: This is an open-source ransomware sample written in C and Python. While the Python version is mostly used as a way to showcase some of the behaviors associated with ransomware, the C version has actually been observed in the wild.

ECh0raix: This ransomware targets QNAP NAS storage devices with weak credentials. This family is written in the Go language, and its features are simpler than other ransomware families.

Cryptominer Families:

XMRig: Is an open-source miner available for Windows, Linux and macOS. While this miner is not a threat by itself, a variant of this component is often deployed as part of crypto-jacking attacks to perform the mining. XMRig is often used to mine the Monero cryptocurrency, which is the preferred target because it can be mined without needing specialized hardware.

Sysrv: Is a botnet written in Go with cryptomining capabilities that has been recently deployed against K8s pods running WordPress. This threat attempts to spread on the network via performing password dictionary attacks against vulnerable services and using a database of exploits against known RCE vulnerabilities.

Team TNT: This threat’s actors target open K8s / Docker environments to deploy XMRig cryptominers. To evade detection, this threat hijacks the library loading mechanism to hide specific directories in the /proc file system, which are associated with the processes running the cryptominers.

Mexalz: Mostly customized versions of XMRig that is exploiting weak credentials to compromise hosts and deploy cryptomining malware.

Omelette: Is a cryptomining worm that exploits known vulnerabilities in Exim, WebLogic, and Confluence to install modified versions of XMRig. It spreads to other systems by exploiting trust relationships.

WatchDog: Represents one of the longest-running cryptomining operations that is written in Go. The name is derived from the presence of a component that is tasked to monitor the execution of the actual cryptomining program, similar to the Linux utility “watchdog.”

Kinsing: The attack exploits Docker API endpoints that are open to the world to download and install a number of shell scripts that aid in persistence and ultimately lead to the download of a cryptomining component.

Many Vulnerabilities of many products (Spring4Shell)

 

Multiple vulnerabilities have been announced related to many VMware products in the last month, especially in the recent two weeks. It's very important to consider them all: Investigate the workaround or install the published patch.

Also most of VMware Tanzu products are vulnerable against the recently announced RCE: Spring4Shell (CVE-2022-22965) related to the Spring Core Java Framework that is described in the VMSA-2022-0010.