The Linux Audit system provides fine-grained logging of security related events. The system administrator configures rules to specify what events are logged. For example, rules may be configured for logging of:
access of a specific file or directory,
specific system calls,
commands executed by a user,
authentication events, or
The Audit system architecture includes:
a kernel component which generates events,
auditddaemon which collects events from the kernel component and writes them to a log file,
audispdispatcher daemon which relays events to other applications for additional processing, and
auditctlcontrol utility which provides configuration of the kernel component.
These tools are provided for reading the Audit log files:
aulastprints out a listing of the last logged in users,
aulastlogprints out the last login for all users of a machine,
aureportproduces summary reports of the Audit logs,
ausearchsearches Audit logs for events fitting given criteria, and
auvirtprints a list of virtual machine sessions found in the Audit logs.
The Audit system generates events according to Audit rules. These rules can
be set dynamically with auditctl or stored persistently in
/etc/audit/rules.d. Persistent rule files in
automatically compiled to
/etc/audit/audit.rules when auditd is initialized.
There are three types of rules: a control rule modifies Audit’s behavior, a file system rule watches a file or directory, and a system call rule generates a log event for a particular system call. For more details about Audit rules, see the Defining Audit Rules page of the Red Hat Enterprise Linux Security Guide.
Common control rules include the following.
-b backlog: Set the maximum number of audit buffers. This should be higher for busier systems or for heavy log volumes.
-D: Delete all rules and watches. Normally used as the first rule.
-e [0..2]: Temporarily disable auditing with
0, enable it with
1, or lock the configuration until the next reboot with
2(used as the last rule).
This is a set of basic rules, some form of which is likely to be found in any ruleset.
# Delete all rules (normally used first) -D # Increase buffers from default 64 -b 320 # Lock Audit rules until reboot (used last) -e 2
To create a file system rule, use
-w path -p permissions -k
pathargument defines the file or directory to be watched.
permissionsargument sets the kinds of accesses that are logged, and is a string containing one or more of
x(execute access), and
key_nameargument is an optional tag for identifying the rule.
This rule watches
/etc/passwd for modifications and tags these events with
-w /etc/passwd -p wa -k passwd
To create a system call rule, use
-a action,filter -S system_call
-F field=value -k key_name.
actionargument can be either
always(to generate a log entry) or
never(to suppress a log entry). Generally, use
alwaysrules, because rules are matched from first to last.
filterargument is one of
task(when a task is created),
exit(when a system call exits),
user(when a call originates from user space) or
exclude(to filter events).
system_callargument specifies the system call by name, and can be repeated by using multiple
field=valuepair can be used to specify additional match options, and can also be used more than once.
key_nameargument is an optional tag for identifying the rule.
This rule generates a log entry when the system time is changed.
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k system_time
System call rules can also monitor activities around files, such as:
access, permission, and owner modifications.
This rule generates a log entry when a file is deleted with the
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
External connections can be monitored with the example below.
This rule checks whether an incoming or outgoing external network connection has been established.
-a always,exit -F arch=b64 -S accept,connect -F key=external-access
The different types of rules are combined to form a ruleset.
This is a simple Audit ruleset based on the above examples.
# Delete all rules -D # Increase buffers from default 64 -b 320 # Watch /etc/passwd for modifications and tag with 'passwd' -w /etc/passwd -p wa -k passwd # Generate a log entry when the system time is changed -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k system_time # Lock Audit rules until reboot -e 2
For more examples of rules see the The Linux Audit Project on GitHub.
NXLog Enterprise Edition includes an im_linuxaudit module for directly accessing the kernel component of the Audit System. With this module, NXLog can be configured to configure Audit rules and collect logs without requiring auditd or any other userspace software.
|If an im_linuxaudit module instance is suspended and the Audit backlog limit is exceeded, all processes that generate Audit messages will be blocked. For this reason, it is recommended for most cases that FlowControl be disabled for im_linuxaudit module instances. With flow control disabled, a blocked route will cause Audit messages to be discarded. To reduce the risk of log data being discarded, make sure the route’s processing is fast enough to handle the Audit messages by adjusting the LogQueueSizes of the following modules and/or adding a pm_buffer instance.|
This configuration uses a
<Rules> block to specify a rule set.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <Input audit> Module im_linuxaudit FlowControl FALSE <Rules> # Delete all rules (This rule has no affect; it is performed # automatically by im_linuxaudit) -D # Increase buffers from default 64 -b 320 # Watch /etc/passwd for modifications and tag with 'passwd' -w /etc/passwd -p wa -k passwd # Generate a log entry when the system time is changed -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k system_time # Lock Audit rules until reboot -e 2 </Rules> </Input>
This configuration is the same as the previous, but it uses a separate rules
file. The referenced
audit.rules file is identical to the one shown in the
above example, but it is stored in a different location
(because auditd is not required).
First, the Audit userspace components must be installed and configured.
Install the Audit package. Include the
audispd-pluginspackage if required for use with audispd (see the Collecting via Network With audispd section below).
# yum install audit
# apt-get install auditd
Configure Auditd by editing the
/etc/audit/auditd.confconfiguration file, which contains parameters for auditd. See the Configuring the Audit Service page in the Red Hat Enterprise Linux Security Guide and the auditd.conf(5) man page.
After modifying the configuration or rules, enable or restart the auditd service to reload the configuration and update the rules (if they are not locked).
# service auditd start # systemctl enable auditd
# systemctl restart auditd
By default, auditd logs events to
/var/log/audit/audit.log with root
ownership. NXLog can be configured to read logs from that file.
NXLog cannot read logs owned as root when running as the
nxloguser. Either omit the
nxlog.confto run NXLog as root, or adjust the permissions as follows (see Reading Rsyslog Log Files for more information about
/etc/audit/audit.confto set the group ownership for Audit log files,
change the current ownership of the log directory and files with
chgrp -R adm /var/log/audit, and
nxloguser to the
usermod -a -G adm nxlog.
Configure NXLog (see the example below) and restart.
In the Input block of this configuration, Audit logs are read from file, the key-value pairs are parsed with xm_kvp, and then some additional fields are added. In the Output block, the messages are converted to JSON format, BSD Syslog headers are added, and the logs are sent to another host via TCP.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 <Extension _json> Module xm_json </Extension> <Extension _syslog> Module xm_syslog </Extension> <Extension audit_parser> Module xm_kvp KVPDelimiter ' ' KVDelimiter = EscapeChar '\' </Extension> <Input in> Module im_file File "/var/log/audit/audit.log" <Exec> audit_parser->parse_kvp(); $Hostname = hostname(); $FQDN = hostname_fqdn(); $Tag = "audit"; $SourceName = "selinux"; </Exec> </Input> <Output out> Module om_tcp Host 192.168.1.1 Port 1514 Exec to_json(); to_syslog_bsd(); </Output>
The Audit dispatcher (audispd) can be configured to forward log events
to a remote server using the
audisp-remote plugin included in the
audisp-remoteplugin. Use appropriate values for the
remote_server = 127.0.0.1 port = 60 transport = tcp queue_file = /var/spool/audit/remote.log mode = immediate queue_depth = 2048 format = ascii network_retry_time = 1 max_tries_per_record = 3 max_time_per_record = 5 heartbeat_timeout = 0 network_failure_action = stop disk_low_action = ignore disk_full_action = ignore disk_error_action = syslog remote_ending_action = reconnect generic_error_action = syslog generic_warning_action = syslog overflow_action = syslog
Activate the plugin by editing
active = yes.
Optionally, auditd may be configured to forward logs only (and not write to log files). Edit
write_logs = no(this option replaces
log_format = NOLOG).
Configure NXLog (see the example below), then restart NXLog.
Restart the auditd service.
With the following configuration, NXLog will accept Audit logs via TCP from audispd on the local host, parse the key-value pairs with xm_kvp, and add some additional fields to the event record.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <Extension audit_parser> Module xm_kvp KVPDelimiter ' ' KVDelimiter = EscapeChar '\' </Extension> <Input in> Module im_tcp Host 127.0.0.1 Port 60 <Exec> audit_parser->parse_kvp(); $Hostname = hostname(); $FQDN = hostname_fqdn(); $Tag = "audit"; $SourceName = "auditd"; </Exec> </Input>