vulnerscom/zabbix-threat-controlPlugin de avaliação de vulnerabilidades do Zabbix
# Zabbix Threat Control (ztc)
**Transforme o Zabbix que você já opera em um console de gerenciamento de vulnerabilidades.**
`ztc` lê o inventário de software de cada host por meio do **zabbix-agent2** padrão
(sem agente extra para implantar), audita-o contra o [Vulners](https://vulners.com) e
envia **descobertas pontuadas por host** — problemas, dashboards e gráficos CVSS —
de volta ao Zabbix. Um único binário estático, instalado com um comando.
[](https://github.com/vulnersCom/zabbix-threat-control/actions/workflows/ci.yml)
[](https://github.com/vulnersCom/zabbix-threat-control/releases)
[](LICENSE)
## Por que ztc
- **Sem novo agente, sem RCE.** Os hosts reportam o inventário via `UserParameter`s
padrão do zabbix-agent2. A remediação passa por uma única chave na lista de permissões
e um sudoers restrito — nunca `system.run` arbitrário.
- **Linux _e_ Windows.** Pacotes Linux via `audit/linux` do Vulners; software do
registro do Windows via **Smart Audit** e KBs instalados via `audit/kb` (com
CVSS por CVE). O Smart Audit é independente da versão do Zabbix.
- **Zabbix 6.0, 7.0, 7.4 e 8.0.** Detecta automaticamente a versão da API; sem
ramificações por versão para manter do seu lado.
- **Acionável, não apenas uma lista.** As descobertas se tornam **problemas do Zabbix
pontuados por severidade CVSS**, filtráveis **por host**, com **gráficos de CVSS
mediano e distribuição de pontuações** em um dashboard pronto.
- **Um único binário.** Instale com um único comando; ele **se atualiza sozinho**.
## Início rápido
No seu servidor Zabbix (ou em qualquer host Linux que alcance o Zabbix + Vulners):
```sh
curl -fsSL https://raw.githubusercontent.com/vulnersCom/zabbix-threat-control/master/deploy/install.sh | sudo sh
```
O instalador solicita sua chave de API do Vulners e a conexão com o Zabbix, instala
um serviço systemd e oferece a criação das entidades do Zabbix (`ztc provision --all`).
Em seguida, vincule o template de coleta aos hosts que deseja auditar — consulte
[`docs/guide.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/guide.md).
Outras opções (Docker, manual, sem conexão externa, bootstrap via Zabbix):
[`deploy/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/README.md).
## Como 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` executa o loop em um agendamento; `ztc provision` cria o
template do Zabbix, os hosts de relatório, os triggers e o dashboard.
## O que você obtém no Zabbix
- **Hosts de relatório:** `Vulners - Hosts`, `- Bulletins`, `- Packages`, `- Statistics`.
- **Dashboard** com uma visão geral de **Problemas por severidade**, listas de
problemas por relatório, uma tendência de **Pontuação CVSS mediana** e um gráfico
de pizza de **distribuição de pontuações CVSS**.
- **Problemas pontuados por severidade** — cada descoberta é acionada como Disaster / High /
Average / Warning com base no seu CVSS, para que *Problemas por severidade* seja significativo.
- **Filtrar por host** — cada descoberta carrega uma tag `vulners.host`. Em *Monitoramento
→ Problemas*, filtre por `Tags: vulners.host Equals <host>` para ver as vulnerabilidades
de um host. (Uma descoberta = um par (vulnerabilidade, host).)
**Tendência de CVSS mediano e distribuição de pontuações em toda a frota:**
**Detalhamento por severidade** — contagens reais de Disaster / High / Average / Warning, não uma barra cinza "Não classificado":
**Vulnerabilidades de um host** via o filtro de tag `vulners.host`:
**Uma única descoberta** — pontuada por CVSS, marcada com seu host e com link para vulners.com:
## Configuração
Tudo tem um padrão; forneça segredos por meio de variáveis de ambiente (elas
substituem o arquivo YAML). Exemplo completo: [`config.example.yaml`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/config.example.yaml).
| Variável de ambiente | Finalidade |
|-----|---------|
| `VULNERS_API_KEY` | Chave da API do Vulners (obrigatória) |
| `VULNERS_BASE_URL` | endpoint do Vulners auto-hospedado / via proxy (opcional) |
| `ZABBIX_URL` | URL do frontend do Zabbix (API JSON-RPC) |
| `ZABBIX_TOKEN` | token da API (preferido) … |
| `ZABBIX_USER` / `ZABBIX_PASSWORD` | … ou usuário + senha |
| `ZABBIX_SERVER_FQDN` / `ZABBIX_SERVER_PORT` | destino do zabbix-sender |
| `ZTC_SCHEDULE` | intervalo da varredura do daemon (ex.: `1h`) |
| `ZTC_MIN_CVSS` | descarta descobertas abaixo desse CVSS antes de criar objetos |
`ztc --help` lista o 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
```
## Remediação
O `ztc fix` atualiza um pacote vulnerável por meio de uma chave de agente
`vulners.fix[<pkg>]` na lista de permissões, consumida por um worker no host — sem
execução arbitrária de comandos. Ele pode ser executado manualmente ou, com
`scan --daemon --auto-fix`, ser acionado por um usuário de confiança que reconhece
o problema no Zabbix. Fundamentação:
[`docs/adr/0001-remediation-mechanism.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/adr/0001-remediation-mechanism.md).
## Matriz de suporte
| | |
|---|---|
| **Zabbix** | 6.0 & 7.0 LTS, 7.4, 8.0 (detecção automática) |
| **SO auditado** | Linux (deb/rpm/apk/…), Windows (software + KB) |
| **O ztc executa em** | Linux amd64 / arm64 |
## Migração da versão Python
A implementação original em Python permanece no histórico do git deste repositório
(os commits anteriores à reescrita em Go) e nas tags de release anteriores ao Go.
Ela compartilha os mesmos nomes no lado do Zabbix (grupo, hosts de relatório, dashboard),
mas coleta por meio das chaves padrão do agente em vez de um `report.py` incluído,
divide o template em dois e remove a Action de correção. Passo a passo (mapeamento de
configuração, limpeza de objetos, reinstrumentação de hosts, troca de remediação):
**[`docs/MIGRATION.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/docs/MIGRATION.md)**.
## Desenvolvimento
```sh
go build ./... # compile
go test ./... # unit tests (no network)
go vet ./... && gofmt -l .
make build # -> bin/ztc
```
Um ambiente de teste com Docker (Zabbix + agente + ztc) está em
[`deploy/docker/README.md`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/deploy/docker/README.md). A CI (build/test/lint) é executada
a cada push; marcar um commit com `v*` publica binários e uma imagem GHCR.
## Licença
Consulte [`LICENSE`](https://github.com/vulnerscom/zabbix-threat-control/blob/master/LICENSE).