Suricata virou o motor de detecção de rede padrão em muitos times de segurança, mas a implantação costuma falhar por excesso, não por falta: o sensor liga com o conjunto de regras completo, dispara alertas além da capacidade de triagem e a equipe aprende a ignorar o painel. Quem responde por detecção na borda, em segmentos internos ou no tráfego de saída precisa calibrar o volume de alertas antes de expandir a cobertura. A ação prioritária é medir quais assinaturas geram mais disparos e contê-las com threshold e supressão no próprio sensor, sem desligar a detecção.
O sensor barulhento custa caro
Alerta que não gera decisão é custo puro: armazenamento de log, atenção do analista e desgaste da credibilidade do monitoramento. O ciclo saudável é o inverso do painel lotado: comece com poucas categorias de regra, meça o volume por sid (o identificador da assinatura), suprima o tráfego legítimo conhecido e só depois libere novas famílias. Cobertura e ruído são decisões de engenharia registradas em arquivo de configuração, não consequência do sorteio da regra pública. Duas alavancas resolvem a maior parte do problema: o controle de volume global por assinatura e o formato de saída dos eventos para o pipeline.
Antes de mexer em qualquer regra, estabeleça a linha de base: uma janela de observação com o sensor em produção, contando alertas por sid, por origem e por categoria. Sem esse número, toda discussão de tuning é opinião. Com ele, as dez assinaturas de maior volume costumam explicar a maior parte do ruído — e cada uma tem um tratamento adequado, que pode ser limitar, suprimir para um host específico ou desligar a categoria inteira por decisão documentada.
Threshold: limite antes do alerta
A documentação oficial do projeto separa o threshold escrito dentro da regra pelo autor da assinatura do ajuste feito pelo operador no sensor: o arquivo threshold.config centraliza o controle de volume sem editar a regra original. A sintaxe aceita três comportamentos e o rastreio por endereço de origem, de destino, pelo par de IPs, pelo fluxo ou pela regra inteira, o que permite declarar que uma assinatura só vale alerta depois de um número de ocorrências dentro de uma janela de segundos, contadas por origem.
Um erro comum é confundir os três tipos de comportamento. A tabela resume o efeito de cada um no painel:
| Tipo | Efeito no alerta | Uso típico |
|---|---|---|
| threshold | Alerta apenas quando a contagem é atingida dentro da janela | Sinalizar comportamento repetido, como envio de e-mails em rajada por um host |
| limit | Alerta nas primeiras ocorrências e silencia o restante na janela | Manter uma ocorrência por host por período para varreduras internas autorizadas |
| both | Combina limite e disparo por contagem na mesma assinatura | Assinaturas de política que precisam de amostra do comportamento, não do evento inteiro |
O exemplo da própria documentação mostra o papel do rate_filter na escalada de ação: uma regra que alerta pacotes SYN para o servidor SSH combinada com um filtro que passa a derrubar o tráfego quando a mesma origem acumula dez tentativas em sessenta segundos, com timeout de trezentos segundos. Em modo IPS, isso converte um alerta informativo em contenção automática contra força bruta. A decisão exige revisão: derrubar tráfego legítimo que sai por NAT compartilhado gera incidente próprio, e o plano de reversão do filtro deve existir antes da primeira queda.
Supressão cirúrgica por host
O comando suppress resolve o caso mais comum de ruído: a assinatura correta apontando para um host legítimo. É possível suprimir uma assinatura para um IP, para uma rede ou para uma variável como $HOME_NET, mantendo o alerta ativo para todo o restante do ambiente. A documentação destaca um detalhe que quebra pipelines: suprimir a assinatura inteira a converte em sem alerta, mas efeitos colaterais da regra, como acionar flowbits, continuam acontecendo. Quem assume que a regra morreu junto com o alerta descobre o erro na primeira investigação.
Supressão é documentação viva: cada linha deve carregar comentário com motivo, responsável e data de revisão. Sem isso, o arquivo vira cemitério de exceções que ninguém audita e a cobertura real do sensor fica desconhecida — o sensor aparece saudável no painel e cego na prática.
EVE JSON como fonte de log
Para o pipeline de detecção, a saída EVE é a decisão estruturante: a saída EVE emite alertas, anomalias, metadados, arquivos e registros de protocolo em um único arquivo JSON, no formato que o SIEM consome sem parser intermediário. A mesma seção de configuração permite separar instâncias por propósito: alertas e quedas em um arquivo, registros de HTTP, DNS e TLS em outro, cada um com retenção e rota próprias. O campo community-id merece atenção: com a mesma semente em todos os sensores, ele permite casar registros do Suricata com a saída do Zeek e de outras ferramentas, unificando a linha do tempo durante a investigação.
A mesma documentação traz rotação por tempo, com janela configurável de minutos a semanas, o que elimina a dependência de ferramenta externa de corte para o arquivo de eventos e facilita a política de retenção diferenciada por tipo de registro.
Em caça a comando e controle, os registros de DNS e TLS do EVE são matéria-prima para identificar padrões de hospedagem dinâmica usada pelo crime, como os sucessores do fast flux já detalhados aqui no portal.
Regras abertas e cadência
O conjunto ET Open, distribuído pela Proofpoint, é a base gratuita mais adotada para começar: atualizada uma vez por dia em dias úteis, com atualizações fora de banda ocasionais, a coleção segue um ritmo de publicação que o time precisa incorporar ao processo. As instruções oficiais recomendam configurar o atualizador para baixar uma vez por dia e, quem quiser checar com mais frequência, consultar antes o arquivo de versão, que muda a cada publicação. O aviso é claro: excesso de requisições recebe resposta 429 e espera de trinta minutos. O gerenciador suricata-update é o caminho preferido, porque baixa, valida e habilita regras por categoria — o que permite liberar famílias de forma incremental em vez de ligar tudo de uma vez e repetir o painel lotado do primeiro dia.
O tráfego de saída revela mais
Deteção de rede costuma nascer olhando a entrada, mas exfiltração, beacon de comando e controle e atualização de malware aparecem na saída. O sensor no egress enxerga o que o perímetro de nuvem só controla com políticas dedicadas, leitura que complementa o controle de perímetro de dados no Google Cloud. Cruze os registros EVE com os logs de DNS interno: consultas repetidas a domínios recém-registrados são um dos sinais mais baratos de comprometimento que uma rede média consegue produzir.
Checklist de cobertura e ruído
- Medir o volume de alertas por sid durante uma janela definida antes de qualquer ajuste, como sugestão inicial de três dias completos de operação.
- Aplicar limit nas assinaturas que dominam o ranking antes de discutir qualquer compra de ferramenta.
- Registrar cada supressão com motivo, responsável e data de revisão periódica definida pela equipe.
- Separar instâncias EVE por tipo de evento: alertas e quedas em arquivo próprio; HTTP, DNS e TLS em outro, com retenções distintas.
- Habilitar community-id com a mesma semente em todos os sensores e ferramentas correlacionáveis.
- Atualizar as regras uma vez ao dia e verificar o arquivo de versão antes de baixar novamente.
- Todo rate_filter que muda a ação para drop precisa de plano de reversão e monitoramento de falsos positivos de contenção.
- Documentar as categorias de regra desligadas e o motivo, para que a cobertura real seja conhecida.
Prioridades de operação
P1 — antes de liberar regras novas: estabelecer o ranking de sids, aplicar limit nas assinaturas dominantes, suprimir hosts legítimos com registro formal e revisar o efeito no ciclo seguinte de operação. P2 — na sequência: separar as instâncias EVE por tipo de evento, habilitar community-id entre sensores, levar DNS e TLS ao SIEM e só então ampliar categorias de regra de forma gradual, com critério de reversão definido. Sensor calibrado não é o que mais alerta: é o cujo alerta ainda vale decisão.