AIDE/en

AIDE
AIDE stands for Advanced Intrusion Detection Environment and is an application that scans files and other resources and stores information about these files in a database. This information can be hash information, file size, ownership and more. The application can then, once this database is available, rescan the system and compare the results with the previously stored values. If values differ, then the file is changed and this change is reported.

Installation and configuration
Within Gentoo, you can easily install aide after setting the USE flags accordingly. The supported USE flags at the time of writing are:

Then it is a matter of installing the software:

The configuration file for aide is not as daunting as it might seem at first sight. The default file is stored at but you can easily create multiple separate configuration files if you want. Besides a few variables, the configuration file contains a few short-hand notations for what aspects of files to scan for (only hashes, or also inode information, etc.) and then which files to scan.

Let's first look at the variables.

These parameters define where the database is stored that contains the known values (database) and where to store a new database if you create a new one (database_out). It is generally recommended to not have these variables point to the same, instead manually copying over the generated database from one location to the other.

For now, leave those variables as-is, we'll get back to them later.

These are short-hand notations for what to measure. The letters are described in the default file, so instead of documenting them all here, I'll just give information about a few of them: permissions, inode number, number of (hard)links, user information, group information, s'ize (or S if the size is allowed to grow but never shrink), block count, modification time, etc. Also, you probably have guessed that md5 and sha1 mean that the MD5 and SHA-1 checksums are taken.

Also, it is pretty obvious that  and   mean that the MD5 and SHA-1 checksums are taken.

These short-hand notations are then used to identify what to scan for which files.

This is the overview of which directories to scan, and what to scan for. In the above three lines example, we tell AIDE to scan the and  locations and take the measures identified earlier in the Binlib short-hand notation. The location should use the Logs scan measures.

AIDE supports regular expressions and you are allowed to "remove" matches. For instance, if you want to scan but not  then you can include an exclusion set as well:

Initialization and frequent scanning
First we need to initialize the database once.

Once initialized, we can copy over the database file.

With the database now available, we can scan the entries again for potential modifications:

When a file modification is occurred, you will get a notification:

Be clear with what to scan
The default AIDE configuration is useful, but you'll need to fine-tune it to suit your needs. It is important to know which files to scan and why.

For instance, if you want to scan for all authentication-related files but not for other files, you can use a configuration like so:

Keep the database offline and read-only
A second important aspect is that you really want the result database to be stored off-line when you don't need it, and use it in read-only modus when you do. This gives some protection against a malicious user, that might already have compromised the machine, to also modify the results database. For instance, you can provide the result database on a read-only NFS mount (for servers) or read-only medium (when you have physical access to the machine) such as CD/DVD or read-only USB sticks.

When you have the database on such location, update the file to have database= point to this new location.

Do offline scanning
If you can, try using offline scanning methods for the system. In case of virtual platforms, you might be able to take a snapshot of the system, mount this snapshot (read-only) and then run the aide scan on the mounted file system.

The above approach uses a chroot. This is only needed when the initial file system has been scanned from the live system and you want to perform an offline validation. If you did your initial scan offline, then your will point to the mount point already and the database will use these paths immediately, so then you do not have the need for chrooting.

More information

 * Integrity/Concepts talks about the concepts related to system integrity