create new tag
view all tags

Using the LCFG auditd component

To use the LCFG auditd component you will want to add the following to your LCFG profile:

#include <lcfg/options/auditd.h>

Configuring the rules

By default there is no value set for the auditd.rulestmpl resource, this means that the auditd rules file (as specified in the auditd.rulesfile resource) is not managed. The auditd package provides a minimalist default file which ensures the daemon starts but does not do anything else. In that state you will get basic logging of events such as login and logout and not much more.

The lcfg-auditd package provides one template which was designed to suit the requirements of the School of Informatics. It might do what you want, if not it is still a useful guide to what can be monitored. To use this template set the following in your LCFG profile:

!auditd.rulestmpl        mSET(/usr/lib/lcfg/conf/auditd/audit.rules.tt)

The template is written using the Perl Template Toolkit.

The first interesting section adds monitoring to various parts of the filesystem

-w /bin -p wa -k FS_mod
-w /boot -p wa -k FS_mod
-w /etc -p wa -k FS_mod
-w /lib -p wa -k FS_mod
-w /lib64 -p wa -k FS_mod
-w /sbin -p wa -k FS_mod
-w /usr -p wa -k FS_mod

This means that a record will be taken of every time anything attempts to modify a file or directory (at any depth) within each of those directories.

Note that it is not possible to add monitoring at the top-level (root) of the filesystem and that would probably generate far too much information if you could.

Each event in this case will have a key of FS_mod associated which makes it easy to search for the events later like this (as root):

/sbin/ausearch --key FS_mod --start yesterday

Note that if you have recently run updaterpms you might get a huge number of events recorded.

The usual route for an attacker to compromise a system is through an executable file which is setuid root. With this in mind the auditd component has the ability to scan the filesystem at boot-time to find all installed setuid files. This scan is done when the auditd.suid_scan resource is set to true. The contents of all directories specified in the auditd.suid_scan_dirs resource will be scanned for setuid files but note that filesystem boundaries will not be crossed (stays in same partition). All setuid files found are stored in the file /var/lcfg/conf/auditd/watch_suid_files.rules which is included in the main rules file like this:

[% if suid_scan %]
# Watch for any executions of various suid binaries

[% insert /var/lcfg/conf/auditd/watch_suid_files.rules %]
[% end %]

When an attacker has compromised a system and gained root access it is common for them to insert a kernel module which can be used to gather sensitive data and cover their tracks. With this in mind, another interesting chunk of configuration is:

-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b32 -S init_module -S delete_module -k modules
[%- if arch == 'x86_64' %]
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules
[%- end %]

This monitors for all attempts to change the installed kernel modules, all events recorded have a key named modules attached. It does this in two ways, firstly it uses the basic filesystem checks to record every time that the insmod, rmmod or modprobe scripts are run. Secondly, it looks for usage of the system calls init_module and delete_module which would be used if an attacker had their own script. Note that on x86_64 it is usually necessary to add separate checks for both 32bit and 64bit system calls.

There are various other ways to setup rules, see the audit.rules(7) manual page for full details. Note that to add new rules you have to create your templates the auditd component does not have direct support through LCFG resources for adding rules to a configuration.

Locking the Configuration

Once the rules are in place it makes sense to lock the configuration into the kernel so that it cannot be changed without a reboot. This prevents an attacker just simply deleting all rules once they have compromised your system. This can be done quite simply using the auditd.enable resource, like this:

!auditd.enable           mSET(lockon)

Report Scripts

Associated with the rules template are a number of scripts which can be used to generate regular reports of the events recorded.

The scripts can be added as a single cron job. All reports are sent to stdout so this will form the contents of a single email sent to wherever mail to the root user normally goes.

!cron.additions                   mADD(auditd_reports)
cron.add_auditd_reports           5 0 * * * AUDITD_SCRIPTSDIR/unowned_changed_files; AUDITD_SCRIPTSDIR/suid_usage; \
                                                               AUDITD_SCRIPTSDIR/kmod_changes; AUDITD_SCRIPTSDIR/list_reboots

All these scripts support the --start option which defaults to 'yesterday' and the --end option which defaults to 'today', this gives a report period of 00:00 through to 23:59 for the previous day. See the ausearch(8) manual page for full details on all the different time period specifiers that are supported.

1. kmod_changes

This will report all events in the required period which are associated with attempts to insert or delete kernel modules (modules key).

2. list_reboots

This will report all events in the required period which are associated with a system reboot.

3. suid_usage

This will report all events in the required period which are associated with usage of setuid root scripts (FS_suid key).

4. unowned_changed_files

This will report on all events where monitored files have changed (FS_mod key) and the files are not owned by any RPM. This massively reduces the size of the report when regular updates are applied. In our experience attackers do not modify files which are provided by RPMs, instead they insert new directories and files into the filesystem.

Log Rotation

You will need to regularly rotate log files, thankfully auditd has built-in support for rotating log files based on the size. This can be done fairly easily:

!auditd.max_log_file_action       mSET(ROTATE)
!auditd.max_log_file              mSET(100) /* MB */
!auditd.num_logs                  mSET(45)

This means that when the size of a log reaches 100MB it will be rotated and once 45 log files have been created the oldest files will be deleted. This will help avoid running out of disk space which could take down your system. It is recommended that you store audit logs in a separate partition to avoid completely depriving your system of disk space, just in case.

This clearly introduces the possibility of an attacker hiding some of their activity by generating enormous numbers of records, but if they have root access they could alternatively just delete the files... If any of that is a concern for you then you should investigate logging the events to a remote server with lots of disk space.

If you want to be informed when space is getting tight you can get auditd to send you an email like this:

!auditd.action_mail_acct          mSETQ('you@example.org');

!auditd.space_left                mSET(500) /* MB */
!auditd.space_left_action         mSET(EMAIL)

!auditd.admin_space_left          mSET(200) /* MB */
!auditd.admin_space_left_action   mSET(EMAIL)

Care has to be taken with using this chunk of configuration. We have seen problems with this since auditd insists on validating the email address at start time, if your networking is not up and fully configured when you attempt to start the auditd then it will fail.

-- Main.squinney - 2013-02-28

Topic revision: r1 - 2013-02-28 - squinney
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback