When it comes to antivirus protection, OneFS provides two options. The first, and legacy, solution is using ICAP (internet content adaptation protocol), and which we featured in a previous blog article. The other, which debuted in OneFS 9.1, is the CAVA (common antivirus agent) solution. Typically providing improved performance than ICAP, CAVA employs a windows server running third-party AV software to identify and eliminate known viruses before they infect files on the system.
OneFS CAVA leverages the Dell Common Event Enabler – the same off-cluster agent that’s responsible for OneFS audit – and which provides compatibility with prominent AV software vendors. These currently include:
| Product | Latest Supported Version |
| Computer Associates eTrust | 6.0 |
| F-Secure ESS | 12.12 |
| Kaspersky Security 10 for Windows Server | 10.1.2 |
| McAfee VirusScan | 8.8i Patch13 |
| McAfee Endpoint Protection | 10.7.0 Update July 2020 |
| Microsoft SCEP | 4.10.209.0 |
| Microsoft Defender | 4.18.2004 |
| Sophos Endpoint Security Control | 10.8 |
| Symantec Protection Engine | 8.0 |
| Symantec Endpoint Protection | 14.2 |
| TrendMicro ServerProtect for Storage | 6.00 Patch 1 |
The Common Event Enabler, or CEE, agent resides on an off-cluster server, and OneFS sends HTTP request to it as clients trigger the AV scanning workflow. The antivirus application then retrieves the pertinent files from the cluster via a hidden SMB share. These files are then checked by the AV app, after which CEE returns the appropriate response to the cluster.
OneFS Antivirus provides three different CAVA scanning methods:
| AV Scan Type | Description |
| Individual File | Single file scan, triggered by the CLI/PAPI. Typically provides increased performance and reduced cluster CPU and memory utilization compared to ICAP. |
| On-access | Triggered by SMB file operation (ie. read and close), and dependent on scan profile:
· Standard profile: Captures an SMB close and rename operation and triggers scan on corresponding file. · Strict profile: Captures an SMB read, close, and rename operation and triggers scan on corresponding file. |
| Policy | Scheduled or manual directory tree-based scans executed by the OneFS Job Engine. |
An individual file scan can be initiated from the CLI or WebUI. Since the scanning target files are manually selected, and lwavscand daemon immediately sends an HTTP scanning request to the CEE or CAVA agent, at which point OneFS places a lock on the file, and the AV app retrieves it via the hidden CHECK$ SMB share. After the corresponding content has been downloaded by the CAVA server, the AV engine performs a virus detection scan, after which CEE sends the results back to the OneFS lwavscand daemon and the file lock is release. All the scanning attributes are recorded under /ifs/.ifsvar/modules/avscan/isi_avscan.db.
For on-access scanning, depending on which scan profile is selected, any SMB read or close requests are captured by the OneFS I/O manager, which passes the details to the AVscan filter. This can be configured per access-zone, and filters by:
- File extension to include
- File extension to exclude
- File path to exclude
For any files matching all the filtering criteria, the lwavscand daemon sends the HTTP scanning request to the CEE/CAVA agent. Simultaneously, OneFS locks the file and the AV app downloads a copy via the hidden SMB share (CHECK$). After the corresponding content is downloaded to the CAVA server, it runs the scan with the anti-virus engine, and CEE sends the scan results and response back to the process lwavscand. At this stage, some scanning attributes are written to this file and the lock is released. The scanning attributes are listed below:
- Scan time
- Scan Result
- Anti-virus signature timestamp
- Scan current
Then the previous SMB workflow can continue if the file is not infected. Otherwise, the file is denied access. If there are errors during the scan and the scan profile is strict, the setting Open on fail determines the next action.
Policy Scan
A policy scan is triggered by the job engine. Like other OneFS jobs, the job impact policy, priority, and schedule can be configured as desired. In this case, filtering includes:
- File extension to include
- File extension to exclude
- File path to exclude
- File path to include
There are two types of connections between CAVA servers and the cluster’s nodes. An SMB connection, which is used to fetch files or contents for scanning via the hidden CHECK$ share, and CEE’s HTTP connections for scan requests, scan responses, and other functions. CAVA SMB connections use a dedicated IP pool and access zone to separate traffic from other workloads. Within this IP pool, SmartConnect ensures all SMB connections are evenly spread across all the nodes.
The anti-virus applications use the SMB protocol to fetch the file or a portion of a file for scanning in a PowerScale cluster. From the anti-virus perspective, a hidden SMB share CHECK$ is used for this purpose and resides on every anti-virus application server. This share allows access to all files on a PowerScale cluster under /ifs. SmartConnect and a dedicated access zone are introduced in this process to ensure that all the connection from the anti-virus application is fully distributed and load-balanced among all the configured nodes in the IP pool. A hidden role AVVendor is created by the CAVA anti-virus service to map the CAVA service account to OneFS.
Upon completion of a scan, a report is available containing a variety of data and statistics. The details of scan reports are stored in a database under /ifs/.ifsvar/modules/avscan/isi_avscan.db and the scans can be viewed from either the CLI or WebUI. OneFS also generates a report every 24 hours that includes all on-access scans that occurred during the previous day. These antivirus scan reports contain the following information and metrics:
- Scan start time.
- Scan end time.
- Number of files scanned.
- Total size of the files scanned.
- Scanning network bandwidth utilization.
- Network throughput consumed by scanning.
- Scan completion.
- Infected file detection count.
- Infected file names.
- Threats associated with infected files.
- OneFS response to detected threats.
CAVA is broadly compatible with the other OneFS data services, but with the following notable exceptions:
| Data Service | Compatibility |
| ICAP | Compatible |
| Protocols | SMB support |
| SmartLock | Incompatible. OneFS cannot set scanning attributes on SmartLock WORM protected files as they are read-only. As such, AV application cannot clean them. |
| SnapshotIQ | Incompatible |
| SyncIQ | SyncIQ is unable to replicate AV scan file attributes to a target cluster. |
When it comes to designing and deploying a OneFS CAVA environment, the recommendation is to adopt the following general sizing guidance:
- Use Windows servers with at least 16 GB memory and two-core processors.
- Provision a minimum of two CEE/CAVA servers for redundancy.
For the Common Event Enabler, connectivity limits and sizing rules include:
- Maximum connections per CAVA servers = 20
- Number of different CAVA servers a cluster node can connect to = 4
- The nth cluster node starts from nth CAVA server
The formula is as follows:
𝑀𝑎𝑥𝑖𝑚𝑢𝑚 𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛𝑠 = 𝑀𝑎𝑥𝑖𝑚𝑢𝑚 𝑐𝑜𝑛𝑒𝑐𝑡𝑖𝑜𝑛𝑠 𝑝𝑒𝑟 𝐶𝐴𝑉𝐴 𝑠𝑒𝑟𝑣𝑒𝑟 × 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐶𝐴𝑉𝐴 𝑠𝑒𝑟𝑣𝑒𝑟𝑠 = 20 × 5 = 100
Additionally, the following formula can help determine the appropriate number of CAVA servers for a particular cluster:
CAVA servers = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 cluster 𝑛𝑜𝑑𝑒𝑠 / 4
For example, imagine a forty four node PowerScale H700 cluster. Using the above formula, the recommended number of CAVA servers will be:
42 / 4 = 10.5
So, with upward rounding, eleven CAVA servers would be an appropriate ratio for this cluster configuration. Note that this approach, based on the cluster’s node count, is applicable for both on-access and policy-based scanning.
For environments where not all of a cluster’s nodes have network connectivity (NANON), CAVA is supported with the following caveats:
| Scan Type | Requirements |
| Individual file | Supported when the node which triggers the scan has the front-end connectivity to the CAVA servers. Otherwise, the CELOG ‘SW_AVSCAN_CAVA_SERVER_OFFLINE’ alert is fired. |
| Policy-based | Works by default. OneFS 9.1 and later automatically detect any nodes without network connectivity and prevents the job engine from allocating scanning tasks to them. Only nodes with front-end connectivity to the CAVA servers will participate in running scheduled scans. |
| On-access | Supported when the node which triggers the scan has front-end connectivity to the CAVA servers. Otherwise, the CELOG ‘SW_AVSCAN_CAVA_SERVER_OFFLINE’ alert is fired. |