Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
auditd — Best Practice Auditd Configuration | Kitploit
Tools/GitHubGitHub/neo23x0/auditd
Defensive ToolsConfiguration AuditingForensicsIntrusion DetectionIncident ResponseLog Analysis
GitHubneo23x0/auditd

auditd

Best Practice Auditd Configuration

Repository anzeigen
1.9k310vor 3 MonatenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Actively Maintained

root@kitploit:~
    ___             ___ __      __
   /   | __  ______/ (_) /_____/ /
  / /| |/ / / / __  / / __/ __  / 
 / ___ / /_/ / /_/ / / /_/ /_/ /  
/_/  |_\__,_/\__,_/_/\__/\__,_/   

Best Practice Auditd Konfiguration

Idee

Die Idee dieser Auditd-Konfiguration ist es, eine Best-Practice-Basislinie bereitzustellen, die

  • out-of-the-box auf den wichtigsten Linux-Distributionen funktioniert
  • eine breite Palette sicherheitsrelevanter Host-Aktivitäten abdeckt
  • wiederverwendbare Telemetrie gegenüber langen Listen hartcodierter Erkennungen bevorzugt
  • die Erkennungslogik in Sigma-Regeln, SIEM-Inhalten oder hostseitigen Analysen belässt
  • durch Abschnitte und Kommentare leicht lesbar und anpassbar bleibt

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.

Abdeckung

Die aktuelle Konfiguration konzentriert sich auf die folgenden Abdeckungsbereiche:

  • Selbstauditierung und Integrität der Audit-Konfiguration
  • Rauschfilter und auf Portabilität ausgerichtete Ausschlüsse
  • Kernel-, Modul-, Mount-, Swap- und Zeitänderungen
  • Geplante Aufgaben, Benutzerkonten-Datenbanken, PAM, sudo und Anmeldestatus
  • Netzwerk-, Firewall-, Start-, Dienst- und Boot-Pfad-Konfiguration
  • Bibliothekspfade, Shell-Profile, SSH, systemd und MAC-Richtlinienänderungen
  • Fehlgeschlagene Zugriffsversuche, DAC-Änderungen, Sitzungsdateien und Heuristiken zum Missbrauch von Berechtigungen
  • Spezielle Primitive wie ptrace, memfd_create, bpf, Namespaces, io_uring und userfaultfd
  • Konfigurationspfade für Software, Container und Sicherheitstools
  • Hochvolumige Telemetrie wie execve, execveat, Socket-Erstellung, Dateilöschung und Nutzung der 32-Bit-ABI

Verwandte Projekte

Dieses 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.

Validierung

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.:

root@kitploit:~
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.

UID_MIN

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:

root@kitploit:~
awk '$1=="UID_MIN" { print $2 }' /etc/login.defs

AF_ALG / Copy Fail Telemetrie

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öße
  • setsockopt(..., 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:

  • Filtern nach key=af_alg
  • Untersuchen von SOCKADDR.saddr / SADDR={ saddr_fam=alg ... }
  • Kennzeichnen von salg_type=aead mit salg_name, das authencesn( enthält
  • Schweregrad erhöhen, wenn dieselbe pid, exe oder auid innerhalb eines kurzen Zeitfensters viele solcher Bindungen ausgibt

Der 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.

Quellen

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

Weitere Regeln

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

Videoerklärungen von IppSec

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

Beitrag

Bitte reichen Sie Ihre Änderungen als Pull-Requests ein

Tool herunterladen