Wazuh-Indexer und needrestart auf Ubuntu 24.04 Server:
Das Java False-Positive verstehen und lösen

Wer Wazuh auf Ubuntu 24.04 Server betreibt, stößt nach jedem apt upgrade auf ein vermeintliches Problem: needrestart meldet den als neustart bedürftig, obwohl der Dienst stabil läuft und die installierten Updates nichts mit dem Indexer zu tun haben. Wer bereits dem Artikel Wazuh-Indexer auf gehärteten Systemen und die /tmp Falle gefolgt ist und das Temp-Verzeichnis auf /var/lib/wazuh-indexer/tmp/ umgeleitet hat, wird dennoch exakt dieses Verhalten beobachten.

needrestart: Default auf Ubuntu 24.04 Server

Seit Ubuntu 22.04 ist needrestart fester Bestandteil der Ubuntu Server Standardinstallation und läuft automatisch als APT/DPKG-Hook nach jedem Paket-Update. Es analysiert laufende Prozesse und prüft, ob diese neu gestartet werden müssen, weil aktualisierte Bibliotheken noch in Form ihrer alten Version im Arbeitsspeicher gehalten werden. Auf Ubuntu 24.04 Server ist dieses Verhalten standardmäßig im interaktiven Modus aktiv, der Administrator wird also bei jedem Update gefragt.

Der Auslöser: /proc/PID/maps und gelöschte Dateien

needrestart liest für jeden laufenden Prozess die Kernel-Datei /proc/<PID>/maps aus. Diese listet alle Dateien auf, die ein Prozess in seinen Adressraum gemappt hat. Findet needrestart dort einen Eintrag mit dem Suffix (deleted), eine Datei also, die im RAM noch gehalten wird, auf der Festplatte aber nicht mehr existiert, wertet es das als Indiz für eine aktualisierte Bibliothek und markiert den Prozess zum Neustart.

Der Wazuh-Indexer (OpenSearch/JVM) nutzt das sogenannte Load-and-Delete-Muster: Beim Start werden native JNI-Bibliotheken wie libzstd-jni in das Temp-Verzeichnis extrahiert, direkt in den Prozessadressraum gemappt und die Datei auf der Festplatte anschließend bewusst gelöscht. Im Adressmapping sieht das dann so aus:

/var/lib/wazuh-indexer/tmp/libzstd-jni-1.5.5-59023198493179607923.so (deleted)

Das ist kein Fehler, sondern gewolltes Verhalten der JVM. needrestart kann es jedoch nicht von einem echten Bibliotheks-Update unterscheiden.

Diagnose: needrestart -v und bestehende Konfiguration prüfen

Bevor man den Fix umsetzt, lohnt ein Blick auf den Ist-Zustand. Zunächst die bestehenden Blacklist-Einträge in der Hauptkonfiguration prüfen:

grep -i "qr" /etc/needrestart/needrestart.conf

Die umfangreiche Ausgabe zeigt, welche Prozesse und Mappings needrestart bereits standardmäßig ignoriert, u. a. VPN-Dienste und systemd interne Prozesse. Der Wazuh-Indexer ist dort nicht aufgeführt.

Dann das Verhalten live nachvollziehen:

admin@wazuh-srv-1# needrestart -v
[main] eval /etc/needrestart/needrestart.conf
[main] #340001 uses deleted/var/lib/wazuh-indexer/tmp/libzstd-jni-1.5.5-59023198493179607923.so
[main] #340001 is not a child
[main] #340001 exe = /usr/share/wazuh-indexer/jdk/bin/java
[Core] #340001 is a NeedRestart::Interp::Java
[Core] #340001 source is UNKNOWN
[main] #340001 is wazuh-indexer.service

Die verbose Ausgabe zeigt klar:needrestart erkennt den Java-Prozess als NeedRestart::Interp::Java, findet das gelöschte Mapping und leitet daraus wazuh-indexer.service ab. [Core] source is UNKNOWN bestätigt dabei, dass keine echte Paketänderung zugrunde liegt, es handelt sich um ein reines False Positive.

Konfigurationsstruktur von needrestart

Die Verzeichnisstruktur unter/etc/needrestart/sieht auf einem frischen Ubuntu 24.04 Server so aus:
/etc/needrestart/
├── conf.d/
│  └── README.needrestart
├── hook.d/
│  ├── 10-dpkg
│  ├── 20-rpm
│  └── 90-none
├── iucode.sh
├── needrestart.conf
├── notify.conf
├── notify.d/
│  ├── 200-write
│  ├── 400-notify-send
│  ├── 600-mail
│  └── README.needrestart
├── restart.d/
│  ├── dbus.service
│  ├── README.needrestart
│  ├── systemd-manager
│  └── sysv-init

Eigene Anpassungen gehören ausschließlich nach /etc/needrestart/conf.d/, niemals direkt in die needrestart.conf. Drop-In-Dateien in conf.d/ werden automatisch beim nächsten needrestart Aufruf geladen, überstehen Paket-Updates ohne Überschreibung und lassen sich einzeln deaktivieren oder versionieren.

Die Lösung: Mapping-Blacklist per Drop-In

Der korrekte Fix schließt nicht den gesamten Service aus, das würde echte Neustart-Notwendigkeiten (z. B. nach einem Update des wazuh-indexer-Pakets selbst) unterdrücken. Stattdessen wird nur das spezifische Mapping-Muster per Drop-In ignoriert:

cat > /etc/needrestart/conf.d/wazuh-indexer.conf << 'EOF'
push @{ $nrconf{blacklist_mappings} }, qr(^/var/lib/wazuh-indexer/tmp/.*\.so( \(deleted\))?$);
EOF

Der Regex greift gezielt alle.so Bibliotheken im Wazuh-Indexer-Temp-Verzeichnis ab, unabhängig von den wechselnden Versionsnummern im Dateinamen. Kein Daemon-Reload notwendig, die Datei wird sofort beim nächsten needrestart Aufruf eingelesen.

Ergebnis nach dem Fix

needrestart -v
...
No services need to be restarted.
...

Der wazuh-indexer.service erscheint nicht mehr in der Neustart-Liste. Echte Bibliotheks-Updates anderer Dienste werden weiterhin korrekt erkannt ➸ der Fix ist präzise und hat keine Nebenwirkungen auf das restliche System.

Lösungen sind erst dann seriös, wenn man die Hintergründe verstanden hat. Daher bietet es sich an, sich näher mit der Thematik needrestart zu beschäftigen, und die Lösung hierzu entsprechend zu dokumentieren. Merke: System-Härtungen und System-Konfigurationen sollte man stets mit Sachverstand bearbeiten.

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.