Sunday, May 23, 2010

CentOS 5 and AIDE

SkyHi @ Sunday, May 23, 2010

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/ /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:


/usr/sbin/aide --check | /bin/mail -s "Weekly Aide Data"

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-*/


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.


#cat /etc/aide.conf

# Example configuration file for AIDE.

@@define DBDIR /var/lib/aide
@@define LOGDIR /var/log/aide

# The location of the database to be read.

# The location of the database to be written.

# Whether to gzip the output to database

# Default.

#NOT IMPLEMENTED report_url=syslog:LOG_AUTH

# These are the default rules.
#p: permissions
#i: inode:
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#acl: Access Control Lists
#selinux SELinux security context
#xattrs: Extended file attributes
#S: check for growing size
#md5: md5 checksum
#sha1: sha1 checksum
#sha256: sha256 checksum
#sha512: sha512 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum

#haval: haval checksum (MHASH only)
#gost: gost checksum (MHASH only)
#crc32: crc32 checksum (MHASH only)
#whirlpool: whirlpool checksum (MHASH only)

#R: p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5
#L: p+i+n+u+g+acl+selinux+xattrs
#E: Empty group
#>: Growing logfile p+u+g+i+n+S+acl+selinux+xattrs

# You can create custom rules like this.
# With MHASH...
# ALLXTRAHASHES = sha1+rmd160+sha256+sha512+whirlpool+tiger+haval+gost+crc32
ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger
# Everything but access time (Ie. all changes)
EVERYTHING = p+i+n+u+g+s+m+c+acl+xattrs+md5+ALLXTRAHASHES

# Sane, with multiple hashes
# NORMAL = R+rmd160+sha256+whirlpool
NORMAL = p+i+n+u+g+s+m+c+acl+xattrs+md5+rmd160+sha256

# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+xattrs

# Access control only
PERMS = p+i+u+g+acl

# Logfile are special, in that they often change
LOG = p+u+g+i+n+S+acl+xattrs

# Just do md5 and sha256 hashes
LSPP = p+i+n+u+g+s+m+c+acl+xattrs+md5+sha256

# Some files get updated automatically, so the inode/ctime/mtime change
# but we want to know when the data inside them changes
DATAONLY = p+n+u+g+s+acl+xattrs+md5+sha256+rmd160+tiger

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

/boot NORMAL
/sbin NORMAL
/root NORMAL
# These are too volatile

# Check only permissions, inode, user and group for /etc, but
# cover some important files closely.
/etc PERMS
# Ignore backup files
/etc/exports NORMAL
/etc/fstab NORMAL
/etc/passwd NORMAL
/etc/group NORMAL
/etc/gshadow NORMAL
/etc/shadow NORMAL
/etc/security/opasswd NORMAL

/etc/hosts.allow NORMAL
/etc/hosts.deny NORMAL

/etc/sudoers NORMAL
/etc/skel NORMAL

/etc/logrotate.d NORMAL

/etc/resolv.conf DATAONLY

/etc/nscd.conf NORMAL
/etc/securetty NORMAL

# Shell/X starting files
/etc/profile NORMAL
/etc/bashrc NORMAL
/etc/bash_completion.d/ NORMAL
/etc/login.defs NORMAL
/etc/zprofile NORMAL
/etc/zshrc NORMAL
/etc/zlogin NORMAL
/etc/zlogout NORMAL
/etc/profile.d/ NORMAL
/etc/X11/ NORMAL

# Pkg manager
/etc/yum.conf NORMAL
/etc/yumex.conf NORMAL
/etc/yumex.profiles.conf NORMAL
/etc/yum/ NORMAL
/etc/yum.repos.d/ NORMAL

/var/log LOG
# This gets new/removes-old filenames daily
# As we are checking it, we've truncated yesterdays size to zero.

# LSPP rules...
# AIDE produces an audit record, so this becomes perpetual motion.
# /var/log/audit/ LSPP
/etc/audit/ LSPP
/etc/libaudit.conf LSPP
/usr/sbin/stunnel LSPP
/var/spool/at LSPP
/etc/at.allow LSPP
/etc/at.deny LSPP
/etc/cron.allow LSPP
/etc/cron.deny LSPP
/etc/cron.d/ LSPP
/etc/cron.daily/ LSPP
/etc/cron.hourly/ LSPP
/etc/cron.monthly/ LSPP
/etc/cron.weekly/ LSPP
/etc/crontab LSPP
/var/spool/cron/root LSPP

/etc/login.defs LSPP
/etc/securetty LSPP
/var/log/faillog LSPP
/var/log/lastlog LSPP

/etc/hosts LSPP
/etc/sysconfig LSPP

/etc/inittab LSPP
# Grub isn't in LSPP, but pretend it is
/etc/grub/ LSPP
/etc/rc.d LSPP

/etc/ LSPP

/etc/localtime LSPP

/etc/sysctl.conf LSPP

/etc/modprobe.conf LSPP

/etc/pam.d LSPP
/etc/security LSPP
/etc/aliases LSPP
/etc/postfix LSPP

/etc/ssh/sshd_config LSPP
/etc/ssh/ssh_config LSPP

/etc/stunnel LSPP

/etc/vsftpd.ftpusers LSPP
/etc/vsftpd LSPP

/etc/issue LSPP
/etc/ LSPP

/etc/cups LSPP

# With AIDE's default verbosity level of 5, these would give lots of
# warnings upon tree traversal. It might change with future version.
#=/lost\+found DIR
#=/home DIR

# Dito /var/log/sa reason...

  1. By Jim Perrin on Apr 30, 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:

    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.

By jeffatrackaid on May 4, 2008

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

3. Chkrootkit is good but I also like rkhunter

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.