File integrity monitoring with AIDE: building the baseline, checking against it, and keeping the database off the host

Goal

Establish a known-good AIDE database for a Linux host, run comparisons against it, exclude paths that change legitimately, and store the baseline somewhere a local compromise cannot reach.

Prerequisites

Root privileges; the aide package installed; a configuration that lists the paths to watch and the rule (which attributes to compare) for each — /etc/aide.conf on RHEL-family systems, /etc/aide/aide.conf (plus /etc/aide/aide.conf.d/) on Debian/Ubuntu. aide --version prints the compiled-in default config file and database_in/database_out values; pass --config=<file> explicitly when they differ from the file you edited.

Steps

1. Define what to watch in the configuration, excluding volatile paths such as /proc, /sys, /tmp, log directories and package-manager caches with a leading !: !/var/log skips that tree. aide.conf documents database_out as the target for the database written by --init, alongside the include/exclude rule syntax.
2. Build the initial database. RHEL-family: aide --init. Debian/Ubuntu: aideinit -y -f (the Debian wrapper; -y and -f answer its overwrite prompts, so it runs non-interactively). The manual page states that after --init you must "move it to the appropriate place (see database_in config option)" before --check works.
3. Move the new database into the database_in path. RHEL-family defaults: mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz. On Debian/Ubuntu, aideinit writes /var/lib/aide/aide.db.new and, with -f, copies it to /var/lib/aide/aide.db itself.
4. Immediately copy that database to storage the host being monitored cannot write to (a separate server, write-once media, or a secrets/config-management system) — a database left only on the monitored host can be edited by anything with root on that host, defeating the check.
5. Run a comparison at any later point: aide --check. Its exit status is a bit mask (1 = new files, 2 = removed files, 4 = changed files; 14 and above are errors), so a non-zero exit is not by itself a failure of the tool. Review the report for unexpected additions, deletions or attribute changes.
6. After every intentional change (a patch, a configuration edit), re-run --init (or --update, which checks and writes a new database to the separate database_out path, which then has to be moved into place the same way) and redistribute the new database the same way, so the next --check compares against the current known-good state rather than flagging routine work.

Expected result

aide --check runs clean immediately after a rebuild, and reports every file that changed, was added, or was removed since the stored baseline for any subsequent run.

Limits and test basis

AIDE only detects a difference between the current filesystem and its stored database — it proves nothing if both are read from the same compromised host during the same session, which is why step 4 (moving the database off the host) is the control that makes the check meaningful. Excluding a path in step 1 removes it from all future checks; review exclusions periodically rather than treating them as permanent. No reboot is required for any of these steps; undo an unwanted exclusion by editing aide.conf and rebuilding the database.