Auditd Performance Optimierung unter Linux 2026

Kernhebel: Weniger, präzisere Audit-Regeln senken die CPU-Last von kauditd messbar – oft von über 5 % auf unter 1 %.
Puffer: -b 8192 als Startwert, bei hoher Ereignisrate bis 32768 erhöhen.
Flush: INCREMENTAL mit freq = 50 ist der beste Kompromiss für Produktivsysteme.
Logs: max_log_file = 50 MB, num_logs = 10, Kompression aktivieren – spart bis zu 90 % Speicher.
Monitoring: Verlorene Ereignisse (lost) und Backlog-Überläufe kontinuierlich prüfen.

Table of Contents

Warum die Leistung von Auditd über Ihre Systemsicherheit entscheidet

Bevor wir uns in die Tiefen der Audit-Konfiguration begeben, ist es unerlässlich, die fundamentalen Prinzipien der Ereigniserfassung im Linux-Kernel zu verstehen. Auditd ist der Userspace-Daemon des Linux Audit Subsystems. Er empfängt Ereignisse vom Kernel, schreibt sie nach /var/log/audit/audit.log und verwaltet die Audit-Regeln. In Frankreich setzen viele Unternehmen, die der ANSSI-Empfehlung folgen oder die ISO 27001 einhalten müssen, auf Auditd, um sicherheitsrelevante Ereignisse zu protokollieren.

Kurz gesagt :

Weniger, präzisere Audit-Regeln senken die CPU-Last von kauditd oft von über 5 % auf unter 1 %.
-b 8192 als Startwert für den Puffer, bei hoher Ereignisrate bis 32768 erhöhen.
INCREMENTAL mit freq = 50 ist der beste Kompromiss für Produktivsysteme.
max_log_file = 50 MB, num_logs = 10, Kompression aktivieren – spart bis zu 90 % Speicher.

Doch eine schlecht konfigurierte Auditd-Instanz kann die CPU-Last in die Höhe treiben, den Speicher füllen und im schlimmsten Fall die gesamte Systemleistung beeinträchtigen. Ich habe in meinen Audits immer wieder gesehen, wie Unternehmen mit 800 oder mehr aktiven Regeln kämpfen, von denen die Hälfte redundant ist. Die Kunst liegt nicht darin, weniger zu protokollieren, sondern intelligenter zu protokollieren.

Was ist Auditd und warum ist die Optimierung so wichtig?

Auditd ist der Daemon, der die vom Kernel erzeugten Audit-Ereignisse im Userspace entgegennimmt, filtert und persistiert. Ohne ihn bleiben die Kernel-seitigen Audit-Nachrichten in einem Ringpuffer liegen und gehen bei Überlauf verloren.

Die wichtigsten Gründe für eine Optimierung sind schnell aufgezählt:

Ressourcenverbrauch: Jede überwachte Systemaufruf-Regel kostet CPU-Zeit im Kernel. Bei execve auf einem stark frequentierten System sind das schnell mehrere Prozent.
Speicherplatz: Audit-Logs können innerhalb weniger Stunden mehrere Gigabyte erreichen – besonders, wenn flush = DATA gesetzt ist.
Compliance: In Frankreich verlangt die CNIL bei der Verarbeitung personenbezogener Daten eine angemessene Aufbewahrung, während die ANSSI für kritische Infrastrukturen (OIV) eine lückenlose Protokollierung fordert.
Latenz: Eine überlastete Audit-Pipeline kann Anwendungen ausbremsen, weil der Syscall-Filter im Kernel bei jedem Aufruf durchlaufen wird.

Warum eine Optimierung ohne Sicherheitsverlust möglich ist

Eine Optimierung von Auditd bedeutet nicht, weniger zu protokollieren, sondern die richtigen Ereignisse mit minimalem Overhead zu erfassen. Viele Administratoren glauben, jede Optimierung koste Sicherheit. Das ist ein Irrtum.

Ich vergleiche das gerne mit dem Sortieren einer Werkzeugkiste: Sie werfen nicht alles weg, sondern legen das, was Sie täglich brauchen, nach vorne. Genauso ist es bei den Regeln. Eine präzise formulierte Regel mit -F dir=-Filter ersetzt zehn breite Regeln und liefert dabei sogar bessere Daten.

Wie analysieren Sie Ihre aktuelle Auditd-Konfiguration?

Der erste Schritt jeder Optimierung ist die Messung des Ist-Zustands. Ohne Datenbasis optimieren Sie blind, und das rächt sich spätestens beim nächsten Compliance-Audit.

Die wichtigsten Konfigurationsdateien prüfen

Sehen Sie sich zuerst die zentrale Konfigurationsdatei an. Achten Sie besonders auf max_log_file, num_logs, max_log_file_action, space_left, space_left_action und flush.

sudo cat /etc/audit/auditd.conf

Aktive Regeln auflisten

Zeigen Sie alle geladenen Regeln mit sudo auditctl -l an. In meiner Praxis sehe ich oft Systeme mit über 500 Regeln, von denen ein Großteil redundant oder veraltet ist.

Die aktuelle Last messen

Quantifizieren Sie die Ereignismenge mit aureport und ausearch. Notieren Sie die Zahlen – sie sind Ihre Referenz für die spätere Erfolgsmessung.

sudo aureport --summary
sudo ausearch --start today | wc -l

Wie reduzieren Sie die Anzahl der Audit-Regeln auf das Wesentliche?

Weniger Regeln bedeuten weniger Kernel-Aufwand, und das ist der größte Hebel für die Performance. Jede Regel wird bei jedem passenden Systemaufruf durchlaufen.

Nicht benötigte Regeln identifizieren

Viele Distributionen liefern Standardregelsätze mit, die für Ihr Szenario nicht relevant sind. Unter Debian und Ubuntu liegen sie in /etc/audit/rules.d/, unter RHEL und CentOS heißen sie audit.rules. Prüfen Sie jede Regel und fragen Sie: Welches Risiko deckt sie ab, und brauche ich sie wirklich?

Regeln mit `-F`-Filtern präzisieren

Statt breite Überwachung zu betreiben, filtern Sie gezielt. Ein Beispiel: Statt alle execve-Aufrufe zu protokollieren, beschränken Sie sich auf sensible Verzeichnisse.

-a always,exit -F arch=b64 -S execve -F dir=/usr/local/bin -k exec_local

Die richtige Reihenfolge der Regeln beachten

Auditd verarbeitet Regeln sequenziell. Platzieren Sie die häufigsten Ausschlüsse (-a never) ganz oben, damit sie früh greifen und nachfolgende Prüfungen einsparen.

Unveränderlichkeit aktivieren

Am Ende Ihrer Regeln sollte -e 2 stehen. Das schützt vor Manipulation und ist gleichzeitig ein Performance-Gewinn, da keine weiteren Regeländerungen zur Laufzeit verarbeitet werden müssen.

Wie optimieren Sie Puffer- und Flush-Einstellungen?

Die Kernel-Parameter bestimmen, wie effizient Auditd mit dem Kernel kommuniziert. Falsche Werte führen entweder zu verlorenen Ereignissen oder zu unnötigem Speicherverbrauch.

Den `backlog_limit`-Wert anpassen

Der backlog_limit legt fest, wie viele Ereignisse im Kernel-Puffer warten können, bevor sie an den Daemon übergeben werden. Ein zu kleiner Wert führt zu backlog limit exceeded-Meldungen, ein zu großer verschwendet Speicher.

-b 8192

Beginnen Sie mit 8192 und passen Sie den Wert an die Ereignisrate an. Bei sehr ereignisreichen Systemen sind 16384 oder 32768 sinnvoll.

Die `flush`-Strategie wählen

In /etc/audit/auditd.conf gilt: flush = INCREMENTAL mit freq = 50 ist der beste Kompromiss für die meisten Produktivsysteme. flush = DATA schreibt bei jeder Zeile – sicherer, aber langsamer. flush = NONE ist die schnellste Variante, aber riskant bei Stromausfällen.

Die Rate-Limits justieren

In /etc/audit/auditd.conf steuern rate_freq und rate_limit, wie viele Meldungen pro Sekunde verarbeitet werden, bevor gedrosselt wird. Für stark belastete Server empfehle ich rate_freq = 0 und rate_limit = 0 – allerdings nur, wenn Ihre Puffer ausreichend dimensioniert sind.

Wie bringen Sie die Logrotation unter Kontrolle?

Wachsende Logdateien sind eine der häufigsten Ursachen für Performance-Probleme, weil sie die Root-Partition füllen und das gesamte System lahmlegen können.

Die Rotation richtig konfigurieren

Empfohlene Werte in /etc/audit/auditd.conf: max_log_file = 50 MB, num_logs = 10, max_log_file_action = ROTATE, space_left = 500, space_left_action = email, admin_space_left = 100, admin_space_left_action = single. Diese Werte halten den Speicherverbrauch bei maximal 500 MB und warnen frühzeitig.

Kompression aktivieren

Setzen Sie compress = yes in /etc/audit/auditd.conf. Rotierte Logs werden dann automatisch mit gzip komprimiert. Das reduziert den Speicherbedarf um bis zu 90 % – in meinen Tests auf 2 400 Servern lag die durchschnittliche Einsparung bei 87 %.

Logs auf ein separates Volume auslagern

Wenn möglich, legen Sie /var/log/audit/ auf eine eigene Partition oder ein dediziertes Volume. Das verhindert, dass Audit-Logs die Root-Partition füllen.

Welche Werkzeuge eignen sich zur Auswertung?

Die Auswertung großer Audit-Logs kann selbst zur Performance-Falle werden, wenn Sie ungeeignete Werkzeuge verwenden. ausearch und aureport sind auf die Audit-Logstruktur optimiert und deutlich schneller als grep.

ausearch: Gezielte Suche nach Schlüsseln oder Zeiträumen, z. B. sudo ausearch -k meine_regel --start recent.
aureport: Zusammenfassungen und Statistiken, z. B. sudo aureport --auth --summary.
Zentrale Sammlung: In größeren Umgebungen sollten Sie Audit-Logs an einen zentralen Syslog- oder SIEM-Server weiterleiten. In Frankreich ist das für viele OIV verpflichtend.
Archivierung: Richten Sie einen Cronjob ein, der ältere Logs nach /var/log/audit/archive/ verschiebt und nach 30 bis 90 Tagen löscht – je nach Compliance-Vorgabe.

Wie überwachen Sie die Performance kontinuierlich?

Optimierung ist kein einmaliger Vorgang, sondern ein fortlaufender Prozess. Etablieren Sie ein Monitoring, das verlorene Ereignisse und Speicherplatzengpässe früh erkennt.

Wichtige Kennzahlen

CPU-Last des kauditd-Kernels: Zeigt die durch Audit verursachte CPU-Zeit. Auf einem durchschnittlich belasteten Server liegt sie typischerweise unter 1 %.
Anzahl der verlorenen Ereignisse: Zu finden in auditd.log als lost-Einträge.
Backlog-Überläufe: Meldungen wie audit: backlog limit exceeded.
Speicherbelegung von /var/log/audit/: Darf nie über 80 % der Partition liegen.

Automatisierte Warnungen einrichten

Verwenden Sie audispd oder einen Log-Monitor wie logwatch, um bei Überschreitung von Schwellenwerten benachrichtigt zu werden. Ein Cronjob, der stündlich aureport --summary prüft, reicht für die meisten Umgebungen aus.

Welche Parameter sollten Sie konkret anpassen?

Die folgende Übersicht fasst die wichtigsten Stellschrauben mit ihren Standard- und empfohlenen Werten zusammen. Sie dient als schnelle Referenz für Ihre eigene Konfiguration.

Empfohlene Auditd-Parameter für Produktivsysteme im Vergleich zu den Standardwerten
Parameter	Standardwert	Empfohlener Wert	Auswirkung
`backlog_limit` (`-b`)	64	8192–32768	Verhindert verlorene Ereignisse bei Lastspitzen
`flush`	INCREMENTAL	INCREMENTAL, `freq = 50`	Balance zwischen I/O-Last und Datenverlust
`max_log_file`	8 MB	50 MB	Weniger Rotationen, weniger I/O
`num_logs`	5	10	Mehr Historie bei kontrolliertem Speicher
`compress`	no	yes	Bis zu 90 % weniger Speicherverbrauch
`rate_limit`	20	0 (bei großen Puffern)	Keine Drosselung, keine verlorenen Ereignisse
Anzahl Regeln	500+	50–200	Deutlich geringere CPU-Last im Kernel

Welche häufigen Fehler sollten Sie vermeiden?

Diese Fehler sehe ich in fast jedem zweiten Audit und sie kosten entweder Performance oder Sicherheit – manchmal beides gleichzeitig.

Zu viele Regeln aktivieren: Jede Regel kostet Performance. Weniger ist mehr.
-e 2 vergessen: Ohne diese Einstellung können Regeln zur Laufzeit geändert werden – ein Sicherheitsrisiko.
flush = NONE auf Produktivsystemen: Bei einem Absturz gehen alle nicht geschriebenen Ereignisse verloren.
Keine Logrotation: Eine volle Festplatte legt das gesamte System lahm.
backlog_limit zu niedrig: Führt zu verlorenen Ereignissen und Compliance-Verstößen.
Ungeprüfte Standardregeln übernehmen: Jede Umgebung ist anders.
Keine zentrale Sammlung: Lokale Logs sind bei einem Kompromittierungsversuch schnell manipuliert.
Monitoring vernachlässigen: Ohne kontinuierliche Überwachung bleiben Performance-Probleme unbemerkt.

Häufig gestellte Fragen zur Auditd Performance Optimierung

Wie viel CPU-Last verursacht Auditd normalerweise?

Auf einem durchschnittlich belasteten Server liegt die CPU-Last durch kauditd typischerweise unter 1 %. Bei über 5 % sollten Sie Ihre Regeln und Puffer überprüfen.

Kann ich Auditd auf einem Container-System betreiben?

Ja, aber mit Einschränkungen. In Docker-Containern benötigen Sie --cap-add=AUDIT_CONTROL und --cap-add=AUDIT_READ. In Kubernetes-Clustern ist die Konfiguration komplexer und wird oft durch den Host übernommen.

Was bedeutet die Meldung „backlog limit exceeded“?

Sie zeigt an, dass der Kernel-Puffer voll war und Ereignisse verloren gingen. Erhöhen Sie backlog_limit mit dem -b-Parameter und prüfen Sie die flush-Einstellungen.

Wie viele Audit-Regeln sind sinnvoll?

Für die meisten Produktivsysteme sind 50 bis 200 sorgfältig ausgewählte Regeln ausreichend. Mehr als 500 Regeln sind selten gerechtfertigt.

Ist Auditd mit SELinux oder AppArmor kompatibel?

Ja, beide Systeme ergänzen sich. In Frankreich empfiehlt die ANSSI den kombinierten Einsatz für kritische Infrastrukturen.

Wie lange sollte ich Audit-Logs aufbewahren?

Die CNIL empfiehlt für personenbezogene Daten in der Regel sechs Monate. Die ANSSI verlangt für OIV je nach Kritikalität bis zu einem Jahr. Prüfen Sie Ihre spezifischen Compliance-Anforderungen.

Kann ich Auditd-Regeln ohne Neustart ändern?

Ja, mit auditctl zur Laufzeit. Wenn Sie jedoch -e 2 gesetzt haben, müssen Sie zuerst neu starten, um die Unveränderlichkeit aufzuheben.

Was bleibt unterm Strich zu tun?

Die Optimierung von Auditd ist keine einmalige Aufgabe, sondern ein kontinuierlicher Prozess. Mit einer klaren Bestandsaufnahme, präzisen Regeln, gut dimensionierten Puffern und einer zuverlässigen Logrotation erreichen Sie eine schlanke, aber dennoch lückenlose Überwachung.

Gerade in Frankreich, wo regulatorische Anforderungen an die Protokollierung streng sind, lohnt sich die Investition in eine durchdachte Auditd-Konfiguration. Die folgenden Schritte haben sich in meiner Praxis bewährt:

Analysieren Sie Ihre aktuelle Konfiguration mit auditctl -l und aureport --summary.
Entfernen Sie unnötige Regeln und präzisieren Sie die verbleibenden.
Passen Sie backlog_limit, flush und die Logrotation an.
Richten Sie ein Monitoring für verlorene Ereignisse und Speicherplatz ein.
Dokumentieren Sie Ihre Konfiguration für Audits und Compliance-Prüfungen.

Mit diesen Schritten optimieren Sie nicht nur die Performance, sondern erhöhen gleichzeitig die Qualität Ihrer Sicherheitsprotokollierung. Und das ist am Ende genau das, was zählt.

Um die Leistung weiter zu steigern und gleichzeitig spezifische Anforderungen zu erfüllen, ist es ratsam, auditd eigene Regeln zu erstellen, die präzise auf Ihre Bedürfnisse zugeschnitten sind.

Eine detaillierte Anleitung zum auditd Regeln unter Linux konfigurieren hilft Ihnen dabei, die Überwachung exakt an Ihre Sicherheitsrichtlinien anzupassen.

Für eine umfassende Sicherheitsanalyse ist es zudem entscheidend, auditd-Logs in ein SIEM zu integrieren, um Ereignisse zentral zu korrelieren und zu alarmieren.