auditd Integration in wazuh

In der dynamischen Welt der Cybersicherheit stellen Credential Access Angriffe eine erhebliche Bedrohung für Unternehmen und Organisationen dar. Diese Angriffe zielen darauf ab, Zugangsdaten zu kompromittieren, um unbefugten Zugriff auf Systeme und sensible Daten zu erlangen. Besonders in Linux-Umgebungen, die in vielen Unternehmensinfrastrukturen weit verbreitet sind, ist die frühzeitige Erkennung solcher Angriffe von entscheidender Bedeutung.

Credential Access Angriffe umfassen eine Vielzahl von Techniken, von Brute-Force-Attacken bis hin zu komplexen Methoden, die Schwachstellen in der Systemkonfiguration ausnutzen. Die rechtzeitige Identifizierung solcher Angriffe ist unerlässlich, um Datenverlust, Systemkompromittierungen und mögliche Reputationsschäden zu vermeiden.

In diesem Artikel präsentiere ich einen Proof-of-Concept (PoC), wie das Open-Source-Sicherheitsinformations- und Ereignismanagement-Tool (SIEM) Wazuh genutzt werden kann, um Credential Access Angriffe in Linux-Umgebungen effektiv zu erkennen und zu überwachen.

Überblick über Credential Access Techniken unter Linux

Bevor wir uns den Erkennungsmethoden widmen, ist es wichtig, die gängigsten Techniken zu verstehen, die Angreifer in Linux-Umgebungen nutzen:

Offline Passwort-Cracking

Angreifer versuchen, Zugriff auf Passwort-Hashes zu erlangen, um diese offline zu knacken, beispielsweise durch Zugriff auf die /etc/shadow-Datei oder durch Speicher-Dumps von Prozessen wie ssh-agent. Tools wie John the Ripper oder Hashcat werden für solche Angriffe verwendet.

Zugriff auf ungesicherte Anmeldeinformationen

Systeme speichern oft Anmeldeinformationen in unverschlüsselter oder schwach verschlüsselter Form. Angreifer suchen nach solchen Informationen in Konfigurationsdateien, Skripten oder temporären Dateien.

Aufbau der Testumgebung

Um die Erkennung von Credential Access Angriffen zu demonstrieren, habe ich eine Testumgebung eingerichtet, die aus folgenden Komponenten besteht:

1. Wazuh-Server: Das zentrale SIEM-System, das Ereignisse sammelt und analysiert.
2. Linux-Endpunkt: Ein Linux-System, das als Ziel für simulierte Angriffe dient und von Wazuh überwacht wird.

Für Testzwecke habe ich LXC-Container in meinem Proxmox-Lab genutzt, was eine flexible und isolierte Umgebung zur Durchführung der Tests ermöglicht.

Konfiguration des Linux-Endpunkts für die Erkennung

Zur effektiven Erkennung von Credential Access Angriffen musste der Linux-Endpunkt entsprechend konfiguriert werden:

Installation und Konfiguration von Auditd

Auditd, ein leistungsfähiges Audit-System für Linux, ermöglicht die Erstellung detaillierter Protokolle über Systemaktivitäten. Installation mittels nala (finde ich deutlich besser als apt):

sudo nala install auditd audispd-plugins

Nala. Paket-Management mit History

Paketmanagement mit Sicherheits-Netz. Einmal probiert - nie wieder ohne!

Meister-Tech-BlogMichael Meister

Erstellung von Audit-Regeln auf dem Linux-Server

Ich habe spezifische Audit-Regeln hinzugefügt, um verdächtige Aktivitäten zu erfassen. Diese wurden zur Datei /etc/audit/rules.d/audit.rules hinzugefügt:

-w /etc/shadow -p wa -k shadow_file_modification
-w /etc/passwd -p wa -k passwd_file_modification
-w /etc/sudoers -p wa -k sudoers_file_modification
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root_execution

Diese Regeln überwachen kritische Systemdateien und protokollieren Root-Befehlsausführungen.

Wazuh-Agent konfigurieren

Um das audit-Log zu beobachten, muss in die /var/ossec/etc/ossec.conf folgendes eingetragen werden:

<ossec_config>  
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

Konfiguration des Wazuh-Servers

Nach der Endpunkt-Konfiguration wurde der Wazuh-Server eingerichtet, um die gesammelten Daten zu analysieren:

Aktualisierung der CDB-Liste

Wazuh verwendet CDB-Listen zur schnellen Suche. Ich habe für meine Tests eine Liste verdächtiger Befehle erstellt unter /var/ossec/etc/lists/suspicious_commands:

/usr/bin/base64:Base64 encoding/decoding
/usr/bin/xxd:Hexdump utility
/usr/bin/od:Octal dump

Implementierung benutzerdefinierter Erkennungsregeln

Folgende Regel wurde zur Datei /var/ossec/etc/rules/local_rules.xml hinzugefügt:

<group name="linux,audit,credential_access">
  <rule id="100200" level="10">
    <if_sid>80700</if_sid>
    <list field="audit.command" lookup="match_key">etc/lists/suspicious_commands</list>
    <description>Suspicious command execution detected: $(audit.command)</description>
  </rule>
</group>

Diese Regel erkennt die Ausführung verdächtiger Befehle basierend auf der definierten CDB-Liste.

Praktische Demonstration der Angriffserkennung

Zur Demonstration der Erkennung habe ich verschiedene Angriffsszenarien simuliert:

Szenario 1: Versuchter Zugriff auf /etc/shadow

Durch Ausführung von:

sudo cat /etc/shadow

wurde eine Warnung in Wazuh generiert, die den Zugriff auf die shadow-Datei meldet.

Szenario 2: Ausführung eines verdächtigen Befehls

Durch Ausführung von:

base64 /etc/passwd

wurde ebenfalls eine Warnung ausgelöst, da der Befehl base64 in der Liste verdächtiger Befehle enthalten ist.

Best Practices für die Implementierung

Bei der Implementierung dieser Erkennungsmethoden habe ich folgende Best Practices berücksichtigt:

Feinabstimmung der Erkennungsregeln

• Anpassung der Regeln an die spezifische Umgebung. Nicht alle Aktivitäten sind in jedem Kontext gleich relevant.
• Regelmäßige Aktualisierung der Liste verdächtiger Befehle basierend auf neuen Bedrohungen und Erfahrungen.

Umgang mit False Positives

• Regelmäßige Überprüfung der Warnungen auf False Positives.
• Whitelisting legitimer Aktivitäten, die fälschlicherweise als verdächtig erkannt wurden.
• Nutzung von Wazuhs Korrelationseigenschaften zur Verbesserung der Erkennungsgenauigkeit.

Warum nicht via Syslog?

Da ich auf meinen Servern, sowohl den Bare Metal Servern als auch den virtuellen Maschinen, immer einen wazuh-agent mit ausrolle, habe ich diesen Weg gewählt. Mein subjektiver Eindruck war, dass dieses Vorgehen stabiler funktionierte. Auditd kann natürlich seine Erkenntnisse auch per Syslog an wazuh melden. Es schien mir dabei allerdings zeitliche Verzögerungen zu geben.

Es gibt jedoch durchaus Gründe, warum man keinen wazuh-agent auf dem Server installieren kann. Am häufigsten wurde ich damit konfrontiert, dass ein Hersteller den Support ablehnt, sobald vom Kunden Änderungen am System vorgenommen werden. Es wurde mir auch schon eine Installation abgelehnt, da das System zeitkritische Aufgaben zu erledigen hat und man befürchtete, der Agent könnte zu viel Ressourcen für sich beanspruchen.

Aber wie es eben immer so ist. Im OSI 10 Layer Modell werden solche Entscheidungen meist im Layer 9 getroffen.

Fazit

Die Erkennung von Credential Access Angriffen in Linux-Umgebungen ist ein wesentlicher Bestandteil der modernen IT-Sicherheit. Durch die Kombination von Auditd auf den Endpunkten und Wazuh als zentrales SIEM-System konnte ich in diesem PoC eine effektive Methode zur Abwehr solcher Bedrohungen nachweisen.

Zukünftige Entwicklungen könnten die Integration von maschinellem Lernen zur Erkennung anomaler Muster oder die Automatisierung von Reaktionen auf erkannte Bedrohungen umfassen. Es bleibt entscheidend, dass IT-Sicherheitsexperten kontinuierlich ihre Verteidigungsstrategien anpassen, um den sich ständig weiterentwickelnden Bedrohungen zu begegnen.