Zabbix Threat Control (ztc)

Verwandeln Sie das Zabbix, das Sie bereits betreiben, in eine Schwachstellen-Management-Konsole.

ztc liest das Software-Inventar jedes Hosts über den Standard-zabbix-agent2 (kein zusätzlicher Agent nötig), prüft es gegen Vulners und schreibt bewertete, pro-Host-Ergebnisse – Probleme, Dashboards und CVSS-Grafiken – zurück in Zabbix. Eine statische Binärdatei, installiert mit einem Befehl.

Warum ztc

• Kein neuer Agent, kein RCE. Hosts melden das Inventar über standardmäßige zabbix-agent2-UserParameters. Die Behebung erfolgt über einen einzigen whitelisted Schlüssel und enge sudoers-Regeln – niemals über beliebiges system.run.
• Linux und Windows. Linux-Pakete über Vulners audit/linux; Windows-Registrierungssoftware über Smart Audit und installierte KBs über audit/kb (mit CVSS pro CVE). Smart Audit ist unabhängig von der Zabbix-Version.
• Zabbix 6.0, 7.0, 7.4 und 8.0. Erkennt die API-Version automatisch; keine versionsspezifischen Branches, die Sie pflegen müssen.
• Handlungsorientiert, nicht nur eine Liste. Ergebnisse werden zu Zabbix-Problemen, die nach CVSS-Schweregrad bewertet sind, pro Host filterbar, mit Median-CVSS- und Verteilungsgrafiken auf einem fertigen Dashboard.
• Eine Binärdatei. Installation mit einem einzigen Befehl; sie aktualisiert sich selbst.

Schnellstart

Auf Ihrem Zabbix-Server (oder einem beliebigen Linux-Host, der Zabbix + Vulners erreichen kann):

curl -fsSL https://raw.githubusercontent.com/vulnersCom/zabbix-threat-control/master/deploy/install.sh | sudo sh

Der Installer fragt nach Ihrem Vulners-API-Schlüssel und der Zabbix-Verbindung, installiert einen systemd-Dienst und bietet an, die Zabbix-Objekte zu erstellen (ztc provision --all). Verknüpfen Sie dann die Collection-Vorlage mit den Hosts, die gescannt werden sollen – siehe docs/guide.md.

Weitere Optionen (Docker, manuell, air-gapped, Bootstrap über Zabbix): deploy/README.md.

So funktioniert es

 hosts: zabbix-agent2  UserParameter
   Linux   → vulners.os / version / arch / packages
   Windows → vulners.os / version / win.software / win.kb
        │   (polled into Zabbix items)
        ▼
   ztc scan ─► collect (Zabbix API) ─► audit (Vulners) ─► aggregate ─► sender ─► Zabbix
                                                                           │
        problems (CVSS severity) · dashboard · graphs · vulners.host tags ◄┘

ztc scan --daemon führt die Schleife nach Zeitplan aus; ztc provision erstellt die Zabbix-Vorlage, Report-Hosts, Trigger und das Dashboard.

Was Sie in Zabbix erhalten

• Report-Hosts: Vulners - Hosts, - Bulletins, - Packages, - Statistics.
• Dashboard mit einer Probleme-nach-Schweregrad-Übersicht, Problemlisten pro Report, einem Median-CVSS-Score-Trend und einem CVSS-Score-Verteilungs-Kreisdiagramm.
• Nach Schweregrad bewertete Probleme – jedes Ergebnis löst je nach CVSS auf Disaster / High / Average / Warning aus, sodass Probleme nach Schweregrad aussagekräftig ist.
• Nach Host filtern – jedes Ergebnis trägt ein vulners.host-Tag. Filtern Sie unter Monitoring → Probleme mit Tags: vulners.host Equals <host>, um die Schwachstellen eines Hosts zu sehen. (Ein Ergebnis = ein (Schwachstelle, Host)-Paar.)

Median-CVSS-Trend und Score-Verteilung über die gesamte Flotte:

Schweregrad-Aufschlüsselung – echte Disaster-/High-/Average-/Warning-Zähler, kein grauer Balken „Nicht klassifiziert“:

Schwachstellen eines einzelnen Hosts über den vulners.host-Tag-Filter:

Ein einzelnes Ergebnis – nach CVSS bewertet, mit seinem Host getaggt, mit vulners.com verlinkt:

Konfiguration

Alles hat einen Standardwert; Geheimnisse werden über Umgebungsvariablen übergeben (sie überschreiben die YAML-Datei). Vollständiges Beispiel: config.example.yaml.

ztc --help listet den vollständigen Satz auf.

Befehle

ztc scan --daemon                 # run the scan loop on a schedule
ztc scan --once                   # a single cycle
ztc provision --all               # create/reconcile templates, report hosts, dashboard
ztc fix --host H --package P      # remediate a package (whitelisted, opt-in)
ztc upgrade                       # self-update, then re-run `provision --all`
ztc version --check               # print version and check for updates

Behebung

ztc fix aktualisiert ein verwundbares Paket über einen whitelisted vulners.fix[<pkg>]-Agentenschlüssel, der von einem host-seitigen Worker abgerufen wird – keine beliebige Befehlsausführung. Es kann manuell ausgeführt oder mit scan --daemon --auto-fix von einem vertrauenswürdigen Benutzer gesteuert werden, der das Problem in Zabbix bestätigt. Begründung: docs/adr/0001-remediation-mechanism.md.

Support-Matrix

Migration von der Python-Version

Die ursprüngliche Python-Implementierung bleibt in der Git-History dieses Repositorys (die Commits vor dem Go-Rewrite) und in den Pre-Go-Release-Tags erhalten. Sie verwendet dieselben Zabbix-seitigen Namen (Gruppe, Report-Hosts, Dashboard), sammelt aber über Standard-Agentenschlüssel anstelle eines mitgelieferten report.py, teilt die Vorlage in zwei Teile und entfernt die Fix-Action. Schritt für Schritt (Konfigurationszuordnung, Objektbereinigung, Neu-Instrumentierung der Hosts, Umstellung der Behebung): docs/MIGRATION.md.

Entwicklung

go build ./...     # compile
go test ./...      # unit tests (no network)
go vet ./... && gofmt -l .
make build         # -> bin/ztc

Ein Docker-Teststand (Zabbix + Agent + ztc) befindet sich in deploy/docker/README.md. CI (Build/Test/Lint) läuft bei jedem Push; das Taggen eines v*-Commits veröffentlicht Binärdateien und ein GHCR-Image.

Lizenz

Siehe LICENSE.