vulnerscom/zabbix-threat-controlZabbix-Plugin zur Schwachstellenbewertung
# 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](https://vulners.com) und schreibt **bewertete, pro-Host-Ergebnisse** – Probleme, Dashboards und CVSS-Grafiken – zurück in Zabbix. Eine statische Binärdatei, installiert mit einem Befehl.
[](https://github.com/vulnersCom/zabbix-threat-control/actions/workflows/ci.yml)
[](https://github.com/vulnersCom/zabbix-threat-control/releases)
[](LICENSE)
## Warum ztc
- **Kein neuer Agent, kein RCE.** Hosts melden das Inventar über standardmäßige zabbix-agent2-`UserParameter`s. 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):
```sh
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`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/guide.md).
Weitere Optionen (Docker, manuell, air-gapped, Bootstrap über Zabbix): [`deploy/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/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`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/config.example.yaml).
| Env | Zweck |
|-----|---------|
| `VULNERS_API_KEY` | Vulners-API-Schlüssel (erforderlich) |
| `VULNERS_BASE_URL` | Selbst gehosteter / Proxy-Vulners-Endpunkt (optional) |
| `ZABBIX_URL` | Zabbix-Frontend-URL (JSON-RPC-API) |
| `ZABBIX_TOKEN` | API-Token (bevorzugt) … |
| `ZABBIX_USER` / `ZABBIX_PASSWORD` | … oder Benutzer + Passwort |
| `ZABBIX_SERVER_FQDN` / `ZABBIX_SERVER_PORT` | zabbix-sender-Ziel |
| `ZTC_SCHEDULE` | Daemon-Scan-Intervall (z. B. `1h`) |
| `ZTC_MIN_CVSS` | Ergebnisse unterhalb dieses CVSS vor dem Erstellen von Objekten verwerfen |
`ztc --help` listet den vollständigen Satz auf.
## Befehle
```sh
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`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/adr/0001-remediation-mechanism.md).
## Support-Matrix
| | |
|---|---|
| **Zabbix** | 6.0 & 7.0 LTS, 7.4, 8.0 (automatisch erkannt) |
| **Geprüfte Betriebssysteme** | Linux (deb/rpm/apk/…), Windows (Software + KB) |
| **ztc läuft auf** | Linux amd64 / arm64 |
## 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`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/MIGRATION.md)**.
## Entwicklung
```sh
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`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/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`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/LICENSE).