Considerations when attempting to deploy 'antivirus' file-scanners and endpoint security modules
This document (000019755) is provided subject to the disclaimer at the end of this document.
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
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 issuesWhen 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 limitedSUSE 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 resourcesIf 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 groupsRunning the scanner under root is dangerous to both files and system stability.
Don't scan remote file-systemsThere 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 servicesIf 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 scanningThere 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 jobsThere 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 systemsLive 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 file scanner has unrestricted use of system resources, which impacts performance and system stability.
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.
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000019755
- Creation Date: 26-Oct-2020
- Modified Date:11-Oct-2021
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Server for SAP Applications
For questions or concerns with the SUSE Knowledgebase please contact: email@example.com