Ensure AIDE Is Installed: How to Fix the CIS Linux AIDE Finding

“Ensure AIDE is installed” is a CIS Benchmark check that fails when the AIDE file integrity tool is missing from a Linux host. To fix it, install aide (plus aide-common on Debian and Ubuntu), build the baseline database with aide –init or aideinit, move it into place, and schedule a daily aide –check.

Installing the package takes one command. The real work is a clean baseline, a schedule that actually runs, and a plan for re-baselining after patching.

What the scanner is actually detecting

This finding comes from a Tenable compliance scan (Nessus, Tenable Vulnerability Management or Tenable Security Center) that runs a CIS Linux audit file over an authenticated SSH session. It is a configuration check, not a vulnerability plugin, and there is no CVE behind it. Item numbers change between benchmark versions, so search your report by title:

Older audits number the same item 1.3.1 (for example CIS Red Hat EL9 v1.0.0 and Rocky Linux 8 v1.0.0) or 1.4.1 (CIS Fedora 19 Family). On the RHEL-family audits, Tenable implements the “installed” item as an RPM package check, so it passes as soon as the package is present, even if no baseline was ever built. The companion item is the one that looks for a scheduled check. Current RHEL-family audits also include “Ensure cryptographic mechanisms are used to protect the integrity of audit tools”, which adds AIDE rules for auditctl, auditd and related binaries to /etc/aide.conf. Fix all of them in one change window.

Real-world risk, stated honestly

A missing AIDE package is not something an attacker can exploit. It is a detection gap. AIDE records a snapshot of files and directories (permissions, modification times, hashes and so on) and later compares the live filesystem against it, so without it you have no simple way to prove that binaries or files such as /etc/sudoers have not been changed.

Keep the limits in mind. AIDE only reports changes when a check runs, and an attacker who already has root can alter the database, the configuration or the binary. That is why Red Hat recommends keeping the database, configuration file and /usr/sbin/aide on read-only media or in a separate secure location. AIDE itself also receives security fixes (Ubuntu patched CVE-2025-54389, described as a bypass of AIDE detection of malicious files), so keep the package updated. Prioritize this below exploitable vulnerabilities on the same host.

How to confirm it on the host

RHEL 8, 9 and 10, Rocky Linux, AlmaLinux and Oracle Linux:

# Is the package installed?
rpm -q aide

# Is there a baseline? Expect /var/lib/aide/aide.db.gz
sudo ls -l /var/lib/aide/

# Is a check scheduled?
sudo crontab -u root -l | grep aide
systemctl list-timers --all | grep -i aide

Debian and Ubuntu:

dpkg-query -W -f='${binary:Package}t${Status}n' aide aide-common

# Expect /var/lib/aide/aide.db
sudo ls -l /var/lib/aide/

# Debian 12 and Ubuntu 24.04 ship a systemd timer
systemctl is-enabled dailyaidecheck.timer
systemctl is-active dailyaidecheck.timer

A package that is installed but has no database in /var/lib/aide is only half done: AIDE has nothing to compare against.

How to fix it

RHEL, Rocky Linux, AlmaLinux and Oracle Linux

Install AIDE, review /etc/aide.conf for your environment (for example, add paths you care about), then build and activate the baseline:

sudo dnf install aide
sudo aide --config-check
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# First comparison: should report no differences
sudo aide --check

For the companion item, the CIS remediation offers two options. The first is a line in root’s crontab (run sudo crontab -u root -e):

0 5 * * * /usr/sbin/aide --check

The second is a systemd service and timer. Create /etc/systemd/system/aidecheck.service:

[Unit]
Description=Aide Check

[Service]
Type=simple
ExecStart=/usr/sbin/aide --check

[Install]
WantedBy=multi-user.target

and /etc/systemd/system/aidecheck.timer:

[Unit]
Description=Aide check every day at 5AM

[Timer]
OnCalendar=*-*-* 05:00:00
Unit=aidecheck.service

[Install]
WantedBy=multi-user.target

Then set ownership and enable them:

sudo chown root:root /etc/systemd/system/aidecheck.*
sudo chmod 0644 /etc/systemd/system/aidecheck.*
sudo systemctl daemon-reload
sudo systemctl enable aidecheck.service
sudo systemctl --now enable aidecheck.timer

Debian 12 and Ubuntu 24.04

The Debian packaging splits AIDE into aide (the binary) and aide-common (configuration, aideinit and the daily job). Configuration lives in /etc/aide/aide.conf plus snippets in /etc/aide/aide.conf.d.

sudo apt install aide aide-common
sudo aideinit

aideinit writes /var/lib/aide/aide.db.new and then copies it to /var/lib/aide/aide.db, prompting first if a database already exists. The CIS text adds mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db; that step only matters if aide.db is still missing afterwards. For the companion item, make sure the packaged timer is not masked and is running:

sudo systemctl unmask dailyaidecheck.timer dailyaidecheck.service
sudo systemctl --now enable dailyaidecheck.timer

One Debian-specific trap: the Debian aide binary is built without a default configuration file, so manual runs must name it, for example sudo aide –config /etc/aide/aide.conf –check. The daily job reads its settings from /etc/default/aide and writes its report to /var/log/aide/aide.log.

Ubuntu 22.04

Ubuntu 22.04 ships AIDE 0.17.4 without the dailyaidecheck systemd units, so the installation steps match the section above but scheduling does not. The CIS 22.04 remediation uses the same crontab or aidecheck service and timer pattern as RHEL, with the command /usr/bin/aide.wrapper –config /etc/aide/aide.conf –update. The Debian packaging dropped aide.wrapper before AIDE 0.17, so check with ls -l /usr/bin/aide.wrapper first. If it is missing, call the binary directly:

0 5 * * * /usr/bin/aide --config /etc/aide/aide.conf --check

Confirm on one host that the audit item passes with your command line before you roll it out, because the audit may match on the command text.

How to verify the fix and rescan

1. Rerun the confirmation commands above. The package query should report the package as installed and the database file should exist.
2. Run a manual check and read the exit code. Per the aide(1) man page, 0 means no differences, 1, 2 and 4 (or their sums) mean added, removed or changed files were reported, and 14 or higher means an error such as a configuration or I/O problem.
3. Confirm the schedule with systemctl list-timers (look for aidecheck.timer or dailyaidecheck.timer) or sudo crontab -u root -l.
4. After the first scheduled run, read the result with journalctl -u aidecheck.service on RHEL, or in /var/log/aide/aide.log on Debian and Ubuntu.
5. Rescan the host with the same compliance policy and credentials. The audit needs root to read root’s crontab and /var/lib/aide.

sudo aide --check; echo "exit: $?"                                   # RHEL family
sudo aide --config /etc/aide/aide.conf --check; echo "exit: $?"   # Debian, Ubuntu

What can break and how to roll back

• Disk I/O and run time: the baseline and every check read and hash each monitored file. On file servers or hosts with large data directories, schedule off-peak and exclude volatile data paths in the configuration. Debian’s documentation notes that excluding large, active home directories can cut run time severely.
• Noise after patching: every dnf or apt update changes monitored files. After reviewing a report, update the baseline instead of rebuilding blind: on RHEL run sudo aide –update and rename aide.db.new.gz to aide.db.gz, as Red Hat documents.
• “Failed” units: AIDE exits non-zero when it reports changes, so systemd marks the CIS aidecheck.service as failed after such a run. Because the CIS service unit is enabled with WantedBy=multi-user.target, it also runs once at every boot.
• Mail on Debian and Ubuntu: the daily job mails reports to root by default. MAILTO, QUIETREPORTS and SILENTREPORTS in /etc/default/aide control this.

To roll back on RHEL-family hosts (this brings the findings back):

sudo systemctl disable --now aidecheck.timer
sudo systemctl disable aidecheck.service
sudo rm /etc/systemd/system/aidecheck.service /etc/systemd/system/aidecheck.timer
sudo systemctl daemon-reload
sudo crontab -u root -e      # remove the aide line if you used cron
sudo dnf remove aide

On Debian and Ubuntu:

sudo systemctl disable --now dailyaidecheck.timer
sudo apt remove aide aide-common

Common false positive reasons

• Another file integrity tool is in use. The audit only knows about AIDE. If a different FIM product covers the host, the item still fails; record a documented exception that names the compensating control.
• The scan account cannot escalate. Without root, the audit cannot read root’s crontab or /var/lib/aide, and results for this section can be wrong. See our guide to setting up SSH credentials for Linux authenticated scans.
• The check is scheduled in a way the audit does not recognize. A job in /etc/cron.d, one managed by configuration management, or the cron script that Ubuntu 22.04’s package installs may run AIDE daily but still fail the benchmark’s companion item.
• Wrong target. Container images and short-lived build hosts often fail host benchmarks by design. Decide whether they belong in scope before remediating. Our overview of real causes of vulnerability scanner false positives covers this pattern.

FAQ

Is installing the aide package enough?

It is enough to pass the RHEL-family “installed” item, which checks the package. It does not protect anything until you build a baseline and schedule checks, and the companion item will keep failing without a schedule.

Do I need to rebuild the database after every patch?

Update it rather than rebuild it. Review the report, run aide –update, and activate the new database. On Debian and Ubuntu, aideinit -y -f rebuilds and replaces the database without prompting.

Does AIDE detect changes in real time?

No. It compares the filesystem with the baseline only when a check runs. For event-level visibility, pair it with auditd watch rules; Red Hat also documents IMA as a separate integrity mechanism.

Where should the baseline database live?

Red Hat recommends read-only media or a separate secure location for the database, configuration and binary. At minimum, keep a copy of the current database off the host.

Tracking this finding across many hosts

On a large Linux estate, the recurring work is finding hosts where AIDE is installed but has no baseline or schedule. If you use SITEY, you can upload the .nessus export from your compliance scan, have its AI draft a host-specific remediation script that runs only after a human approves it, deploy it through SITEY agents on Linux endpoints, and then re-test to verify the finding is closed. Duplicate findings are merged per scanner, not across scanners.

Sources

• Tenable: CIS Red Hat Enterprise Linux 9 v2.0.0 L1 Server, 6.1.1 Ensure AIDE is installed
• Tenable: CIS Debian Linux 12 v2.0.0 L1 Server, 6.3.2 Ensure filesystem integrity is regularly checked
• Red Hat: RHEL 9 Security hardening, Checking integrity with AIDE
• aide(1) manual page (Ubuntu 24.04)
• aide-common README.Debian (Debian and Ubuntu packaging notes)