Open topic with navigation

# Caution for EDR Applications

Some EDR (Endpoint Detection and Response) applications which come configured to the most secure settings by default can impede the operation or prevent the correct installation of the OMT application on a node. Micro Focus is aware of difficulties associated with the following security solutions.

- Broadcom/Symantec AntiVirus for Linux (AVfL)

- McAfee and Fireeye

- Caution for SysOps Applications

## Broadcom/Symantec AntiVirus for Linux (AVfL)

The Autoprotect feature of Symantec AVfL will impact any new as well as any running installation on a OMT node. It will prevent the creation, persistence and use of files required by Kubernetes to operate. As per the guidance from the vendors Linux experts [link opens external web site] it is recommended to turn off Autoprotect where performance and stability are important, as well as to consider full scans while the system is in maintenance mode.

Detection: The issue can be identified by seeing a “5” process using a significant amount of CPU when running the TOP command.

Fix: Run `checkcfg` on each node. If Autoprotect is on, please disable it.

Important: Note that the scanning engine may run as normal.

Recommendation: It is recommended that you exclude the sys, proc and tmp directories from scanning.

If installation is being performed on a system with exclusions, create another temporary (tmp) directory and add it to the exclusion list. When installing OMT, make sure to specify the new temporary directory as part of command-line arguments.

## McAfee and Fireeye

An installation or upgrade performed on servers running a McAfee or Fireeye agent may cause issues with pod operations.

Detection: Impact can include disabled access to /etc/passwd.

Recommendation: Disable any McAfee agent on the servers used for installation or upgrade until the installation or upgrade is complete. After completion, you may re-enable the disabled McAfee agents.

# Caution for SysOps Applications

Micro Focus recognizes the use of third-party SysOps applications such as CFEngine, Puppet, or Chef to help ensure consistent system configurations to support the operation of various applications across their network. It is critical that prerequisite components that are part of the configuration of the system are not removed, reset, or altered while the system is running and during its lifecycle. Automated actions modifying the state of the configuration have often been the sources of issues and failures.

Detection: Very often users may notice that the hosts file has been repopulated with the systems’ IP and FQDN.

Recommendation: Please coordinate with your appropriate internal group about the creation of a separate policy for the OMT systems, to ensure the prerequisites implemented persist in a manner where they are not altered or re-added in any way during the continued lifecycle of the system.

If you must check on the running configuration using a template which would replace or reset configuration parameters used by the OMT system, the SysOps job must run after all OMT services have been stopped.

Examples to avoid:

- Re-adding of the IP and FQDN to the hosts file when it should be present.
- Running `sysctl -w on` already persisted parameters while the system is operating.
- Specifying conflicting values for the same values (such as ip_forwarding = 1 and 0)