Technical Articles ID:
KB95920
Last Modified: 2022-09-28 04:53:00 Etc/GMT
Environment
Endpoint Security for Linux Firewall (ENSLFW) 10.x
Endpoint Security for Linux Threat Prevention (ENSLTP) 10.x
Summary
Below are the recommended best practices when using ENSL.
Contents
Click to expand the section you want to view:
The kernel module and Fanotify are two ways through which ENSL can get file access events (for example, open, read, and write) from the system.
With the kernel module, ENSL hooks on to the system calls to get the events.
Later, the Linux kernel itself provides a facility named Fanotify. With Fanotify, any user space application can register to get all filesystem events for processing. This configuration avoids user space applications from writing kernel modules for the same purpose.
So, the kernel module and Fanotify have the same purpose of providing all events to the user space ENSLTP to scan. All ENSL customers using Ubuntu/Debian or SUSE use only Fanotify as we don't provide a kernel module for them.
Customers can safely use Fanotify or the kernel module as there's no difference in functionality.
When ENSL is installed with OAS enabled (without Deferred Scan), it blocks access to the file until ENSL scans it and finds it to be clean. If the file isn't clean, ENSL takes the specified action and then blocks access to the file. A file scan might complete in milliseconds or might take longer for bigger files.
We observed that in high I/O intensive environments (for example, Hadoop and splunkd), a small delay in getting events from the system (due to the scan of files) causes a delay in performance and the operation of the application. So, blocking the events while scanning caused operation issues. To address this issue, ENSL 10.7.5 and later provide the "Deferred Scan" option. Both the READ and WRITE events get scanned, but aren't blocked during scanning.
With Fanotify, ENSL uses a "Deferred Scan" option that enables users to perform the scan in a non-blocking manner to support high I/O intensive applications to run smoothly.
NOTE: Deferred Scan is applicable only on Fanotify-based systems.
You can enable Deferred Scan while installing ENSL as a parameter:
Configuring OAS profiles helps to identify and filter out the files and folders to be scanned during scan operations. Creating OAS profiles with proper exclusions and configurations helps the system to run more smoothly and efficiently.
NOTES:
For Linux, the process name must be the absolute path of the binary getting executed instead of just a process name.
Don't add "Windows" specific paths in the exclusions.
You can configure OAS profiles based on the following methods:
Set up customer-specific OAS profiles (customized):
You can include any customer-specific applications or third-party application processes in the exclusions.
You can set up customized OAS profile exclusions based on requirements. By default, ENSL has the following file-type exclusions in the OAS profile: arc, ctl, dbf, dbl, dtx, frm, jar, log, myd, myi, rdo, vmdk, war.
Some third-party applications perform intensive I/O operations that lead to system slowness or a hang. To avoid this issue, identify such processes by enabling the "OAS Activity log" and add the processes in the OAS profile-exclusion lists. For example, /docker/, /splunk/, and /opt/IBM/.
From the ePolicy Orchestrator (ePO) console, go to Policy Category, On-Access Scan, your policy, and click Advanced, Process Settings, Exclusions.
Add the process names or paths.
Click Save.
Set up risk-based (High Risk, Low Risk) OAS profiles:
The OAS profile is configured as "Standard" by default unless you choose a risk-based option. Categorize your system or application processes based on criticality and sensitivity. Then, configure such processes as High Risk and Low Risk in the OAS profile.
To create risk-based profiles from the ePO console:
Go to Policy Category, On-Access Scan, your policy, and choose High Risk and Low Risk options.
Click Add and add your processes with the risk option as High Risk or Low Risk.
To create risk-based profiles using the command line:
Log on to the system with administrator rights and execute the following command:
Below is a list of best practices for creating and assigning policies for ENSLTP and ENSLFW.
Product
Dos
Don'ts
ENSLTP
Use proper naming conventions while creating any ENSLTP policies. Use any 'alphanumeric' or '_' characters.
Avoid using spaces in between profile names.
Keep the names short and understandable.
Avoid long and lengthy names.
Always enable the "On network drives" option in the OAS policy if any network drives (NFS/CIFS) are mounted and need to be scanned.
Network-mounted drives aren't scanned if disabled in the OAS policy.
Add the proper file types in the exclusions to be excluded from scanning.
Avoid adding invalid file types and Windows-based paths in the exclusions from scanning.
ENSLFW
Use proper naming conventions while creating any ENSLFW policies. Use any 'alphanumeric' or '_' characters.
Avoid using spaces in between profile names.
Keep the names short and understandable.
Avoid long and lengthy names.
Create multiple firewall rules separately within an ENSLFW policy.
Don't create nested firewall rules (rule inside rule). Linux doesn't support nested firewall rules.
Always configure firewall rules with working domain names.
Don't configure firewall rules for invalid domain names.
Always configure firewall rules with valid network port numbers.
Don't configure firewall rules with invalid network port numbers.
NOTES: For ENSLFW in Adaptive mode:
For security reasons, incoming pings (inbound) are blocked in Adaptive mode. Hence, you have to create an explicit Allow Rule for incoming ICMP traffic.
Incoming traffic to a port that isn't open on the host is blocked in Adaptive mode. Hence, you have to create an explicit Allow Rule for that traffic.
Always enable and run the Server task "Endpoint Security Firewall Property Translator" from ePO when Adaptive mode is enabled for the policy.
Problem:
Splunk is a very I/O intensive application. Its performance is impacted as the Splunk operations are intercepted for OAS scanning.
Recommendation:
Performance can be improved for I/O intensive trusted applications by configuring OAS exclusions. These OAS exclusions exclude scanning events from these trusted processes. Add the OAS process exclusions as "Low Risk" processes with scan set to "Do not scan" for the Low Risk profile.
Steps to add OAS exclusions for Splunk:
From the ePO console, go to Policy Category, On-Access Scan, your policy, and click Advanced, Process Settings.
Select Configure different settings for High Risk and Low Risk processes.
Set the "When to scan" option for Low Risk to Do not scan.
Click Add and add the list of trusted excluded Splunk processes. List of Splunk exclusions for OAS:
NOTE: The latest ENSL versions have performance optimizations for processing exclusions. Hence, to achieve better performance with excluded processes, use the following versions:
Fanotify-based systems - Use ENSL 10.7.10 or later.
Kernel module-based systems - Use ENSL 10.7.12 or later.