Auditing the System With Auditd and Rsyslogd

Auditing collects data at the kernel level for analysis to identify unauthorized activity. Auditing also often collects data in greater detail than system logging does. The process of examining audit trails to find events of interest can be challenging, but it can be automated.

Some definitions in the audit configuration file, /etc/audit/auditd.conf, include the following:

  • Data retention policy

  • Maximum size of the audit volume

  • Action to take if the capacity of the audit volume is exceeded

  • Locations of local and remote audit trail volumes

The default audit trail volume is the /var/log/audit/audit.log file. For more information, see the auditd.conf(5) manual page.

Creating Audit Rules

Create audit rules in the /etc/audit/audit.rules configuration file to collect more relevant data for analysis.

By default, auditing captures specific events such as system logins, modifications to accounts, and sudo actions. You can configure auditing to capture detailed system call activity and modifications to certain files. The kernel audit daemon (auditd) records the events that you configure, including the event type, a timestamp, the associated user ID, and whether a system call succeeded or failed.

The entries in the audit rules file, /etc/audit/audit.rules, configures which events are audited. Each rule is a command line option that's passed to the auditctl command. Configure this file to match organization's security policy.

The following are examples of rules that can be set in the /etc/audit/audit.rules file:

To record all unsuccessful exits from open and truncate system calls for files and store the information in the /etc directory hierarchy, add the following line:

-a exit,always -S open -S truncate -F /etc -F success=0

To record all files opened by a user with a UID value of 10, add the following line:

-a exit,always -S open -F uid=10

To record all files that have been revised or whose attributes were changed by any user who originally signed in with a UID value of 500 or greater, add the following line:

-a exit,always -S open -F auid>=500 -F perm=wa

To record requests for write or for file attribute change access, you can store the records in the /etc/sudoers file and tag such a record with the string sudoers-change:

-w /etc/sudoers -p wa -k sudoers-change

To record requests for write and for file attribute change access and store records in the /etc directory hierarchy, add the following line:

-w /etc/ -p wa

To require a reboot after changing the audit configuration, add the following line:

-e 2
Note

Defining a rule to reboot at the end of the /etc/audit/audit.rules file is considered good security practice.

For more examples of audit rules, see also the auditctl(8) and audit.rules(7) manual pages.

Generating Audit Reports

Search audit data and and generate audit reports with the ausearch and aureport commands.

Stringent auditing requirements generate large amounts of audit data and can impose a significant performance overhead. Some site security policies stipulate that a system must shut down if events can't be recorded because the audit volumes have exceeded their capacity. Sending auditing data to separate file systems in rotation to prevent overspill and to ease backups is considered good practice.

Tagging audit records can make it more straightforward to search an audit volume by running the ausearch command and referring to those tags. For example, to examine records that are tagged with the string sudoers-change, run the following command:

sudo ausearch -k sudoers-change

The aureport command generates summaries of audit data. For example, the following command generates a report that shows every sign-in event from 1 second after midnight on the previous day until the current time:

sudo aureport -l -i -ts yesterday -te now

For more information, see the ausearch(8) and aureport(8) manual pages.

You can also set up cron jobs or systemd timers that run aureport periodically to generate reports of interest. For more information about scheduling those tasks, see Oracle Linux 8: Automating System Tasks With cron, Oracle Linux 9: Automating System Tasks With cron, and Oracle Linux 10: Automating System Tasks With cron, and Managing the System With systemd.