AIDE Early Steps

Some pre-checks for AIDE

Run:

aide -v

This will show some information including the program's version. One of the details it will give is the configuration file that is used. For example, one of the lines of the output may be something like:

CONFIG_FILE = "/etc/aide.conf"

Check out what configuration files currently exist. e.g.

ls -l /etc/aide*

(This came from file integrity checking)

Back up original configuration file
cpytobak /etc/aide.conf
sudo cp -pi /etc/aide.conf /etc/aideorig.conf
Remove existing file-specific rules

First, let's check out what pre-existing rules exist.

grep -i ^/ /etc/aide.conf
grep -i ^= /etc/aide.conf
grep -i ^! /etc/aide.conf
Sample results

e.g.:

$ grep -i ^/ /etc/aide.conf
/bsd$ L+s+sha256
/etc$ L+s+sha256
$ grep -i ^= /etc/aide.conf
=/$ R
=/home$ R
$ grep -i ^! /etc/aide.conf
$

It may be possible to remove those lines through “ grep -v ...” trickery, but it is probably easiest just to make the needed changes with a nice text editor.

echo ${VISUAL}
sudoedit /etc/aide.conf

The lines to remove are the lines that were shown by the earlier commands. As an example, the default file may show these three lines (next to each other):

=/$ R
/bsd$ L+s+sha256
/etc$ L+s+sha256

Comment out those lines by inserting a “comment character” (“hash mark”) at the start of each those lines. Actually, even better, insert two hash marks, which easily allows the newly-created comments to visually look different than pre-existing comments.

##=/$ R
##/bsd$ L+s+sha256
##/etc$ L+s+sha256

Do the same for the last line of the default file:

##=/home$ R
Additional Reading/Resources

(Note: also documented at: File Integrity Checking: Removing existing (configuration) rules)

Adding rules
Exclusions

Some data might not be worth reporting when there are changes. For example, the /dev/ directory may have a device object that relates to a terminal. If a user types something at the command prompt, that action shouldn't be flagged as an unusual/unexpected change to the system. Some log files are also updated so routinely that this guide is recommending that you don't bother reporting when those files get changed. Instead, just assume that they typically do get changed a lot.

The new method

To make the exclusions, run these commands:

Download and run a bunch of scripts:

export AIDEWSCF=http://cyberpillar.com/dirsver/1/mainsite/techns/bhndscen/protsoft/filintgr/aide/mkaidecf/aidecfsc/aidecfs1

(Class environments might have users be pointing to a different location, on a private server. If project documentation provides a different value for AIDEWSCF (AIDE website with configuration details), then specify that site instead.)

cd /tmp/
mkdir ./aide/
cd ./aide/
for x in 1 2 3 4 5 6 7 10 11 12 13 14 ; do ftp -v -o aidep${x} ${AIDEWSCF}/aidep${x} ; chmod u+x aidep${x} ; echo aidep${x} ready ; done
Code verification

This code was downloaded by HTTP. For a system where security is paramount, such code should be validated. Otherwise, an attacker could use the “MITM” technique to supply malicious code. One way to effectively consider the code to be okay is to have the code be validated is to use a trusted connection to obtain trusted code from a trusted server.

More advanced verification techniques may be worthwhile, but this guide does not perform such steps at this time. (In all likelihood, using HTTPS is one way to improve things, though even that process will still rely on trusting PKI.)

for x in 1 2 3 4 5 6 7 10 11 12 13 14 ; do ./aidep${x} ; echo aidep${x} done ; done
  • These scripts may assume that “sudo -n” works. (Support for “sudo -n” does not need to remain forever, on an ongoing basis, as AIDE gets regularly run over time. However, it may be needed for these scripts that help to “set up”/initialize things.)
  • Note: these scripts modify the /etc/aide.conf text file. When creating that text file, these scripts use information on the local system, like what devices exist on the local system. So the resulting text file may not be identical on all different systems. That is why this method involves downloading and running scripts, instead of just downloading the configuration file.
The older way

Note: This is not currently recommended. Instead, use the scripts above. (This is simply remaining documentation until the latest process is confirmed to work easily/smoothly.)

Follow these steps:

Also of possible interest: making AIDE config file: modify configuration file version 1 (gzipped)

Exclusions are most of the typical AIDE configuration file that this guide has the user create. That portion of the configuration process is now complete.

More configuration file changes
After those things are done...

Then, make sure that the configuration file is valid, by running the following:

time aide -D
echo ${?}

The first command is shown using the time command because it may not be instantaneous. However, it also might take less than 5 seconds, so impatiently leaving the computer is not recommended. (By the time this paragraph is read, that first command might be done.)

The desired results of the second command would be a single digit: the number zero (“0”). (The output of the first command will be quite a bit more verbose.)

Initializing

Before a database file can be routinely used, it should be initialized.

Before performing this database-initializing process, prevent data loss by moving out any existing data files. This can be done by following a process that this guide calls “rotating the data files”. First, it should be noted that rotating the data files is not something that needs to be done before performing AIDE's initialization on a system that has never run AIDE before. (Therefore, most users won't need to do that. However, since this topic is about preventing data loss, this is important enough to mention in case anyone wants to do this after using AIDE earlier.) If rotating the data files needs to be done at this time, then see the instructions for rotate the AIDE data files. (If you attempt this on a machine that does not have pre-existing data that needs rotation, then some harmless error messages are expected to be generated.)

Then, initialize the database files, using one of the following sets of instructions:

Init db files w/ OpenBSD's ksh

People who are using OpenBSD's ksh, or similarly/compatible, may run this:

{ sudo time aide -i -V231 ; echo Err=$? ; } 2>&1 | tee -a /tmp/aideinit.txt
Initializing the database files with other shells

People who are using other shells should simply run this:

sudo time aide -i -V231 | tee -a /tmp/aideinit.txt

Unlike the variation meant for OpenBSD's ksh and similar/compatible shells, this simpler command line won't record errors in the log file.

That process may take minutes. (On a freshly installed operating system, this has been seen to take slilghtly less than 5 minutes or more than 20. This could definitely at least a timespan of hours depending on how much data there is).

Example output:

AIDE, version 0.15.1

### AIDE database at /var/db/aide.db.new initialized.

     1035.84 real       863.12 user       130.48 sys
Err=0

(The last two lines of the example output are based on a provided example command line, and do not come directly from the AIDE program. The example shown adds up to 2,029.44 seconds, which is 33 minutes 49.44 seconds.)

Once the new database is made, the newly created database will have a name specified by the “database_out=” line in the configuration file that is being used. (The configuration file used is likely to be the /etc/aide.conf file.)

These sample commands are not required, but are provided for demonstration and convenience.

grep -i database_out /etc/aide.conf
ls -l $( grep -i database_out /etc/aide.conf | grep -v ^\# | cut -d = -f 2 | cut -d : -f 2 )

(Some of this information, like the command to run, came from: See: aideinlz)

Post initializing
Making output directory
sudo mkdir /var/log/aide
sudo chmod ug+rwx /var/log/aide
Rotating the database

So that the database may be easily checked and/or updated, go ahead and perform a rotation of the AIDE database files as described in this documentation.