System auditing simply refers to in-depth analysis of a specific targeted system: an audit is made up of an examination of the various parts which comprise that system, with critical assessment (and testing if required) in different areas of interest.
Read Also: Lynis – Security Auditing and Scanning Tool for Linux Systems
One of the critical subsystems on RHEL/CentOS the Linux audit system commonly known as auditd. It implements a means to track security-relevant information on a system: it uses pre-configured rules to collect vast amounts of information about events that are happening on the system, and records them in a log file, thus creating an audit trial.
It can record information such as date and time, type, and result of an event; users who caused the event, any modifications made to files/databases; uses of system authentication mechanisms, such as PAM, LDAP, SSH, and others.
Auditd also registers any changes made to the audit configuration files or any attempts to access audit log files, and any efforts to import or export information into or from the system plus a lot of other security-related information.
The audit system has two core components, namely:
The most important part is the user-space audit daemon (auditd) which gathers information based on pre-configured rules, from the kernel and generates entries in a log file: the default log is /var/log/audit/audit.log.
Additionally, the audispd (audit dispatcher daemon) is an event multiplexor that interacts with auditd and sends events to other programs that want to perform real time event processing.
There are a number of user-space tools for managing and retrieving information from the audit system:
First make sure to verify that the audit tool is installed on your system using the rpm command and grep utility as follows:
# rpm -qa | grep audit
If you do not have the above packages installed, run this command as the root user to install them.
# yum install audit
Next, check if auditd is enabled and running, issue the systemctl commands below on the terminal.
--------------- On CentOS/RHEL 7 --------------- # systemctl is-enabled auditd # systemctl status auditd # systemctl start auditd [Start] # systemctl enable auditd [Enable] --------------- On CentOS/RHEL 6 --------------- # service auditd status # service auditd start [Start] # chkconfig auditd on [Enable]
Now we will see how to configure auditd using the main configuration file /etc/audit/auditd.conf. The parameters here allow you to control how the service runs, such as defining the location of the log file, maximum number of log files, log format, how to deal with full disks, log rotation and many more options.
# vi /etc/audit/auditd.conf
From the sample output below, the parameters are self-explanatory.
As we mentioned earlier on, auditd uses rules to gather specific information from the kernel. These rules are basically auditctl options (see man page) that you can pre-configure rules in the /etc/audit/rules.d/audit.rules file (On CentOS 6, use the /etc/audit/audit.rules file), so that they are loaded at startup.
There are three kinds of audit rules you can define:
Now open the main configuration file for editing:
# vi /etc/audit/rules.d/audit.rules
Note that the first section of this file must contain control rules. Then add your audit rules (file watches and system call rules) in the middle section, and finally the last section contains immutability settings which are also control rules.
-D #removes all previous rules -b 3074 #define buffer size -f 4 #panic on failure -r 120 #create at most 120 audit messages per second
You can define file watches using this syntax:
-w /path/to/file/or/directory -p permissions -k key_name
Where the option:
These rules allow auditing to watch events making changes to these critical system files.
-w /etc/passwd -p wa -k passwd_changes -w /etc/group -p wa -k group_changes -w /etc/shadow -p wa -k shadow_changes -w /etc/sudoers -p wa -k sudoers_changes
You can set a system call rule using the form below:
-a action,filter -S system_call -F field=value -k key_name
where:
Here are some rules you can define.
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change -a always,exit -S sethostname -S setdomainname -k system_locale
Then lastly add the immutability settings at the end of the file, for example:
-e 1 #enable auditing -e 2 #make the configuration immutable -- reboot is required to change audit rules
Alternatively, send the options to auditd while it’s running, using the auditctl as in the following examples. These commands can override rules in the configuration file.
To list all currently loaded audit rules, pass the -l
flag:
# auditctl -l
Next, try to add a few rules:
# auditctl -w /etc/passwd -p wa -k passwd_changes # auditctl -w /etc/group -p wa -k group_changes # auditctl -w /etc/sudoers -p wa -k sudoers_changes # auditctl -l
All audit messages are recorded in /var/log/audit/audit.log file by default. To understand the log entry format, we’ll load a rule and check the log entry generated after an event matching the rule.
Assuming we have a secret backups directory, this audit rule will log any attempts to access or modify this directory:
# auditctl -w /backups/secret_files/ -p rwa -k secret_backup
Now, using another system account, try to move into the directory above and run the ls command:
$ cd /backups/secret_files/ $ ls
The log entry will look like so.
The above event is made up of three types of audit records. The first is type=SYSCALL:
type=SYSCALL msg=audit(1505784331.849:444): arch=c000003e syscall=257 success=yes exit=3 a0=ffffffffffffff9c a1=8ad5c0 a2=90800 a3=0 items=1 ppid=2191 pid=2680 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="secret_backup"
The second is type=CWD.
type=CWD msg=audit(1505784331.849:444): cwd="/backups/secret_files"
And the last one is type=PATH:
type=PATH msg=audit(1505784331.849:444): item=0 name="." inode=261635 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 objtype=NORMAL
You can find a complete list of all the event fields (such as msg, arch, ses etc..) and their meanings in the Audit System Reference.
That’s all for now. In the next article, we will look at how to use ausearch to query audit log files: we will explain how to search for specific information from the audit logs. If you have any questions, please reach us via the comment section below.
Article Number: 535
Posted: Fri, Apr 5, 2019 12:49 PM
Last Updated: Fri, Apr 5, 2019 12:49 PM
Online URL: http://kb.ictbanking.net/article.php?id=535