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.
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 the 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.
Commands:
- checkmodule
- semodule_package
- semodule
- sestatus
- getenforce
Packages:
- policycoreutils-python
- policycoreutils
- libselinux-utils
Note: If you are installing FIM on RHEL /centOS 8 then install the package policycoreutils-python package with the new name as "python3-policycoreutils".
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.
Remediation
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.
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:
'/etc/audit/audit.rules'
'/etc/audit/rules.d/audit.rules'
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:
/etc/audit/audit.rules
/etc/audit/rules.d/audit.rules
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.
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.
To install packages on rpm based systems run the followin command,
yum install auditd -y
yum install checkmodule -y
yum install semodule-package -y
yum install checkpolicy -y
yum install policycoreutils -y
yum install semodule -y
yum install restorecon -y
service qualys-cloud-agent restart
To install packages on deb based systems run the following command,
apt install auditd -y
apt install checkmodule -y
apt install semodule-package -y
apt install checkpolicy -y
apt install policycoreutils -y
apt install semodule -y
apt install restorecon -y
service qualys-cloud-agent restart
When 'UseAuditDispatcher=1', it is mandatory to have the auditd service in a running state and the EDR plugin process can be seen registered with the 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
[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)
https://github.com/linux-audit/audit-documentation
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
FIM manifest (.json) can be located under following location:
'/usr/local/qualys/cloud-agent/fim/manifests/'
[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
Log file for FIM has been renamed from fimc.log to edr.log and can be located at same location:
'/var/log/qualys/'
[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
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
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:
This setting is configured to alert administrators for any modifications in the audit rules on the Linux system.
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.
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:
2. Qualys FIM rule to monitor ‘/etc/audit/auditd.conf’ file in real-time
3. Qualys FIM rule to monitor ‘/etc/audit/rules.d/audit.rules’ file in real-time
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 a case, we can modify/revoke the CIS recommendation.
Following are the generic examples where customer usually revoke the guidelines 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
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 the negligible load on the target.