Linux Security Tips – AIDE

AIDE – Advanced Intrusion Detection Environment

What is AIDE?  AIDE creates a database from regular expression rules established within its configuration files.  Once AIDE has been kicked off, it will conduct a comparison against the database from the current systems environment.

The comparisons conducted are defined within the aide.conf and are capable of comparing the following points:

  • File type, permissions, inode, uid, gid, link name, size, block count, number of links, Mtime, Ctime and Atime.

AIDE is capable of creating and comparing the following hashing algorithms:

  • md5, sha1, rmd160, tiger, crc32, sha256, sha512, and whirlpool

In addition, AIDE can also inspect additional properties such as:

  • Posix ACL, SELinux labels, and XAttrs

One of the power points of AIDE is that regular expressions can be utilized to selectively include or exclude files and directories to be monitored, and which attributes of those files/directories will be compared.  An example could be: Monitor /etc for any changes to file type, permissions, inode, uid, gid, and md5.  Monitor /opt for any changes to permissions, inode, sha512, Mtime and SELinux labels but ignore Mtime on /opt/share/xml/access.log

 

Where would I use this?

AIDE is best deployed on a system where file permission and integrity are a high priority.  To me, this would be any external facing server no matter the level of services being offered by the asset.

This level of monitoring should be considered and executed on internal servers of importance as well, and its use shouldn’t just be used on host OS configuration files.

AIDE can instead be leveraged and targeted to specific folders for explicit monitoring.

Why would I use this?

This tool, coupled with cron and some scripting, provides a method of automation to inspect and verify file system contents have remained unaltered since the last AIDE database was created.

This can be beneficial in detecting if an un-authorized user has gained access to your host or monitor legitimate system users from altering files (approved or otherwise).

How do I use this?

Established AIDE configuration for the host, establish an execution schedule for the program, and review output reports from the program.

The goal of this is to audit system configuration files daily and to collect reports remotely for analysis.

Additional desired functionality is e-mail driven notification system to Sys Admin to review changes that occur on host.

 

Putting the tool to use.  This use case is using RHEL 6.

Install the tool utilizing yum, yum install aide.

On RHEL6 based systems, AIDE database resides in /var/lib/aide

You can generate a new AIDE database via:

aide --init --config=/etc/aide.conf

 

This creates the file aide.db.new.gz within /var/lib/aide directory.  AIDE will not use the new configuration file until it has been renamed to aide.db.gz.  The DB should be updated on a set period to ensure appropriate monitoring of changes.

 

To launch AIDE run:

aide -C --config=/etc/aide.conf

Here are some generic cron options to execute a comparison daily and e-mail the report to your designated user.

* 1 * * * root /usr/sbin/aide --config=/etc/aide.conf -C | mail -s "AIDE report for $HOSTNAME" user@example.com

An e-mailed output report will resemble:

AIDEReportExample

Best common practice for AIDE
For sensitive systems it’s best to execute an AIDE check at least once a day and deliver the output to a system or person to interpret the output.  This is easily managed by utilizing cron as we used in the earlier example:

* 1 * * * /usr/sbin/aide --config=/etc/aide.conf -C | mail -s "AIDE report for $HOSTNAME" user@example.com

An issue we’ll run into however is that log files will rotate and some files may have new timestamps, so without doing a database update we’ll be reviewing unnecessary information.  It’s best to update the database at least weekly, but I don’t recommend just executing an AIDE DB update.  What happens when we missed an event that happened a month back and we would like to go back and review what took place on the system?  This is why we should create a simple script to create an archive folder and offload old databases before we apply the new database.

A sample database update script would resemble:
#!/bin/bash
/usr/sbin/aide --init
mv /var/lib/aide/aide.db.gz /var/lib/aide/archive/aide.db.$(date +%y%m%d).gz
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
/usr/sbin/aide --config=/etc/aide.conf -C | mail -s "AIDE DB Update for $HOSTNAME" user@example.com

So the reviewing resource will have two e-mails to review on the day the database is updated.  The first e-mail should be the AIDE report prior to updating the database and the second sent after the update has been completed.

This is easily established via crontab:
* 1  *  *  * root /usr/sbin/aide --config=/etc/aide.conf -C | mail -s "AIDE report for $HOSTNAME" user@example.com
* 2 * * 0 root /etc/cron.d/aide-update.sc

This is where you’ll want to execute your AIDE checks and groom how sensitive the scanner is to system changes.  If you notice certain files change patterns and want to start omitting them, update the aide.conf and filter out the unnecessary triggers.  We can also advance the scripting to only send e-mail traffic when the system actually finds changes to reduce manual review effort.  Another pro tip would be to have the AIDE database files stored on an off-system media, as a person who has compromised your system could effectively alter and manipulate this system.

There you have it, a fairly quick and easy way to monitor your system for potential unwanted intruders.  Understand this is a reactive measure meant to identify that a system has been compromised and in no way prevents a user from gaining unauthorized access.  AIDE has proven to be an effective tool in enforcing change control validation, system integrity, and help track file manipulation.