Schematischer Aufbau eines SIEM Systems.

Wazuh-Indexer auf gehärteten Systemen und die /tmp Falle

Werden IT-Infrastrukturen und deren Linux Distributionen basierend auf den weltweit anerkannten CIS-Benchmarks™ gehärtet, stößt man bei der Implementierung von Wazuh SIEM und dessen Wazuh-Indexer (basierend auf OpenSearch 2.19.4) auf ein kritisches Problem.

Die gängigen CIS-Benchmarks™ wie z. B. der "CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0" vom 08.26.2024, fordern bereits im Level-1 Server Profil restriktive Mount-Optionen um sich vor schädlichen Binaries und Malware besser zu schützen. 

Besonders die Option noexec auf der /tmp Partition dient dazu, auf dieser "für alle zugänglichen" Partition, eine Ausführung von Binaries und Skripten zu unterbinden. Allerdings sorgt diese Sicherheitseinstellung auch, dass der Wazuh-Indexer den Dienst quittiert.


Die Ursache: JNA und noexec


Der Wazuh-Indexer nutzt u. a. Java und die JNA (Java Native Access) Library, um native Systemfunktionen aufzurufen. Zur Laufzeit entpackt JNA native Bibliotheken (.so-Dateien) in das durch die JVM definierte temporäre Verzeichnis ➸ standardmäßig /tmp. 

Ist /tmp gemäß CIS-Vorgaben mit noexec gemountet, verhindert der Kernel das Mapping dieser Dateien in den Adressraum des Prozesses. Der Wazuh-Indexer bricht den Bootstrap-Vorgang sofort ab.

Fehleranalyse im JSON-Log


Da der Wazuh-Indexer seine Logs auch im JSON-Format schreibt, lässt sich der Fehler effizient mit jq extrahieren. Ein typischer Fehlerbericht in der wazuh-cluster_server.json sieht wie folgt aus:


jq 'select(.stacktrace[]? | contains("UnsatisfiedLinkError"))' /var/log/wazuh-indexer/wazuh-cluster_server.json


{ 

  "type":"server",

  "timestamp":"2026-01-27T17:19:25,773Z",

  "level": "WARN",

  "component": "o.o.b.Natives",

  "cluster.name":"wazuh-cluster",

  "node.name": "wazuh-indexer",

  "message": "unable to load JNA native support library, native methods will be disabled.",

  "stacktrace": [

    "java.lang.UnsatisfiedLinkError: /tmp/opensearch-abc123/jna321.tmp: /tmp/opensearch-abc123/jna321.tmp: failed to map segment from shared object",

   "..."

  ]

},
{
 "type": "server",
 "timestamp": "2026-01-27T17:19:45,052Z",
 "level": "ERROR",
 "component":"o.o.b.OpenSearchUncaughtExceptionHandler",
 "cluster.name": "wazuh-cluster",
 "node.name": "wazuh-indexer",
 "message": "fatal error in thread [opensearch[wazuh-indexer][scheduler][T#1]], exiting",
 "stacktrace": [
 "java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native",
 "..."
 "Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: /tmp/opensearch-abc123.tmp: /tmp/opensearch-abc123/jna321.tmp: failed to map segment from shared object [in thread \"main\"]",
 "..."

  ]
}


Die Pfadangabe mit "/tmp/opensearch-" und die Meldung "failed to map segment from shared object"  ist das eindeutige Indiz für eine durch noexec blockierte Ausführung.

Die Lösung: Umleitung des java.io.tmpdir


Um die CIS-Compliance für /tmp nicht aufweichen zu müssen, wird der JVM ein dediziertes temporäres Verzeichnis zugewiesen. Dieses sollte auf einer Partition liegen, auf der die Ausführung von Code erlaubt ist (z. B. /var), und muss restriktive Zugriffsberechtigungen besitzen.


Umsetzung

  1. Dediziertes Verzeichnis erstellen:
    Wir nutzen    /var/lib/wazuh-indexer/tmp, da /var in der Regel die notwendigen Berechtigungen besitzt und der Speicherplatz für die Indizierung ohnehin dort liegt.

    mkdir -p /var/lib/wazuh-indexer/tmp
    chown wazuh-indexer:wazuh-indexer /var/lib/wazuh-indexer/tmp
    chmod 750 /var/lib/wazuh-indexer/tmp

  2. JVM-Konfiguration anpassen:
    Die Konfiguration erfolgt direkt über die JVM-Optionen des Indexers. Editieren Sie die Datei     /etc/wazuh-indexer/jvm.options:

    vim /etc/wazuh-indexer/jvm.options

    Fügen Sie am Ende die folgende Zeile hinzu:

    # CIS Hardening has noexec on /tmp, so we give him another path.
    -Djava.io.tmpdir=/var/lib/wazuh-indexer/tmp

  3. systemd Unit File anpassen:
    Ratsam ist es auch, das SystemdD Unit File vom Wazuh-Indexer anzupassen und dort die Umgebungsvariable     OPENSEARCH_TMPDIR zu hinterlegen:

    [Service]
    ... 
    Environment="OPENSEARCH_TMPDIR=/var/lib/wazuh-indexer/tmp"

  4. Dienst neustarten:

    systemctl daemon-reload && systemctl restart wazuh-indexer

    Mit klassischen Tools prüfen, ob der Wazuh-Indexer Prozess auch den neuen     tmp Pfad übernommen hat:

    ps aux | grep wazuh-indexer | grep -i '\-Djava.io.tmpdir='

Sicherheit durch Härtung darf die Funktionalität kritischer SIEM-Systeme nicht behindern. Durch die gezielte Umleitung des java.io.tmpdir bleibt die /tmp-Partition gemäß CIS-Benchmark mit noexec abgesichert, während der Wazuh-Indexer stabil läuft. Der Platzbedarf für dieses Verzeichnis ist mit weniger als 100 MB minimal, da dort lediglich kleine Shared Objects für den JNA-Betrieb abgelegt werden.


Meine Dienstleistungen für Sie: SIEM-Systeme, Systemhärtung und Compliance-Anforderungen


Als Wazuh-Experte  und offizieller Wazuh Ambassador, biete ich mit meinem Unternehmen Gray-Hat IT-Security Consulting professionelle Unterstützung bei der Implementierung von Wazuh SIEM in Ihrer IT-Infrastruktur an. Meine Expertise umfasst nicht nur die fachgerechte Etablierung eines SIEM-Systems, sondern auch die systematische Härtung Ihrer Server und Netzwerke, sodass selbst produktive Umgebungen optimal geschützt sind. Dabei berücksichtige ich wichtige Compliance-Anforderungen wie ISO 27001:2022 und NIS-2, um sicherzustellen, dass Ihre IT-Infrastruktur nicht nur sicher, sondern auch mit Ihrer Compliance bzw. ISMS konform sind.

Falls Sie ebenfalls Ihre Sicherheitslage mit Wazuh optimieren, Ihre Systeme härten oder spezifische Compliance-Anforderungen erfüllen möchten, unterstütze ich Sie gerne mit meiner Erfahrung und einem umfassenden Angebot an Lösungen.

Kontaktieren Sie mich