Ajuste Prático do OpenVAS para Redes Corporativas
Ajuste Prático do OpenVAS para Redes Corporativas
Atualizado em: 2026-09
O que você vai aprender:
- Como calibrar scans OpenVAS/GVM para minimizar impacto operacional e maximizar cobertura de vulnerabilidade
- Arquitetura de scanner corporativo, integração com CI/CD e SOС/SIEM e estratégias para ambientes OT/ICS
- Playbooks operacionais para Blue Team e Red Team, métricas para auditoria e checklist de conformidade
Pré-requisitos: conhecimento de Linux (Debian/Ubuntu), familiaridade com redes TCP/IP, noções de pentest e autorização para testes em ambiente corporativo.
Nível: intermediário | avançado
Sumário:
- Contexto Atual e Relevância Estratégica
- Fundamentos Técnicos do Tema
- Arquitetura, Fluxos e Superfície de Ataque
- Cenários Reais e Estudos de Caso
- Implementação Prática Step-by-Step
- Hardening, Controles e Melhores Práticas
- Playbooks Operacionais para Blue Team e Red Team
- Métricas, KPIs e Auditoria Técnica
- Erros Comuns, Armadilhas e Correções
- FAQ Técnico para Busca Orgânica
- Considerações Finais
- Referências
Varredura sem ajuste é risco operacional e ruído que cega o SOC. OpenVAS, via Greenbone GVM, é poderoso mas, sem tuning, gera falsos positivos, saturação de rede e até interrupção de serviços críticos. Este texto mostra – com comandos, métricas e playbooks – como transformar o OpenVAS em ferramenta de avaliação útil, confiável e auditável para ambientes empresariais heterogêneos, incluindo nuvem e OT.
Contexto Atual e Relevância Estratégica
Por que o ajuste importa agora
Em 2025 e 2026 observamos duas tendências que tornam o tuning de scanners obrigatório: digitalização acelerada de ativos (mais superfícies expostas) e maior sensibilidade a varreduras agressivas que causam incidentes operacionais. Organizações que mantêm scans agressivos sem whitelist de ativos críticos geraram tickets de incident response e interrupções em 2026, segundo relatórios públicos de fornecedores e órgãos de resposta.
1 2 3 4 | Rede Corporativa - problemas sem tuning [Scanner OpenVAS] --> flood de probes --> [Servidor Web legado] = crash/performance drop [Scanner OpenVAS] --> múltiplos logins = disparo de EDR/IDS --> SOC inundado [Scanner OpenVAS] --> autenticação incorreta = lockout de contas de serviço |
Tuning não é luxo: é controle de risco. Ajustar velocidade, escopo e credenciais reduz chance de DoS e torna resultados acionáveis.
Risco de negócios e métricas que importam
Quatro métricas ligam scanning à decisão executiva: taxa de interrupção por scan (incidentes/100 scans), tempo médio para triagem de novo alerta (MTTR logs), percentual de falsos positivos criticamente impactantes e cobertura de ativos categorizados (porc. de ativos com scan autenticado). Metas recomendadas: interrupção por scan <0.1%, MTTR inicial <24h, cobertura autenticada >70% para servidores críticos.
SAT: scans não autorizados podem violar contratos de fornecedores e SLAs operacionais. Obtenha autorização formal antes de qualquer varredura em produção.
Política e conformidade
Escanear sem rastreabilidade fere práticas ISO-27001 e NIST-SP-800-115. Para auditoria, registre: horário, perfil de NVTs (Network Vulnerability Tests), credenciais utilizadas, e hashes de resultados. Exija retenção de logs por 1 ano para auditoria e 90 dias para triagem ativa como bom compromisso operacional/compliance.
Fundamentos Técnicos do Tema
Arquitetura do OpenVAS/GVM e componentes relevantes
O Greenbone Vulnerability Management (GVM) é o projeto que engloba scanner (openvas-scanner), manager (gvmd), feed sync (greenbone-nvt-sync), e GSAD/UI. Em deployments empresariais, os pontos críticos para tuning são o openvas-scanner (paralelismo de NVTs), gvmd (gerenciamento de sessões e tasks), e redis/postgres (armazenamento e lock de tasks).
1 2 3 4 5 6 7 8 9 10 11 | +---------------------------+ | Camada de decisão (policy)| +---------------------------+ | +---------------------------+ | Controles e lógica | +---------------------------+ | +---------------------------+ | Telemetria e evidência | +---------------------------+ |
| Componente | Função | Parâmetros chave |
|---|---|---|
| openvas-scanner | Execução de NVTs, probes TCP/UDP | –max-threads, –max-hosts, timeout NVT |
| gvmd | Agendamento, credenciais, reports | scan configs, port lists, creds store |
| ospd-openvas | Broker entre gvmd e scanner | Workers, timeout, logging |
| greenbone-nvt-sync | Atualização de NVTs | agendamento, whitelist/blacklist |
Tipos de varredura e trade-offs
Varreduras sem credenciais oferecem alcance amplo mas alta taxa de falsos positivos; varreduras autenticadas reduzem false positives e possibilitam detecção de configuração, mas aumentam risco de lockouts e requerem gestão de credenciais segura. Trade-off: priorizar autenticado para servidores essenciais e usar não autenticado para inventário amplo.
Use varreduras ‘non-intrusive’ em janelas de produção e reserve ‘full intrusive’ para ambientes de QA/teste com autorização.
Parâmetros de tuning primários
| Parâmetro | Efeito | Valor inicial recomendado |
|---|---|---|
| Parallel host checks | Maior velocidade, maior impacto na rede | 5-20 hosts por worker |
| Parallel NVT threads | Threads por host para NVTs | 2-10 dependendo do host |
| Timeout de NVT | Evita hangs em NVTs problemáticos | 30-120s por teste |
| Max checks per host | Limita número simultâneo de probes | 4-8 |
| Port list | Define portas alvo para reduzir superfície | Customizar por perfil de ativo |
Arquitetura, Fluxos e Superfície de Ataque
Topologias seguras para enterprise scanning
Em grandes redes, prefira arquitetura distribuída: central manager + scanners regionais. Scanners locais reduzem latência e o risco de atravessar perímetros. Cada scanner deve ter políticas de acesso restritas e comunicação TLS mútua com o manager.
1 2 3 4 | Topologia recomendada [GVMD Central] <---TLS---> [Scanner Regional 1] --> [Rede Segmento A] [Scanner Regional 2] --> [Rede Segmento B] [Scanner OT isolado] --> [Purdue Level 2-3 OT only] |
Fluxo de dados e integração com SOC
Fluxo mínimo: gvmd gera alerta -> exporta via OTX/CSV/JSON para SIEM -> correlaciona com EDR/IDS -> analista triagem -> ticketing. Integre via API e normalized fields para reduzir esforço do SOC. Automatize criação de casos com regras que priorizem ativos críticos e exploits conhecidos (ex.: CVSS >=7 e ativo em produção).
Superfície de ataque introduzida pelo próprio scanner
Um scanner – se comprometido – é um vetor privilegiado: possui credenciais, acesso de rede amplo e logs de varredura sensíveis. Mitigue isolando scanners em VLANs com regras de firewall estritas, usando credenciais por ativo com rotação e logs imutáveis enviados a SIEM externo.
Cenários Reais e Estudos de Caso
Estudo de caso 1 – Empresa financeira com produção sensível
Empresa X (setor financeiro) executava scans noturnos sem scan autenticado e sofreu múltiplos false positives que geraram abertura de janelas de manutenção desnecessárias. Ajuste aplicado: redução do parallel hosts de 50 para 8, introdução de port lists e autenticação em servidores de backend. Resultado: redução de 70% nos alertas críticos falsos em 30 dias e nenhuma interrupção operacional por scans no trimestre seguinte.
Estudo de caso 2 – Indústria com OT (Purdue)
Fabricante Y aplicou scanner em rede flat e causou falha em PLCs ao executar probes em portas proprietárias. Solução: isolar OT scanner em segmento separado com regras apenas para IPs de engenharia, usar fingerprints passivos para inventário e apenas executar scans autenticados e não intrusivos fora do horário de produção. A política incluiu rollback e plano de contingência com snapshots de PLCs.
1 2 3 4 | Purdue-aware scanning [Scanner OT] -> [DMZ OT] -> [PLC Level 2] (only authorized probes) | -> [Engineering VLAN] (auth scans scheduled maintenance window) |
Implementação Prática Step-by-Step
Pré-requisitos técnicos e checklist inicial
Requisitos mínimos: servidor Debian/Ubuntu LTS com 4-8 vCPU, 16-32 GB RAM para scanner regional; banco Postgres para gvmd; TLS com certificados válidos; gestão de segredos (HashiCorp Vault, AWS Secrets Manager ou similar) para credenciais de varredura; autorização por escrito e registro de escopo.
Passo a passo: instalação básica (Kali/Ubuntu)
- Provisionar VM Debian 12 LTS com 4 vCPU e 16 GB RAM para ambiente piloto.
- Atualizar sistema: 1sudo apt update && sudo apt upgrade -y
- Instalar dependências: 1sudo apt install -y postgresql redis gnupg curl libgcrypt20-dev
- Instalar GVM/OpenVAS via repositório oficial ou pacote da distro: 1sudo apt install -y gvm
- Inicializar banco e sincronizar feeds: 1sudo runuser -u _gvm -- gvmd --create-user=admin --password=SenhaForte && sudo gvm-feed-update
- Configurar TLS e firewall: abrir apenas portas 9390-9392 para manager e 9391 para web com restrições de origem.
- Executar varredura de teste em laboratório com port list reduzida: 1gvmd --create-task --name "Test Scan" --target "10.0.10.5" --config "Full and fast"
- Validar resultados e ajustar timeouts/parallelism conforme logs.
Exemplo prático de tuning por perfil
Crie scan configs customizados por perfil de ativo: Web-Server-Prod, Database-Prod, Desktop, OT-NonIntrusive. Para Web-Server-Prod: porta 80/443 + autenticação via HTTP(S) + scripts crawling limitados. Para Database-Prod: autenticação com credenciais read-only, evite checks que executam DDL/DML.
| Perfil | Port List | Credenciais | Configuração NVT |
|---|---|---|---|
| Web-Server-Prod | 80,443,8080 | HTTP auth read-only | crawl limit 50 URLs, disable intrusive NVTs |
| Database-Prod | 1433,1521,3306 | DB read-only creds | no intrusive queries, timeout 60s |
| Desktop | common ports | no creds | inventory + host discovery only |
| OT-NonIntrusive | port list OT specific | engineering creds – read-only | disable write operations, extended timeouts |
Comandos e validação de tuning
Ver logs de execução para identificar NVTs que causam delay ou falha:
1 | sudo tail -f /var/log/gvm/tasks.log |
Ajuste thread count no ospd config:
1 | sudo vim /etc/ospd/ospd.conf # worker_pool=4 |
Para limitar testes, edite port list no gvmd e atribua ao task.
Automação com CI/CD
Integre varredura de imagens e infraestrutura como código no pipeline: crie jobs OPA que chamam gvmd via API quando um PR altera infra. Exemplo simples com curl:
1 | curl -X POST -H "Authorization: Bearer $GVM_API_TOKEN" -d '{"scan_config":"Dev-Imagens","target":"10.1.0.0/24"}' https://gvm.example.com/api/scan |
Valide que pipelines rodem em contas de teste com IAM limitado e que tokens sejam rotacionados automaticamente.
1 2 3 | CI/CD integration [Repo] -> [CI Pipeline] --on image build--> [GVM API] --> [Scan task created] [Pipeline] -> waits for report -> fails build if high severity vuln found |
Hardening, Controles e Melhores Práticas
Isolamento e defesa em profundidade
Coloque scanners em VLANs dedicadas com regras de egress limitadas. Use TLS mutual authentication entre gvmd e scanners, e IPSec ou VPN onde aplicável. Não armazene credenciais de produção em plain-text; use um secrets manager e audite cada acesso.
Matriz de controles – credenciais, logging e acesso
| Controle | Descrição | Métrica/KPI |
|---|---|---|
| Gestão de Credenciais | Armazenar em Vault com rotação automática | Rotação 90 dias, acesso just-in-time |
| Segurança de Scanner | Isolamento VLAN, mínimo privilégio | 0 acessos externos não autorizados |
| Registro e Retenção | Logs para SIEM com integridade | Retenção 1 ano, alertas de alteração |
| Segregação de Perfis | Scan configs por criticidade | Percentual ativos com perfil correto >95% |
Hardening de software GVM/OpenVAS
Atualize feeds e software regularmente; aplique patches do projeto Greenbone e monitor CVEs relacionados ao scanner. Remova plugins NVT obsoletos que geram tráfego indesejado. Habilite auditoria detalhada do gvmd e restrinja APIs via firewall e tokens com scope mínimo.
1 2 | Hardening checklist flow [Update feeds] -> [Patch manager] -> [Audit config] -> [Rotate creds] -> [Restrict access] |
Marque NVTs intrusivos como “disabled” em produção e mantenha um conjunto ativado apenas em ambientes de teste controlados.
Segmentação e Purdue para OT
Para ambientes ICS, aplique varredura passiva quando possível e, se for necessário executar scans ativos, coordene janela de manutenção, reduza parallelism ao mínimo, e mantenha um rollback em caso de falha. Documente cada teste com um playbook específico para OT contendo contats e rollback steps.
Playbooks Operacionais para Blue Team e Red Team
Playbook Blue Team – triagem e remediação rápida
- Receber alerta de novo scan/relatório
- Correlacionar host com CMDB e service owner
- Validar false positive inicial usando scan autenticado com credenciais de leitura
- Priorizar vulnerabilidades com CVSS >=7 e evidência de exploitabilidade
- Gerar ticket e aplicar mitigação temporária (firewall rule)
- Planejar patch/remediate com janela e rollback
- Registrar lições e atualizar listas de exclusão/escopo
Playbook Red Team – usar OpenVAS para validação controlada
- Definir objetivo e autorização clara com duração e escopo
- Configurar scan com port lists reduzidas e credenciais de teste
- Executar scans durante janela definida e monitorada
- Validar que varredura não cause impacto (testes em sandbox primeiro)
- Documentar poC para vulnerabilidades encontradas
- Entregar relatório com evidências e recomendações medidas
Playbook resumido – resposta a incidente causado por scanner
Playbook resumido: isolar scanner na rede, revogar credenciais expostas, analisar logs para atividades não autorizadas, restaurar configuração a partir de backup, notificar stakeholders e realizar sweep de integridade.
1 2 3 4 | [ Detectar ] --> [ Contornar / Contenção ] ^ | | v [ Lições ] <------- [ Recuperar + validar ] |
Métricas, KPIs e Auditoria Técnica
Métricas operacionais para governança
| KPI | Definição | Meta recomendada |
|---|---|---|
| Coverage autenticada | % de ativos críticos escaneados com credenciais | >70% |
| False positive rate | % de alertas que não são vulnerabilidades reais após validação | <20% |
| Scan-induced incidents | número de incidentes causados por scans / 1000 scans | <0.1 |
| Time to triage | Tempo médio para triagem inicial de novo alerta | <24h |
Auditoria técnica e evidência
Recolha: comandos usados, configuração de scan, versão de NVTs, output raw em XML/JSON, checksum do report, logs OS e rede, e evidências de autorização. Armazene em repositório WORM ou SIEM com cadeia de custódia para auditorias e compliance.
1 2 3 4 | [ Coleta ] -> [ Indicador ] -> [ Limiar/alerta ] ^ | | v [ Melhoria ] <-------------- [ Ação / ticket ] |
Sem evidência rastreável, relatórios de varredura perdem valor legal e operacional. Automatize snapshots do relatório original e certifique-se de que um hash esteja disponível.
Erros Comuns, Armadilhas e Correções
Erro 1: Escopo demasiado amplo
Varredura em /16 sem filtros causa ruído massivo e maior risco de impacto. Correção: subdividir escopo em subnets e aplicar perfis específicos por classe de ativo.
1 2 3 4 | [ Anti-padrão ] --> [ Sintoma ] --> [ Correção ] | v [ Evidência / regressão ] |
Erro 2: Falta de autenticação nas varreduras críticas
Resultado: muitos falsos positivos e baixa confiança nos resultados. Correção: provisionar credenciais read-only e usar scripts de sanity check para evitar operações destrutivas.
Erro 3: Não testar NVTs em laboratório
Muitos NVTs podem ser intrusivos. Teste NVTs em clone de ambiente antes de habilitar em produção e mantenha lista de NVTs aprovados.
Rollback da política
Implemente rollback seguro: snapshot do host (VM) ou backup de configuração antes de execução de scans intrusivos; em OT, plano de contingência com engenharia disponível é obrigatório.
FAQ Técnico para Busca Orgânica
O que é OpenVAS e como ele se relaciona com GVM?
OpenVAS refere-se ao mecanismo de scanner; GVM (Greenbone Vulnerability Management) engloba o conjunto: gvmd (manager), ospd-openvas (daemon), e a UI. Em deploys, você interage com gvmd para criar tasks e com openvas-scanner para execução.
Como reduzir falsos positivos no OpenVAS?
Use autenticação, limite NVTs intrusivos, utilize port lists específicas, ajuste timeouts e valide resultados com verificações manuais ou scripts de verificação autenticados.
Posso rodar scans em ambientes OT?
Sim, mas com extrema cautela: priorize passivo, crie scanner OT separado, use janelas autorizadas e coordene com engenharia; execute apenas NVTs marcados non-intrusive e sempre faça testes em ambiente de homologação.
Qual a diferença entre scanning autenticado e não autenticado?
Autenticado usa credenciais para verificar configurações internas e reduzir falsos positivos. Não autenticado depende de serviços expostos, sendo útil para mapeamento inicial e descoberta externa.
Como integrar outputs do OpenVAS ao SIEM?
Exportar relatórios em formatos JSON/XML e usar parsers para normalizar campos: host, port, vuln id, CVSS, descrição. Configure ingest pipelines no SIEM para enriquecer com CMDB e tags de criticidade.
Quais parâmetros ajustar para reduzir impacto na rede?
Diminuir parallel hosts, reduzir threads por host, aumentar timeouts, limitar portas, e escalonar scans fora de janelas de pico. Cada ajuste reduz consumo de banda e risco de efeito cascata.
Como gerir credenciais de varredura com segurança?
Use um secrets manager com controle de acesso baseado em função, logs de acesso e rotação automática. Evite armazenar em arquivos de configuração ou variáveis de ambiente sem proteção.
Quais são os indicadores de que um NVT é problemático?
Logs com longos tempos de execução, falhas repetidas no mesmo host, ou relatos de impacto operacional após execução. Isolar NVTs que apresentam esses sinais e marcar para revisão.
Como priorizar vulnerabilidades encontradas pelo OpenVAS?
Use combinação de CVSS, evidência de exploit, criticidade do ativo (CMDB) e exposição pública. Crie regras no SIEM para priorizar remediação automática ou tickets de alta prioridade.
Existe integração nativa com ferramentas de ticketing?
GVM tem API que pode ser usada para integrar com Jira, ServiceNow ou ferramentas internas via scripts; prefira integrações idempotentes que atualizam estado do ticket com mudanças de scan.
Como lidar com NVTs desatualizados?
Mantenha feeds atualizados com greenbone-nvt-sync, audite a idade dos NVTs e desative NVTs que não são relevantes ou que tenham histórico de falhas.
Preciso de autorização formal para scans de vulnerabilidade?
Sim. Autorizações formais reduzem risco legal e operacional. Documente escopo, datas, responsáveis e contatos de emergência antes de iniciar qualquer varredura.
Considerações Finais
OpenVAS/GVM é flexível e escalável, mas a diferença entre um scanner útil e um gerador de ruído está no tuning. Combine arquiteturas distribuídas, controles de credenciais, políticas de scan por perfil e integração com SOC para transformar scans em inteligência acionável. O objetivo prático: reduzir false positives, evitar impacto operacional e acelerar remediação. Em 2026, com superfícies crescendo, varredura bem calibrada passou de prática recomendável a requisito de governança.
Próximo passo: execute este checklist de 10 itens no seu ambiente piloto em 30 dias e envie os resultados para avaliação da nossa newsletter técnica da União Geek.
Recursos Visuais Sugeridos
Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.
- MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
- CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
- NIST Cybersecurity Framework – figuras oficiais e referências de controles.
- ENISA – relatórios anuais com gráficos e mapas de ameaça.
- Kali Linux – documentação oficial com fluxos práticos.
- Parrot Security – documentação oficial com arquitetura modular.
Referências
- Greenbone Community Edition Documentation, Greenbone Networks, 2026, https://www.greenbone.net
- GVM – Greenbone Vulnerability Management, GitHub, 2026, https://github.com/greenbone/gvm
- OpenVAS – Open Vulnerability Assessment Scanner, openvas.org, 2026, https://www.openvas.org
- NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, NIST, 2008, https://csrc.nist.gov/publications/detail/sp/800-115
- MITRE ATT&CK, MITRE, 2026, https://attack.mitre.org
- CISA – Guidance on Vulnerability Disclosure and Scanning, CISA, 2025, https://www.cisa.gov
- ENISA Threat Landscape 2026 Summary, ENISA, 2026, https://www.enisa.europa.eu/publications
- HashiCorp Vault – Secret Management Best Practices, HashiCorp, 2025, https://www.vaultproject.io
- Tenable – Vulnerability Scanning Operational Guidance, Tenable, 2025, https://www.tenable.com/blog
- OWASP – Application Security Verification Standard, OWASP, 2025, https://owasp.org
- ISO/IEC 27001 – Information Security Management, ISO, 2022, https://www.iso.org
- Rapid7 – Best Practices for Vulnerability Scanning at Scale, Rapid7, 2026, https://www.rapid7.com/blog
- CVSS v3.1 Specification, FIRST, 2019, https://www.first.org/cvss
- Paper: “Operational Risks of Network Scanners in ICS”, SANS Institute, 2025, https://www.sans.org/white-papers
