Considerations when attempting to deploy 'antivirus' file-scanners and endpoint security modules

Any SLES product with an AV file-scanner or embedded endpoint module.

Instances with 3rd party 'antivirus' file-scanner modules/services experience performance degradation, system crash, or other service interruption. The purpose of this document is to provide guidance to customers who are considering deploying these solutions or who are experiencing issues likely to be related to the deployment of these solutions.

When applying 3rd party file scanner solutions, several general considerations should be made:

Is the file scanner needed for a particular use case?

File scanners are unnecessary on SUSE Linux under ordinary circumstances and do not provide additional security for the SUSE Linux System as an endpoint. Based on the function of the Linux machine certain limited use cases are known, for example:

• scanning untrusted upload data on a web server
• scanning incoming mail for malicious attachments on a mail server
• scanning file systems that are exported to Windows hosts via Samba or NFS on a file server

There should always be a sound and justified reason for using the file scanner, it should be limited to this use only.

More information on how to harden a system can be found here:

Is virus/malware protection software needed on a SUSE Linux Enterprise Server? TID 19608

Hardening and Securing Master TID 16819 

Certain functionality often promised by endpoint protection vendors is already implemented in SLES. Examples include: the rpm -Va command, auditctl, SELinux.

File scanners can and do cause severe performance, stability, and security issues

When scanners are implemented as kernel modules, they have total control over the system. Bugs or design issues in the third-party software can do various unpredictable things to the system. Perhaps paradoxically, because of the control granted to them, the modules and third-party services themselves are valuable points of attack for malicious actors.

Even when not embedded in the kernel, file scanners operating as services can cause issues. File or file signature scanning can use a lot of disk and processor I/O and brings systems to crawl or take them down, particularly if run under root or resources are not managed for the user running the service.

For an example of what an unsecure system service can do see this TID about The OMIGOD vulnerability TID 20388

Support options may be limited

SUSE can't guarantee the functioning of 3rd party modules or packages not packaged by SUSE. If there is indication that the system is experiencing one of the many difficulties associated with an implementation of an "on the fly" file scanner, SUSE Support will recommend removing it and attempt to reproduce the issue with the module removed.

If deploying a file scanner on a system, avoid these common pitfalls:

Make sure it doesn't scan system directories. Limit the scanner to look in locations pertaining to its use case.

Even if the scanner doesn't change the files in the system directories, just reading the files can put a lot of load on the I/O.

Don't give the file scanner unlimited system resources

If the file-scanner is given unlimited system resources, it can lead to the system falling over.

Run the scanner under a dedicated non-root account with tailored privileges and groups

Running the scanner under root is dangerous to both files and system stability.

Don't scan remote file-systems

There is no good reason for an NFS or CIFS file client to be scanning a remote file server. If there is a need to scan the file system, it should be scanned on the host itself.

Be aware that endpoint protection modules may block desired network services

If there are issues that seem like network issues on a system with endpoint protection modules, they could well be the module deciding to filter packets.

Exclude auto-fs mounts from scanning

There are known issues where the scanner touches the auto-fs mount repeatedly and prevents it from unmounting

Make sure that the file-scanner doesn't interfere with other scheduled jobs

There are various file system jobs run at regular intervals which keep the file system healthy. AV file scanners have been known to interfere with those jobs.

Check the database vendor documentation to make sure that the file-scanner is compatible with your database solution

These are some pertinent questions to ask:

• Will an AV scan affect database IO performance?
• Will an AV scan fool storage placement by repeatedly loading otherwise "cold" data?
• Does the database generate checksums of its files? Can these be used by the scanner?

Does the security module being implemented interfere with built-in security features of Linux?

Depending on the Linux deployment you might have set up built-in hardening solutions such as: Apparmor, SE Linux, kernel auditing, packet filtering, seccomp etc.

Embedded security modules won't add anything to these, but they can subtract. Make sure that the function of these security solutions isn't hampered by the third-party component in some way.

Warning: security scanner modules may inhibit live patching of systems

Live patching is a good way to patch minor changes into the kernel to reduce downtime. Some of these "live patches" address vulnerabilities. It is known that 3rd party security modules will often reject these live patches as suspicious, thus preventing crucial updates.

 

A 3rd party kernel module is installed and destabilizes the kernel.
A file scanner has unrestricted use of system resources, which impacts performance and system stability.

These are only some of the most common considerations and pitfalls. They may or may not be applicable to your system or 3rd party solution under consideration.

If you encounter networking, stability or performance issues on a system with an "on the fly" scanning kernel module, see if removing it helps.

Such a solution should be well documented for use case and risks. Tracking how the software is intended to behave and how it actually behaves on the system is recommended.

As stated above SUSE cannot help you with 3rd party software. Your software vendor may also have limitations on what versions of their software they can support with which kernel. Some helpful external links are listed below:

https://kc.mcafee.com/corporate/index?page=content&id=KB93517
https://linux-repo.us.securitycloud.symantec.com/SAL/1.0/seplinux_supported_kernels.html
https://help.deepsecurity.trendmicro.com/20_0/on-premise/agent-linux-kernel-support.html

The above external links are not an endorsement of any particular product. These links may change.