vulnerscom/zabbix-threat-controlPlugin per la valutazione delle vulnerabilità di Zabbix
# Zabbix Threat Control (ztc)
**Trasforma lo Zabbix che già utilizzi in una console di vulnerability management.**
`ztc` legge l'inventario software di ogni host tramite lo standard **zabbix-agent2**
(nessun agente aggiuntivo da distribuire), lo confronta con [Vulners](https://vulners.com) e
inserisce **risultati con punteggio, per host** — problemi, dashboard e grafici CVSS —
di nuovo in Zabbix. Un singolo binario statico, installato con un comando.
[](https://github.com/vulnersCom/zabbix-threat-control/actions/workflows/ci.yml)
[](https://github.com/vulnersCom/zabbix-threat-control/releases)
[](LICENSE)
## Perché ztc
- **Nessun nuovo agente, nessuna RCE.** Gli host segnalano l'inventario tramite i
`UserParameter` standard di zabbix-agent2. La remediation passa attraverso una singola
chiave in whitelist e sudoers ristretti — mai `system.run` arbitrario.
- **Linux _e_ Windows.** Pacchetti Linux tramite Vulners `audit/linux`; software Windows dal
registro di sistema tramite **Smart Audit** e KB installati tramite `audit/kb` (con
CVSS per CVE). Smart Audit è indipendente dalla versione di Zabbix.
- **Zabbix 6.0, 7.0, 7.4 e 8.0.** Rileva automaticamente la versione dell'API; nessun
branch per versione da mantenere da parte tua.
- **Azionabile, non solo un elenco.** I risultati diventano **problemi Zabbix con punteggio
basato sulla gravità CVSS**, filtrabili **per host**, con **grafici della mediana CVSS e
della distribuzione dei punteggi** in una dashboard già pronta.
- **Un solo binario.** Installazione con un singolo comando; si **auto-aggiorna**.
## Avvio rapido
Sul tuo server Zabbix (o su qualsiasi host Linux che possa raggiungere Zabbix + Vulners):
```sh
curl -fsSL https://raw.githubusercontent.com/vulnersCom/zabbix-threat-control/master/deploy/install.sh | sudo sh
```
L'installer chiede la tua API key Vulners e la connessione Zabbix, installa un
servizio systemd e offre di creare le entità Zabbix (`ztc provision --all`).
Poi collega il template di raccolta agli host che vuoi scansionare — vedi
[`docs/guide.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/guide.md).
Altre opzioni (Docker, manuale, air-gapped, bootstrap-via-Zabbix):
[`deploy/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/README.md).
## Come funziona
```
hosts: zabbix-agent2 UserParameter
Linux → vulners.os / version / arch / packages
Windows → vulners.os / version / win.software / win.kb
│ (interrogati negli item Zabbix)
▼
ztc scan ─► collect (Zabbix API) ─► audit (Vulners) ─► aggregate ─► sender ─► Zabbix
│
problemi (gravità CVSS) · dashboard · grafici · tag vulners.host ◄┘
```
`ztc scan --daemon` esegue il ciclo secondo una pianificazione; `ztc provision` crea il
template Zabbix, gli host di report, i trigger e la dashboard.
## Cosa ottieni in Zabbix
- **Host di report:** `Vulners - Hosts`, `- Bulletins`, `- Packages`, `- Statistics`.
- **Dashboard** con una panoramica **dei problemi per gravità**, elenchi di problemi per
report, un trend della **mediana del punteggio CVSS** e un grafico a torta della
**distribuzione dei punteggi CVSS**.
- **Problemi con punteggio di gravità** — ogni risultato genera un evento Disaster / High /
Average / Warning in base al suo CVSS, così *Problems by severity* è significativo.
- **Filtro per host** — ogni risultato porta un tag `vulners.host`. In *Monitoring
→ Problems* filtra con `Tags: vulners.host Equals <host>` per vedere le vulnerabilità
di un singolo host. (Un risultato = una coppia (vulnerabilità, host).)
**Trend della mediana CVSS e distribuzione dei punteggi sull'intera flotta:**
**Ripartizione per gravità** — conteggi reali di Disaster / High / Average / Warning, non una sola barra grigia "Non classificato":
**Le vulnerabilità di un singolo host** tramite il filtro sul tag `vulners.host`:
**Un singolo risultato** — con punteggio CVSS, taggato con il suo host, collegato a vulners.com:
## Configurazione
Tutto ha un valore predefinito; fornisci i segreti tramite variabili d'ambiente (queste
sovrascrivono il file YAML). Esempio completo: [`config.example.yaml`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/config.example.yaml).
| Env | Scopo |
|-----|---------|
| `VULNERS_API_KEY` | API key Vulners (richiesta) |
| `VULNERS_BASE_URL` | endpoint Vulners self-hosted / proxy (opzionale) |
| `ZABBIX_URL` | URL del frontend Zabbix (API JSON-RPC) |
| `ZABBIX_TOKEN` | token API (preferito) … |
| `ZABBIX_USER` / `ZABBIX_PASSWORD` | … oppure utente + password |
| `ZABBIX_SERVER_FQDN` / `ZABBIX_SERVER_PORT` | destinazione zabbix-sender |
| `ZTC_SCHEDULE` | intervallo di scansione del demone (es. `1h`) |
| `ZTC_MIN_CVSS` | scarta i risultati sotto questo CVSS prima di creare gli oggetti |
`ztc --help` elenca l'insieme completo.
## Comandi
```sh
ztc scan --daemon # esegue il ciclo di scansione secondo una pianificazione
ztc scan --once # un singolo ciclo
ztc provision --all # crea/riconcilia template, host di report, dashboard
ztc fix --host H --package P # ripara un pacchetto (in whitelist, opt-in)
ztc upgrade # auto-aggiornamento, poi riesegue `provision --all`
ztc version --check # stampa la versione e verifica la presenza di aggiornamenti
```
## Remediation
`ztc fix` aggiorna un pacchetto vulnerabile tramite una chiave agente `vulners.fix[<pkg>]`
in whitelist, gestita da un worker lato host — nessuna esecuzione di comandi arbitrari. Può
essere eseguito manualmente o, con `scan --daemon --auto-fix`, essere attivato da un utente
fidato che riconosce il problema in Zabbix. Motivazione:
[`docs/adr/0001-remediation-mechanism.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/adr/0001-remediation-mechanism.md).
## Matrice di supporto
| | |
|---|---|
| **Zabbix** | 6.0 & 7.0 LTS, 7.4, 8.0 (rilevamento automatico) |
| **SO controllati** | Linux (deb/rpm/apk/…), Windows (software + KB) |
| **ztc gira su** | Linux amd64 / arm64 |
## Migrazione dalla versione Python
L'implementazione Python originale rimane nella storia git di questo repository
(i commit precedenti alla riscrittura in Go) e nei tag di release pre-Go. Condivide
gli stessi nomi lato Zabbix (gruppo, host di report, dashboard), ma raccoglie tramite
le chiavi agente standard invece di uno `report.py` distribuito, divide il template in due
e rimuove l'Action di fix. Passo passo (mappatura della configurazione, pulizia degli oggetti,
re-istrumentazione degli host, passaggio alla remediation): **[`docs/MIGRATION.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/MIGRATION.md)**.
## Sviluppo
```sh
go build ./... # compilazione
go test ./... # test unitari (senza rete)
go vet ./... && gofmt -l .
make build # -> bin/ztc
```
Un banco di prova Docker (Zabbix + agent + ztc) si trova in
[`deploy/docker/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/docker/README.md). La CI (build/test/lint) viene eseguita
a ogni push; il tagging di un commit `v*` pubblica i binari e un'immagine GHCR.
## Licenza
Vedi [`LICENSE`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/LICENSE).