An introduction to AIDE
The Advanced Intrusion Detection Environment (aka AIDE) is a tool that compares the current state of files and directories on a system against a known good snapshot made previously, reporting any differences. It is very robust at detecting filesystem changes, utilizing multiple different hashing algorithms to be collision-resistant and even compares size, permissions and attributes.
This thorough comparison enables operators to quickly identify files that have changed unexpectedly and can alert them to activities on a system that weren't authorized. Most systems configure their default installation to exclude problematic directories like /dev
(because some device files like /dev/zero
could be read endlessly) or /tmp
(because temp files change frequently, causing numerous false positives), but include every other path in scans that wasn't excluded specifically.
Creating an initial snapshot
Before any comparison can be done, aide requires a snapshot of a "known good" filesystem state. You can generate this snapshot of the system by passing the --init flag:
sudo aide --config /etc/aide/aide.conf --init
The command may take several minutes to complete, depending on the CPU speed, hardware acceleration and amount of disk contents. It will generate a new snapshot database, which you need to copy to the default location so subsequent checks can find it:
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
This snapshot database contains the state of all directories and files, including their size, permissions, attributes etc. Any change will be reported when comparing the current disk contents against it.
Checking for changes
Once you have a snapshot database, you can compare the current disk contents against it:
sudo aide --config /etc/aide/aide.conf --check
Comparing the entire disk may take some time again. Once it completes, you will receive a report of all differences:
Summary:
Total number of entries: 30623
Added entries: 2
Removed entries: 0
Changed entries: 1
---------------------------------------------------
Added entries:
---------------------------------------------------
d+++++++++++++++++: /bad-dir
f+++++++++++++++++: /bad-dir/new-file.bin
---------------------------------------------------
Changed entries:
---------------------------------------------------
d =.... mc.n .. . : /
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
Directory: /
Mtime : 2025-04-23 17:03:59 +0000 | 2025-04-23 17:27:26 +0000
Ctime : 2025-04-23 17:03:59 +0000 | 2025-04-23 17:27:26 +0000
Linkcount : 20 | 21
The report clearly states that a new directory /bad-dir
and a file /bad-dir/new-file.bin
have been created. It also reports than the root directory /
has changed, because creating files has updated it's timestamps and changed its "size" (number of contained items, aka "linkcount").
This type of scan should be automated for example using a cron job, with the results forwarded to an email address of chat server that you can check regularly. Scans can be quite taxing for system resources (disk read bandwidth, cpu load), so consider running them at low-traffic times or outside of office hours (e.g. at night).
Updating the snapshot
While tracking changes is useful, some changes are intentional. If an administrator updates system packages, a lot of directories and files may change, which aide would obviously report as well. This much noise could hide an attacker's changes in plain sight, by burying it within thousands of false positives.
To combat this, administrators need to update the existing snapshot database after making legitimate changes:
sudo aide --config /etc/aide/aide.conf --update
Now the snapshot database will refer to the current disk contents when comparing during future checks, implicitly allowing all changes up until this point.
Be aware that updating the snapshot will treat the entire filesystem as the new known good state, even if it contained malicious changes. For increased security, consider running a manual check immediately before making changes like package updates, then updating the aide database to minimize the time window in which unnoticeable changes can be sneaked into the system.
Excluding a directory
Most production systems have some directories where file contents are expected to change frequently. Most operating-system level directories like /tmp
are excluded by default, but application-specific ones need some custom configuration.
Suppose you are running a website which saves temporary files like partial uploads to /var/www/html/tmp_uploads/
. The contents of this directory are expected to change a lot and don't signal an intrusion, so it is best avoided from aide
scans altogether.
To extend the aide configuration, you need to know how it works: Aide is configured to only keep track of paths given to it explicitly. Exceptions to these paths can only be made before the path is included, so order matters. Under debian, the config file /etc/aide/aide.conf.d/99_aide_root
includes the root directory /
as a last step, effectively adding all system paths. If you want to add your own exclusion rules, it should be in a file starting with a number lower than 99 to ensure it is loaded before this file, for example 90_custom_webapp-tmp
/etc/aide/aide.conf.d/90_custom_webapp-tmp
!/var/www/html/tmp_uploads
This exclamation mark at the start tells aide to ignore this path and everything under it (it is treated as a prefix, any path starting with this string is ignored). You can now safely run a scheduled aide background scan without constant false positives from temporary files.
Considerations when using AIDE
Scanning most of the filesystem can cause quite a bit of load on cpu/disks on some systems (depending on disk/cpu speed and filesystem size), so operators need to find a balance for scanning frequency that is often enough to catch intruders fast, but not so often that it negatively impacts normal operations.
AIDE is a great tool to catch intruders once they already got in through an exploit or credential leakage, but remember that it is best used in combination with other tools like apparmor/selinux to limit system access, as well as tools to prevent intrusion in the first place. It also does not catch memory-only exploits or rootkits that were removed directly after execution. It is often part of a solid security strategy, but not on its own.
Also note that if an attacker can manipulate the aide database file (or run aide --update
), they may be able to hide their changes from scheduled scans. Consider copying a fresh database file before every scan for heavily hardened systems.