AIDE constructs a database of the files specified in AIDE.conf, AIDE’s configuration file. The AIDE database stores various file attributes including: permissions, inode number, user, group, file size, mtime and ctime, atime, growing size, number of links and link name. AIDE also creates a cryptographic checksum or hash of each file using one or a combination of the following message digest algorithms: sha1, sha256, sha512, md5, rmd160, tiger (gost and whirlpool can be compiled in if mhash support is available). Additionaly, the extended attributes acl, xattr and selinux can be used when expliticly enabled during compile time.

Typically, a system administrator will create an AIDE database on a new system before it is brought onto the network. This first AIDE database is a snapshot of the system in it’s normal state and the yardstick by which all subsequent updates and changes will be measured. The database should contain information about key system binaries, libraries, header files, all files that are expected to remain the same over time. The database probably should not contain information about files which change frequently like log files, mail spools, proc filesystems, user’s home directories, or temporary directories.

After a break-in, an administrator may begin by examinining the system using system tools like ls, ps, netstat, and who — the very tools most likely to be trojaned. Imagine that ls has been doctored to not show any file named “sniffedpackets.log” and that ps and netstat have been rewritten to not show any information for a process named “sniffdaemond”. Even an administrator who had previously printed out on paper the dates and sizes of these key system files can not be certain by comparison that they have not been modified in some way. File dates and sizes can be manipulated, some better root-kits make this trivial.

While it is possible to manipulate file dates and sizes, it is much more difficult to manipulate a single cryptographic checksum like md5, and exponentially more difficult to manipulate each of the entire array of checksums that AIDE supports. By rerunning AIDE after a break-in, a system administrator can quickly identify changes to key files and have a fairly high degree of confidence as to the accuracy of these findings.

Unfortunately, AIDE can not provide absolute sureness about change in files. Like any other system files, AIDE’s binary and/or database can also be altered.

[ Source: http://www.cs.tut.fi/~rammer/aide/manual.html ]

Configuring AIDE

There are three types of lines in aide.conf:

configuration lines - used to set configuration parameters and define/undefine variables
selection lines - indicate which files will be added to the database
macro lines - define or undefine variables within the the config file
Lines beginning with # are ignored as comments.

Here is an example configuration.

#AIDE conf

# Here are all the things we can check - these are the default rules
#
#p: permissions
#i: inode
#n: number of links
#l: link name
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#I: ignore changed filename
#md5: md5 checksum
#sha1: sha1 checksum
#sha256: sha256 checksum
#sha512: sha512 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#haval: haval checksum
#crc32: crc32 checksum
#R: p+i+l+n+u+g+s+m+c+acl+selinux+xattrs+md5
#L: p+i+l+n+u+g+acl+selinux+xattrs
#E: Empty group
#>: Growing logfile p+l+u+g+i+n+S+acl+selinux+xattrs
#The following are available if you have mhash support enabled:
#gost: gost checksum
#whirlpool: whirlpool checksum
#The following are available when explicitly enabled using configure:
#acl: access control list
#selinux SELinux security context
#xattr: extended file attributes

# You can alse create custom rules - my home made rule definition goes like this
#
MyRule = p+i+n+u+g+s+b+m+c+md5+sha1

# Next decide what directories/files you want in the database

/etc p+i+u+g #check only permissions, inode, user and group for etc
/bin MyRule # apply the custom rule to the files in bin
/sbin MyRule # apply the same custom rule to the files in sbin
/var MyRule
!/var/log/.* # ignore the log dir it changes too often
!/var/spool/.* # ignore spool dirs as they change too often
!/var/adm/utmp$ # ignore the file /var/adm/utmp

Here we include files in /etc, /bin and /sbin. We also include /var but ignore /var/log, /var/spool and a single file /var/adm/utmp.

It is generally a good idea to ignore directories that frequently change, unless you want to read long reports. It is good practice to exclude tmp directories, mail spools, log directories, proc filesystems, user’s home directories, web content directories, anything that changes regularly. It is also good practice to include all system binaries, libraries, include files, system source files. It will also be a good idea to include directories you don’t often look in like /dev /usr/man/.*usr/. Of course you’ll want to include as many files as practical, but think about what you include.

One example: If you have a block device whose owner is changing frequently, you can configure aide to just check the attributes that do not normally change (inode, number of links, ctime).

Note that if you are referring to a single file you should add $ to the end of the regexp. This matches to the name of the file exactly and does not include any other files that might have the same beginning. In the example, all filenames beginning with /var/adm/utmp would be ignored if there were no dollar sign at the end of the last line. An intruder could then create a directory called /var/adm/utmp_root_kit and place all the files he/she/they wanted there and they would be ignored by AIDE.

There are two special group definitions to tweak what attributes are printed in the report. First report_attributes lists those attributes that are always printed from changed files. For example, if you say

attributes = u+g

and the size of a file changes, it’s user and group id will also be printed in the report. Secondly, ignore_list defines which attributes to ignore from the report. For example, if you define
ignore_list = b

and this size of a file changes, it’s block count will not be printed in the report, even if it did change as well. Ignore_list overrules report_attributes where they conflict.

Using AIDE

First you must create a database against which future checks are performed. This should be done immediately after the operating system and applications have been installed, before the machine is plugged into a network. You can do this by giving the command aide –init. This creates a database that contains all of the files that you selected in your config file. The newly created database should now be moved to a secure location such as read-only media. You should also place the configuration file and the AIDE binary and preferably the manual pages and this manual on that media also. Please remember to edit the configuration file so that the input database is read from that read-only media. The config file should not be kept on the target machine. The attacker could read the config file and alter it or even if he does alter it he could place his rootkit to place that AIDE does not check. So the read-only media should be accessible only during the check.

Now you are all set to go. You can now check the integrity of the files. This can be done by giving the command aide –check. AIDE now reads the database and compares it to the files found on disk. AIDE may find changes in places that might not expect. For instance tty devices often change owners and permissions. You may want to read long reports and that is up to you to decide. But most of us do not have the time or the inclination read through tons of garbage every day. So you should trim the config file to include only the files and attributes of certain files that should not change. But keep in mind that you should not ignore too much as that leaves you open for an attack. An intruder might place his/her/its/their root kit in a directory that you have ignored completely. One good example is /var/spool/lp or something similar. This is the place that lp daemon stores its temporary files. You should not ignore it completely however. You should only ignore the format of files that you lp daemon keeps creating. And remember to use the $-sign at the end of your regexps. This stops someone from creating a directory that is ignored along with its contents.

Now that you have trimmed your config file you should update the database this can be done aide –update command. The update command also does the same thing as check but it also creates a new database. This database should now be placed on that read-only media along with the new config file. The check, trim, update cycle should be repeated as long as necessary. I recommend that the config file should be reviewed once in a while. The definition of “a while” depends on your paranoia. Some might want do it daily after each check. Some might want to do it weekly.

There is usually some drift in the databases. What I mean by drift is that new files are created, config files of applications are edited, tons of small changes pile up until the report becomes unreadable. This can be avoided by updating the database once in a while. I myself run the update every night. But, I don’t replace the input database nearly as often. The replacement of the input datbase should always be a manual operation. This should not be automated.

There is also an alternative way of doing this. This method may be preferable for people that have lots of machines that run aide. You can run aide –init on all of the hosts and move the generated databases to a central host where you compare different versions of the databases with aide –compare This has the benefit of freeing up resources on the monitored machines.

For more information about AIDE:

AIDE manual: http://www.cs.tut.fi/~rammer/aide/manual.html
AIDE site: http://www.cs.tut.fi/~rammer/aide.html
AIDE development site: http://sourceforge.net/projects/aide
AIDE MAN page: http://swoolley.org/man.cgi/aide

Most of the information here has been copied from http://www.cs.tut.fi/~rammer/aide/manual.html

The Example screenshots are produced by me.Hacking Hacking Tools Linux Commands/Tools