Over the last two months, I’ve been working on a VDI refresh engagement, involving technologies such as VMware Horizon View 5.2, vCNS (vShield) and McAfee Move, agentless solution. The customer previously used a standard McAfee agent solution, with the agent installed in every Windows virtual desktop. However they own the license for the agentless solution, and thought this would a suitable time to investigate this, to optimize the environment and provide the best performance, whilst continuing to protect their virtual desktops.
With the agentless solution, a virtual security appliance is run on each host, and performs all the scanning, plus definition and policy updates. This dramatically reduces the load on the host in terms of memory and CPU, and also the Windows virtual desktop, as there’s no requirement for the agent to be installed in Windows. The benefits are clear, with increased virtual desktop performance and anti-virus updates and scanning storms, a thing of the past. You can also manage the solution from the McAfee ePolicy Orchestrator software.
Therefore, after research and a trial period, I deployed the agentless solution and I thought I’d document the process and quirks\issues I found along the way, in case a future engagement involves this or a similar agentless solution. I hope others may also find this useful?
First of all, the McAfee Move solution and product guide can be found here:
You can also review other external references at the end of this post.
The following graphic is taken from the above guide from McAfee, and outline the components involved in the solution.
Note: Ensure the upgrade bundle is named as above, otherwise you’ll receive an error when trying to update vShield. I had to rename the file after download, in order to ensure this worked. This problem has been document by another blogger.
There are a couple of VMware KB articles to support this process.
After vCNS (vShield Manager) was upgraded to 5.1.2a, it was time to install the vShield Endpoint component onto each ESXi host. You can review the best practices guide from here
In preparation for the McAfee Move virtual security appliances (VSA) on each ESXi host, McAfee ePolicy Orchestrator software, which acts as the management station for the solution needs to be deployed. The latest version 5.01 was downloaded and installed onto Windows Server 2008. This was performed by the customer, but it’s a simple process, selecting either a SQL Express or dedicated SQL Server installation, depending on the size of your environment. For more information, refer to the McAfee documentation or external references at the end of the post.
Following the ePO deployment, you need to install ‘Product Extensions’ to extend the functionality of the ePO software and allow for the Move agentless solution.
Note: When completing the details in the Properties section of the Deploy OVF template, I found some of these settings did not apply after the deployment of the VM. For example, if you set a new admin password for the svaadmin account, for some reason this password does not apply when first setting up the VSA at the console screen, you still need to use the default password of admin.
Also, settings such as the vShield and ePO did not apply either, and I had to re-enter these through the console.
The VM-based scan configuration allow further granular control, to group protected virtual machines, and then apply policies to these groups. You need to install the relevant Data Center Connector for vSphere, which discovers and imports both running and stopped machine instances from VMware vCenter to the McAfee ePO server. This product integrates the management feature of McAfee ePO with the VMware vCenter server, and displays the imported virtual machines and their protection status on McAfee ePO.
Trouble-Shooting
‘No route to host’
I found this to be a setup issue, after a quick ping test of the appliance which failed, I double checked the appliance VM. On initial deployment of the OVF template, I mis-configured the management network, and selected the next VLAN in the list. After quickly editing the VM and selecting the correct vNetwork, I was able to ping my appliance and register with vShield Manager.
You can use Linux commands like ‘tail’ to inspect the logs –
The logs are fairly self-explanatory, in my experience I used the mcafee_agent_registration.log and mvsvc.log, whilst trouble-shooting communication from the appliance to the ePO server.
Move-AV appliance – VM Resources
The standard deployment of the VM, is configured for 2GB and 2 vCPU by default. I couldn’t find any sizing guidance within the documentation, for example, recommended specification for 50+ VMs per host or 100+ VMs per host. The documentation stated a minimum of the above configuration. Therefore, initially I deployed with the default values.
On-Demand scans, where the appliance will scan all the VMs on the host, can be scheduled for a window of your choice (preferably out of production hours). The On-Demand scan setting is disabled by default. I enabled this to see how the appliance and host performed during a test period.
CPU – Resources of the appliance were maxed out during on-demand scans, which by default scans a maximum of two VMs. You could change this setting, however if you increase the number of concurrent scans, I would advise possibly looking at increasing the Move appliance to 4 vCPU. As long as On-Demand scans are occurring out of production hours, having a 4 vCPU Move appliance, which will no doubt make full use of those vCPUs (although I haven’t tested), should not affect other virtual desktops running on the host in terms of ESXi co-scheduling.
RAM – The operating system of the appliance tends to consume around 1.5GB RAM, however when On-Demand scans are taking place, the VM uses all of the RAM available. Towards the end of the scanning window, I found a couple of different appliances just locked up and crashed. The host was running with around 50 VMs.
I recommend increasing this to at least 4GB RAM, possibly 6GB or 8GB depending on the VM\host ratio.
Unprotected Status
Within vShield Manager, Service VMs (appliances managed by Endpoint), should not be visible from the Inventory, as management operations are not supported. However, I detected a few Move appliances which were visible and showing under the Summary page as Services ‘Unprotected’.
I could not find any errors or alarms in the logs from vShield Manager, or via the vShield tab on each host within vCenter using the client. From here, the Endpoint status was also good. However, from the General page, I noticed the ‘Service Virtual Machines’ listing as blank. Other hosts were listing the Service VM.
Logging into McAfee ePolicy Orchestrator, showed all appliances communicating and within compliance. However, I did notice from each of these three Move appliances, the ‘Threat Events’ within ePO was relatively empty for the last few days, in comparison to the other Move appliances.
Therefore, to resolve this issue, I had to unregister the Move appliance from vShield Manager, and then register the appliance again.
From the Move appliance console, login as svaadmin and run the below command to run the setup configuration script
Run the sva-config command again (use tab), enter ‘no’ for configuring other items.
This time when prompted for vShield, choose ‘Register’ and supply the details.
Waiting for a minute or two for registration to complete, then quickly switching to vShield Manager and selecting the VM, shows ‘Operations not supported on this virtual machine’. Wait for another minute, and the VM will disappear from the inventory (which is a good sign!).
To verify all components, within vShield Manager, under the Inventory, click on Datacenter. Under General, verify the Service VMs (Move appliances) are detected and running on each host. Also, double check Endpoint is enabled for all hosts.
External References