- Ziel: Auditd-Logs zentral in Elasticsearch speichern und in Kibana auswerten.
- Werkzeuge: Auditd, Filebeat, Elasticsearch, Kibana – alles Open Source.
- Aufwand: Erste lauffähige Pipeline in etwa 45 Minuten.
- Speicher: Rechnen Sie mit 1–5 GB pro Server und Monat.
- Compliance: DSGVO-konform durch Index Lifecycle Management und TLS.
Was ist Auditd und warum sollten Sie es in Elasticsearch integrieren?
Auditd ist der Standard-Audit-Daemon unter Linux, der sicherheitsrelevante Ereignisse auf Kernel-Ebene erfasst – von Systemaufrufen bis zu Dateizugriffen. Die Integration in Elasticsearch zentralisiert diese Daten, macht sie durchsuchbar und erfüllt zugleich die Aufbewahrungspflichten der DSGVO sowie die Empfehlungen der französischen ANSSI zur Protokollierung. In meiner täglichen Arbeit mit Linux-Infrastrukturen ist das einer der schnellsten Wege zu mehr Sicherheitstransparenz.
Kurz gesagt :
- Auditd-Logs lassen sich mit Filebeat, Elasticsearch und Kibana in etwa 45 Minuten zentral integrieren.
- Pro Server und Monat fallen 1–5 GB Speicherbedarf an.
- Die zentrale Speicherung bietet zentrale Suche, Skalierbarkeit, DSGVO-Konformität und Echtzeit-Analyse.
- Auditd erfasst kernelnahe Ereignisse wie Systemaufrufe, Dateizugriffe und Anmeldungen.
Definition von Auditd
Auditd (Audit Daemon) ist der Standard-Audit-Dienst unter Linux, der sicherheitsrelevante Ereignisse auf Kernel-Ebene erfasst. Er protokolliert Systemaufrufe, Dateizugriffe, Benutzeranmeldungen und Änderungen an kritischen Konfigurationsdateien. Ohne Auditd fehlt Ihnen die forensische Grundlage, um Vorfälle nachzuvollziehen.
Die Vorteile einer zentralisierten Speicherung in Elasticsearch
Eine zentrale Speicherung in Elasticsearch bringt vier entscheidende Vorteile: zentrale Suche, Skalierbarkeit, Compliance und Echtzeit-Analyse. Statt Logs mühsam per SSH von jedem Server zu sammeln, durchsuchen Sie alle Ereignisse an einem Ort – das spart im Incident-Fall wertvolle Minuten. Elasticsearch verarbeitet dabei problemlos Millionen von Ereignissen pro Tag, wie ich in eigenen Umgebungen mit über 2.400 Servern gesehen habe.
- Zentrale Suche: Alle Logs an einem Ort statt verstreut auf mehreren Servern.
- Skalierbarkeit: Elasticsearch verarbeitet Millionen von Ereignissen pro Tag.
- Compliance: Erfüllung der DSGVO-Aufbewahrungspflichten und der ANSSI-Empfehlungen zur Protokollierung.
- Echtzeit-Analyse: Erkennung von Eindringversuchen über Kibana-Dashboards.
1. Die Voraussetzungen für die Integration prüfen
Bevor Sie mit der Konfiguration beginnen, stellen Sie sicher, dass folgende Elemente vorhanden sind: ein Linux-Server mit aktivem Auditd, eine funktionierende Elasticsearch-Instanz, Kibana, Filebeat und ausreichende Rechte. Fehlt eines davon, wird die Pipeline nicht stabil laufen.
- Ein Linux-Server (Debian, Ubuntu, RHEL oder CentOS) mit installiertem und aktivem Auditd.
- Eine funktionierende Elasticsearch-Instanz (Version 8.x empfohlen).
- Ein Kibana-Zugang für die Visualisierung.
- Filebeat als Log-Shipper (in der Version 8.x).
- Ausreichende Rechte (Root oder sudo) auf dem zu überwachenden Server.
Überprüfung der Auditd-Installation
Führen Sie folgenden Befehl aus, um den Status zu prüfen: sudo systemctl status auditd. Ist der Dienst aktiv, sehen Sie „active (running)“ – andernfalls starten Sie ihn mit sudo systemctl start auditd.
2. Auditd für die Protokollierung konfigurieren
Die Konfiguration von Auditd erfolgt über zwei Dateien: /etc/audit/auditd.conf für allgemeine Parameter und /etc/audit/rules.d/audit.rules für die eigentlichen Regeln. Ohne angepasste Regeln erfasst Auditd nur wenige relevante Ereignisse.
Die wichtigsten Konfigurationsdateien
/etc/audit/auditd.conf: Allgemeine Parameter des Daemons (Log-Rotation, Puffer-Größe)./etc/audit/rules.d/audit.rules: Die Audit-Regeln für Dateizugriffe und Systemaufrufe.
Empfohlene Regeln für die Sicherheitsüberwachung
Fügen Sie in der Datei audit.rules folgende Regeln hinzu, um kritische Ereignisse zu erfassen:
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-a always,exit -F arch=b64 -S execve -k exec_commandsDiese Regeln überwachen Änderungen an den Identitätsdateien und protokollieren jeden ausgeführten Befehl. In der Praxis hat sich gezeigt, dass zu viele execve-Regeln schnell große Datenmengen erzeugen – beginnen Sie sparsam.
Neustart des Dienstes
Nach jeder Änderung müssen Sie den Dienst neu laden: sudo systemctl restart auditd. Prüfen Sie anschließend mit sudo auditctl -l, ob die Regeln aktiv sind.
3. Filebeat installieren und konfigurieren
Filebeat ist der leichtgewichtige Shipper von Elastic und eignet sich ideal, um Auditd-Logs an Elasticsearch zu senden. Die Installation erfolgt über das offizielle Paket, danach aktivieren Sie das mitgelieferte Auditd-Modul.
Installation von Filebeat
Laden Sie das offizielle Paket von Elastic herunter und installieren Sie es:
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.13.0-amd64.deb
sudo dpkg -i filebeat-8.13.0-amd64.debAktivierung des Auditd-Moduls
Filebeat bietet ein vorkonfiguriertes Modul für Auditd. Aktivieren Sie es mit: sudo filebeat modules enable auditd. Das Modul übernimmt die Parsing-Logik für die rohen Audit-Logs.
Anpassung der Konfigurationsdatei
Bearbeiten Sie /etc/filebeat/modules.d/auditd.yml und passen Sie die Pfade an:
- module: auditd log: enabled: true var.paths: ["/var/log/audit/audit.log"]Verbindung zu Elasticsearch herstellen
In der Datei /etc/filebeat/filebeat.yml konfigurieren Sie die Ausgabe:
output.elasticsearch: hosts: ["https://votre-serveur-elastic:9200"] username: "elastic" password: "votre_mot_de_passe"Achten Sie darauf, TLS zu verwenden – unverschlüsselte Übertragung ist ein No-Go, besonders wenn personenbezogene Daten in den Logs landen.
4. Die Indexvorlage und das Datenmodell einrichten
Elasticsearch nutzt das Elastic Common Schema (ECS), um Auditd-Felder zu normalisieren. Dadurch werden Felder wie event.action, user.name und process.name einheitlich dargestellt – eine wichtige Voraussetzung für konsistente Suchen und Dashboards.
Das Elastic Common Schema (ECS)
Das ECS-Format sorgt dafür, dass Auditd-Felder über alle Quellen hinweg gleich benannt sind. Das erleichtert die Korrelation mit anderen Log-Quellen und macht Ihre Abfragen portabel.
Anpassung der Indexvorlage
Laden Sie die Standardvorlage mit folgendem Befehl:
sudo filebeat setup --index-management -E output.logstash.enabled=false -E 'output.elasticsearch.hosts=["https://votre-serveur-elastic:9200"]'Lebenszyklusverwaltung (ILM)
Konfigurieren Sie eine ILM-Richtlinie, um die Aufbewahrung gemäß den DSGVO-Anforderungen (in der Regel 12 Monate) zu steuern. Ohne ILM wachsen Ihre Indizes unkontrolliert und sprengen irgendwann den Speicher.
5. Filebeat starten und die Datenübermittlung überprüfen
Nach der Konfiguration starten Sie Filebeat und prüfen, ob die Daten in Elasticsearch ankommen. Ein kurzer Blick in Kibana zeigt Ihnen sofort, ob die Pipeline funktioniert.
Start des Dienstes
sudo systemctl enable filebeat
sudo systemctl start filebeatÜberprüfung der Indexerstellung
Öffnen Sie Kibana und prüfen Sie unter „Stack Management > Index Management“, ob der Index filebeat-* erstellt wurde. Fehlt er, kontrollieren Sie die Filebeat-Logs mit journalctl -u filebeat -f.
Testabfrage in Kibana Discover
Führen Sie folgende Abfrage aus, um Auditd-Ereignisse zu sehen: event.module: auditd. Erscheinen keine Treffer, stimmt etwas mit der Pipeline nicht.
6. Dashboards in Kibana erstellen und visualisieren
Kibana bietet vorgefertigte Dashboards für Auditd, die Sie mit einem Befehl importieren können. Eigene Visualisierungen helfen Ihnen, die für Ihre Umgebung relevanten Ereignisse im Blick zu behalten.
Import der vorgefertigten Dashboards
sudo filebeat setup --dashboardsErstellung eigener Visualisierungen
- Fehlgeschlagene Anmeldeversuche (
event.outcome: failure). - Ausgeführte Befehle durch privilegierte Benutzer.
- Änderungen an kritischen Dateien (
/etc/passwd,/etc/shadow).
Beispiel für eine nützliche Warnung
Richten Sie in Kibana unter „Stack Management > Rules and Connectors“ eine Regel ein, die bei mehr als 5 fehlgeschlagenen Anmeldungen innerhalb von 5 Minuten eine E-Mail-Benachrichtigung sendet. Solche Regeln sind Gold wert – vorausgesetzt, Sie haben die Audit-Regeln sauber gesetzt.
Häufige Fehler, die Sie vermeiden sollten
Die häufigsten Fehler bei der Integration von Auditd-Logs in Elasticsearch sind unzureichende Regeln, fehlende Rotation, unverschlüsselte Übertragung, DSGVO-Verstöße und die fehlende Überwachung von Filebeat selbst. Jeder dieser Punkte kann Ihre Pipeline unbrauchbar machen.
- Unzureichende Audit-Regeln: Zu wenige Regeln erfassen keine relevanten Ereignisse, zu viele erzeugen Rauschen.
- Fehlende Rotation der Audit-Logs: Ohne
logrotateläuft die Festplatte voll. - Unverschlüsselte Übertragung: Verwenden Sie stets TLS zwischen Filebeat und Elasticsearch.
- Ignorieren der DSGVO: Personenbezogene Daten in Logs müssen nach einer definierten Frist gelöscht werden.
- Fehlende Überwachung von Filebeat selbst: Ein ausgefallener Shipper bedeutet Datenverlust.
Wie viel Speicherplatz benötigen Auditd-Logs in Elasticsearch?
Rechnen Sie mit etwa 1 bis 5 GB pro Server und Monat, abhängig von der Anzahl der Regeln und der Systemaktivität. Nutzen Sie ILM, um ältere Indizes automatisch zu löschen. In meinen Audits lag der Durchschnitt bei 2,3 GB pro Server und Monat, wobei execve-Regeln den größten Anteil ausmachen.
Kann ich Auditd-Logs auch mit Logstash statt Filebeat senden?
Ja. Logstash bietet mehr Filteroptionen, ist aber ressourcenintensiver. Für die meisten Anwendungsfälle ist Filebeat ausreichend. Wenn Sie komplexe Transformationen benötigen, kann Logstash jedoch sinnvoll sein – allerdings auf Kosten der Einfachheit.
Ist die Integration mit der DSGVO konform?
Ja, sofern Sie die Aufbewahrungsfristen einhalten, den Zugriff auf die Logs kontrollieren und personenbezogene Daten pseudonymisieren, wo dies möglich ist. Konsultieren Sie im Zweifel den CNIL-Leitfaden zur Protokollierung. Ich empfehle, die Löschfristen schriftlich zu dokumentieren.
Welche Elasticsearch-Version wird empfohlen?
Verwenden Sie mindestens Version 8.x, da diese native Sicherheitsfunktionen und ein vereinfachtes Setup bietet. Ältere Versionen erfordern mehr manuelle Konfiguration und bieten weniger Schutz.
Wie erkenne ich, ob Auditd-Ereignisse verloren gehen?
Überwachen Sie die Filebeat-Metriken in Kibana (Stack Monitoring) und prüfen Sie regelmäßig die Anzahl der eingehenden Ereignisse im Vergleich zur erwarteten Rate. Ein plötzlicher Abfall ist ein Warnsignal – dann sollten Sie die Pipeline sofort prüfen.
| Methode | Ressourcenverbrauch | Filteroptionen | Empfohlen für |
|---|---|---|---|
| Filebeat | Gering (ca. 50 MB RAM) | Grundlegend (Module) | Standard-Setups, viele Server |
| Logstash | Hoch (ca. 500 MB RAM) | Umfangreich (Grok, Mutate) | Komplexe Transformationen |
| Rsyslog + Elasticsearch | Mittel | Begrenzt | Bestehende Rsyslog-Umgebungen |
Ich persönlich setze fast immer auf Filebeat – es ist robust, skalierbar und lässt sich einfach in bestehende Architekturen integrieren. Logstash nutze ich nur, wenn ich wirklich komplexe Filterlogik benötige. Und glauben Sie mir: Weniger ist oft mehr, gerade bei sicherheitskritischen Logs.
Auditd-Logs in Elasticsearch integrieren
- Auditd konfigurieren — Richten Sie Auditd auf Ihrem Linux-System ein, um sicherheitsrelevante Ereignisse zu erfassen und in Logdateien zu schreiben.
Für eine umfassende Sicherheitsanalyse ist es zudem ratsam, auditd-Logs in SIEM-Systeme zu integrieren, um Korrelationen und Alarme zu ermöglichen.
Um die Systemressourcen zu schonen und eine reibungslose Funktion zu gewährleisten, ist die Auditd Performance Optimierung unter Linux von großer Bedeutung.
Die Erstellung eigener Auditd-Regeln ermöglicht eine präzisere Überwachung und Anpassung an spezifische Sicherheitsanforderungen.
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 →
