The software described in this documentation is either in Extended Support or Sustaining Support. See https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdf for more information.
Oracle recommends that you upgrade the software described by this documentation as soon as possible.
Auditing collects data at the kernel level that you can analyze to identify unauthorized activity. Auditing collects more data in greater detail than system logging, but most audited events are uninteresting and insignificant. The process of examining audit trails to locate events of interest can be a significant challenge that you will probably need to automate.
The audit configuration file,
/etc/audit/auditd.conf
, defines the data
retention policy, the maximum size of the audit volume, the action
to take if the capacity of the audit volume is exceeded, and the
locations of local and remote audit trail volumes. The default
audit trail volume is /var/log/audit/audit.log
.
For more information, see the auditd.conf(5)
manual page.
By default, auditing captures specific events such as system
logins, modifications to accounts, and sudo
actions. You can also configure auditing to capture detailed
system call activity or modifications to certain files. The kernel
audit daemon (auditd
) records the events that
you configure, including the event type, a time stamp, the
associated user ID, and success or failure of the system call.
The entries in the audit rules file,
/etc/audit/audit.rules
, determine which events
are audited. Each rule is a command-line option that is passed to
the auditctl command. You should typically
configure this file to match your site's security policy.
The following are examples of rules that you might set in the
/etc/audit/audit.rules
file.
Record all unsuccessful exits from open
and
truncate
system calls for files in the
/etc
directory hierarchy.
-a exit,always -S open -S truncate -F /etc -F success=0
Record all files opened by a user with UID 10.
-a exit,always -S open -F uid=10
Record all files that have been written to or that have their attributes changed by any user who originally logged in with a UID of 500 or greater.
-a exit,always -S open -F auid>=500 -F perm=wa
Record requests for write or file attribute change access to
/etc/sudoers
, and tag such record with the
string sudoers-change
.
-w /etc/sudoers -p wa -k sudoers-change
Record requests for write and file attribute change access to the
/etc
directory hierarchy.
-w /etc/ -p wa
Require a reboot after changing the audit configuration. If
specified, this rule should appear at the end of the
/etc/audit/audit.rules
file.
-e 2
You can find more examples of audit rules in
/usr/share/doc/audit-
,
and in the version
/stig.rulesauditctl(8)
and
audit.rules(7)
manual pages.
Stringent auditing requirements can impose a significant performance overhead and generate large amounts of audit data. Some site security policies stipulate that a system must shut down if events cannot be recorded because the audit volumes have exceeded their capacity. As a general rule, you should direct audit data to separate file systems in rotation to prevent overspill and to facilitate backups.
You can use the -k option to tag audit records
so that you can locate them more easily in an audit volume with
the ausearch command. For example, to examine
records tagged with the string sudoers-change
,
you would enter:
# ausearch -k sudoers-change
The aureport command generates summaries of
audit data. You can set up cron
jobs that run
aureport periodically to generate reports of
interest. For example, the following command generates a reports
that shows every login event from 1 second after midnight on the
previous day until the current time:
# aureport -l -i -ts yesterday -te now
For more information, see the ausearch(8)
and
aureport(8)
manual pages.