Configuring basic AIDE server

<yambe:breadcrumb self="Configuring basic AIDE server">AIDE configuration|AIDE configuration</yambe:breadcrumb>

Configuring basic AIDE server

About AIDE

AIDE stands for Advanced Intrusion Detection Environment. It is file integrity based IDS like tripwire. AIDE supports very easy to use configuration file and command line syntax and large number of hash functions.

Basic AIDE configuration

AIDE configuration file contain three types of lines:

• Configuration lines
• Macro lines
• Selection lines

Parameter configuration lines

Configuration lines have format '<variable>=<value>'. The various configuration parameters and their values are explained below:

Variable	Description
database	The database configuration must have value of type file://<full_path> This is the database which is used to check current file attributes and report changes in comparison to when database was initialized
database_out	This value should also point to a file. This is the name of output file where the new database gets stored, which gets created when we initialize (or rebuild) aide database as per current file attributes. We copy this database to current database whenever we want to check for file integrity.
verbose	It is integer value between 0 and 255. Default is 5. Value of 20 generates additional output during database update or file check process
report_url	This is the place where aide will write its output. We can specify multiple report_url if we want output to be written to multiple files. We can set report_url to stdout to ensure that output also gets printed on screen which is useful if we run aide manually or redirect its output using cron to email output to administrators.
gzip_dbout	By default the output database is not gzipped. But this parameter can be set to yes to enable compression to save considerable space.
acl_no_symlink_follow	This option is used to indicate whether symbolic links should be followed or not. Default is yes, which is pretty good
warn_dead_symlinks	This option is used to specify whether AIDE should generate warning for dead-links. Default is no, which can be changed to true or yes.
report_attributes	Normally AIDE will only report attributes that have changed or being updated. But using this we can define special set of attributes (permission, user owner, group owner, size, etc.) which always get printed in report whether they have changed or not.
ignore_list	Normally AIDE will print all report attributes defined and changed attributes on files/folders that have changed. Using ignore_list we can suppress printing of report attributes when we are not interested in their values and only care if they changed or not.
config_version	It is informational parameter and can be helpful in versioning. Version information is stored in database and also included in generated report.

Group definitions configuration lines

AIDE has set of pre-defined groups which help in specifying which parameters need to be monitored for particular file /folder or directory hierarchy. Basic AIDE groups are

Indicator	Description
p	File permissions (rwx, etc.)
i	Inode number
l	Link name
n	Number of links
u	User owner of file
g	Group owner of file
s	Size of file
m	Modification time of file
a	Access time of file
c	Status change or configuration change
S	Checking for growing file size. This is very important for log files whose size should always increase. This wont cause any alarms if size change and final size increases. But if final size is less then the last time database was initialized(updated) then reduction in size is reported during check operation.
I	Ignore changed filename. AIDE can recognize the same file with inode number. Now if we do not care if filename changes but some other parameter like owner, size, timestamps etc. remain same then we can use this option. Note that I will cause 'c' to get ignored as if we change file name the status change or configuration change timestamp will get updated.
ANF	Allow new files
ARF	Allow removed files
md5 sha1 sha256 sha512 rmd160 tiger haval crc32	calculate respective checksum

• Read 'man fstat' if difference between modification, access and change times is not clear

Apart from these there are four complex groups which are pre-defined and can also be re-defined in our configuration files.

Group	Description
R	R is defined by-default as R=p+i+l+n+u+g+s+m+c+md5. (On SELinux enabled systems it could include selinux as well. This can be used to check for files which are to-be used in read-only manner like library files, configuration files and executables. This does not report problems on access so we can keep using the library files, configuration files and binary files without AIDE reporting problems to us.
L	L is defined by-default as L=p+i+l+n+u+g. This can be used to monitor files which can be modified by their ownership information should not change.
E	E is defined by-default as empty group.
>	> is defined by-default as p+l+u+g+i+n+S. This group can be used to monitor growing logfiles whose size should always increase.

• Note that we can redefine R, L, E and > in configuration file as per our needs

Additional basic groups are also available if AIDE was configured to include them during compile time. The important additional groups are

Basic Group	Description2011-05-08-aide.conf.txt
selinux	This can be used to store SELinux context of files in database and report any changes to SELinux context
xattr	This can be used to store Extended attributes of files in database.

• To learn about extended attributes use 'man chattr'

Macro lines

We can define variables and use their values using MACRO lines. This can be used in similar way we use constants in a programming language so that we can use the same basic value and create other dependent values based on this constant. For example we can define a base dir and other directories like log directory, database directory etc. can be defined with respect to base dir.

To define a variable we can use syntax '@@define VAR val'. To reuse this value somewhere in the configuration file we can use '@@{VAR}'. One special variable HOSTNAME gets replaced with host name of current system.

Selection lines

Selection lines start with either '/', '!' or '='. Selection lines help in specifying which files/directories to monitor and which attributes of these files should be monitored.

• If selection lines start with '/' then they should contain full path of file/directory tree to be monitored. Note that in case of directory all sub-folders/files will also get included.
• If selection lines start with '!' then all files/folders inside that directory get ignored and are not monitored for parameter changes.
• If selection lines start with '=' then only that specific folder gets monitored for attributes. Its sub-folders and files are not automatically included.

Examples:

• '/test p+u+g' can be used to monitor all files/folders inside folder /test for change in permission, user owner or group owner. This would include the directory /test itself too.
• '!/etc/yum.repos.d ' can be used to ignore changes done to or inside yum.repos.d folder even if '/etc' is configured to be monitored in some previous line.
• '=/root p+u+g' can be used to ensure that directory '/root' always has same permissions, user owner and group owner. Sub-folders and files inside /root wont be monitored.

Sample configuration file

Sample aide configuration file

@@define AIDEDIR /home/saurabh/Desktop/aide
database=file://@@{AIDEDIR}/database/current_database.db.gz
database_out=file://@@{AIDEDIR}/database/new_database.db.gz
verbose=20
report_url=file://@@{AIDEDIR}/log/aide_report.txt
report_url=stdout
gzip_dbout=yes
warn_dead_symlinks=yes
config_version=1.0

/home/saurabh/Desktop/aide/test p+u+g+S

We can save this file as 'aide_test.conf' and use it to learn aide by making changes in test directory and running aide with -c parameter to specify this custom configuration file instead of default '/etc/aide.conf' file.

Note:

• A fully matured configuration file is present at 2011-05-08-aide.conf.txt

Using AIDE

Checking configuration

We can check custom AIDE configuration file using:

aide -c <configuration file> --config-check

This would just report mistakes in configuration file, if any.

Initializing Database

We can initialize AIDE database using:

aide -c <configuration_file> -i

This can be used to create new database as specified with value of database_out parameter in configuration file. After creating new database we have to manually copy it to database url value before we check files/folders for integrity. This is necessary after making any change to configuration file as database storage format depends on configuration file.

Check system

We can check system against current database. All changes are reported to all report_url defined in configuration file. Command to run check is

aide -c <configuration_file> -C

Update database

To update database with current values we can use:

aide -c <configuration_file> -u

Note that this is useful to perform checks and also update output database at same time. Hence if we feel that changes are not security problem then we can simply copy output database to current database after check so that same changes do not get reported again.

Running AIDE periodically using cron

We can create cron script like:

#!/bin/bash
/usr/sbin/aide --update -V 20 | /bin/mail -s "Weekly Aide Data" saurabh.barjatiya@iiit.ac.in
cp <new_database> <current_database>

in '/etc/cron.weekly' to run weekly AIDE checks on all files automatically and get report of files changed since last run in email.

Miscellaneous

There is no security provided by AIDE to protect its database from attacker. Hence onus of keeping configuration file and database secure is on user. We can either copy database and configuration file to remote location after intializing or updating database or we can mount the entire system on other system using sshfs and do all hash calculations on other system.

Note:

• If we do not try to secure AIDE database and configuration file then attacker can change the configuration, update database and hide changes to filesystem.
• If we try to keep copy on remote system then we should pull the files from system being monitored on to a secure system just after initializing/updating database and push them on the system being monitored just before running next check. If we try to automate things in other direction then even attacker would be able to modify files/database and push them on more secure server to avoid detection. This all is applicable when one is trying to automate pushing/pulling of files using SSH authorized keys in combination with cron.
• If we mount files on other system then during hash calculation entire hard-disk data will travel over network. Networks being generally slow in comparison to disk I/O on main machine this may take really long time to build/check system. Also large amount of network bandwidth will get wasted.

More information can be found using 'man aide' and 'man aide.conf' commands.

<yambe:breadcrumb self="Configuring basic AIDE server">AIDE configuration|AIDE configuration</yambe:breadcrumb>