Wazuh Vulnerability Detection auf Debian 12/13: Warum „tausende CVEs“ erscheinen, wie man echte Findings von False Positives trennt und was bei Debian-Versionen wirklich verglichen wird

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Vulnerability Detection ist in Wazuh ein zentrales Hygiene- und Exposure-Signal: Es korreliert die Software-Inventardaten der Agents mit Vulnerability-Intelligence und macht Schwachstellen im Dashboard und via Alerts sichtbar. Gerade auf Debian 12/13 sorgt dieses Feature aber immer wieder für Frust, wenn nach einer frischen Installation scheinbar „Hunderte bis Tausende“ CVEs auftauchen, die laut Debian Security Tracker bereits „fixed“ sein sollen. Der Knackpunkt liegt fast nie in „Linux ist kaputt“, sondern in (1) Debian-spezifischer Versionierung, (2) Inventory-Quelle (Syscollector), (3) Paket-/Kernel-Altlasten, (4) Feed-Status (Debian vs. CTI) – und erst danach in echten False Positives.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Symptomatik:

  • Frisches Debian 12 (bookworm) oder Debian 13, vollständig aktualisiert (apt update && apt full-upgrade)
  • Wazuh Agent meldet im Vulnerability-Inventory sehr viele CVEs, teils kritisch
  • Externe Scanner (z. B. Tenable) oder Debian Security Tracker zeigen deutlich weniger oder „keine“ Findings
  • Es entsteht der Eindruck, Wazuh „liest Versionsnummern falsch“ oder „prüft Updates nicht korrekt“

Architektur-Kontext:

  • Wazuh Agent sammelt Software/OS-Inventory über Syscollector und sendet es an den Wazuh Server.
  • Der Vulnerability Detection Service korreliert diese Inventardaten mit Vulnerability-Content (CTI / Offline-Repo) und generiert Inventory-Einträge und ggf. Alerts.
  • Für Debian nutzt Wazuh typischerweise Debian-spezifische Feeds (nicht stumpf NVD-Baselines).

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) „Frisch installiert“ heißt nicht „ohne bekannte Schwachstellen“

Ein Debian-ISO enthält Pakete in einem bestimmten Snapshot. Auch nach einem Update bleiben oft Pakete installiert, die (a) noch nicht auf den Security-Stand gehoben wurden, (b) aus nicht-Security-Repos stammen oder (c) als „installed but unused“ weiter im System liegen (z. B. ältere Kernel-Images). Genau deshalb ist der Debian Security Tracker die Referenz für den Debian-Status einer CVE.

2) Debian-Versionen sind nicht trivial: Epoch, Upstream, Debian-Revision, +deb12uX

Debian-Paketversionen folgen einer Logik, die auf den ersten Blick schwer zu beurteilen ist (Epoch 1:, Debian-Revision, Security-Suffixe wie +deb12u1, +deb12u2, …). In der Praxis ist die korrekte Bewertung „vulnerable vs. fixed“ oft exakt an diese Suffix-Schritte gekoppelt. Das ist auch der Kern vieler Diskussionen zu „False Positives“, obwohl der Befund am Ende häufig stimmt, weil die installierte Version tatsächlich unter der als „fixed“ markierten Version liegt (z. B. deb12u1 < deb12u2). Das Problem ist also oft nicht „Wazuh vergleicht falsch“, sondern „menschlich falsch eingeschätzt“. (Genau diese Verwechslungsgefahr wird in Debian/Wazuh-Kontexten regelmäßig thematisiert.)

3) Wazuh prüft ggf. mehr als „den aktiven Kernel“

Ein häufiger „Explosions“-Treiber: Wazuh prüft nicht nur den aktuell gebooteten Kernel, sondern alle installierten Kernelpakete. Wenn auf dem System noch ältere Kernel-Images liegen, werden CVEs weiterhin gemeldet – auch wenn der aktuell laufende Kernel bereits gepatcht ist. Das führt zu „tausenden“ Findings, die sich nach apt autoremove --purge oft drastisch reduzieren.

4) Inventory-Quelle (Syscollector) kann selbst die Ursache sein

Die Vulnerability Detection ist nur so gut wie das Inventar. Wenn Syscollector Pakete doppelt, inkonsistent oder in seltenen Fällen „phantom“-artig meldet, kann das zu scheinbar falschen CVE-Mengen führen. Dazu existieren öffentliche Wazuh-Issues, die genau solche Inventory-Anomalien untersuchen (z. B. nicht existente Pakete / falsche Paketklassifikation).

5) „False positives“ sind nicht ausgeschlossen – es gibt bekannte Untersuchungen

Wazuh hat selbst Issues dokumentiert, bei denen Debian-Ergebnisse als false positives aufgefallen sind und Feed-/Matching-Logik überprüft wurde. Das zeigt: Der Fall ist real – aber ohne konkrete Paket-/Version-/CVE-Beispiele lässt er sich weder bestätigen noch sauber beheben.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: Faktenbasis schaffen – welches Paket und welche Version triggert die CVE?

  1. Im Wazuh Dashboard (Dev Tools / API) die Software-Inventardaten prüfen
    Wazuh beschreibt, wie Syscollector Inventory sammelt und welche Felder verfügbar sind.
  2. Auf dem Agent die Paketversion verifizieren (Debian)
    Für ein verdächtiges Paket:
dpkg -s <paketname> | egrep 'Package|Version|Status'
apt-cache policy <paketname>
  1. Kernel-Altlasten prüfen (häufigster „Mass-Findings“-Grund):
dpkg -l | egrep 'linux-image|linux-headers' | awk '{print $2, $3}'
uname -r

Wenn mehrere alte Kernel installiert sind: bereinigen (mit Vorsicht, mindestens einen bekannten guten Kernel behalten):

apt autoremove --purge

Begründung: Wazuh meldet auch für installierte, aber nicht aktive Kernelpakete CVEs.

Schritt 2: Debian Tracker vs. Wazuh-Feed sauber vergleichen

  • Debian Security Tracker als „OS-Wahrheit“: Status und Fixed-Version pro Release prüfen.
  • Wazuh CTI als Korrelationsquelle (und zum schnellen CVE-Lookup).

Wichtig: Ein „fixed“ im Tracker gilt erst, wenn die installierte Paketversion mindestens die dort angegebene Fixed-Version erreicht.

Schritt 3: Wenn es wirklich ein False Positive ist – reproduzierbar und verwertbar melden

Wazuh kann ohne Datensatz nicht „raten“, wo der Vergleich bricht. Für eine belastbare Analyse gehören immer dazu:

  • Agent OS + Version (z. B. Debian 12 bookworm)
  • Paketname + Paketversion (genau, inkl. Epoch/Suffix)
  • CVE-ID
  • Wazuh Inventory-Auszug (aus Dashboard/Dev Tools)
  • Debian Security Tracker Link und dortiger Status/Fix-Version

Das ist exakt der Weg, wie Wazuh-Teams solche Fälle intern gegen Feed/Matcher abgleichen und fixen können.

Schritt 4: Umgang mit „bereits validierten“ (vermeintlichen) False Positives

Operativ wünschen sich viele eine „Dismiss“-Funktion. In der Praxis gibt es drei Ebenen:

  1. Nicht scannen (grob): Vulnerability Detection konfigurieren/scan-Verhalten steuern (Frequenz, Quellen, etc.).
  2. Alerts unterdrücken (fein): Rules/Filter so bauen, dass bestimmte CVEs nicht als Alert eskalieren.
  3. Exclusions: Es gibt Diskussionen/Workstreams zu Exclusion-Listen und deren Grenzen (z. B. Begrenzungen und Verhalten beim Rescan).

Wichtig für Erwartungsmanagement: Selbst wenn man Alerting unterdrückt, kann die Inventory-Datenbasis weiterhin wachsen, wenn man die Ursache (Inventory oder Feed/Match) nicht behebt. Das wird in Wazuh-Diskussionen explizit angesprochen.

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • Debian-Versionen immer maschinell vergleichen, nicht „per Auge“: deb12u1 vs. deb12u2 ist häufig der ganze Unterschied zwischen „vulnerable“ und „fixed“.
  • Kernel-Hygiene: Regelmäßig alte Kernelpakete entfernen, sonst bleibt Vulnerability-Noise hoch.
  • Inventory-Qualität priorisieren: Vulnerability Detection hängt direkt an Syscollector. Inventory-Anomalien erzeugen Vulnerability-Anomalien.
  • Validierungskette standardisieren:
    1. Paketversion (dpkg/apt)
    2. Debian Tracker Status/Fix-Version
    3. Wazuh CTI Eintrag
    4. Wazuh Inventory/Events im Dashboard
  • Bei echten False Positives: minimaler Repro-Datensatz statt „tausende CVEs“ als Pauschalbeschreibung – sonst bleibt es nicht debugbar.

Fazit (knappe Zusammenfassung mit Mehrwert)

„Tausende Debian-Vulnerabilities“ in Wazuh sind in der Praxis oft eine Mischung aus Debian-Versionierungs-Missverständnissen, installierten Altlasten (insbesondere ältere Kernelpakete) und Inventar-/Feed-Korrelation – und nur in einem Teil der Fälle echte False Positives. Mit einer sauberen Paketversions-Verifikation, konsequenter Kernel-Bereinigung und einem strukturierten Vergleich gegen Debian Security Tracker und Wazuh CTI lässt sich die Signalqualität schnell verbessern. Wenn danach weiterhin Abweichungen bestehen, sind konkrete Paket/Version/CVE-Beispiele der einzige Weg, um Matching-Bugs zuverlässig zu identifizieren und zu fixen.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1768336013938059