WARNING: Version 6.1 of Auditbeat has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Audit kernel metricset
editAudit kernel metricset
editThe kernel
metricset receives audit events from the Linux Audit Framework that
is a part of the Linux kernel.
This metricset is available only for Linux.
How it works
editThis metricset establishes a subscription to the kernel to receive the events
as they occur. So unlike most other metricsets, the period
configuration
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 metricset 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 metricset will buffer the messages in order to combine related messages into a single event even if they arrive interleaved or out of order.
Useful commands
editWhen running Auditbeat with the kernel
metricset enabled, you might find
that other monitoring systems interfere with Auditbeat.
For example, you might encounter errors if another process, such as auditd
, is
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:
-
See if
auditd
is running:service auditd status
-
Stop the
auditd
service:service auditd stop
-
Disable
auditd
from starting on boot:chkconfig auditd off
To save CPU usage and disk space, you can use this command to stop journald
from listening to audit messages:
systemctl mask systemd-journald-audit.socket
Configuration options
editThis metricset has some configuration options for tuning its behavior. The following example shows all configuration options with their default values.
- module: audit metricsets: ["kernel"] kernel.resolve_ids: true kernel.failure_mode: silent kernel.backlog_limit: 8196 kernel.rate_limit: 0 kernel.include_raw_message: false kernel.include_warnings: false
-
kernel.socket_type
-
This optional setting controls the type of socket that Auditbeat uses to receive events from the kernel. The two options are
unicast
andmulticast
.unicast
should 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. stopauditd
).multicast
can be used in kernel versions 3.16 and newer. By usingmulticast
Auditbeat will receive an audit event broadcast that is not exclusive to a a single process. This is ideal for situations whereauditd
is running and managing the rules. Ifmulticast
is specified, but the kernel version is less than 3.16 Auditbeat will automatically revert tounicast
.By default Auditbeat will use
multicast
if the kernel version is 3.16 or newer and no rules have been defined. Otherwiseunicast
will be used. -
kernel.resolve_ids
- This boolean setting enables the resolution of UIDs and GIDs to their associated names. The default value is true.
-
kernel.failure_mode
-
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
options are
silent
,log
, orpanic
.silent
basically makes the kernel ignore the errors,log
makes the kernel write the audit messages usingprintk
so they show up in system’s syslog, andpanic
causes the kernel to panic to prevent use of the machine. Auditbeat’s default issilent
. -
kernel.backlog_limit
- This controls the maximum number of audit messages that will be buffered by the kernel.
-
kernel.rate_limit
- 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.
-
kernel.include_raw_message
-
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. -
kernel.include_warnings
-
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
kernel.include_raw_message
config setting. This setting is primarily used for development and debugging purposes. -
kernel.audit_rules
-
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 Linuxauditctl
utility. Auditbeat supports adding file watches (-w
) and syscall rules (-a
or-A
).
Audit rules
editThe 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
/etc/passwd
.
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: audit metricsets: ["kernel"] kernel.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
Fields
editFor a description of each field in the metricset, see the exported fields section.
Here is an example document generated by this metricset:
{ "@timestamp": "2017-04-22T21:25:01.818Z", "audit": { "kernel": { "action": "logged-in", "actor": { "attrs": { "auid": "unset", "uid": "root" }, "primary": "unset", "secondary": "(invalid user)" }, "category": "user-login", "data": { "acct": "(invalid user)", "addr": "179.38.151.221", "exe": "/usr/sbin/sshd", "op": "login", "pid": "12635", "terminal": "sshd" }, "how": "/usr/sbin/sshd", "record_type": "user_login", "result": "fail", "sequence": 19955, "session": "unset", "thing": { "primary": "sshd", "secondary": "179.38.151.221", "what": "user-session" } } }, "beat": { "hostname": "host.example.com", "name": "host.example.com" }, "metricset": { "module": "audit", "name": "kernel", "rtt": 115 }, "type": "metricsets" }