auditd module receives audit events from the Linux Audit Framework that
is a part of the Linux kernel.
This module is available only for Linux.
How it worksedit
This module establishes a subscription to the kernel to receive the events
as they occur. So unlike most other modules, the
option is unused because it is not implemented using polling.
The Linux Audit Framework can send multiple messages for a single auditable
event. For example, a
rename syscall causes the kernel to send eight separate
messages. Each message describes a different aspect of the activity that is
occurring (the syscall itself, file paths, current working directory, process
title). This module will combine all of the data from each of the messages
into a single event.
Messages for one event can be interleaved with messages from another event. This module will buffer the messages in order to combine related messages into a single event even if they arrive interleaved or out of order.
When running Auditbeat with the
auditd module enabled, you might find
that other monitoring tools interfere with Auditbeat.
For example, you might encounter errors if another process, such as
registered to receive data from the Linux Audit Framework. You can use these
commands to see if the
auditd service is running and stop it:
service auditd status
service auditd stop
auditdfrom starting on boot:
chkconfig auditd off
To save CPU usage and disk space, you can use this command to stop
from listening to audit messages:
systemctl mask systemd-journald-audit.socket
This module has some configuration options for tuning its behavior. The following example shows all configuration options with their default values.
- module: auditd resolve_ids: true failure_mode: silent backlog_limit: 8196 rate_limit: 0 include_raw_message: false include_warnings: false
This optional setting controls the type of socket that Auditbeat uses to receive events from the kernel. The two options are
unicastshould be used when Auditbeat is the primary userspace daemon for receiving audit events and managing the rules. Only a single process can receive audit events through the "unicast" connection so any other daemons should be stopped (e.g. stop
multicastcan be used in kernel versions 3.16 and newer. By using
multicastAuditbeat will receive an audit event broadcast that is not exclusive to a a single process. This is ideal for situations where
auditdis running and managing the rules. If
multicastis specified, but the kernel version is less than 3.16 Auditbeat will automatically revert to
By default Auditbeat will use
multicastif the kernel version is 3.16 or newer and no rules have been defined. Otherwise
unicastwill be used.
- This boolean setting enables the resolution of UIDs and GIDs to their associated names. The default value is true.
This determines the kernel’s behavior on critical
failures such as errors sending events to Auditbeat, the backlog limit was
exceeded, the kernel ran out of memory, or the rate limit was exceeded. The
silentbasically makes the kernel ignore the errors,
logmakes the kernel write the audit messages using
printkso they show up in system’s syslog, and
paniccauses the kernel to panic to prevent use of the machine. Auditbeat’s default is
- This controls the maximum number of audit messages that will be buffered by the kernel.
- This sets a rate limit on the number of messages/sec delivered by the kernel. The default is 0, which disables rate limiting. Changing this value to anything other than zero can cause messages to be lost. The preferred approach to reduce the messaging rate is be more selective in the audit ruleset.
This boolean setting causes Auditbeat to
include each of the raw messages that contributed to the event in the document
as a field called
messages. The default value is false. This setting is primarily used for development and debugging purposes.
This boolean setting causes Auditbeat to
include as warnings any issues that were encountered while parsing the raw
messages. The default value is false. When this setting is enabled the raw
messages will be included in the event regardless of the
include_raw_messageconfig setting. This setting is primarily used for development and debugging purposes.
A string containing the audit rules that should be
installed to the kernel. There should be one rule per line. Comments can be
embedded in the string using
#as a prefix. The format for rules is the same used by the Linux
auditctlutility. Auditbeat supports adding file watches (
-w) and syscall rules (
The audit rules are where you configure the activities that are audited. These
rules are configured as either syscalls or files that should be monitored. For
example you can track all
connect syscalls or file system writes to
Auditing a large number of syscalls can place a heavy load on the system so consider carefully the rules you define and try to apply filters in the rules themselves to be as selective as possible.
The kernel evaluates the rules in the order in which they were defined so place the most active rules first in order to speed up evaluation.
You can assign keys to each rule for better identification of the rule that triggered an event and easier filtering later in Elasticsearch.
Defining any audit rules in the config causes Auditbeat to purge all
existing audit rules prior to adding the rules specified in the config.
Therefore it is unnecessary and unsupported to include a
-D (delete all) rule.
auditbeat.modules: - module: auditd audit_rules: | # Things that affect identity. -w /etc/group -p wa -k identity -w /etc/passwd -p wa -k identity -w /etc/gshadow -p wa -k identity -w /etc/shadow -p wa -k identity # Unauthorized access attempts to files (unsuccessful). -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
The Auditd module supports the common configuration options that are described under configuring Auditbeat. Here is an example configuration:
auditbeat.modules: - module: auditd audit_rules: | ## Define audit rules here. ## Create file watches (-w) or syscall audits (-a or -A). Uncomment these ## examples or add your own rules. ## If you are on a 64 bit platform, everything should be running ## in 64 bit mode. This rule will detect any use of the 32 bit syscalls ## because this might be a sign of someone exploiting a hole in the 32 ## bit API. #-a always,exit -F arch=b32 -S all -F key=32bit-abi ## Executions. #-a always,exit -F arch=b64 -S execve,execveat -k exec ## External access (warning: these can be expensive to audit). #-a always,exit -F arch=b64 -S accept,bind,connect -F key=external-access ## Identity changes. #-w /etc/group -p wa -k identity #-w /etc/passwd -p wa -k identity #-w /etc/gshadow -p wa -k identity ## Unauthorized access attempts. #-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -k access #-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -k access