44 Introducing an audit rule set #
The following example configuration illustrates how audit can be used to monitor your system. It highlights the most important items that need to be audited to cover the list of auditable events specified by Controlled Access Protection Profile (CAPP).
The example rule set is divided into the following sections:
Basic audit configuration (see Section 44.1, “Adding basic audit configuration parameters”)
Watches on audit log files and configuration files (see Section 44.2, “Adding watches on audit log files and configuration files”)
Monitoring operations on file system objects (see Section 44.3, “Monitoring file system objects”)
Monitoring security databases (see Section 44.4, “Monitoring security configuration files and databases”)
Monitoring miscellaneous system calls (Section 44.5, “Monitoring miscellaneous system calls”)
Filtering system call arguments (see Section 44.6, “Filtering system call arguments”)
To transform this example into a configuration file to use in your live setup, proceed as follows:
Choose the appropriate settings for your setup and adjust them.
Adjust the file
/etc/audit/audit.rulesby adding rules from the examples below or by modifying existing rules.
Do not copy the example below into your audit setup without adjusting it to your needs. Determine what and to what extent to audit.
The entire audit.rules is a collection of
auditctl commands. Every line in this file expands to a
full auditctl command line. The syntax used in the rule
set is the same as that of the auditctl command.
44.1 Adding basic audit configuration parameters #
-D1 -b 81922 -f 23
Delete any preexisting rules before starting to define new ones. | |
Set the number of buffers to take the audit messages. Depending on the level of audit logging on your system, increase or decrease this figure. | |
Set the failure flag to use when the kernel needs to handle critical
errors. Possible values are |
By emptying the rule queue with the -D option, you make
sure that audit does not use any other rule set than what you are
offering it by means of this file. Choosing an appropriate buffer number
(-b) is vital to avoid having your system fail because
of too high an audit load. Choosing the panic failure flag -f
2 ensures that your audit records are complete even if the
system is encountering critical errors. By shutting down the system on a
critical error, audit makes sure that no process escapes from its control
as it otherwise might if level 1 (printk) were chosen.
Before using your audit rule set on a live system, make sure that the
setup has been thoroughly evaluated on test systems using the
worst case production workload. It is even more
critical that you do this when specifying the -f 2
flag, because this instructs the kernel to panic (perform an immediate
halt without flushing pending data to disk) if any thresholds are
exceeded. Consider the use of the -f 2 flag for only
the most security-conscious environments.
44.2 Adding watches on audit log files and configuration files #
Adding watches on your audit configuration files and the log files themselves ensures that you can track any attempt to tamper with the configuration files or detect any attempted accesses to the log files.
Creating watches on a directory is not necessarily sufficient if you need events for file access. Events on directory access are only triggered when the directory's inode is updated with metadata changes. To trigger events on file access, add watches for each file to monitor.
-w /var/log/audit/ 1 -w /var/log/audit/audit.log -w /var/log/audit/audit_log.1 -w /var/log/audit/audit_log.2 -w /var/log/audit/audit_log.3 -w /var/log/audit/audit_log.4 -w /etc/audit/auditd.conf -p wa2 -w /etc/audit/audit.rules -p wa -w /etc/libaudit.conf -p wa
Set a watch on the directory where the audit log is located. Trigger an event for any type of access attempt to this directory. If you are using log rotation, add watches for the rotated logs as well. | |
Set a watch on an audit configuration file. Log all write and attribute change attempts to this file. |
44.3 Monitoring file system objects #
Auditing system calls helps track your system's activity well beyond the application level. By tracking file system–related system calls, get an idea of how your applications are using these system calls and determine whether that use is appropriate. By tracking mount and unmount operations, track the use of external resources (removable media, remote file systems, etc.).
Auditing system calls results in a high logging activity. This activity, in turn, puts a heavy load on the kernel. With a kernel less responsive than usual, the system's backlog and rate limits might be exceeded. Carefully evaluate which system calls to include in your audit rule set and adjust the log settings accordingly. See Section 42.2, “Configuring the audit daemon” for details on how to tweak the relevant settings.
-a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown321 -a entry,always -S creat -S open -S truncate -S truncate64 -S ftruncate -S ftruncate642 -a entry,always -S mkdir -S rmdir3 -a entry,always -S unlink -S rename -S link -S symlink4 -a entry,always -S setxattr5 -a entry,always -S lsetxattr -a entry,always -S fsetxattr -a entry,always -S removexattr -a entry,always -S lremovexattr -a entry,always -S fremovexattr -a entry,always -S mknod6 -a entry,always -S mount -S umount -S umount27
Enable an audit context for system calls related to changing file
ownership and permissions. Depending on the hardware architecture of
your system, enable or disable the | |
Enable an audit context for system calls related to file content modification. Depending on the hardware architecture of your system, enable or disable the *64 rules. 64-bit systems, like AMD64/Intel 64, require the *64 rules to be removed. | |
Enable an audit context for any directory operation, like creating or removing a directory. | |
Enable an audit context for any linking operation, such as creating a symbolic link, creating a link, unlinking, or renaming. | |
Enable an audit context for any operation related to extended file system attributes. | |
Enable an audit context for the | |
Enable an audit context for any mount or umount operation. For the
x86 architecture, disable the |
44.4 Monitoring security configuration files and databases #
To make sure that your system is not made to do undesired things, track
any attempts to change the cron and
at configurations or the lists of scheduled
jobs. Tracking any write access to the user, group, password and login
databases and logs helps you identify any attempts to manipulate your
system's user database.
Tracking changes to your system configuration (kernel, services, time, etc.) helps you spot any attempts of others to manipulate essential functionality of your system. Changes to the PAM configuration should also be monitored in a secure environment, because changes in the authentication stack should not be made by anyone other than the administrator, and it should be logged which applications are using PAM and how it is used. The same applies to any other configuration files related to secure authentication and communication.
1 -w /var/spool/atspool -w /etc/at.allow -w /etc/at.deny -w /etc/cron.allow -p wa -w /etc/cron.deny -p wa -w /etc/cron.d/ -p wa -w /etc/cron.daily/ -p wa -w /etc/cron.hourly/ -p wa -w /etc/cron.monthly/ -p wa -w /etc/cron.weekly/ -p wa -w /etc/crontab -p wa -w /var/spool/cron/root 2 -w /etc/group -p wa -w /etc/passwd -p wa -w /etc/shadow -w /etc/login.defs -p wa -w /etc/securetty -w /var/log/lastlog 3 -w /etc/hosts -p wa -w /etc/sysconfig/ w /etc/init.d/ w /etc/ld.so.conf -p wa w /etc/localtime -p wa w /etc/sysctl.conf -p wa w /etc/modprobe.d/ w /etc/modprobe.conf.local -p wa w /etc/modprobe.conf -p wa 4 w /etc/pam.d/ 5 -w /etc/aliases -p wa -w /etc/postfix/ -p wa 6 -w /etc/ssh/sshd_config -w /etc/stunnel/stunnel.conf -w /etc/stunnel/stunnel.pem -w /etc/vsftpd.ftpusers -w /etc/vsftpd.conf 7 -a exit,always -S sethostname -w /etc/issue -p wa -w /etc/issue.net -p wa
Set watches on the | |
Set watches on the user, group, password, and login databases and logs and set labels to better identify any login-related events, such as failed login attempts. | |
Set a watch and a label on the static host name configuration in
| |
Set watches on the PAM configuration directory. If you are interested in particular files below the directory level, add explicit watches to these files as well. | |
Set watches to the postfix configuration to log any write attempt or attribute change and use labels for better tracking in the logs. | |
Set watches and labels on the SSH,
| |
Perform an audit of the |
44.5 Monitoring miscellaneous system calls #
Apart from auditing file system related system calls, as described in
Section 44.3, “Monitoring file system objects”, you can also track various other
system calls. Tracking task creation helps you understand your
applications' behavior. Auditing the umask
system call lets you track how processes modify creation mask. Tracking
any attempts to change the system time helps you identify anyone or any
process trying to manipulate the system time.
1 -a entry,always -S clone -S fork -S vfork 2 -a entry,always -S umask 3 -a entry,always -S adjtimex -S settimeofday
44.6 Filtering system call arguments #
In addition to the system call auditing introduced in Section 44.3, “Monitoring file system objects” and Section 44.5, “Monitoring miscellaneous system calls”, you can track application behavior to an even higher degree. Applying filters helps you focus audit on areas of primary interest to you. This section introduces filtering system call arguments for non-multiplexed system calls like access and for multiplexed ones like socketcall or ipc. Whether system calls are multiplexed depends on the hardware architecture used. Both socketcall and ipc are not multiplexed on 64-bit architectures, such as AMD64/Intel 64.
Auditing system calls results in high logging activity, which in turn puts a heavy load on the kernel. With a kernel less responsive than usual, the system's backlog and rate limits might well be exceeded. Carefully evaluate which system calls to include in your audit rule set and adjust the log settings accordingly. See Section 42.2, “Configuring the audit daemon” for details on how to tweak the relevant settings.
The access system call checks whether a process would be allowed to read,
write or test for the existence of a file or file system object. Using
the -F filter flag, build rules matching specific access
calls in the format-F
a1=ACCESS_MODE. Check
/usr/include/fcntl.h for a list of possible
arguments to the access system call.
-a entry,always -S access -F a1=41 -a entry,always -S access -F a1=62 -a entry,always -S access -F a1=73
Audit the access system call, but only if the second argument of the
system call ( | |
Audit the access system call, but only if the second argument of the
system call ( | |
Audit the access system call, but only if the second argument of the
system call ( |
The socketcall system call is a multiplexed system call. Multiplexed
means that there is only one system call for all possible calls and that
libc passes the actual system call to use as the first argument
(a0). Check the manual page of socketcall for possible
system calls and refer to
/usr/src/linux/include/linux/net.h for a list of
possible argument values and system call names. Audit supports filtering
for specific system calls using a -F
a0=SYSCALL_NUMBER.
-a entry,always -S socketcall -F a0=1 -F a1=101 ## Use this line on x86_64, ia64 instead #-a entry,always -S socket -F a0=10 -a entry,always -S socketcall -F a0=52 ## Use this line on x86_64, ia64 instead #-a entry, always -S accept
Audit the socket(PF_INET6) system call. The | |
Audit the socketcall system call. The filter flag is set to filter for
|
The ipc system call is another example of multiplexed system calls. The
actual call to invoke is determined by the first argument passed to the
ipc system call. Filtering for these arguments helps you focus on those
IPC calls of interest to you. Check
/usr/include/linux/ipc.h for possible argument
values.
1 ## msgctl -a entry,always -S ipc -F a0=14 ## msgget -a entry,always -S ipc -F a0=13 ## Use these lines on x86_64, ia64 instead #-a entry,always -S msgctl #-a entry,always -S msgget 2 ## semctl -a entry,always -S ipc -F a0=3 ## semget -a entry,always -S ipc -F a0=2 ## semop -a entry,always -S ipc -F a0=1 ## semtimedop -a entry,always -S ipc -F a0=4 ## Use these lines on x86_64, ia64 instead #-a entry,always -S semctl #-a entry,always -S semget #-a entry,always -S semop #-a entry,always -S semtimedop ## shmctl -a entry,always -S ipc -F a0=24 ## shmget -a entry,always -S ipc -F a0=23 ## Use these lines on x86_64, ia64 instead #-a entry,always -S shmctl #-a entry,always -S shmget
Audit system calls related to IPC SYSV message queues. In this case,
the | |
Audit system calls related to IPC SYSV message semaphores. In this
case, the | |
Audit system calls related to IPC SYSV shared memory. In this case, the
|
44.7 Managing audit event records using keys #
After configuring a few rules generating events and populating the logs,
you need to find a way to tell one event from the other. Using the
ausearch command, you can filter the logs for various
criteria. Using ausearch -m
MESSAGE_TYPE, you can at least filter
for events of a certain type. However, to be able to filter for events
related to a particular rule, you need to add a key to this rule in the
/etc/audit/audit.rules file. This key is then added
to the event record every time the rule logs an event. To retrieve these
log entries, simply run ausearch -k
YOUR_KEY to get a list of records
related to the rule carrying this particular key.
As an example, assume you have added the following rule to your rule file:
-w /etc/audit/audit.rules -p wa
Without a key assigned to it, you would probably need to filter for
SYSCALL or PATH events then use
grep or similar tools to isolate any events related to the above rule.
Now, add a key to the above rule, using the -k option:
-w /etc/audit/audit.rules -p wa -k CFG_audit.rules
You can specify any text string as key. Distinguish watches related to
different types of files (configuration files or log files) from one
another using different key prefixes (CFG,
LOG, etc.) followed by the file name. Finding any
records related to the above rule now comes down to the following:
ausearch -k CFG_audit.rules
----
time->Thu Feb 19 09:09:54 2009
type=PATH msg=audit(1235030994.032:8649): item=3 name="audit.rules~" inode=370603 dev=08:06 mode=0100640 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=2 name="audit.rules" inode=370603 dev=08:06 mode=0100640 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=1 name="/etc/audit" inode=368599 dev=08:06 mode=040750 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=0 name="/etc/audit" inode=368599 dev=08:06 mode=040750 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1235030994.032:8649): cwd="/etc/audit"
type=SYSCALL msg=audit(1235030994.032:8649): arch=c000003e syscall=82 success=yes exit=0 a0=7deeb0 a1=883b30 a2=2 a3=ffffffffffffffff items=4 ppid=25400 pid=32619 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="vim" exe="/bin/vim-normal" key="CFG_audit.rules"