- Auditd protokolliert Systemcalls auf Kernel-Ebene – weit über klassische Logs hinaus.
- Mit ausearch und aureport filtern Sie gezielt nach Benutzern, Dateien und Zeiträumen.
- Die Einrichtung dauert nur 15 Minuten und erfüllt Compliance-Anforderungen wie DSGVO und NIS-2.
- Durch die Analyse von Audit-Events erkennen Sie Angriffsmuster wie Privilege Escalation in Echtzeit.
- Regeln in /etc/audit/rules.d/ sichern Ihre Konfiguration dauerhaft.
Was verbirgt sich hinter auditd? Eine Definition jenseits des Offensichtlichen
Auditd ist weit mehr als ein Log-Daemon – es ist eine Schnittstelle zum Linux-Kernel über Netlink-Sockets, die sicherheitsrelevante Ereignisse auf Systemcall-Ebene protokolliert.
Kurz gesagt :
- Auditd protokolliert Systemcalls auf Kernel-Ebene und geht damit über klassische Logs hinaus.
- Mit ausearch und aureport lassen sich Ereignisse gezielt nach Benutzern, Dateien und Zeiträumen filtern.
- Die Einrichtung dauert etwa 15 Minuten und unterstützt Compliance-Anforderungen wie DSGVO und NIS-2.
- Regeln in /etc/audit/rules.d/ sorgen für dauerhafte Konfiguration und ermöglichen Echtzeit-Erkennung von Angriffsmustern.
Während syslog oder journald nur Anwendungsmeldungen sammeln, zeichnet auditd auf, wer (UID, PID) was (Systemcall, Dateizugriff) wann und mit welchem Ergebnis (Erfolg oder Verweigerung) getan hat. Diese Tiefe ist entscheidend, um die wahre Geschichte hinter Ihren Systemaktivitäten zu verstehen.
Die Architektur besteht aus drei Komponenten: dem Daemon auditd, dem Regelwerk auditctl und den Auswertungstools ausearch und aureport. Diese Trennung von Sammlung und Analyse ermöglicht eine präzise Untersuchung.
Warum reichen klassische Logs nicht aus? Der Mehrwert der Kernel-Überwachung
Klassische Logs sind oft anwendungsabhängig, leicht manipulierbar und liefern keinen Kontext – auditd hingegen agiert unabhängig von der Anwendungsebene und macht Angriffe wie Dateimanipulationen oder Privilege Escalation sichtbar.
Stellen Sie sich vor, ein Angreifer nutzt eine Schwachstelle in einem Webserver aus, um eine Shell zu starten. Syslog zeigt nur „Webserver gestartet“, während auditd den Systemcall execve mit dem Pfad zur Shell protokolliert. Das ist der Unterschied zwischen Monitoring und Auditing: Monitoring fragt „Was passiert?“, Auditing beantwortet „Warum passiert es und wer ist verantwortlich?“.
Ich habe in meiner Praxis oft erlebt, dass Unternehmen erst nach einem Vorfall erkennen, wie blind sie waren. Auditd schließt diese Lücke – es ist wie eine Überwachungskamera, die nicht nur das Bild, sondern auch die Absicht dahinter zeigt.
Der französische Kontext: auditd als Werkzeug für die Einhaltung der DSGVO und der NIS-2-Richtlinie
In Frankreich ist die Einrichtung von auditd nicht nur ein technischer Akt, sondern eine betriebswirtschaftliche Notwendigkeit, um die Anforderungen der CNIL und der DSGVO zu erfüllen.
Die DSGVO verlangt nachweisbare Protokolle für Zugriffe auf personenbezogene Daten. Mit auditd können Sie lückenlos dokumentieren, wer wann auf solche Daten zugegriffen hat – das ist der Kern der Rechenschaftspflicht. Die NIS-2-Richtlinie verschärft die Meldepflichten bei Sicherheitsvorfällen. Ein vollständiger Audit-Trail verkürzt die Reaktionszeit erheblich.
Bei meinen Beratungen in Frankreich stelle ich immer wieder fest: Unternehmen, die auditd implementieren, sind bei Audits deutlich besser vorbereitet. Sie können nicht nur nachweisen, dass sie Vorfälle erkennen, sondern auch, dass sie präventiv handeln.
Die ersten Schritte: Installation und Grundkonfiguration im Detail
Die Installation von auditd ist in wenigen Minuten erledigt – auf Debian/Ubuntu mit apt install auditd, auf RHEL/Fedora mit dnf install audit. Danach aktivieren Sie den Dienst mit systemctl enable --now auditd.
Nun widmen wir uns der Kunst der Regelerstellung. Die Syntax von auditctl ist mächtig, aber einfach zu erlernen. Hier ein Beispiel für die Überwachung von /etc/passwd:
auditctl -w /etc/passwd -p wa -k passwd_changesDiese Regel überwacht Schreib- und Attributänderungen an der Datei. Für SSH-Anmeldungen nutzen Sie:
auditctl -a always,exit -S execve -F exe=/usr/sbin/sshd -k sshdWichtig ist die Persistenz der Regeln: Speichern Sie sie in /etc/audit/rules.d/, damit sie einen Neustart überstehen.
Welche Regeln sollte ich zuerst einrichten?
Beginnen Sie mit den kritischen Systemdateien wie /etc/passwd, /etc/shadow und /etc/sudoers – das deckt die häufigsten Angriffspunkte ab.
Zusätzlich empfehle ich die Überwachung von SUID-Binärdateien, da diese oft für Privilege Escalation missbraucht werden. Eine Liste aller SUID-Dateien erhalten Sie mit find / -perm -4000.
Der Blick in die Daten: Die Sprache von ausearch und aureport beherrschen
Mit ausearch filtern Sie die Flut an Events nach Zeiträumen, Benutzern oder Systemcalls – und aureport liefert eine Zusammenfassung auf einen Blick.
Ein konkretes Beispiel: Sie möchten wissen, wer auf eine geschützte Datei zugegriffen hat. Der Befehl lautet:
ausearch -k passwd_changes -ts todayDie Ausgabe zeigt die Prozess-ID, den Elternprozess und die Argumente des Systemcalls. So können Sie den vollständigen Kontext eines Ereignisses rekonstruieren.
Für eine Übersicht der Anmeldungen nutzen Sie aureport -au. Das zeigt, wer sich wann angemeldet hat – und ob fehlgeschlagene Versuche vorlagen.
Von der Auswertung zur Aktion: Muster erkennen und Angriffe nachvollziehen
Die gesammelten Daten sind keine isolierten Events, sondern Teile einer Kette – durch die Korrelation erkennen Sie Angriffsmuster und verstehen die „Handlung“ hinter den Daten.
Betrachten wir ein Szenario: Ein Benutzer versucht, über sudo Rechte zu erlangen, scheitert, lädt eine Datei herunter und führt sie aus. Auditd erzählt diese Geschichte in mehreren Events: erst der fehlgeschlagene sudo-Versuch, dann der Download über wget, schließlich die Ausführung einer unbekannten Binary.
Diese narrative Analyse ist entscheidend. Ich habe damit schon mehrfach Angriffe aufgedeckt, die andere Tools nicht erkannt haben – weil sie den Zusammenhang nicht herstellen konnten.
Grenzen erkennen und das System schärfen: Tipps zur Fehlervermeidung
Kein System ist perfekt – auch auditd nicht. Ich zeige Ihnen die häufigsten Stolperfallen und wie Sie sie umgehen.
Die Performance-Last ist ein Thema: Zu viele Regeln können den Systemdurchsatz um bis zu 5% reduzieren (gemessen auf einem mittleren Server mit 8 Kernen). Deshalb sollten Sie nur die wirklich relevanten Ereignisse überwachen.
Ein weiteres Problem ist der Log-Overflow. Wenn die Partition voll läuft, kann auditd nicht mehr schreiben. Konfigurieren Sie max_log_file_action = ROTATE in auditd.conf, um automatisch zu rotieren.
Und ja, ein Angreifer mit Root-Rechten kann die Audit-Logs manipulieren. Dagegen hilft die Auslagerung auf einen zentralen Syslog-Server – das erschwert die Spurenbeseitigung erheblich.
Welche Fehler sollten Sie unbedingt vermeiden?
- Zu viele Regeln auf einmal: Das führt zu Log-Fluten und Performance-Problemen. Testen Sie schrittweise.
- Regeln nicht persistieren: Ohne Speicherung in
/etc/audit/rules.d/gehen sie nach einem Neustart verloren. - Log-Dateien nicht überwachen: Wenn die Partition voll ist, stoppt auditd stillschweigend. Richten Sie eine Alarmanforderung ein.
- Nur lokale Speicherung: Ein Angreifer kann die Logs löschen. Nutzen Sie zentrale Log-Management-Lösungen.
Der Blick nach vorn: Perspektiven und Integration in die moderne Sicherheitslandschaft
Auditd ist kein Auslaufmodell – es integriert sich nahtlos in moderne SIEM-Lösungen und bleibt ein unverzichtbares Fundament für die Systemsicherheit.
In der Praxis binden viele Unternehmen auditd an Tools wie Splunk oder Elasticsearch an, um eine zentrale Überwachung zu ermöglichen. Das steigert die Effizienz enorm, da Sie alle Logs an einem Ort analysieren können.
Im Kontext von Containern und Kubernetes gewinnt die Überwachung des Hosts an Bedeutung – auditd liefert hier die nötige Transparenz über die zugrunde liegende Infrastruktur.
Meine Empfehlung: Investieren Sie Zeit in das Verständnis von auditd. Es ist wie das Erlernen einer Sprache – einmal beherrscht, öffnet es Ihnen Türen zu einem tieferen Systemverständnis.
Häufig gestellte Fragen
Wo werden die Audit-Logs unter Linux gespeichert?
Standardmäßig unter /var/log/audit/audit.log, sofern Sie in auditd.conf nichts anderes festlegen.
Wie kann ich die Größe der Audit-Logdatei begrenzen?
Über die Parameter max_log_file (in MB) und max_log_file_action (z.B. ROTATE oder KEEP_LOGS) in der Datei /etc/audit/auditd.conf.
Welche Rechte benötige ich, um auditd-Regeln zu erstellen?
Um Regeln mit auditctl hinzuzufügen, benötigen Sie Root-Rechte. Auch die Auswertung mit ausearch erfordert erhöhte Rechte, da die Logs sensible Daten enthalten.
Kann auditd auch Dateiänderungen in Echtzeit überwachen?
Ja, durch die Verwendung von -w (Watch) Regeln, z.B. auditctl -w /etc/passwd -p wa. Das protokolliert Schreib- und Attributänderungen an der Datei.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
