It appears that security is top of mind currently, with several customer discussions of late around OneFS and antivirus practices. So, it seemed like a useful topic to review in a couple of blog articles.
That said, OneFS provides support for ICAP (Internet Content Adaptation Protocol), enabling real-time scanning of a cluster’s dataset for computer viruses, malware, and other threats. To do this, OneFS sends files to an ICAP server running third-party antivirus scanning software, which scrutinizes the files for viruses and other threat signatures. If a threat is detected, OneFS typically alerts cluster admins by firing an event, displaying near real-time summary information, and documenting the threat in an antivirus scan report. Here’s a high-level view of a typical OneFS antivirus architecture.
OneFS can also be configured to either request that ICAP servers attempt to repair infected files, or to protect users against potentially dangerous files by truncating or quarantining infected files. Before OneFS sends a file to be scanned, it ensures that the scan is not redundant. If a file has already been scanned and has not been modified, OneFS will not send the file to be scanned unless the virus database on the ICAP server has been updated since the last scan. Note that Antivirus scanning is available only if all nodes in the cluster are connected to the external network (NANON configurations are not supported).
OneFS works with antivirus software that conforms to the ICAP standard, and the following list includes the supported and most widely used antivirus vendors:
Scan Engine 5.2 and later
Interscan Web Security Suite 3.1 and later
Anti-Virus for Proxy Server 5.5 and later
VirusScan Enterprise 8.7 and later with VirusScan Enterprise for Storage 1.0 and later
OneFS can be configured to send files to be scanned prior to opening, after they are closed, or both. Sending files to be scanned after they are closed is faster but less secure, whereas scanning before they are opened is slower but safer. If antivirus is configured for scanning files after they are closed, when a user creates or modifies a file on the cluster, OneFS queues the file to be scanned. It then sends the file to an ICAP server to be scanned when convenient. In this configuration, users can always access files without any delay. However, it is possible that after a user modifies or creates a file, a second user might access the file before the file is scanned. If a virus was introduced to the file from the first user, the second user would be able to access the infected file. Similarly, if an ICAP server is unable to scan a file, that file will still be accessible to users.
If a cluster is configured to scan files before they are opened, when a user attempts to download a file, OneFS first sends the file to an ICAP server to be checked. The user cannot access that file until the scan is complete. Scanning files before they are opened is more secure, however it does add access latency.
OneFS can also be configured to deny access to files that cannot be scanned by an ICAP server, which can further increase the delay. For example, if no ICAP server(s) are available, users will not be able to access any files until an ICAP server become available again. If OneFS is set to scan before open, it is recommended that it’s configured to scan files after they are closed. Scanning files as they are both opened and closed will not necessarily increase security, but it will usually improve data availability, because that file may have already been scanned since it was last modified. In this case, it can be skipped, as it would not need to be re-scanned if the ICAP server database has not been updated since its previous scan.
Antivirus scanning policies can be crafted that send files from a specified directory to be scanned. OneFS Antivirus policies target a specific directory tree on the cluster and can either be run manually at any time or scheduled for automatic execution. Exclusion rules can also be configured to prevent a policy from sending certain files within the specified root directory, based on the size, name, or extension of the file.
Antivirus scans are managed by the OneFS Job Engine and function similarly to and contend with other system jobs. Note that antivirus policies do not target snapshots, and only on-access scans include snapshots.
Antivirus allows specific file(s) to be manually sent to an ICAP server for scanning at any time. For example, if a virus is detected in a file but the ICAP server is unable to repair it, that file can be re-sent to the ICAP server after the virus database had been updated, and the ICAP server might be able to repair the file. You can also scan individual files to test the connection between the cluster and ICAP servers.
In summary, OneFS offers three flavors of AV scan which include:
AV Scan Type
Sends file to ICAP server(s) for scanning prior to opening, after closing, or both. Before opening is slower but safer, after closing is faster but less secure.
Scheduled or manual directory tree-based scans executed by the OneFS Job Engine.
Specific individual files sent to ICAP server(s) for targeted scanning, initiated via OneFS CLI command.
In the event that an ICAP server does detect a threat and/or an infected file, OneFS can be configured to respond in one of the following ways:
All threats that are detected cause an event to be generated in OneFS at the warning level, regardless of the threat response configuration.
The ICAP server attempts to repair the infected file before returning the file to OneFS.
OneFS quarantines the infected file. A quarantined file cannot be accessed by any user. However, a quarantined file can be removed from quarantine by the root user if the root user is connected to the cluster through secure shell (SSH). If you back up your cluster through NDMP backup, quarantined files will remain quarantined when the files are restored. If you replicate quarantined files to another Isilon cluster, the quarantined files will continue to be quarantined on the target cluster. Quarantines operate independently of access control lists (ACLs).
OneFS truncates the infected file. When a file is truncated, OneFS reduces the size of the file to zero bytes to render the file harmless.
It is recommended that you do not apply this setting. If you truncate files without attempting to repair them, you might delete data unnecessarily.
Repair or quarantine
Attempts to repair infected files. If an ICAP server fails to repair a file, OneFS quarantines the file. If the ICAP server repairs the file successfully, OneFS sends the file to the user. Repair or quarantine can be useful if you want to protect users from accessing infected files while retaining all data on a cluster.
Only generates an event for each infected file. It is recommended that you do not apply this setting.
Attempts to repair infected files. Afterwards, OneFS sends the files to the user, whether or not the ICAP server repaired the files successfully. It is recommended that you do not apply this setting. If you only attempt to repair files, users will still be able to access infected files that cannot be repaired.
Quarantines all infected files. It is recommended that you do not apply this setting. If you quarantine files without attempting to repair them, you might deny access to infected files that could have been repaired.
OneFS automatically generates an antivirus scan report each time that a policy is run. It also generates a global status report every 24 hours which includes all the on-access scans that occurred during the day. AV scan reports typically contain the following information:
The time that the scan started.
The time that the scan ended.
The total number of files scanned.
The total size of the files scanned.
The total network traffic sent.
The network throughput that was consumed by virus scanning.
Whether the scan succeeded.
The total number of infected files detected.
The names of infected files.
The threats associated with infected files.
How OneFS responded to detected threats.
The available scans can be viewed from the CLI as follows:
# isi antivirus reports scans list
ID Policy ID Status Start Files Infections
R:5e1d0e66:7f8b 1b8028028048580 Started 2020-01-14T00:42:14 1 0
R:5e1d0896:706a MANUAL Succeeded 2020-01-14T00:17:26 0 0
R:5e1d083c:6f86 MANUAL Succeeded 2020-01-14T00:15:56 0 0
RO5e1d0480 SCAN_ON_OPEN Started 2020-01-14T00:00:30 0 0
RO5e1bb300 SCAN_ON_OPEN Finish 2020-01-13T00:00:31 0 0
More detail on a particular scan is available via:
# isi antivirus reports scans view R:5e1d0e66:7f8b
Policy ID: 1b8028028048580
Bytes Sent: 4242360130
Job ID: 5363
Similarly, threats can be viewed using the following CLI syntax:
# isi antivirus reports threats list
Scan ID File Remediation Threat Time
R:5d240ee9:2d62 /ifs/data/suspect.tar.gz Skipped 2019-12-09T03:50:01
And, details of a particular threat via:
# isi antivirus reports threats view <id>
# isi antivirus reports threats view R:5d240ee9:2d62
Threat id 'R:5d240ee9:2d62' is not valid.
Or from the WebUI, by navigating to Data Protection > AntiVirus > Detected Threats:
That's it for now. In the next article in this AntiVirus series, we'll take a look at policies, exclusions, global configuration, and some monitoring and sizing ideas.