Wazuh Vulnerability-Detection und unnötige Kernel-CVEs kontrolliert bereinigen

Die mächtige Vulnerability-Detection von Wazuh erkennt schonungslos registrierte Pakete und deren CVEs. Bei einer Linux-Distribution basierend auf der RHEL-Familie wie z.b. Rocky Linux, kann die Anzahl erkannter Kernel-Schwachstellen zunächst irritieren.

Oftmals fragt sich der IT-Admin, warum Wazuh teils hunderte CVEs für Kernel Versionen anzeigt, die eigentlich seit Monaten nicht mehr im aktiven Einsatz sind. Immerhin, das System wurde vollständig aktualisiert, läuft bereits mit dem neuesten Kernel und Wazuh meldet dennoch zahlreiche CVEs für ältere Kernelversionen.

Don't shoot the messenger

Kernel-Pakete werden unter RHEL-basierten Systemen als installonly-Pakete behandelt. Eine neue Kernelversion wird zusätzlich installiert und beim nächsten Reboot geladen. Die vorherigen Kernelversionen (Plural!) bleiben als Rückfalloption installiert, bis das konfigurierte installonly_limit (default 3) überschritten oder eine manuelle Bereinigung durchgeführt wird.

Wazuh bewertet dabei nicht ausschließlich den aktuell laufenden Kernel, sondern den tatsächlich installierten Paketbestand. Solange ältere Kernel-Pakete installiert bleiben, sind sie Bestandteil des System-Inventars und damit auch der Vulnerability-Detection.

Der hier dokumentierte Test wurde mit folgender Umgebung durchgeführt:

Rocky Linux 9 und Wazuh 4.14.6

Dieser Artikel betrachtet klassische RPM-/DNF-basierte Systeme der RHEL-Familie ab Generation 8, darunter Rocky Linux, AlmaLinux und Red Hat Enterprise Linux 8 bis 10 im Package Mode.

Wazuh bewertet installierte Kernel-Pakete

Der Wazuh-Agent erfasst mit dem Modul 'Syscollector' unter anderem die installierten Softwarepakete und übermittelt diesen Bestand regelmäßig an den Wazuh-Server. Die Vulnerability-Detection korreliert die Paketnamen und Paketversionen anschließend mit den Vulnerability-Daten der Wazuh CTI-Plattform.

Unter Rocky Linux 9 besteht ein Kernel im dokumentierten Test nicht nur aus einem einzelnen RPM-Paket, sondern aus:

kernel
kernel-core
kernel-modules
kernel-modules-core

Andere Systeme können zusätzlich beispielsweise folgende Pakete enthalten:

kernel-modules-extra
kernel-devel
kernel-headers

Maßgeblich ist deshalb immer der tatsächlich installierte Bestand des jeweiligen Systems.

Ist eine ältere Kernel-Version weiterhin installiert (aber nicht aktiv in Benutzung), wird sie von Wazuh dennoch als vorhandene Software behandelt. Das ist fachlich korrekt: Der Kernel befindet sich noch auf dem System und kann grundsätzlich über den Bootloader gestartet werden.

Den aktuell laufenden Kernel prüfen

Zunächst wird kontrolliert, welcher Kernel tatsächlich läuft:

uname -r

Im Testsystem war dies:

5.14.0-687.12.1.el9_8.x86_64

Diese Version darf keinesfalls Bestandteil der späteren Entfernung sein.

Alle installierten Kernel-Versionen anzeigen

Die installierten installonly-Pakete werden mit folgendem Befehl abgefragt:

dnf repoquery --installonly --installed

Das Rocky-Linux-9-System enthielt drei vollständige Kernel-Versionen:

5.14.0-687.12.1.el9_8

5.14.0-611.54.1.el9_7

5.14.0-611.36.1.el9_7

Damit ergab sich folgende Situation:

5.14.0-687.12.1.el9_8 aktuell laufender Kernel

5.14.0-611.54.1.el9_7 Rückfall-Kernel

5.14.0-611.36.1.el9_7  ältester Kernel

Der älteste Kernel wird nicht mehr benötigt. Der unmittelbar vorherige Kernel sollte dagegen bewusst als Rückfalloption erhalten bleiben.

Warum standardmäßig drei Kernel-Versionen installiert bleiben

Die Anzahl parallel installierter installonly-Paketversionen wird über folgende DNF-Einstellung gesteuert:

installonly_limit

Der Standardwert von DNF und DNF5 lautet:

installonly_limit=3

Damit werden normalerweise drei Kernel-Versionen parallel gehalten. Der Minimalwert beträgt 2; der Wert 1 ist nicht zulässig. 0 würde das Limit vollständig deaktivieren und die Folge wären dutzende alte Kernelversionen! RTFM: https://dnf.readthedocs.io/en/latest/conf_ref.html

Der Standard entspricht vereinfacht:

aktueller Kernel
+ erster Rückfall-Kernel
+ zweiter Rückfall-Kernel

Für viele Serversysteme reicht jedoch folgende Konstellation vollständig aus:

aktueller Kernel
+ ein Rückfall-Kernel

Jede zusätzlich installierte Kernel-Version belegt nicht nur unnötig Speicherplatz, sondern vergrößert auch den von Wazuh inventarisierten und auf Schwachstellen geprüften Paketbestand erheblich.

Ausgangslage in Wazuh Vulnerability-Detection

Vor der Bereinigung zeigte das Wazuh Vulnerability-Inventory beim expliziten Filter auf das Paket 'kernel' insgesamt 230 aktive Findings, deren Bewertung auf das 'Rocky Enterprise Product Errata' basiert. Auffällig sind dabei zahlreiche Findings für die älteste und nicht genutzte Kernel-Version 5.14.0-611.36.1.el9_7.

Ein Reboot allein, nach einem entsprechenden Update, entfernt diese Findings nicht. Der neuere Kernel wird dadurch zwar gestartet, die älteren Kernel-RPMs bleiben jedoch weiterhin installiert, wie bereits weiter oben erläutert.

Die ältesten Kernel-Pakete gezielt ermitteln.

Die beiden neuesten Kernel-Versionen sollen erhalten bleiben. Alle älteren installonly-Pakete können mit folgender Abfrage ermittelt werden:

dnf repoquery --installonly --installed --latest-limit=-2

Die Option --latest-limit=-2 bedeutet: Die zwei neuesten Versionen je Paketname und Architektur werden von der Ausgabe ausgeschlossen. Ausgegeben werden nur ältere installierte Versionen. Diese Semantik ist sowohl in DNF4 als auch in DNF5 vorhanden.

Im Testsystem wurden ausschließlich folgende Pakete ausgegeben:

kernel-5.14.0-611.36.1.el9_7.x86_64
kernel-core-5.14.0-611.36.1.el9_7.x86_64
kernel-modules-5.14.0-611.36.1.el9_7.x86_64
kernel-modules-core-5.14.0-611.36.1.el9_7.x86_64

Damit wurde ausschließlich die älteste Kernel-Version als Löschkandidat ausgewählt. Sind bereits nur zwei Kernel-Versionen installiert, darf die Abfrage keine Pakete mehr ausgeben.

Die Entfernung zuerst im Dry-Run testen.

Vor der tatsächlichen Deinstallation wird die vollständige DNF-Transaktion geprüft:

dnf remove --assumeno $(dnf repoquery --installonly --installed --latest-limit=-2)

--assumeno führt die Abhängigkeitsauflösung und Transaktionsplanung durch, beantwortet die abschließende Rückfrage jedoch automatisch mit Nein.

Im Testsystem wurden ausschließlich folgende vier Pakete zur Entfernung vorgesehen:

kernel
kernel-core
kernel-modules
kernel-modules-core

Alle Pakete gehörten exakt zur Kernel-Version:

5.14.0-611.36.1.el9_7

Der aktuell laufende Kernel 5.14.0-687.12.1.el9_8 und der vorgesehene Rückfall-Kernel 5.14.0-611.54.1.el9_7 waren nicht Bestandteil der Transaktion. Erst nachdem diese Ausgabe vollständig geprüft wurde, sollte die tatsächliche Entfernung erfolgen.

Warum ich den vermeintlich einfacheren Befehl nicht verwende.

DNF bietet ebenfalls folgende Funktion:

dnf remove --oldinstallonly

Über eine temporäre Änderung des Limits könnte man daher auf die Idee kommen, folgenden Befehl zu verwenden:

dnf remove --oldinstallonly --setopt installonly_limit=2

Die dokumentierte Funktion von --oldinstallonly besteht darin, ältere installonly-Pakete unter Berücksichtigung des konfigurierten Limits zu entfernen. Auf einem eigenen Rocky-Linux-8-System führte genau diese Kombination jedoch zu folgendem Ergebnis:

Vorher: drei installierte Kernel-Versionen
Nachher: nur noch der aktuell laufende Kernel

Es wurden somit nicht nur der älteste, sondern beide vorherigen Kernel-Versionen entfernt. 🫣

Deshalb verwende ich für diese Bereinigung bewusst die transparente Abfrage über:

dnf repoquery --installonly --installed --latest-limit=-2

Die tatsächlich betroffenen RPM-Pakete sind damit vor der Deinstallation vollständig sichtbar und können zunächst mit --assumeno geprüft werden.

Den ältesten Kernel entfernen.

Nachdem der Dry-Run ausschließlich die vorgesehenen Pakete angezeigt hatte, wurde die tatsächliche Entfernung ausgeführt:

dnf remove $(dnf repoquery --installonly --installed --latest-limit=-2)

Anschließend wird der installierte Bestand erneut kontrolliert:

dnf repoquery --installonly --installed

Übrig blieben im Test:

5.14.0-687.12.1.el9_8
5.14.0-611.54.1.el9_7

Damit standen weiterhin zwei Kernel-Versionen zur Verfügung:

5.14.0-687.12.1.el9_8  aktuell laufender Kernel
5.14.0-611.54.1.el9_7  Rückfall-Kernel

Das Ergebnis der Wazuh Vulnerability-Detection.

Wazuh erkannte die entfernten RPM-Pakete beim nächsten regulären Syscollector-Lauf und aktualisierte daraufhin das Vulnerability-Inventory.

Wazuh erzeugt Paket-Alerts, wenn Schwachstellen durch die Installation oder Entfernung eines Pakets zum Inventory hinzugefügt oder daraus entfernt werden. Voraussetzung für entsprechende Events ist, dass die Paketänderung während eines regulären Syscollector-Scans erkannt wird.

Beim exakten Filter auf den Paketnamen 'kernel' wurden im Test 98 Solved-Events erzeugt!

Im Vulnerability-Inventory blieben anschließend 132 aktive Findings für die weiterhin installierten Kernel-Versionen übrig.

Damit ergibt sich für das explizite Paket 'kernel':

230 aktive Findings vor der Bereinigung
- 98 aufgelöste Findings
----------------------------------------
132 verbleibende Findings

Wird in der Events-Ansicht nicht ausschließlich nach dem exakten Paketnamen 'kernel', sondern breiter nach '*kernel*' über sämtliche passenden Kernel-Pakete gesucht, zeigte das Testsystem 392 Solved-Events!

Der entfernte Kernelstand bestand aus vier separat inventarisierten RPM-Paketen:

kernel
kernel-core
kernel-modules
kernel-modules-core

Für jedes dieser Pakete wurden im dokumentierten Test jeweils 98 paketbezogene Statusänderungen verarbeitet. 98 Solved-Events × 4 entfernte RPM-Pakete = 392 Solved-Events in Summe! Das bedeutet nicht, dass 392 unterschiedliche CVE-IDs beseitigt wurden. Die Events sind paketbezogen. Dieselbe CVE kann mehreren RPM-Bestandteilen eines Kernels zugeordnet sein und dadurch für jedes betroffene Paket ein eigenes Event erzeugen.

Künftig nur zwei Kernel-Versionen behalten.

Nach der kontrollierten manuellen Bereinigung wird das dauerhafte Limit in folgender Datei angepasst:

/etc/dnf/dnf.conf

Unterhalb des Abschnitts [main] wird eingetragen:

installonly_limit=2

Existiert bereits ein Eintrag, wird dessen Wert entsprechend geändert.

Kontrolle:

grep -Ei '^[[:space:]]*installonly_limit=' /etc/dnf/dnf.conf

Erwartete Ausgabe:

installonly_limit=2

Das bloße Ändern der Konfiguration entfernt keine bereits installierten Kernel, sondern das Limit wirkt erst bei zukünftigen DNF-Transaktionen. Nach dem nächsten Kernel-Update hält DNF anschließend grundsätzlich:

neuer Kernel
+ unmittelbar vorheriger Kernel als Rückfalloption

Die dann älteste Kernel-Version wird aus dem installierten Paketbestand entfernt. Das Entfernen eines nicht mehr benötigten Kernels ist weder ein Wazuh-Workaround noch eine Unterdrückung von Schwachstellen, sondern saubere Paketpflege!

Nachdem nicht mehr benötigte Kernel-Pakete entfernt wurden, arbeitet Wazuh diesen Prozess ab:
→ Syscollector aktualisiert das Software-Inventar
→ Vulnerability-Detection bewertet den neuen Bestand
→ nicht mehr zutreffende Findings werden auf Solved gesetzt

Wazuh zeigt anschließend weiterhin sämtliche Schwachstellen der tatsächlich installierten Kernel-Pakete an. Die Wazuh Vulnerability-Detection ist nur so sauber wie das zugrunde liegende Software-Inventar. Nicht mehr benötigte Kernel-Pakete zu entfernen gehört deshalb ebenso zur regulären Systempflege wie die Installation aktueller Sicherheitsupdates. Selbstverständlich gilt dies auch für alle anderen ungenutzten Pakete, wie z. B. alte PHP und Java Versionen.

Das Beispiel mit dem Kernel ist jedoch besonders prominent, da häufig 3 (ab und an sogar mehr) alte Kernel-Versionen auf ein System schlummern, ohne jemals genutzt zu werden … und eine alte Kernel-Version kann durchaus mal 100+ CVEs aufweisen.

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

Als Wazuh-Experte und offizieller Wazuh Platinum 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.