[Auditbeat] Allow setting kernel audit config immutable

[ndubss]

I don't believe auditbeat supports any type of tamper feature of this type. Specifically, this is to prevent an attacker from disabling the system that would be used to alert to intrusion.

The closest thing I can find is failure_mode: log
Although I haven't tested yet.

There is also an auditd immutability mode (-e) that auditbeat will not allow in the accepted config. I do like that an attacker would likely go after auditd first (with auditctl -l), see rules, and then attempt auditctl -D. That (and any other recon) would be logged.

[ceeeekay]

+1 for allowing auditbeat to set -e 2

[kleekai-gsd]

+1 to auditbeat setting -e 2

[dmlary]

This workaround does not work for systems that don't support Multicast sockets for audit data

Workaround for CentOS/RHEL:

• Edit the auditbeat.service, and add the following line to the [Service] section:

ExecStartPre=/usr/sbin/augenrules --load

• Keep your rules files in /etc/audit/rules.d/*.rules.
• Comment out both audit_rules_files and audit_rules in auditbeat.yml

Now, augenrules is responsible for parsing & loading audit rules out of /etc/audit/rules.d/*.rules before auditbeat starts. Auditbeat will not add any rules.

Why didn't it work?

auditbeat can't register as the pid handling audit events after the rules have been made immutable. You'll get the error from
https://github.com/elastic/beats/blob/fec835c970c0d2ea34f483c238a1d13be51428f8/auditbeat/module/auditd/audit_linux.go#L830:L836, Cannot continue: audit configuration is locked in the kernel (enabled=2) which prevents using unicast sockets.

Dug down and found the why here.
#6019 (comment)

[dmlary]

Workaround for unicast-only systems

Along the same lines as the previous workaround, modify auditbeat.service and add the following line to the [Service] section:

ExecStartPost=/bin/sh -c "/usr/bin/sleep 15;/usr/sbin/augenrules --load"

The key here is the sleep. When I did just augenrules --load, sometimes the rules would be immutable before auditbeat performed the check to see if the rules were locked.

I'd also suggest throwing RefuseManualStop=yes into [Unit] so you don't accidentally restart auditbeat. Once you do that, it can't receive the audit events anymore.

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[admlko]

This really needs to be implemented.

[Erni]

Is there any plan to implement this in the near future?

[ndubss]

@andrewkroh thank you! This can be closed. elastic/go-libaudit@ba0bbab

[andrewkroh]

I did add support for this feature in the go-libaudit library, but Auditbeat still needs updated to use the feature and also to provide helpful errors when certain actions cannot be performed due to the kernel being immutable.

[cynorsense]

This is still a problem on 7.10.1 auditbeat. Not sure if this will come up as highest priority.

[wilrodriguez]

Does anyone know when this change might occur?

[boomcubist]

@dmlary does this workaround work on RHEL 7 servers? Specifically one's with the C2S profile applied? I'm not having much luck with either workaround.

[dmlary]

@boomcubist over the past few years, this has evolved into something a little more complicated.

With the version of auditbeat I'm running (6.8.1), I would see auditbeat crash at startup on occasion, which prevents the audit data from being correctly captured after the rules have been set immutable (you can't change the destination pid). To work around this, I pulled the immutable flag from the audit rules, and moved it into a separate service entirely.

This service will only start after auditbeat service is up and running. It will check if auditbeat has been running for more than 60 seconds, and if so, it will set the audit rules immutable.

audit-rules-immutable.service:

[Unit]
Description=Make audit rules immutable
After=auditbeat.service

[Service]
ExecStart=/bin/bash -xc '[[ $(ps -o etimes= -C auditbeat) -ge 60 ]] && auditctl -e 2'
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)