OpenVAS/Greenbone: Scan de Vulnerabilidades Self-Hosted

Um parque de 40 máquinas, um firewall, alguns servidores e nenhum inventário do que cada um tem de vulnerável. O relatório de um scanner externo custa por IP, os serviços cloud cobram por activo, e a NIS2 e a ISO 27001 pedem identificação periódica de vulnerabilidades com evidência. A solução open-source chama-se Greenbone Community Edition: serviços que correm em contentores Docker no hardware da PME, com o scanner OpenVAS ao centro e uma interface web para gerir scans e relatórios.

O OpenVAS é o motor: executa dezenas de milhares de testes de vulnerabilidade (VTs) contra os alvos, e o gvmd gere o resto — bases de dados, utilizadores, agendamentos. A interface web, o Greenbone Security Assistant (GSA), é onde o trabalho diário acontece. OpenVAS é o scanner, Greenbone a empresa e o conjunto de serviços. Neste guia, instala-se a stack por Docker, espera-se a sincronização do feed da comunidade, corre-se o primeiro scan à rede interna e lê-se o relatório com as métricas que as auditorias pedem: severidade CVSS e qualidade de detecção QoD.

O hardware mínimo é modesto — 2 vCPU, 4 GB de RAM e 20 GB de disco — e a instalação por contentores é o caminho mais simples de manter.

Neste artigo

1. 1. O que é o Greenbone Community Edition e como funciona
2. 2. Requisitos e preparação do servidor
3. 3. Instalação em Docker com o compose oficial
4. 4. Sincronização do feed da comunidade
5. 5. Primeiro acesso e password de administrador
6. 6. Criar o alvo e o primeiro scan à rede interna
7. 7. Ler severidade CVSS e QoD nos resultados
8. 8. Relatórios: formatos, exportação e o que guardar
9. 9. Scan autenticado: ver o sistema por dentro
10. 10. Integração na NIS2 e na ISO 27001
11. Erros Comuns
12. Checklist
13. Artigos Relacionados
14. Fontes Oficiais

1. O que é o Greenbone Community Edition e como funciona

A edição Community é a versão open-source da plataforma da Greenbone — a mesma família de software dos appliances Greenbone Enterprise, sem o feed pago. Cada serviço vive num container próprio:

A comunicação faz-se por sockets Unix em volumes partilhados, sem portas internas expostas além das duas do nginx. Os dados que alimentam o scanner vêm do Greenbone Community Feed via imagens dedicadas — scripts NASL com os testes, informação SCAP com CVEs e CPEs, avisos CERT-Bund/DFN-CERT, scan configs e formatos. Estas imagens copiam os dados para volumes Docker e saem, e os daemons apanham-nos depois.

O feed da comunidade actualiza-se diariamente e cobre sobretudo testes de rede — os relatórios de compliance avançados e parte dos testes locais profundos pertencem ao feed comercial Greenbone Enterprise, como o FAQ sublinha. Os scans remotos e autenticados básicos funcionam na íntegra com o feed gratuito.

2. Requisitos e preparação do servidor

O carregamento inicial do feed ocupa vários GB e os volumes crescem com cada scan — na prática, uma máquina com 4 vCPU, 8 GB de RAM e 60 GB de disco corre a pilha sem stress.

A lista oficial de sistemas do anfitrião: Debian stable (bookworm), Ubuntu 24.04 LTS, Fedora 35/36 e CentOS 9 Stream. As dependências de base são curl e Docker, com o utilizador no grupo docker — sem o grupo, os comandos falham com permissão negada:

sudo apt install ca-certificates curl
sudo usermod -aG docker $USER && su $USER
export DOWNLOAD_DIR=$HOME/greenbone-community-edition
mkdir -p $DOWNLOAD_DIR

3. Instalação em Docker com o compose oficial

A instalação usa o compose.yaml oficial da Greenbone — a nota oficial pede sempre a versão mais recente, que pode ter alterações desde a última descarga. Descarregue-o e puxe as imagens:

curl -f -O -L https://greenbone.github.io/docs/latest/_static/compose.yaml --output-dir "$DOWNLOAD_DIR"
docker compose -f $DOWNLOAD_DIR/compose.yaml pull

O pull descarrega cerca de vinte imagens do registo oficial registry.community.greenbone.net — os serviços e as imagens de dados do feed, que pesam vários GB. Depois, arranque a pilha:

docker compose -f $DOWNLOAD_DIR/compose.yaml up -d

Para acompanhar o arranque, abra o stream de logs:

docker compose -f $DOWNLOAD_DIR/compose.yaml logs -f

Os containers de dados mostram as licenças do feed e terminam — os dados ficam nos volumes. Em alternativa, o script oficial setup-and-start-greenbone-community-edition.sh descarrega o compose, faz pull, arranque e pergunta a password do admin.

4. Sincronização do feed da comunidade

Sem feed, o scanner não sabe testar nada. A sincronização descarrega as alterações via pull de imagens e carrega-as pelos daemons — minutos a horas, a inicial mais, sob pena de resultados incompletos. A descarga faz-se com o pull dos containers de dados:

docker compose -f $DOWNLOAD_DIR/compose.yaml pull notus-data vulnerability-tests scap-data dfn-cert-data cert-bund-data report-formats data-objects

E a cópia para os volumes:

docker compose -f $DOWNLOAD_DIR/compose.yaml up -d notus-data vulnerability-tests scap-data dfn-cert-data cert-bund-data report-formats data-objects

Os daemons carregam depois tudo automaticamente, com o progresso nos logs: Finished loading VTs no ospd-openvas, Updating VTs in database … done, Updating SCAP info succeeded e Updating CERT info succeeded no gvmd. Os scan configs só carregam com os VTs já no gvmd e um Feed Import Owner definido.

Em instalações nativas (Kali ou compilação do código), o download corre com sudo greenbone-feed-sync. O teste da sincronização: o menu SecInfo da GSA mostra os NVTs e o total sobe com cada feed. Antes de estabilizar, não corra o primeiro scan.

5. Primeiro acesso e password de administrador

Com os serviços a correr, a interface abre-se no browser do servidor:

xdg-open "https://127.0.0.1" 2>/dev/null >/dev/null &

O aviso de certificado é normal — o nginx gera um certificado auto-assinado. Aceite a excepção e a página de login do GSA aparece no ecrã. Por omissão, o admin nasce com password admin: mude-a de imediato, dentro do container gvmd, como a documentação oficial recomenda:

docker compose -f $DOWNLOAD_DIR/compose.yaml \
    exec -u gvmd gvmd gvmd --user=admin --new-password=''

Passwords com caracteres especiais como $ exigem aspas simples, e a nova password aplica-se no próximo login. Guarde-a no gestor de passwords — é a chave para todos os resultados de scan.

O acesso remoto não vem activado: o nginx escuta só em 127.0.0.1 (portas 443 e 9392). Para abrir a outras máquinas, a documentação oficial descreve a alteração — NGINX_HOST com o IP do servidor, mapeamento 443:443 e reinício. Com o dashboard aberto à rede, mantenha a password forte e restrinja-o na firewall.

6. Criar o alvo e o primeiro scan à rede interna

Com o feed carregado, o primeiro scan segue três passos oficiais da GSA: alvo (target), tarefa (task) e arranque. Comece pelo alvo em Configuration > Targets:

O Alive Test importa em redes com hosts que ignoram ping — ICMP Ping, TCP-ACK, TCP-SYN e ARP Ping são as opções, combináveis em modo Custom. Com impressoras ou IoT na gama, escolha Consider Hosts as Alive ou um alive test por TCP: hosts sem resposta a ICMP ficam fora do scan sem aviso.

O segundo passo é a tarefa em Scans > Tasks — New Task, com o alvo criado, o scan config e o scanner. Os conjuntos pré-feitos: Full and fast (verificação completa com VTs seguros), Full and fast ultimate (acrescenta VTs que podem perturbar serviços), Host Discovery e System Discovery.

Para o primeiro scan, Full and fast é a escolha recomendada: os testes remotos seguros correm com a preferência safe_checks activa, e os VTs invasivos ou capazes de denial of service ficam excluídos. O ultimate fica para janelas de manutenção, sob pena de falsos positivos.

Arranque a tarefa com o botão de play. Um scan a uma /24 leva de minutos a horas — a página refresca-se sozinha e os resultados intermédios são consultáveis a qualquer momento. Com o estado em Done, o relatório está pronto.

7. Ler severidade CVSS e QoD nos resultados

Cada resultado traz duas métricas. A primeira é a severidade CVSS (Common Vulnerability Scoring System), nota de 0.0 a 10.0: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9, Log 0.0. A segunda é a QoD — Quality of Detection —, um valor de 0% a 100% que descreve a fiabilidade do método de detecção: 100% é exploit (prova plena), 99% remote_vul, 97% package ou registry (verificação autenticada de pacotes Linux ou de registo Windows), e valores baixos indicam inferência.

Por omissão, a GSA só mostra resultados com QoD de 70% ou superior — o filtro desce quando o scan parece demasiado limpo. A hierarquia prática: Critical e High com QoD alto tratam-se primeiro, Medium e Low entram no planeamento de patches, e Log são notas de inventário.

A chave da leitura: um Critical com QoD 60% pode ser um falso positivo, um High com QoD 99% é quase certo. A distinção entre severidade e fiabilidade é a que as auditorias ISO 27001 pedem ao perguntar como as vulnerabilidades são classificadas.

8. Relatórios: formatos, exportação e o que guardar

Cada tarefa produz relatórios na página Reports da GSA — resumo por severidade no topo, resultados em baixo. Os formatos de exportação são data objects distribuídos pelo feed:

O GSR PDF é a evidência de auditoria, o GXR PDF anexa-se à revisão do SGSI, o CSV Results alimenta folhas de cálculo de patches, e o Anonymous XML partilha-se com um fornecedor sem expor o endereçamento interno.

9. Scan autenticado: ver o sistema por dentro

O scan remoto vê só o que a rede expõe. O autenticado entra com credenciais válidas e corre os testes locais (local security checks) — versões exactas de pacotes Linux e chaves de registo Windows, com menos falsos positivos. Criam-se credenciais em Configuration > Credentials (SSH, SMB), associam-se ao alvo e usa-se uma scan config com os testes locais activos — o facto de o scanner iniciar sessão com credenciais válidas é o que permite chegar a dados que nenhum teste remoto alcança. Uma credencial de leitura por tipo de sistema chega, com o login registado nos logs dos alvos.

10. Integração na NIS2 e na ISO 27001

A NIS2 (Diretiva 2022/2555) lista no artigo 21 o tratamento de vulnerabilidades entre as medidas mínimas de gestão do risco de cibersegurança. A ISO/IEC 27001:2022 pede o mesmo no controlo 8.8 do Anexo A: identificar, avaliar e tratar vulnerabilidades num intervalo definido pela organização. O scanner self-hosted é a evidência operacional — rede analisada periodicamente, relatórios datados, ciclo fechado com a remediação.

A ligação prática: scan mensal como processo, relatório PDF como evidência, e a matriz CVSS × QoD como classificação que a auditoria pede. A Declaração de Aplicabilidade ganha uma linha com o scanner como controlo, e as revisões da gerência ganham um gráfico com a evolução de Critical e High — o GXR PDF fornece esse resumo. O custo de operação é o argumento decisivo: pilha no hardware próprio, feed gratuito, e o investimento é o tempo de instalação.

Erros Comuns

Checklist

• [ ] Máquina com 2 vCPU, 4 GB de RAM e 20 GB de disco no mínimo, com Docker e curl instalados
• [ ] compose.yaml oficial descarregado para $DOWNLOAD_DIR
• [ ] docker compose pull e up -d concluídos, 21 serviços no compose
• [ ] Logs do feed com Finished loading VTs e Updating SCAP info succeeded
• [ ] Password de admin alterada dentro do container gvmd
• [ ] Alvo criado com gama CIDR correcta e Alive Test adequado à rede
• [ ] Tarefa com scan config Full and fast, sem ultimate no primeiro scan
• [ ] Relatório Done lido com filtro QoD ≥ 70% e severidades classificadas
• [ ] GSR PDF de cada scan arquivado como evidência
• [ ] Ciclo agendado (schedule no gvmd) e responsável de remediação definido

Artigos Relacionados

• Nuclei: Scanner de Vulnerabilidades Automatizado para PME
• NetAlertX: Descoberta e Monitorização de Dispositivos de Rede para PME
• Snipe-IT: Gestão de Inventário IT Open-Source para PME
• NIS2 em 2026: Como Implementar a Checklist em 90 Dias — Guia Prático para Sysadmins

Fontes Oficiais

• Greenbone Community Documentation: https://greenbone.github.io/docs/latest/index.html
• Greenbone Community Containers (22.4): https://greenbone.github.io/docs/latest/22.4/container/index.html
• Workflows dos containers (feed sync, logs): https://greenbone.github.io/docs/latest/22.4/container/workflows.html
• Kali Linux Install Guide: https://greenbone.github.io/docs/latest/22.4/kali/index.html
• FAQ da documentação da comunidade: https://greenbone.github.io/docs/latest/faq.html
• OpenVAS — site oficial: https://www.openvas.org/
• Manual GSA (QoD, CVSS, relatórios, targets): https://docs.greenbone.net/GSM-Manual/gos-24.10/en/
• greenbone-feed-sync (ferramenta): https://github.com/greenbone/greenbone-feed-sync