Admin Spotting for Fun and Profit

CentOS 5 and aide

April 10th, 2008 Posted in Linux

In recent days, the subject of intrusion detection systems for centos has come up. To cover this and hopefully help some folks out, I’ve decided to do a brief writeup of Aide, the IDS which comes with CentOS. Please don’t confuse this with SELinux. SELinux is a Mandatory Access Control style permissioning system. SELinux stops people from getting into your system via protected applications. Aide lets you know if they actually get beyond SELinux and onto your system.

Installing Aide
yum install aide
What? You expected it to be harder? Now that we have aide installed, we need to configure it. The default config file should be okay for most folks who haven’t relocated things on the distro too much. Double check to make sure that all the directories you want to scan are listed. If you want to fine-tune the aide config, then you’ll need to edit /etc/aide.conf.

Initializing Aide’s Records

The next thing we need to do is create the initial aide database. For this, you need to run the following command:
# /usr/sbin/aide --init

This will take a little bit of time to run, and you’ll have some disk churn for minute or two while aide investigates your system and creates a baseline. Once this is done, we’re going to run an initial query of the system, just to make sure that everything’s working properly. To do this, run the command below:
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
# /usr/sbin/aide --check

This copies the initial database to the current database, then checks them against each other. In theory you should not have any differences. If you do, investigate them. As we’re still setting this up, they’re likely to be mundane .viminfo files or something similar. Keep in mind that when you update applications via ‘yum update’ that you may see aide go a bit nuts, just as tripwire or others would. You’re replacing files on your system when you update, and this is exactly what aide is designed to warn you about. In a perfect world, you should get some output like the text below:

# aide --check
AIDE, version 0.13.1
### All files match AIDE database. Looks okay!

Once we’re satisfied that aide is working as we expect, it’s time to set up a periodic check of the system. Only you can determine what’s often enough for your servers. I personally run aide as weekly cron, by creating a file in /etc/cron.weekly/ called aide.cron, with the following contents:


#!/bin/bash
/usr/sbin/aide --check | /bin/mail -s "Weekly Aide Data" email@host.com

This runs my check once a week. That’s pretty much it to setting up aide. If you want to see more options for aide, please check out the documentation in /usr/share/doc/aide-*/

Update:

So it seems that by default, aide requires selinux to be enabled, or at least permissive so that it can record the selinux contexts of the files it watches. If for some reason you really, truly want to have selinux disabled, but you still want aide to watch the system, use the config file below. It is identical to the default scan, but with the selinux bits removed.

selinux-free.aide.conf

  1. 6 Responses to “CentOS 5 and aide”

  2. By jonny on Apr 27, 2008

    Nice article thanks. I got a few errors as I built the new database before saving the selinux-free conf file. Once I rebuilt the database (with the selinux-free conf) and cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz everything was fine.
    One question though - if someone was to get into a system could they themselves not rebuild the the aide database after replacing an important system file? Solution would obviously be to keep a copy of that database in a backup somewhere away from the machine but just wondering?

    [Reply]

    jperrin reply on April 29th, 2008 2:20 pm, 29 Apr 2008:

    This depends on the level of compromise accomplished against your machine. If they simply gain access as apache and change some of your files, then aide will pick that up. If they gain root access through some other method, then you are correct and they could create their own aide config and database with you being none the wiser. It is up to you to protect the aide database by moving it off local storage or onto read-only media.

    What errors did you get with the selinux config?

    [Reply]

  3. By jonny on Apr 30, 2008

    Sorry it was not an error - just my own stupidity. I created the database and afterwards copied in the non-selinux config file. Obviously the two did not match after that and I got errors when running –check.
    Rebuilding the database (–init) with the non-selinux conf file sorted it out for me.
    Would you depend solely on this or would you also use a root kit hunter like rkhunter or chkrootkit?
    Thanks for the tips.

    [Reply]

    Jim Perrin reply on April 30th, 2008 10:43 pm, 30 Apr 2008:

    Hey, no worries, we all make mistakes.

    For my webservers, I do a few different things because I’m a fan of layered security. I’ll lay a few out here, and depending on how in-depth you want to go or how many other comments we get I may do a new post detailing it.

    1. make /tmp a separate partition and mount it with the options: noexec, and nodev. This can keep some of the more automated and clumsy attacks from doing anything useful.

    2. for php or other scripting language, move the tmp dir out of /tmp and create a /var/www/tmp or some other such for it. This can keep applications from straying over into other files in /tmp, which may have interesting information in them.

    3. Selinux! aide and chkrootkit are good at letting you know if someone’s broken in, but by then it’s already too late. Keep them from getting in to begin with. Real-world example: http://www.linuxjournal.com/article/9176

    4. Mod_Security. This works wonders for SQL injection and other attacks. It’s very good.

    The rest is just the usual filesystem protections and such.

    [Reply]

    jeffatrackaid reply on May 4th, 2008 6:57 pm, 04 May 2008:

    1. Don’t forget /dev/shm. I make it noexec,nosuid as well.

    3. Chkrootkit is good but I also like rkhunter
    http://www.rootkit.nl/

    5. PHP: Disable functions. I disable some functions in PHP when possible. Especially things like exec, system, etc.

    6. wget/curl/fetch tools. When possible we set these to 700 and owned by root. If end-users need wget I create a “uwget”. This prevents many of the bot-type attacks. Not great but helpful on shared hosting boxes with 100’s of sites managed by the end users.

    [Reply]

  4. By jeffatrackaid on May 4, 2008

    I’ve not used AIDE in quite some time but one thing I did was to setup a cron job to mail me the database each week/month. This way I had an off-server, known good copy of the database.

    [Reply]

Post a Comment