Issues on FIM Linux - Agent Binary (v4.1 or later)

From Linux agent binary v4.1 onwards, the 'fimc' process has been discontinued and a common EDR process takes care of both EDR and FIM events. This section includes issues and questions related to this change.

How to check if process for FIM is running on the asset?

When 'UseAuditDispatcher=1', it is mandatory to have the auditd service is in running state and the EDR plugin process can be seen registered with te auditd service.

[root@135302-T490 ~]# ps -elf | grep edr

0 R root 20804 20785 0 80 0 - 28162 - 03:42 pts/1 00:00:00 grep --color=auto edr

0 S root 28469 28467 0 76 -4 - 44598 futex_ Nov14 ? 00:01:23 /usr/local/qualys/cloud-agent/bin/edrplugin/usr/local/qualys/cloud-agent/sock/audit_disp.sock

5 S root 28489 1 0 80 0 - 149099 futex_ Nov14 ? 00:23:11 /usr/local/qualys/cloud-agent/bin/qualys-edr

How does the EDR plugin process get registered with the auditd service?

[root@135302-T490 ~]# systemctl status auditd

auditd.service - Security Auditing Service

Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)

Active: active (running) since Sun 2021-11-14 18:03:40 IST; 2 weeks 4 days ago

Docs: man:auditd(8)

Process: 28473 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)

Process: 28464 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)

Main PID: 28465 (auditd)

CGroup: /system.slice/auditd.service

28465 /sbin/auditd

28467 /sbin/audispd

28469 /usr/local/qualys/cloud-agent/bin/edr-plugin /usr/local/qualys/cloud-agent/sock/audit_disp.sock

When UseAuditDispatcher=0, it is mandatory to have the auditd service is in stopped state

[root@135302-T490 ~]# ps -elf | grep edr

root 3288 1 2 10:59 ? 00:02:06 /usr/local/qualys/cloud-agent/bin/qualys-edr

How to check if FIM Profile (manifest) got associated with the asset?

FIM manifest (.json) can be located under following location:


[root@135302-T490 ~]# ls -l /usr/local/qualys/cloud-agent/fim/manifests/total 12

-rw------- 1 root root 9588 Sep 16 08:00 22e653bf-6d51-4933-8f01-71e4279578a8.json

What is the location of FIM logs?

Log file for FIM has been renamed from fimc.log to edr.log and can be located at same location:


[root@135302-T490 qualys]# ls -l /var/log/qualys/ | grep edr.log

-rw------- 1 root root 4558524 Dec 3 03:54 edr.log

-rw------- 1 root root 10485883 Dec 3 03:45 edr.log.0

-rw------- 1 root root 10485838 Dec 3 01:59 edr.log.1

-rw------- 1 root root 10485797 Dec 2 22:56 edr.log.2

-rw------- 1 root root 10485781 Dec 2 21:55 edr.log.3

-rw------- 1 root root 10485814 Dec 2 18:45 edr.log.4

What are the pre-requisites for FIM to function properly?

Following are the prerequisites for Qualys FIM to function successfully in the auditd-compatible mode:

1. The auditd package must be present on the endpoint.

2. If SELinux is enabled, the following commands and packages should be present on system.

Using the commands, you can ensure that even if SELinux is enabled, audispd will be allowed to receive events from the auditd daemon. This allows the FIM module to receive audit events.


- checkmodule

- semodule_package

- semodule

- sestatus

- getenforce


- policycoreutils-python

- policycoreutils

- libselinux-utils

3. The audit configuration file (/etc/audit/auditd.conf) must have the following line uncommented:

dispatcher = /sbin/audispd

4. If auditd is stopped externally, the FIM module does not receive any events.

5. Qualys agent must be running as root user only.

Note: The agent itself can run as a non-root user with sudo permissions and the qualys-edr process will always run as root.

6. Audit must not be in immutable mode.

Use the following command to check the output of 'auditctl -s' command for flag "enabled":

[root@135302-T490 ~]# auditctl -s

enabled 1 -> this is unlocked state

failure 1

pid 28465

rate_limit 0

backlog_limit 64

lost 83

backlog 6

loginuid_immutable 0 unlocked

enabled 2 means that audit configuration is immutable.

If audit configuration is in immutable mode, it does not allow Qualys FIM module to add or edit any FIM rules. To recover from audit immutable mode, Linux-Ubuntu distribution requires a system reboot.

For more details, refer to auditctl(8) — Linux manual page.

image of enable2 message


Remove "-e 2" rule (if present) from the following audit configuration files and reboot the machine.

a. /etc/audit/audit.rules

b. /etc/audit/rules.d/audit.rules

Important: This configuration must be remediated for Qualys FIM to function successfully.

The prerequisite for Audit to be in mutable mode requires a reboot of the host. How should I plan that?

Once the audit configuration set i.e. '-e 2' option is removed, the host machines need to go under planned reboots. Such reboots can take place during regular maintenance cycle for activities such as scheduled system updates, patch application, kernel updates or when glibc is updated.

These reboots can be scheduled and planned for batches and not all servers at a time.

7. The " -a never,task " rule must not be present in the audit configuration files.

Check files at the following location for presence of this rule:



No other events are generated if the '-a never,task' rule is present in the audit system in output of (auditctl -l). As per RedHat's official documentation, a "never" rule means that no audit records will be generated. This can be used to suppress event generation Remediation

Remove the rule '-a never,task' (if present) from the following audit configuration files and restart the Qualys Agent service:



Use the following command to restart Qualys Agent service:

service qualys-cloud-agent restart

Important: This issue must be remediated for Qualys FIM to function successfully.

If audit system is in immutable mode and FIM Rules are pushed on to it via FIM UI (Qualys platform), can it cause an auto-reboot of the asset on which qualys-cloud-agent is deployed?

No, Qualys Cloud Agent is not designed to cause auto-reboot of the host machine.

However, auto reboot can happen if some specific set of configurations are set on the asset. For example: setting up 'kernel panic' mode in audit system.

auditctl -f [0..2]

Set failure mode 0=silent 1=printk 2=panic.

This option lets you determine how you want the kernel to handle critical errors.

'-f 2' option i.e. 'panic' causes the kernel to panic to prevent use of the machine.

Note: Even in this case when 'kernel panic' mode is set in audit system, which is immutable i.e. '-e2' is also set, auto-reboot won't happen when FIM rules are applied.

How to check if audit system is set for 'kernel panic' mode?

Check the output of command 'auditctl -s'

[root@135302-T490 ~]# auditctl -s

enabled 1

failure 2 -> this is panic mode

pid 28465

rate_limit 0

backlog_limit 64

lost 83

backlog 6

loginuid_immutable 0 unlocked

Prerequisite says 'Audit should not be in immutable mode' but CIS says 'Ensure the audit configuration is immutable'. Does it mean using Qualys FIM might lead to non-compliance?

No, the system stays PCI Compliant as having FIM application working itself is a compliance requirement. Refer PCI-DSS Requirement no 11.5. Moreover, for CIS Level 2 Profiles, exceptions can be made. This is explained in the following section:

Immutable mode in audit system

This setting is configured to alert administrators for any modifications in the audit rules on the Linux system.

Image of Audit Configuration as Immutable

But, if the audit configuration is set to immutable mode, it does not allow Qualys FIM module to add/edit any FIM rules. Therefore, it has to be unlocked.

How Qualys assures compliance and security when immutable mode is removed?

Issue: When the immutable mode is removed, the audit rules can be modified

Solution: Qualys FIM with its out-of-the-box monitoring Profiles provides rules to alert for any modifications on such critical audit system files in real-time, making sure that nothing goes unnoticed.

Here are some quick examples:

1. Qualys FIM rule to monitor ‘/etc/audit/audit.rules’ file in real-time:

image of audit rule

2. Qualys FIM rule to monitor ‘/etc/audit/auditd.conf’ file in real-time

image of auditd.conf rule

3. Qualys FIM rule to monitor ‘/etc/audit/rules.d/audit.rules’ file in real-time

image of the audit.rules

These rules will trigger change events for any modification with exhaustive event details like user and process responsible for the change, with exact timestamp, and asset details on which activity was performed.

Qualys is a CIS partner and contributor, and had this scenario analyzed by CIS.

Summary: The Level 2 profile acts as a defense-in-depth measure that might inhibit the utility or negatively impact the performance of the technology. In such case, we can modify/revoke the CIS recommendation.

Following are the generic examples where customer usually revoke the guidelines in order to ensure smooth functioning in the production environment:

- CIS states that - 5.2.8 Ensure SSH root login is disabled (Scored).

- DISA guideline states that The system must disable SSH.

- DISA guideline states that Group ID (Vulid): V-72247 - The Red Hat Enterprise Linux operating system must not permit direct logons to the root account using remote access via SSH.

If we follow such guidelines strictly as per the benchmarks – we will end up breaking a lot of critical day-to-day functionalities of the production environment

Advantages of using auditd over kernel approach

Let’s elaborate on why Qualys FIM does not use Kernel injection. In ideal situations, Kernel Injection is not a recommended method as modifying the kernel driver with a third-party tool may mean a bigger security risk. This could also result in performance issues, requiring manual intervention with the endpoints. This would also mean that with every version update, users will have to make changes to the kernel as well–which may not be a viable option for customers. Thus, auditd channel turns out to be a more secure and comprehensive method of collecting data.

On Linux platforms, Qualys FIM works in compatible mode with auditd and collects audit event notifications from the audit daemon. The Qualys FIM plugin process is launched as a child of the audit dispatcher, which collects the audit event notifications from the auditd daemon and broadcasts to all child plugin processes, putting negligible load on the target.