vulnerscom/zabbix-threat-controlPlugin d'évaluation des vulnérabilités Zabbix
# Zabbix Threat Control (ztc)
**Transformez le Zabbix que vous exécutez déjà en console de gestion des vulnérabilités.**
`ztc` lit l'inventaire logiciel de chaque hôte via le **zabbix-agent2** standard (aucun agent supplémentaire à déployer), l'audite auprès de [Vulners](https://vulners.com), et renvoie dans Zabbix des **résultats notés, par hôte** — problèmes, tableaux de bord et graphiques CVSS. Un binaire statique, installé en une seule commande.
[](https://github.com/vulnersCom/zabbix-threat-control/actions/workflows/ci.yml)
[](https://github.com/vulnersCom/zabbix-threat-control/releases)
[](LICENSE)
## Pourquoi ztc
- **Aucun nouvel agent, aucune RCE.** Les hôtes remontent leur inventaire via les `UserParameter`s standard de zabbix-agent2. La remédiation passe par une seule clé autorisée + un sudoers restreint — jamais de `system.run` arbitraire.
- **Linux _et_ Windows.** Paquets Linux via Vulners `audit/linux` ; logiciels du registre Windows via **Smart Audit** et KB installés via `audit/kb` (avec CVSS par CVE). Smart Audit est indépendant de la version de Zabbix.
- **Zabbix 6.0, 7.0, 7.4 et 8.0.** Détection automatique de la version de l'API ; aucune branche par version à maintenir de votre côté.
- **Exploitable, pas juste une liste.** Les résultats deviennent des **problèmes Zabbix notés par sévérité CVSS**, filtrables **par hôte**, avec des **graphiques de CVSS médian et de distribution des scores** sur un tableau de bord prêt à l'emploi.
- **Un seul binaire.** Installation en une commande ; il se **met à jour tout seul**.
## Démarrage rapide
Sur votre serveur Zabbix (ou tout hôte Linux pouvant atteindre Zabbix + Vulners) :
```sh
curl -fsSL https://raw.githubusercontent.com/vulnersCom/zabbix-threat-control/master/deploy/install.sh | sudo sh
```
L'installateur demande votre clé API Vulners et la connexion Zabbix, installe un service systemd, et propose de créer les entités Zabbix (`ztc provision --all`). Ensuite, liez le modèle de collecte aux hôtes que vous voulez auditer — voir [`docs/guide.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/guide.md).
Autres options (Docker, manuel, réseau isolé, bootstrap-via-Zabbix) : [`deploy/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/README.md).
## Comment ça marche
```
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` exécute la boucle selon un planning ; `ztc provision` crée le modèle Zabbix, les hôtes de rapport, les déclencheurs et le tableau de bord.
## Ce que vous obtenez dans Zabbix
- **Hôtes de rapport :** `Vulners - Hosts`, `- Bulletins`, `- Packages`, `- Statistics`.
- **Tableau de bord** avec une vue d'ensemble **Problèmes par sévérité**, des listes de problèmes par rapport, une tendance **Score CVSS médian** et un camembert de **distribution des scores CVSS**.
- **Problèmes notés par sévérité** — chaque résultat déclenche en Catastrophique / Élevé / Moyen / Avertissement selon son CVSS, donc *Problèmes par sévérité* est pertinent.
- **Filtre par hôte** — chaque résultat porte une balise `vulners.host`. Dans *Monitoring → Problems*, filtrez `Tags: vulners.host Equals <host>` pour voir les vulnérabilités d'un hôte. (Un résultat = un couple (vulnérabilité, hôte).)
**Tendance du CVSS médian et distribution des scores sur l'ensemble du parc :**
**Répartition par sévérité** — de vrais compteurs Catastrophique / Élevé / Moyen / Avertissement, pas une barre grise « Non classé » :
**Vulnérabilités d'un hôte** via le filtre par balise `vulners.host` :
**Un résultat unique** — noté par CVSS, balisé avec son hôte, lié à vulners.com :
## Configuration
Tout a une valeur par défaut ; fournissez les secrets via des variables d'environnement (elles surchargent le fichier YAML). Exemple complet : [`config.example.yaml`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/config.example.yaml).
| Env | Objectif |
|-----|---------|
| `VULNERS_API_KEY` | Clé API Vulners (requise) |
| `VULNERS_BASE_URL` | Point d'accès Vulners auto-hébergé / via proxy (optionnel) |
| `ZABBIX_URL` | URL du frontend Zabbix (API JSON-RPC) |
| `ZABBIX_TOKEN` | Jeton API (préféré) … |
| `ZABBIX_USER` / `ZABBIX_PASSWORD` | … ou utilisateur + mot de passe |
| `ZABBIX_SERVER_FQDN` / `ZABBIX_SERVER_PORT` | Cible zabbix-sender |
| `ZTC_SCHEDULE` | Intervalle d'analyse du démon (ex. `1h`) |
| `ZTC_MIN_CVSS` | Ignorer les résultats sous ce CVSS avant de créer les objets |
`ztc --help` liste l'ensemble complet.
## Commandes
```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
```
## Remédiation
`ztc fix` met à niveau un paquet vulnérable via une clé agent autorisée `vulners.fix[<pkg>]` consommée par un worker côté hôte — aucune exécution de commande arbitraire. Il peut être exécuté manuellement ou, avec `scan --daemon --auto-fix`, être piloté par un utilisateur de confiance qui reconnaît le problème dans Zabbix. Justification : [`docs/adr/0001-remediation-mechanism.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/adr/0001-remediation-mechanism.md).
## Matrice de prise en charge
| | |
|---|---|
| **Zabbix** | 6.0 et 7.0 LTS, 7.4, 8.0 (détection automatique) |
| **OS audités** | Linux (deb/rpm/apk/…), Windows (logiciels + KB) |
| **ztc s'exécute sur** | Linux amd64 / arm64 |
## Migration depuis la version Python
L'implémentation Python d'origine reste dans l'historique git de ce dépôt (les commits antérieurs à la réécriture Go) et dans les tags de version antérieurs à Go. Elle partage les mêmes noms côté Zabbix (groupe, hôtes de rapport, tableau de bord), mais collecte via les clés agent standard au lieu d'un `report.py` fourni, divise le modèle en deux, et supprime l'Action de correction. Procédure pas à pas (mapping de configuration, nettoyage des objets, ré-instrumentation des hôtes, bascule de remédiation) : **[`docs/MIGRATION.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/MIGRATION.md)**.
## Développement
```sh
go build ./... # compile
go test ./... # unit tests (no network)
go vet ./... && gofmt -l .
make build # -> bin/ztc
```
Un banc de test Docker (Zabbix + agent + ztc) se trouve dans [`deploy/docker/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/docker/README.md). La CI (build/test/lint) s'exécute à chaque push ; taguer un commit `v*` publie les binaires et une image GHCR.
## Licence
Voir [`LICENSE`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/LICENSE).