vulnerscom/zabbix-threat-controlPlugin de evaluación de vulnerabilidades de Zabbix
# Zabbix Threat Control (ztc)
**Convierte el Zabbix que ya ejecutas en una consola de gestión de vulnerabilidades.**
`ztc` lee el inventario de software de cada host a través del **zabbix-agent2** de serie (sin desplegar agentes adicionales), lo audita contra [Vulners](https://vulners.com) y envía de vuelta a Zabbix **hallazgos puntuados por host** — problemas, paneles y gráficos CVSS. Un único binario estático, instalado con un solo comando.
[](https://github.com/vulnersCom/zabbix-threat-control/actions/workflows/ci.yml)
[](https://github.com/vulnersCom/zabbix-threat-control/releases)
[](LICENSE)
## Por qué ztc
- **Sin agentes nuevos, sin RCE.** Los hosts reportan el inventario mediante `UserParameter`s estándar de zabbix-agent2. La remediación pasa por una única clave en lista blanca + sudoers restringidos — nunca `system.run` arbitrario.
- **Linux _y_ Windows.** Paquetes Linux vía Vulners `audit/linux`; software del registro de Windows vía **Smart Audit** y KBs instalados vía `audit/kb` (con CVSS por CVE). Smart Audit es independiente de la versión de Zabbix.
- **Zabbix 6.0, 7.0, 7.4 y 8.0.** Detecta automáticamente la versión de la API; sin ramas por versión que mantener por tu parte.
- **Accionable, no solo una lista.** Los hallazgos se convierten en **problemas de Zabbix puntuados por severidad CVSS**, filtrables **por host**, con **gráficos de CVSS mediano y distribución de puntuaciones** en un panel listo para usar.
- **Un solo binario.** Se instala con un solo comando; se **actualiza solo**.
## Inicio rápido
En tu servidor Zabbix (o cualquier host Linux que pueda alcanzar Zabbix + Vulners):
```sh
curl -fsSL https://raw.githubusercontent.com/vulnersCom/zabbix-threat-control/master/deploy/install.sh | sudo sh
```
El instalador te pide tu clave API de Vulners y la conexión a Zabbix, instala un servicio systemd y ofrece crear las entidades de Zabbix (`ztc provision --all`). Luego vincula la plantilla de recopilación a los hosts que quieras escanear — consulta [`docs/guide.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/guide.md).
Otras opciones (Docker, manual, sin conexión a internet, arranque vía Zabbix): [`deploy/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/README.md).
## Cómo funciona
```
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` ejecuta el bucle según una programación; `ztc provision` crea la plantilla de Zabbix, los hosts de informe, los disparadores y el panel.
## Lo que obtienes en Zabbix
- **Hosts de informe:** `Vulners - Hosts`, `- Bulletins`, `- Packages`, `- Statistics`.
- **Panel** con una vista general de **Problemas por severidad**, listas de problemas por informe, una tendencia de **Puntuación CVSS mediana** y un gráfico circular de **distribución de puntuaciones CVSS**.
- **Problemas puntuados por severidad** — cada hallazgo se dispara como Desastre / Alta / Media / Aviso según su CVSS, de modo que *Problemas por severidad* es significativo.
- **Filtro por host** — cada hallazgo lleva una etiqueta `vulners.host`. En el filtro de *Monitorización → Problemas* usa `Tags: vulners.host Equals <host>` para ver las vulnerabilidades de un host. (Un hallazgo = un par (vulnerabilidad, host).)
**Tendencia de CVSS mediano y distribución de puntuaciones en todo el parque:**
**Desglose por severidad** — recuentos reales de Desastre / Alta / Media / Aviso, no una barra gris "Sin clasificar":
**Vulnerabilidades de un host** mediante el filtro por etiqueta `vulners.host`:
**Un hallazgo individual** — puntuado por CVSS, etiquetado con su host y enlazado a vulners.com:
## Configuración
Todo tiene un valor predeterminado; proporciona los secretos mediante variables de entorno (estas anulan el archivo YAML). Ejemplo completo: [`config.example.yaml`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/config.example.yaml).
| Variable | Propósito |
|-----|---------|
| `VULNERS_API_KEY` | Clave API de Vulners (obligatoria) |
| `VULNERS_BASE_URL` | endpoint de Vulners autoalojado / proxy (opcional) |
| `ZABBIX_URL` | URL del frontend de Zabbix (API JSON-RPC) |
| `ZABBIX_TOKEN` | token de API (preferido) … |
| `ZABBIX_USER` / `ZABBIX_PASSWORD` | … o usuario + contraseña |
| `ZABBIX_SERVER_FQDN` / `ZABBIX_SERVER_PORT` | destino de zabbix-sender |
| `ZTC_SCHEDULE` | intervalo de escaneo del daemon (p. ej. `1h`) |
| `ZTC_MIN_CVSS` | descartar hallazgos por debajo de este CVSS antes de crear objetos |
`ztc --help` enumera el conjunto completo.
## Comandos
```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
```
## Remediación
`ztc fix` actualiza un paquete vulnerable mediante una clave de agente `vulners.fix[<pkg>]` en lista blanca, gestionada por un worker en el host — sin ejecución arbitraria de comandos. Puede ejecutarse manualmente o, con `scan --daemon --auto-fix`, ser impulsada por un usuario de confianza que reconozca el problema en Zabbix. Justificación: [`docs/adr/0001-remediation-mechanism.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/adr/0001-remediation-mechanism.md).
## Matriz de soporte
| | |
|---|---|
| **Zabbix** | 6.0 y 7.0 LTS, 7.4, 8.0 (detección automática) |
| **SO auditado** | Linux (deb/rpm/apk/…), Windows (software + KB) |
| **ztc se ejecuta en** | Linux amd64 / arm64 |
## Migración desde la versión en Python
La implementación original en Python permanece en el historial de git de este repositorio (los commits anteriores a la reescritura en Go) y en las etiquetas de versión previas a Go. Comparte los mismos nombres en el lado de Zabbix (grupo, hosts de informe, panel), pero recopila mediante claves de agente estándar en lugar de un `report.py` incluido, divide la plantilla en dos y elimina la Action de corrección. Paso a paso (mapeo de configuración, limpieza de objetos, reinstrumentación de hosts, cambio de remediación): **[`docs/MIGRATION.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/MIGRATION.md)**.
## Desarrollo
```sh
go build ./... # compile
go test ./... # unit tests (no network)
go vet ./... && gofmt -l .
make build # -> bin/ztc
```
Un banco de pruebas Docker (Zabbix + agente + ztc) está en [`deploy/docker/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/docker/README.md). La CI (build/test/lint) se ejecuta en cada push; etiquetar un commit `v*` publica binarios y una imagen GHCR.
## Licencia
Consulta [`LICENSE`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/LICENSE).