Replacing McAfee VSE with MOVE MP AV

MOVE - McAfee Management for Optimized Virtual Environments
MP - Multi-Platform AV (requires McAfee agents on VMs)
AL - Agentless AV (no software required on VMs)
OSS - Offload Scan Server — provides offloaded scanning support for VMs
SVA - Security Virtual Appliance - delivered as an Open Virtualization Format package
VSE - VirusScan Enterprise 
HIPS - Host Intrusion Prevention

The difference between MOVE MP and AL:

• According to McAfee, there is no difference in performance
• MP supports ePO policies per VM or OU through McAfee agents; AL has only 1 policy per hypervisor
• MP is easier to install, configure and manage than AL
• AL requires dedicated networks/links between the SVA and target VMs
• On-screen pop-up notifications on client VMs are available with MP only
• AL can be deployed on VMware hypervisors only
• AL requires 1 SVA per ESX host, while MP requires 1 or 2 OSS’s per cluster
• AL is slightly lighter; it may be beneficial to lose McAfee agents from VMs in order to achieve higher VM density

As access protection and buffer-overflow protection features are not included in MOVE AV, McAfee recommends deploying HIPS as an additional layer in order to get close to the security level offered by VSE. HIPS can be configured for minimal interference so it doesn’t impact VMs’ performances badly.

OSS VM(s) should not be hosted together with other resource-hungry VMs, so that they don’t compete for resources with important production systems. Each ESX cluster should have its own OSS server(s). It’s recommended to have 2 OSS servers per cluster. If there is more than 1 OSS per cluster, they should be hosted on separate hypervisors.

I could not get official advice or find any info on whether VSE would perform better in certain scenarios, e.g. on file servers, as it could take some time for a big file to be transferred from a host VM to the OSS for scanning. Lots of such files accessed simultaneously could negatively affect all VMs on the cluster. There is no info on how MOVE compares to VSE performance wise.

MOVE uses file caching to boost performances, and it’s available for both on-demand and on-access (real-time) scanning. The size of the cache and time to keep the items are configurable.

Officially, an OSS can manage/scan up to 450 hosts, but in reality probably between 100 and 250, depending how busy these VMs are. The current load of an OSS can be determined by monitoring the OSS server statistics, e.g. the values of Avg request process time and Avg request wait time (C:\Program Files (x86)\McAfee\MOVE AV Server>mvadm stats).

VMware on vShield:

vShield Endpoint improves performance by offloading virus-scanning activities from each virtual machine to a secure virtual appliance that has a virus-scanning engine, as well as the stored antivirus signatures. For antivirus and anti-malware functions, this architecture eliminates the software agent footprint in guest virtual machines, frees up system resources, improves performance and eliminates the risk of antivirus “storms” (overloaded resources during scheduled scans and signature updates). Because the secure virtual appliance - unlike a guest virtual machine – doesn’t go offline, it can continuously update antivirus signatures, giving uninterrupted protection to the virtual machines on the host. Also, new virtual machines (or existing virtual machines that went offline) are immediately protected with the most current antivirus signatures when they come online.

General guidelines (from the MOVE deployment guide):

The number of clients that can connect to a single Offload Scan Server depends on these factors:

• Server hardware
• Network availability
• Workload per client

The optimal configuration is different in every environment. The primary criteria for determining the optimal number of clients a single Offload Scan Server can support is the number of concurrent client scan requests. Performance degrades when it receives more concurrent scan requests than it is configured to handle.

The Offload Scan Server can handle a maximum of 3,000 concurrent active scan connections:

• Heartbeats
• Scan requests
• Server‑side cache requests

If the server has reached its maximum of 3,000 active connections, any new connection is accepted, but queued for handling until one of the 3,000 active connections completes. Each client has a maximum of six active connections to an Offload Scan Server (one connection for a heartbeat and five for scan and cache check requests), limiting the Offload Scan Server to effectively handle a maximum of 500 clients before the connections start to queue. You can increase the number of clients connected to a single Offload Scan Server if the number of concurrent scan requests does not exceed the configured Concurrent Scans value. If this value is exceeded, server performance begins to rapidly decline.

Getting info on MOVE clients and servers:

MOVE client and server policies:

Deploying MOVE clients:

More info:
McAfee in the Data Center -Optimized Security for Virtualization
McAfee MOVE Antivirus joins the vShield Endpoint Family
MOVE Antivirus 2.6 Known Issues
Release Notes - McAfee MOVE AntiVirus 2.6.0 Patch 1
Supported environments for MOVE on Microsoft Windows
To HIPS or not
What are the McAfee MOVE 2.x products?
What is vShield Endpoint?

Configure McAfee ePO alerting on failed Master Repository updates

First configure an email server:

1. Go to Menu > Configuration > Server Settings > Email Server
2. Specify email server, the port and a from email address and save it. Test the configuration.

Then configure alerting:

3. Go to Menu > Automation > Automatic Responses and create a new response called ‘Master Repository Update failed’ (the response should already be there)
4. Set the following:
Event group: ePO Notification Events
Event type: Server
Status: Enabled and click Next

5. Under ‘Available Properties’ click on Event ID, select Equals and type in 16003 or select Event Description, Equals and ‘Master Repository Update failed’ and click Next

6. Select ‘Trigger this response for every event’ and put a check mark for ‘At most, trigger response once every (day) and click Next

7. In the drop down menu select Send Email, add the recipients, set:

Importance: High
Subject: "Master Repository Update failed" events received
Body:

ePolicy Orchestrator Notification
Response Name: {responseRuleName}
Event Type Name: {responseEventType}
Description: Sends an e-mail notification when "Master Repository Update failed" events are received.

Event Description: {eventDesc}
Source Computers: {sourceComputers}

8. Click Next and Save

How to exclude processes from virus scanning in McAfee ePO 4.5

Open the ePO management console and go to Policy Catalog. In the drop down menu switch to:

Product: VirusScan Enterprise 8.x.x
Category: On-Access Low-Risk Processes Policies

Create a new policy and apply it to the target computers. Click on Edit Settings, choose Workstation or Server, and add processes to the list under the tab Low-Risk Processes:

Switch to the Scan Items tab and tick or untick specific actions. If you want to exclude the listed processes from any kind of scanning (read/write/open for backup etc), remove the tick mark from all the tick boxes in the Scan files section. Save the changes.

Switch the Category drop-down menu to On-Access Default Processes Policies. Edit the policies that should include the process exclusion settings. Under the default tab Processes, select Workstation or Server and select the radio button for “Configure different scanning policies for high risk, low risk, and default processes”. Save the change.

Check if the policy applied successfully. Go to a targeted client computer, run the McAfee Agent Monitor (C:\Program Files\McAfee\Common Framework>cmdagent.exe /s), initialise policy refresh (click on Collect and Send Props, Check New Policies, Enforce Policies), open On-Access Scan properties, click on Low-Risk Processes and verify the new configuration has been applied under the tabs Processes and Scan Items.


How to create low-risk and high-risk process exclusions for VirusScan Enterprise 8.x in ePO 4.5

Clearswift Secure Web Gateway – bypass authentication

In case an application needs access to the Internet (e.g. to check for updates), but does not support NTLM or Kerberos authentication, most likely it will be blocked by a proxy.

On a Clearswift Secure Web Gateway proxy, the easiest way to configure authentication bypass is to use a user-defined HTTP header for identifying the requests generated by the application in question.

Go to the Clearswift Home page > Policy > Web Policy Routes and click on the Authentication Bypass tab, click New and in the Add HTTP Header Bypass window provide the requested info.

Clearswift suggests that the header user-agent can be used if it was defined and if the application vendor cannot provide this value, here is how to find it using Wireshark.

Using Wireshark to get the value of a user-defined HTTP header (User-Agent)

Close all applications on the PC which hosts the application in question.

Start Wireshark, click on the Capture tab and click on Interfaces. Find the interface that will be used for sending the Internet request and click on the start button next to it.

Start the application and initialise the Internet traffic. Click on the Stop button in the Interfaces window, once you get the error that tells you that the request has been turned down.

Click on Edit > Find Packet, in Find By switch to String and type the target server or domain name in the field Filter: and click on the Find button. Right click on the highlighted line and click on Follow TCP Stream. Look for the value of the User-Agent entry.

If the value has not been specified, than it will show up as a generic name, something like “Setup Factory”, which cannot be used for filtering purposes.


Configure a new web route in order to bypass authentication

In case a user-defined http header was not specified in the application, authentication can still be bypassed by creating a new web route and using a machine IP address as a source.

Create a new machine entry under Policy > Machines.
Create a new Internet Zone entry under Policy > Internet Zones and specify the destination under the Sites tab using an asterisk sign in front and at the end of the destination server or domain name.
Make sure the new rule is either at the top of the list or that the rules above this one do not interfere with it.
Apply the changes. (Deploying any non policy changes will require the web proxy to restart, cancelling any downloads currently in progress.)

Deploying McAfee ePO agents v4.5 and VSE clients v8.7

Here are some useful tips for those who might need to deploy McAfee AV clients in an enterprise.

Note 1: On client side, the McAfee AV software is divided into 2 parts:

1. ePO agent is a management agent that talks to the ePO server and receives all configuration and updates from it.
2. VSE client is an AV scanner

Note 2: McAfee policies are not cumulative, so whatever you configure in a parent policy, you will need to configure again in every child policy as they break inheritance. Keep this in mind when setting file and process exclusions.


Deploying AV clients:

Active Directory computer discovery task discovers new computers by scanning Active Directory, mirrors the structure of AD containers as in ADUC, and populates it with newly detected systems. It then deploys the ePO agent on newly discovered systems (Push agents to new systems when they are discovered), configures the agent in accordance with the policies and then installs the VSE client.

The problem with this is that the server attempts to install ePO agent only at the initial discovery of a host in AD. If a newly discovered host is not online (available) at the time of discovery, the agent will not be installed and the server will not attempt to install it ever again. This behaviour causes many PCs and servers to run without AV protection.

There are several ways to ensure that all the PCs and servers are protected by McAfee AV client and here is one that works:

1. In the ePO console, under server tasks, create a new task
2. For the 1st action choose: Run Query
3. Click on the browse button and under “Select a query from the list”, switch to “Shared Groups”, scroll down to “System Management” and choose “Unmanaged Systems”.
This query will create a list of all unmanaged systems
4. Create a sub action and choose “Deploy McAfee Agent”, choose the version you want, enable “Force installation over existing version”
If a system already has an agent installed but it’s still showing as an unmanaged system, than something is wrong with that agent and you want to reinstall it
5. Set the installation path and credentials that will be used for installation (it should be an admin account)
6. In “Number of Attempts” type 15, “Retry Interval” leave at 30 seconds, in “Abort After” enter 15 minutes
I tested agent deployment using the default values for “Number of Attempts” (0) and “Abort After” (5) and it turned out that the agent failed to install on some hosts. After increasing these values and rerunning the job on hosts where an installation previously failed, the agent installed successfully. This behaviour is probably conditioned by the number of selected clients, that is, the larger the number of clients the server is trying to serve the more time/attempts it takes.
7. Add another sub action, choose “Wake up Agents” and “Agent Wake-Up Call”, for “Number of Attempts” enter 5, for “Abort After” enter 10, enable “Get full product properties…” and “Force complete policy and task update”.
8. Schedule a test run and see how it performs under Server Task Log
It will tell you how long the task took to complete, how many systems it detected and it will provide a summary of completed/failed installations
9. Schedule the task to run once a day or as you wish

VSE client not receiving configuration:

After you deployed the ePO agent and VSE client to a host, you might find that the client has not been configured. This could be very unpleasant, especially if you need to exclude critical files from scanning.

To confirm which policy is applied to a specific hosts, go to System Tree and search for the host, put a tick mark next to the host and click on Actions > Directory Management > View Effective Policy

A good practice is to deploy the agent, wait for 24 hours or so, and then deploy the VSE client. This way, the agent should be able to contact the server and pull configuration.

If you install the VSE client and then you find it hasn't been configured, run the cmdAgent.exe tool locally on the affected host. Open CMD prompt under admin credentials: navigate to (the default path) “C:\Program Files\McAfee\Common Framework” and type cmdagent.exe /s and hit enter.

Click on these buttons to force communication with the server:
- Collect and send props
- Check new policies
- Enforce policies


If this did not help, you might want to check for updates. In my case, we had to install a patch v4, including:

Name: VirusScan Enterprise 8.7
Version: 8.7.0.195

Name: VirusScan Enterprise Reports
Version: 1.1.0.154

The patch finally fixed the issue and all the clients were configured properly.