
Best Practice Auditd Configuration
___ ___ __ __
/ | __ ______/ (_) /_____/ /
/ /| |/ / / / __ / / __/ __ /
/ ___ / /_/ / /_/ / / /_/ /_/ /
/_/ |_\__,_/\__,_/_/\__/\__,_/
Best Practice Auditd Konfiguration
Die Idee dieser Auditd-Konfiguration ist es, eine Best-Practice-Basislinie bereitzustellen, die
Das vereinfachte Regelwerk behält absichtlich einige hochwertige, aber potenziell hochvolumige Telemetrie bei, insbesondere Prozesserstellungs-, Socket-Erstellungs- und Dateizugriffsfehlerereignisse. Passen Sie diese Abschnitte bei Bedarf an Ihre Umgebung an.
Die aktuelle Konfiguration konzentriert sich auf die folgenden Abdeckungsbereiche:
ptrace, memfd_create, bpf, Namespaces, io_uring und userfaultfdexecve, execveat, Socket-Erstellung, Dateilöschung und Nutzung der 32-Bit-ABIDieses Regelwerk soll unabhängig von der nachgelagerten Erkennungslogik bleiben. Es konzentriert sich auf das Sammeln allgemein nützlicher Audit-Telemetrie, die dann auf unterschiedliche Weise analysiert werden kann, beispielsweise mit Sigma-basierten Tools oder SIEM-Abfragen.
Ein Open-Source-Projekt, das diese Auditdaten nutzen kann, ist Aurora Linux, ein leichtgewichtiger und anpassbarer Sigma-basierter Agent für Linux, der eBPF-basierte Telemetrie mit User-Space-Anreicherung und Sigma-Regelabgleich kombiniert.
Dieses Regelwerk enthält absichtlich -i, sodass optionale distributionsspezifische Pfade
das Laden auf Systemen, auf denen einige Binärdateien oder Verzeichnisse fehlen, nicht
abbrechen. Das vereinfacht die Standardbereitstellung, bedeutet aber auch, dass Fehler
beim Regelladen ignoriert werden.
Wenn Sie eine strikte Validierung vor der Bereitstellung wünschen, testen Sie eine temporäre
Kopie, bei der die Zeile mit -i entfernt wurde, z. B.:
grep -v '^-i$' audit.rules > /tmp/audit.rules.strict
auditctl -R /tmp/audit.rules.strict
Das Repository enthält auch GitHub Actions-Prüfungen, die die Regeln linten und validieren, dass sowohl eine portable CI-Kopie als auch eine strikte Kopie auf Ubuntu geladen werden können.
Mehrere Regeln in audit.rules verwenden auid>=1000 -F auid!=unset, um sich auf
interaktive Benutzeraktivitäten zu konzentrieren und nicht gesetzte Anmeldesitzungen
auszuschließen.
1000 ist der übliche UID_MIN auf vielen Linux-Distributionen, aber nicht universell.
Wenn Ihr Host einen anderen UID_MIN verwendet, überprüfen Sie /etc/login.defs
und ersetzen Sie 1000 in audit.rules vor der Bereitstellung:
awk '$1=="UID_MIN" { print $2 }' /etc/login.defs
Am 29. April 2026 veröffentlichte Xint Copy Fail (CVE-2026-31431), eine lokale
Privilegieneskalationstechnik, die das Kernel-Crypto-Userspace-Interface (AF_ALG)
zusammen mit splice() missbraucht, um von Page-Cache unterstützte Dateien im
Speicher zu korrumpieren.
Dieses Regelwerk enthält einen kleinen af_alg-Block, um die stabilen,
rauscharmen Teile dieses Aufbaus aus zurechenbaren Benutzersitzungen zu sammeln:
socket(AF_ALG, ...)bind() unter Verwendung der üblichen struct sockaddr_alg mit fester Größesetsockopt(..., SOL_ALG, ...)Dies ist bewusst generischer gehalten als eine einmalige Signatur für
authencesn(hmac(sha256),cbc(aes)), da Audit-Syscall-Filter keine Zeichenfolgen-
Argumente abgleichen können. In der Praxis befindet sich der Algorithmusname im
SOCKADDR-Datensatz, der von bind() ausgegeben wird. Die empfohlene nachgelagerte
Erkennung ist daher:
key=af_algSOCKADDR.saddr / SADDR={ saddr_fam=alg ... }salg_type=aead mit salg_name, das authencesn( enthältpid, exe oder auid innerhalb eines kurzen
Zeitfensters viele solcher Bindungen ausgibtDer von Xint beschriebene Proof-of-Concept stützt sich auch auf wiederholte
splice()-Operationen. Diese Syscalls sind im Standardregelwerk auf vielen Systemen
zu laut, daher enthält das Repository nur eine auskommentierte splice_user-Overlay
in audit.rules. Aktivieren Sie diese nur, wenn splice / vmsplice in Ihrer
Umgebung ungewöhnlich sind, und korrelieren Sie sie mit kürzlichen af_alg-Aktivitäten
desselben Prozesses oder derselben Benutzersitzung.
Die Konfiguration basiert auf den folgenden Quellen und jahrelangen zusammengeführten Verbesserungen des Standardregelwerks:
Gov.uk auditd rules https://github.com/gds-operations/puppet-auditd/pull/1
CentOS 7 hardening https://highon.coffee/blog/security-harden-centos-7/#auditd---audit-daemon
Linux audit repo https://github.com/linux-audit/audit-userspace/tree/master/rules
Auditd high performance linux auditing https://linux-audit.com/tuning-auditd-high-performance-linux-auditing/
Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. https://xint.io/blog/copy-fail-linux-distributions
Linux kernel crypto userspace interface (AF_ALG) https://docs.kernel.org/crypto/userspace-if.html
Nicht alle dieser Regeln wurden aufgenommen.
Für PCI-DSS-Compliance siehe: https://github.com/linux-audit/audit-userspace/blob/master/rules/30-pci-dss-v31.rules
Für NISPOM-Compliance siehe: https://github.com/linux-audit/audit-userspace/blob/master/rules/30-nispom.rules
IppSec hat ein Video aufgenommen, das erklärt, wie man die Ausnutzung der
OMIGOD-Sicherheitslücke mit auditd erkennt. Die Kernkonzepte von auditd in diesem
Video sind immer noch nützlich, aber das Regelwerk in diesem Repository wurde
seitdem erheblich vereinfacht. Betrachten Sie das Video als historischen Hintergrund
und als Einführung in auditd-basierte Erkennungsideen, nicht als zeilenweise
Dokumentation der aktuellen audit.rules.
https://www.youtube.com/watch?v=lc1i9h1GyMA
Bitte reichen Sie Ihre Änderungen als Pull-Requests ein